From nobody Thu Jun 2 06:38:27 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 D74B812D6FB for ; Thu, 2 Jun 2016 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rp_Qv3wl7mh for ; Thu, 2 Jun 2016 06:38:24 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E53212D137 for ; Thu, 2 Jun 2016 06:38:24 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id z87so70142386wmh.0 for ; Thu, 02 Jun 2016 06:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ckxc+AUPIzT6EvJHy+VF2oZ3V+Ksa2n3Q3AG76Asvk8=; b=lI7wd0ZJeb5n20C0p7sm8ewzRi9H8JdOuBJ+mDx7ZRBVFFZ5BgjXFwZZby0eHU1DID UFvi0FYCdp0zIEFemtcS8BBoToHfCBVXK1DPM/PePEEUfOCtR1bglaq0MLdOHue7BcyZ GK9fsoa17SZGDKd8b+w6hbFqIQ6cqJMRTtI6TjuUy5hMnUGZgCofol8WyMHmQ3zfyQpF IjiN5dnM4DjcPFYIVpUSVbKLHLAapl2I/0+xVJKKZgRoLRN0Ucorh5a9TVdarfWlYpmb IVFsZeyuz5MFVXMb8vP76DcDk9jRdEHCnKgv5pqlUvpDCVR/p3b1AOTvyla0uq0Z6ykD qB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ckxc+AUPIzT6EvJHy+VF2oZ3V+Ksa2n3Q3AG76Asvk8=; b=Ri0rpaJy6M7dKW1el6nJOP6UocxpLDRQRRE99XewhUorvn/uAluz5TUYgcfTzORZeB ucMbtDwgsOdFly+fwXECTf3yuW+ugTPqlCUfCrXDAEcpdym//gU6MnNfpx+hFdiZZYMa a5zA/N9NXRlEl4ohoCxNEX+g9vBV+4pSCVId4wK9WQRcgZotKRZRlIkndMqRHXWLzJ/k LymFWACCZBMHH5aZbSSNH8SFSIWyOHvnFJKLZT/v0e2YGRc2GNEkjL51R/2dU2w4svV2 7J8m7TBR3QUc/sFgAucTEZMK5WVOz95+GT8ia52ZFhLsfqGI2AEK58PRBf+IvvhSHPZa ZofA== X-Gm-Message-State: ALyK8tI4sPOMNlm3wPgfMVrAuKyKH3O+qqqpnt12r1eC2VmP+CobNiLMRBmTXlqZErlsOXDtRPLwZryInQDnOw== X-Received: by 10.194.134.67 with SMTP id pi3mr8646065wjb.148.1464874702432; Thu, 02 Jun 2016 06:38:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.12 with HTTP; Thu, 2 Jun 2016 06:38:02 -0700 (PDT) From: Julien Vermillard Date: Thu, 2 Jun 2016 15:38:02 +0200 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary=089e01228ca447797505344bb89c Archived-At: Subject: [Ace] Constrained Environment PKI enrollment 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, 02 Jun 2016 13:38:26 -0000 --089e01228ca447797505344bb89c Content-Type: text/plain; charset=UTF-8 Hi, In industrial or enterprise M2M/IoT application we often use PSK for authentication, but more and more user want to enroll the device on their public key infrastructure like they does with some routers using SCEP/CMP. I wonder if it was explored to enroll devices, and renew certificates on PKI only using CoAP and not HTTP? -- Julien Vermillard --089e01228ca447797505344bb89c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
In industrial or enterprise M2= M/IoT application we often use PSK for authentication, but more and more us= er want to enroll the device on their public key infrastructure like they d= oes with some routers using SCEP/CMP.

I wonder if it was explo= red to enroll devices, and renew certificates on PKI only using CoAP and no= t HTTP?

--=
Julien Vermillard
--089e01228ca447797505344bb89c-- From nobody Thu Jun 2 07:31:07 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 130D512D73F for ; Thu, 2 Jun 2016 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 vxLk7-h8XNoK for ; Thu, 2 Jun 2016 07:30:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8CD12D73A for ; Thu, 2 Jun 2016 07:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4594; q=dns/txt; s=iport; t=1464877848; x=1466087448; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=68XSm4PLpIl2PcmQZeGjRpz+snEi37Xipi8ODP5W+/M=; b=kPt7mjRRn9qnBZCM9qhQSXgmpvfAeHczW23UcbkDEnaYg/VxTSd5uf2o Gg5KBuWe15OP4qnW/wpBoYymSd73tTxIZO055QHfdS0gBE+9GRDiYFX/A wJaqFOmryGGR7gHqQRSJI2YHK3a2dudxu7JBpCV1MoF3yGj4NdDqc5fee w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAQQlBX/5ldJa1dgzpWK1K1NYR5g?= =?us-ascii?q?XkXAQqFcAKBLzgUAQEBAQEBAWUnhEYBAQQBAQEgSxsLBAoKKgICJzAGAQwGAgE?= =?us-ascii?q?BiCsOsFmRLQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgeglaHQYJZAQSYN4Mrg?= =?us-ascii?q?WiJDYlBhVuPTB42hAogMop8AQEB?= X-IronPort-AV: E=Sophos;i="5.26,406,1459814400"; d="asc'?scan'208,217";a="110833067" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 14:30:47 +0000 Received: from [10.86.246.114] ([10.86.246.114]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u52EUk0q019237; Thu, 2 Jun 2016 14:30:46 GMT To: Julien Vermillard , ace@ietf.org References: From: Eliot Lear Message-ID: <602e9035-ee12-3a80-9b20-63f869c4391c@cisco.com> Date: Thu, 2 Jun 2016 10:30:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uPsB3kU99eopWSDdTOqdlWLkANOjxaSvL" Archived-At: Subject: Re: [Ace] Constrained Environment PKI enrollment 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, 02 Jun 2016 14:30:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uPsB3kU99eopWSDdTOqdlWLkANOjxaSvL Content-Type: multipart/mixed; boundary="uUvcMRJoNwaMVvp5xfSITxgiIxIqwbgNR" From: Eliot Lear To: Julien Vermillard , ace@ietf.org Message-ID: <602e9035-ee12-3a80-9b20-63f869c4391c@cisco.com> Subject: Re: [Ace] Constrained Environment PKI enrollment References: In-Reply-To: --uUvcMRJoNwaMVvp5xfSITxgiIxIqwbgNR Content-Type: multipart/alternative; boundary="------------1F129B78B1C9E43D7D2C549F" This is a multi-part message in MIME format. --------------1F129B78B1C9E43D7D2C549F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt? Eliot On 6/2/16 9:38 AM, Julien Vermillard wrote: > Hi, > In industrial or enterprise M2M/IoT application we often use PSK for > authentication, but more and more user want to enroll the device on > their public key infrastructure like they does with some routers using > SCEP/CMP. > > I wonder if it was explored to enroll devices, and renew certificates > on PKI only using CoAP and not HTTP? > > -- > Julien Vermillard > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------1F129B78B1C9E43D7D2C549F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt?

Eliot



On 6/2/16 9:38 AM, Julien Vermillard wrote:
Hi,
In industrial or enterprise M2M/IoT application we often use PSK for authentication, but more and more user want to enroll the device on their public key infrastructure like they does with some routers using SCEP/CMP.

I wonder if it was explored to enroll devices, and renew certificates on PKI only using CoAP and not HTTP?

--
Julien Vermillard


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

--------------1F129B78B1C9E43D7D2C549F-- --uUvcMRJoNwaMVvp5xfSITxgiIxIqwbgNR-- --uPsB3kU99eopWSDdTOqdlWLkANOjxaSvL 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 iQEcBAEBCAAGBQJXUEMWAAoJEIe2a0bZ0nozKkAIAJqDJ0DUbwPGRpmg7nPGXlsb H6dTEC64WEBw8YoOwvBZiX+qY++SpM0NvMqs4nLgr/pNdIsw80mMQopHIllNwfxK nUSyUfCeMtPNGTQdgwPJg3zk5d6PCKUKBIO20znAUIpCNXqs6Q5ZwZ9V5XjIc5gL w+KInXW7msLixWOdus7N9qS1qS8rMrsjP7P6jRs4NzzLkLVZiEsCzXNrYJQJwc+b tuhQSfOqPAyimOnSgvZy7wcllZZmytlNL4ZbRapvA3pec9FQXMB9eABWtIYwJgdn QzSCey9/V2qWapy63FBGam8VQ0AQ4Mpm7I7VvGoY4HgMgNbtTn1o1BAlr+9qfb4= =Bzoo -----END PGP SIGNATURE----- --uPsB3kU99eopWSDdTOqdlWLkANOjxaSvL-- From nobody Thu Jun 2 08:36:44 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 9D6DC12D550 for ; Thu, 2 Jun 2016 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYP3BVFqgv6J for ; Thu, 2 Jun 2016 08:36:40 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1FE12D1E4 for ; Thu, 2 Jun 2016 08:36:40 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n184so85959625wmn.1 for ; Thu, 02 Jun 2016 08:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VzsT7gN07+tDbMUe8WvQgkmRUDW8Rz5NGrH3n2jL2w0=; b=hoD26B4cHhcc+v94xn0/mFRWFkaWEqq6i68lAcpF24YMXEeRs5IaY9X6d1GJOKD00d kQW54J08JTMdoZirKzflelyq+xbDfksNLuhTG+YKEFscQPeJvv7fZWRhEfENzyqPWpIR C8Ffkt+7QjXCtoIy3y8mIL0IG10qAMiyj9U2lJMYfyhxFQ4A+yepjqQD295QBmHs1PFQ TxeJ8YBEWcMO1lORJ14bU53l6oiDW/5PIYG5zRyC3ZtK5cwOBtZDFQ1c5vnlxNQ4Pjk/ QtEnPXB6S7YcLOxGiwzch6CaDkSuCeqdnS5r9dIgWP16y3eKHLIuiEYtRDhpydPDgbaw pcQQ== 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=VzsT7gN07+tDbMUe8WvQgkmRUDW8Rz5NGrH3n2jL2w0=; b=IphJUMUWa0wGmX8CgsWzWacml00gj9otr2YgE7uZVYaUBjvr5lbJAnXnHwpZp4Pn8l 7yRY1Fw08q4EZVAfhjyF5uGC7mGC3SE/aGIgpf+NS2n0Cy9jIt2uFLczaZ9NEeyncZG5 axXhrImqjvZY7gr3KBmkkS3S0xQD8IORKytntxLNjz7dD6kWNMTzYiGNUL1ZRuCjdR41 c7eZNBQWeQbEE3FPTqOy6JKv66NdjMpf+vof2KGpyl0F6sikTIcIzpfqe+NjMSdw7dG7 gNmuaSu1xlbNoanR9ANYrBZ7zfaxMOrflFVcaFtVf2ZNwtKV/VEuvDHa+74oif6zYWQH afZw== X-Gm-Message-State: ALyK8tIVWjpoOR02qlAbbs34AmrFD7MAsh6hdIpyUbA43QYJI0pVGDomQRonIDAPJCRFbzQtFSxpkdwhcyVX6g== X-Received: by 10.28.168.86 with SMTP id r83mr9804030wme.9.1464881798942; Thu, 02 Jun 2016 08:36:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.12 with HTTP; Thu, 2 Jun 2016 08:36:19 -0700 (PDT) In-Reply-To: <602e9035-ee12-3a80-9b20-63f869c4391c@cisco.com> References: <602e9035-ee12-3a80-9b20-63f869c4391c@cisco.com> From: Julien Vermillard Date: Thu, 2 Jun 2016 17:36:19 +0200 Message-ID: To: Eliot Lear Content-Type: multipart/alternative; boundary=001a114c08f443957705344d5f62 Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Constrained Environment PKI enrollment 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, 02 Jun 2016 15:36:42 -0000 --001a114c08f443957705344d5f62 Content-Type: text/plain; charset=UTF-8 Thanks Eliot, I'll take a look. -- Julien Vermillard On Thu, Jun 2, 2016 at 4:30 PM, Eliot Lear wrote: > Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt? > > Eliot > > > > On 6/2/16 9:38 AM, Julien Vermillard wrote: > > Hi, > In industrial or enterprise M2M/IoT application we often use PSK for > authentication, but more and more user want to enroll the device on their > public key infrastructure like they does with some routers using SCEP/CMP. > > I wonder if it was explored to enroll devices, and renew certificates on > PKI only using CoAP and not HTTP? > > -- > Julien Vermillard > > > _______________________________________________ > Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace > > > --001a114c08f443957705344d5f62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Eliot, I'll take a look.

--
Julien Vermillard

On Thu, Jun 2, 2016 at 4:30 PM, Eliot Lear <= span dir=3D"ltr"><le= ar@cisco.com> wrote:
=20 =20 =20

Have you seen draft-ietf-anima-bootstrapping-keyinfra-02.txt?

Eliot



On 6/2/16 9:38 AM, Julien Vermillard wrote:
=20
Hi,
In industrial or enterprise M2M/IoT application we often use PSK for authentication, but more and more user want to enroll the device on their public key infrastructure like they does with some routers using SCEP/CMP.

I wonder if it was explored to enroll devices, and renew certificates on PKI only using CoAP and not HTTP?

--
Julien Vermillard


_______________________________________________
Ace mailing list
Ace@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/ace


--001a114c08f443957705344d5f62-- From nobody Fri Jun 3 08:08: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 7504A12D6D4 for ; Fri, 3 Jun 2016 08:08:16 -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 xNX4z941bwco for ; Fri, 3 Jun 2016 08:08:14 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2993512D6CD for ; Fri, 3 Jun 2016 08:08:14 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a136so463353wme.0 for ; Fri, 03 Jun 2016 08:08:14 -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:date:message-id:subject:from:to :cc; bh=c9MlxpQ1Oizp7RlzA+iwlZkslHy1UbQzJMbCtDqHiic=; b=ify0AfBFs/hBohvl8vDKGyufw3atGtJZvhlEes2Z0Q2SmKyrMkunx/w3AWg92aDNLO wABCny4WkHSDQ8+boQws8S/Rdkdiot70Wwiemin2SSSyc+Po1uhm0j+ybQGSjuia7D5f YPTgHdNti4m6Xu5/8zuahB4L3lvLvEJA6uLXzsU5ablPTKAvo63lSsw6VCz4X+KmPvqX szNost/T1Am1EpQGmbWIrs1/VsowjVOTH1L5ulz4qE4UVzgEGYCKb9afzKaeC4sR3BXT SWFsqwwV7CyLoDeixqq5Na774n9yVsjaXUujqZJr26OGbsJYJ02aXEG4duhZ6TIt2FpR oxXA== 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:date :message-id:subject:from:to:cc; bh=c9MlxpQ1Oizp7RlzA+iwlZkslHy1UbQzJMbCtDqHiic=; b=ewNMLIOC2zDxivfhy3xqIyG6LbA/KFLpK5LlR4lDE9J3kELOfjWK/Cvkk7NkgMw8Op bWP2IBLPW8g6dSl67m3vxchgmU8Dds3HbPD7kxB9IQc0VklsdX0nh3Le2tzIYnhLA+Ad L1Mu0eVl8cqlGnqodvud7OaYxnTMphaWLvhuc9yHzFIGciEv4oBXH6ITkVGpBSdq+Qo2 m6Hrnc4VGsoIyNtKzhzhpOHzMMxnSHQz5Yv/OIqHGPvUWuU+rq5+6VMbiJr6n4vC3DS5 xYnA0/cnG4eeMQZk8fcQkXyxn7jDjH8Vr/NCPCkaRoaMtYOSPzDXvgDsjheAVvfZaaDk aaYQ== X-Gm-Message-State: ALyK8tJQ8jiI3tc7hKVdtV8zMLmg9OYL5D8jPwLGYcQJbowSoxTbsfuE/Zl2695QuR0Jg7MqiDC/MuCw2FGN9Q== MIME-Version: 1.0 X-Received: by 10.28.137.133 with SMTP id l127mr31601wmd.50.1464966492716; Fri, 03 Jun 2016 08:08:12 -0700 (PDT) Received: by 10.194.119.163 with HTTP; Fri, 3 Jun 2016 08:08:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Jun 2016 17:08:12 +0200 Message-ID: From: Samuel Erdtman To: Julien Vermillard Content-Type: multipart/alternative; boundary=001a1149793e6826210534611729 Archived-At: Cc: Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Fri, 03 Jun 2016 15:08:16 -0000 --001a1149793e6826210534611729 Content-Type: text/plain; charset=UTF-8 The company I previously worked for where looking into adopting EST for this purpose, the benefit of EST compared to cmp or scep was that it defined the process for server side generated keys, which could be beneficial if key generation would be to cumbersome for the device or if you don't trust the device to generate a "good" key. Maybe Shahid could give sold more updates since he was helping us with this project On Thursday, 2 June 2016, Julien Vermillard wrote: > Hi, > In industrial or enterprise M2M/IoT application we often use PSK for > authentication, but more and more user want to enroll the device on their > public key infrastructure like they does with some routers using SCEP/CMP. > > I wonder if it was explored to enroll devices, and renew certificates on > PKI only using CoAP and not HTTP? > > -- > Julien Vermillard > --001a1149793e6826210534611729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The company I previously worked for where looking into adopting EST for thi= s purpose, the benefit of EST compared to cmp or scep was that it defined t= he process for server side generated keys, which could be beneficial if key= generation would be to cumbersome for the device or if you don't trust= the device to generate a "good" key.

Maybe Sh= ahid could give sold more updates=C2=A0since he was helping us= with this project

On Thursday, 2 June 2016, Julien Vermillard <<= a href=3D"mailto:jvermillard@gmail.com">jvermillard@gmail.com> wrote= :
Hi,
=
In industrial or enterprise M2M/IoT application we often use PSK for = authentication, but more and more user want to enroll the device on their p= ublic key infrastructure like they does with some routers using SCEP/CMP.
I wonder if it was explored to enroll devices, and renew certif= icates on PKI only using CoAP and not HTTP?

--
Julien Vermillard
--001a1149793e6826210534611729-- From nobody Fri Jun 3 16:01:37 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 2F3CA12B01F for ; Fri, 3 Jun 2016 16:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 FW7XMBWe5L_3 for ; Fri, 3 Jun 2016 16:01:33 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305BE128B44 for ; Fri, 3 Jun 2016 16:01:33 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id s64so63344165lfe.0 for ; Fri, 03 Jun 2016 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=K+ZQObFdPteRUTicFYna1ZiQ9PAetrInHlb4Blupqs8=; b=EkHoh2f9Bc8JxA2YPsopxydAt04Mh/7ub0zPaB1LSe3Y4bxz53E1Pq/fsy2KV+BwsM vXshtUBywHtwt3OJLyHxBGa1mYTjiR8SPNU5yoHejTE49XjcBhA1sjSi0GlTy8mlwoyg Hc0/yXZdOYQ0skPNF2LhHr24UDtPV55a6Ir4xmGT59eNbkxWjLi/yoPVqtrrA+g+xjvP yZDb94Yy942KN0vN/YffzieYN+kF8G5Ke1E5rmP/Z+feyduvkgejRLUArM5MVODkxFek SRxBJY5zeWVDsGPNHszJ924bKS395ADzT/aTAwo0/fb0xa44DGybn+0BQA+fH59+ButC buMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=K+ZQObFdPteRUTicFYna1ZiQ9PAetrInHlb4Blupqs8=; b=EDA1g2Jbbr7dmGyPpVufTNV+Z67TTobVxx9AHyrtTGyjjwia5L/7OH2yJ9CLrRSGXg HSN1WOPQFNtFedKML1IRwZbUQaCrinIMJRITpINqMfwfdu0upDyLVP3U0eMcWGduk1tR vHzk9zGZyGNUSupAKsb+d+uGv4d3NLrEFMmUWhPCEu+ZJCNb2pYijklF1y00vkAkNWCE nhnZrCHUQsPl7nrxoOjk0QA7j2U3UqVUkUjUZYxsNM7u65lp07zRCwTkh2lrfGujrjT5 TBU+Cy9BCLLNIMO4oosPXWfI+fi4f9uZNCpaVOq2EGM5F7BOAn+TFouRVjYqlo3ldaXC fb0w== X-Gm-Message-State: ALyK8tKsWaFcpoHkA4onla/gRDqbbGGn5i4iRMRPv7wiPGmSyhjLcrOW/j+NP/VH0bbDl6Ld X-Received: by 10.25.18.167 with SMTP id 39mr1882922lfs.118.1464994891318; Fri, 03 Jun 2016 16:01:31 -0700 (PDT) Received: from [192.168.0.15] (c83-251-26-38.bredband.comhem.se. [83.251.26.38]) by smtp.gmail.com with ESMTPSA id y124sm724659lfd.0.2016.06.03.16.01.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 16:01:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shahid Raza In-Reply-To: Date: Sat, 4 Jun 2016 01:01:29 +0200 Message-Id: <0EB38F45-003A-42DA-92F6-E166D9642010@sics.se> References: To: Samuel Erdtman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Fri, 03 Jun 2016 23:01:36 -0000 --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We (SICS and neXus) have been working on this since September last year = and designed and implemented an enrollment protocol over secure CoAP. = Both the specifications and the Contiki source code will be available = soon. This is done under the umbrella of a Swedish project called CEBOT: = Certificate Enrollment in Billions of Things. Regards, Shahid > On 03 Jun 2016, at 17:08, Samuel Erdtman wrote: >=20 > The company I previously worked for where looking into adopting EST = for this purpose, the benefit of EST compared to cmp or scep was that it = defined the process for server side generated keys, which could be = beneficial if key generation would be to cumbersome for the device or if = you don't trust the device to generate a "good" key. >=20 > Maybe Shahid could give sold more updates since he was helping us with = this project >=20 > On Thursday, 2 June 2016, Julien Vermillard > wrote: > Hi, > In industrial or enterprise M2M/IoT application we often use PSK for = authentication, but more and more user want to enroll the device on = their public key infrastructure like they does with some routers using = SCEP/CMP. >=20 > I wonder if it was explored to enroll devices, and renew certificates = on PKI only using CoAP and not HTTP? >=20 > -- > Julien Vermillard > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We (SICS and neXus) have been working on this since September = last year and designed and implemented an enrollment protocol over = secure CoAP. Both the specifications and the Contiki source code will be = available soon. This is done under the umbrella of a Swedish project = called CEBOT: Certificate Enrollment in Billions of Things.

Regards,
Shahid

On = 03 Jun 2016, at 17:08, Samuel Erdtman <samuel@erdtman.se> = wrote:

The = company I previously worked for where looking into adopting EST for this = purpose, the benefit of EST compared to cmp or scep was that it defined = the process for server side generated keys, which could be beneficial if = key generation would be to cumbersome for the device or if you don't = trust the device to generate a "good" key.

Maybe Shahid could give sold more = updates since he was helping us with this = project

On Thursday, 2 June 2016, Julien = Vermillard <jvermillard@gmail.com> wrote:
Hi,
In industrial or = enterprise M2M/IoT application we often use PSK for authentication, but = more and more user want to enroll the device on their public key = infrastructure like they does with some routers using SCEP/CMP.

I wonder if it was explored to enroll = devices, and renew certificates on PKI only using CoAP and not HTTP?

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

= --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD-- From nobody Mon Jun 6 06:19:04 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 3707712D79D for ; Mon, 6 Jun 2016 06:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLAiivOzb6CX for ; Mon, 6 Jun 2016 06:19:01 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8A112D797 for ; Mon, 6 Jun 2016 06:19:01 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id k204so26822638wmk.0 for ; Mon, 06 Jun 2016 06:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=souY+FKvUAoShWS5GlKPJ0oqV1hjBr5vQJhhF5eOFKA=; b=RzpMZ6LOf3tW+DrdK0dHhOyS0GREPCE9P2aYe8PA+dDXOUGysmaK9vR+wXF3CkUW5I D8Sk3gqPv+Cf9Ev02a4cI1n9ROr1Z6eGLH9iA4gZ1XSKi/1kVcSPZsWiEf6xJXuTX4ZW ukptowGGAKjiMZ+PPSriMKBruwvdotBNrtXY2RK4mEAssLqX7zlI09mAB4sidqNyEizv SxqO3lOws4FrwMd7JytGxt8aXsGueJIiOWrcWcp+5A5lzDo+khBTJcvMrd/+vO3f7+jq k8QCjJ6DVKh7qBhYA8Ki7iDEky+anCoeuDMbH2czxpdLWZtrW8gMEmvaswjYFFv93L9y nN8w== 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=souY+FKvUAoShWS5GlKPJ0oqV1hjBr5vQJhhF5eOFKA=; b=PyglV1jk/v1hqtY5+wMKXTP9D7uu5GEGXM5vu2lreppjqVZ9SXcVsvssVEGz0s3Q/G 70YSu+nLByTkDIxPTo7+rRa/qsRN/NtneRccRz2LYIsl4VC7hC9oE/+Cn61/jEnMC8Gv m6jjttm6YmMXeSTwkABiCJQ9QVgLCrHOt3b7G08vgJapQZkEfz8ZKYQarlT/yFXz+lHG TXD80IddGitGIicY6QxuwDFi1Ts1o2WSkvB0YGEGXu+VYVFcvGwKjproQ+NB+3dlz3V3 uT4j6Flxmlfwb/9yubYmkgA0J+7ZkLYk1+qIHtO39+WUrTGWEvFvKQVO8qj6OL0OE2pn 5iog== X-Gm-Message-State: ALyK8tKjpgz4K4cld+ChhJKkMWBhcY77HJnGNo2uMWKrnIDz7CKGy9Y+3hh2Tf7fHeNNMMsvYKlzCjDJk2uL/A== X-Received: by 10.194.169.37 with SMTP id ab5mr15536210wjc.141.1465219139939; Mon, 06 Jun 2016 06:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.12 with HTTP; Mon, 6 Jun 2016 06:18:40 -0700 (PDT) In-Reply-To: References: From: Julien Vermillard Date: Mon, 6 Jun 2016 15:18:40 +0200 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=089e012284c85ab75005349beaf0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 06 Jun 2016 13:19:03 -0000 --089e012284c85ab75005349beaf0 Content-Type: text/plain; charset=UTF-8 Hi Samuel, I wonder in which scenario a RNG is safe enough for running a DTLS stack but not good enough for generating a ECDSA key couple? -- Julien Vermillard On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman wrote: > The company I previously worked for where looking into adopting EST for > this purpose, the benefit of EST compared to cmp or scep was that it > defined the process for server side generated keys, which could be > beneficial if key generation would be to cumbersome for the device or if > you don't trust the device to generate a "good" key. > > Maybe Shahid could give sold more updates since he was helping us with > this project > > > On Thursday, 2 June 2016, Julien Vermillard wrote: > >> Hi, >> In industrial or enterprise M2M/IoT application we often use PSK for >> authentication, but more and more user want to enroll the device on their >> public key infrastructure like they does with some routers using SCEP/CMP. >> >> I wonder if it was explored to enroll devices, and renew certificates on >> PKI only using CoAP and not HTTP? >> >> -- >> Julien Vermillard >> > --089e012284c85ab75005349beaf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Samuel,
I wonder in which scenario a RNG = is safe enough for running a DTLS stack but not good enough for generating = a ECDSA key couple?

<= div>
--
Julien Vermillard

On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
The company I previously worked for where looking into adopting EST for= this purpose, the benefit of EST compared to cmp or scep was that it defin= ed the process for server side generated keys, which could be beneficial if= key generation would be to cumbersome for the device or if you don't t= rust the device to generate a "good" key.

Mayb= e Shahid could give sold more updates=C2=A0since he was helpin= g us with this project


On Thursday, 2 June 20= 16, Julien Vermillard <jvermillard@gmail.com> wrote:
Hi,
In industrial or enter= prise M2M/IoT application we often use PSK for authentication, but more and= more user want to enroll the device on their public key infrastructure lik= e they does with some routers using SCEP/CMP.

I wonder if it w= as explored to enroll devices, and renew certificates on PKI only using CoA= P and not HTTP?

--
Julien Vermill= ard

--089e012284c85ab75005349beaf0-- From nobody Mon Jun 6 07:30: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 831CB12D7C0 for ; Mon, 6 Jun 2016 07:30:15 -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 6ciJ6FZUNlX6 for ; Mon, 6 Jun 2016 07:30:13 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859C312B076 for ; Mon, 6 Jun 2016 07:30:13 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id c74so49089352wme.0 for ; Mon, 06 Jun 2016 07:30:13 -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=ZudjSNgOC8yN23ckOy2Db2ay/lIqxHn+o54+Qh9zaTs=; b=h53ORyDlkgsI5pF7WA3oq0dx6wwXJzGDtwSw+5rKh2V4pPhOavtuPGorXqmwTp2yAj hGb0XENiHWrVnWqBRW5jxo6MPVTosqYh/eWinoSX3KYRue3jLCzdxxgXD1kuj/OXu9kk Fk1qbDbdDGzNH0O45RYri1C58crVvstoDS0gOypdqQj74B8dSam/JAzq1hKzFOqyOx6g M5atwBcyaKGz5TcZWoJgm7emhy9O+Rt5lCF/7wu1RxsAHDueiJEyS11X1K1ap8EBJODB U0StsVNCEsyUPKciL8BMqyk+vfkEUJDlM66GLEvpjz4EU7D4rwKzoXyQPiZps7MxaJKS UnKA== 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=ZudjSNgOC8yN23ckOy2Db2ay/lIqxHn+o54+Qh9zaTs=; b=YeINkDcas8B+V3f8tY448lXbNcE4yZu9lqg8/P5uintOO5VYj4tpO96yT08Ii+NUUy Xpy6JcYWwmRnYnplH2nmvipfpiBMQ5jMrZY26OTU3g68D1XrZCXzW7+4SpD1PMwdrHnF f4RO/UnYjKDT3ijqNAGSzKVFFImJvQ+wvsmxhGiSAc8L8IsMAGX2dbtdjtIXKisyj5qM Sg5fjkgHRPxFyYFXQSL9O6njEXj/IrGQkWC/h32mVMUIUTcKLhXdv0u7KTUTiwPGOnCD 4JOFVanQC9JMb4Xcvz98vTtPJuaD/r5FczPL9NL9+rHZgqqVnZcL6nWXWOEAStGiZnkN eL0w== X-Gm-Message-State: ALyK8tKsrKUg51vo6JEi0TCbX8xr6XcIw9WnO0y5gRtU1roqwedG3/2fZ99vEKsXilnjpccUD0JqrTRW+8Biog== X-Received: by 10.194.203.226 with SMTP id kt2mr1667709wjc.75.1465223411460; Mon, 06 Jun 2016 07:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.119.163 with HTTP; Mon, 6 Jun 2016 07:30:10 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Mon, 6 Jun 2016 16:30:10 +0200 Message-ID: To: Julien Vermillard Content-Type: multipart/alternative; boundary=047d7bacc82af5065405349ce8cd Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 06 Jun 2016 14:30:15 -0000 --047d7bacc82af5065405349ce8cd Content-Type: text/plain; charset=UTF-8 Hi Julien, The first one that comes to mind would be where Pre-Shared-keys are used i.e. symmetric keys. These keys could be factory keys used only to setup the PKI-keys. If you look at EST the server generated keys is also recommended to be wrapped in an extra layer of encryption in addition to the transport layer security (DTLS/TLS). So if the transport layer security is not absolute no keys should be leaked. //Samuel On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard wrote: > Hi Samuel, > I wonder in which scenario a RNG is safe enough for running a DTLS stack > but not good enough for generating a ECDSA key couple? > > -- > Julien Vermillard > > On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman wrote: > >> The company I previously worked for where looking into adopting EST for >> this purpose, the benefit of EST compared to cmp or scep was that it >> defined the process for server side generated keys, which could be >> beneficial if key generation would be to cumbersome for the device or if >> you don't trust the device to generate a "good" key. >> >> Maybe Shahid could give sold more updates since he was helping us with >> this project >> >> >> On Thursday, 2 June 2016, Julien Vermillard >> wrote: >> >>> Hi, >>> In industrial or enterprise M2M/IoT application we often use PSK for >>> authentication, but more and more user want to enroll the device on their >>> public key infrastructure like they does with some routers using SCEP/CMP. >>> >>> I wonder if it was explored to enroll devices, and renew certificates on >>> PKI only using CoAP and not HTTP? >>> >>> -- >>> Julien Vermillard >>> >> > --047d7bacc82af5065405349ce8cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Julien,

The first one that comes= to mind would be where Pre-Shared-keys are used i.e. symmetric keys. These= keys could be factory keys used only to setup the PKI-keys.

<= div>If you look at EST the server generated keys is also recommended to be = wrapped in an extra layer of encryption in addition to the transport layer = security (DTLS/TLS). So if the transport layer security is not absolute no = keys should be leaked.

//Samuel




= On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard <jvermillard@gmail.c= om> wrote:
Hi Samuel,
I wonder in which scenario a RNG is safe enough f= or running a DTLS stack but not good enough for generating a ECDSA key coup= le?

--
Julien Vermillard

On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
The company I previously worked for where looking into adopting EST for= this purpose, the benefit of EST compared to cmp or scep was that it defin= ed the process for server side generated keys, which could be beneficial if= key generation would be to cumbersome for the device or if you don't t= rust the device to generate a "good" key.

Mayb= e Shahid could give sold more updates=C2=A0since he was helpin= g us with this project


On Thursday, 2 June 2016, Julien Ve= rmillard <jve= rmillard@gmail.com> wrote:
Hi,
In industrial or enterprise M2M/IoT a= pplication we often use PSK for authentication, but more and more user want= to enroll the device on their public key infrastructure like they does wit= h some routers using SCEP/CMP.

I wonder if it was explored to = enroll devices, and renew certificates on PKI only using CoAP and not HTTP?=

--
Julien Vermillard
=


--047d7bacc82af5065405349ce8cd-- From nobody Mon Jun 6 08:05:28 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 3C3BB12D7DA for ; Mon, 6 Jun 2016 08:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmozIYI5YdHW for ; Mon, 6 Jun 2016 08:05:24 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E1012D7D4 for ; Mon, 6 Jun 2016 08:05:23 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id c74so50692644wme.0 for ; Mon, 06 Jun 2016 08:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OD/dQCdEkdASYlVkvNAxxD/wQEOxZAqf4ijSZxqJoQc=; b=kHXI84/4F7IAUcADQtfEhUNPvU5oGAm0GqMSGw0jbfleQeRzF5Ok+6g8acBK7NrIwR QFMCFvSeFkaveb3x5hVDck3BdWblG0WC+dmryTdzfX12C+2H9bt1g27qwfxAR+9ZL7k3 C1w0MxWcC+TmfeaK2UbxGKOr/4ApERCSGcuZl3mCGfV4YtQsTD3rJgCIaYVEWzh5UzwZ 3BG0EeCRRmfLSsP4qy0iD86mhzOgOckhxzQcV/sl1jH/NEZumASZxxbiRsl5B9f17cK1 l6oU8m+fSRa/3HB3viZoZ/tlcMIrrr+E8jErvVPvMd4UPXNO804BoTI5HZNUcWZhI+a5 G9IQ== 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=OD/dQCdEkdASYlVkvNAxxD/wQEOxZAqf4ijSZxqJoQc=; b=ZimlSL+jidXCRlLXw1YNvOaZSoVgde3wt32kCOmJ2e67B8O5authy5LY4v5hcLE9Gx XC+nXtOwNpFPPjBbmGbdg3dRwNLS/0rcxtWhCjnA+Fq+uFa5UwggoYACfgfOMwy/0tKx LLBiDjKD+idKIZfUcdOiXX87TPGRoRAM+uo2GS6dePWtyuAr+EppVhF2s4gNRhFNZuK5 T71yjONyhY1fdDx2CVZmPk9Bl7XZnmKyF8v+TBbac18CkvhUrOri8t6Beqzj9CBkyUHP MNi61lSsjXkX171QlofGuhbDH+dYNDimJka/VO4vVyP1QduAOLy8Me0ak0z+k1oTfYgB KI2Q== X-Gm-Message-State: ALyK8tK+ZHBPpiqTfCgZ6R4PAXOnwgvumZD93or8MBhxn6tVgsX0KRyCxAAciQGqJpcNM5KItB3kGlGh3u+nAg== X-Received: by 10.28.7.208 with SMTP id 199mr12157512wmh.74.1465225522387; Mon, 06 Jun 2016 08:05:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.12 with HTTP; Mon, 6 Jun 2016 08:05:02 -0700 (PDT) In-Reply-To: References: From: Julien Vermillard Date: Mon, 6 Jun 2016 17:05:02 +0200 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a114447ccc71ff105349d6635 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 06 Jun 2016 15:05:26 -0000 --001a114447ccc71ff105349d6635 Content-Type: text/plain; charset=UTF-8 Yes, but since you need some random numbers for doing a TLS-PSK handshake (ClientHello random) why a TLS-PSK client should no be able to generate ECDSA keys? -- Julien Vermillard On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman wrote: > Hi Julien, > > The first one that comes to mind would be where Pre-Shared-keys are used > i.e. symmetric keys. These keys could be factory keys used only to setup > the PKI-keys. > > If you look at EST the server generated keys is also recommended to be > wrapped in an extra layer of encryption in addition to the transport layer > security (DTLS/TLS). So if the transport layer security is not absolute no > keys should be leaked. > > //Samuel > > > > > > On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard > wrote: > >> Hi Samuel, >> I wonder in which scenario a RNG is safe enough for running a DTLS stack >> but not good enough for generating a ECDSA key couple? >> >> -- >> Julien Vermillard >> >> On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman wrote: >> >>> The company I previously worked for where looking into adopting EST for >>> this purpose, the benefit of EST compared to cmp or scep was that it >>> defined the process for server side generated keys, which could be >>> beneficial if key generation would be to cumbersome for the device or if >>> you don't trust the device to generate a "good" key. >>> >>> Maybe Shahid could give sold more updates since he was helping us with >>> this project >>> >>> >>> On Thursday, 2 June 2016, Julien Vermillard >>> wrote: >>> >>>> Hi, >>>> In industrial or enterprise M2M/IoT application we often use PSK for >>>> authentication, but more and more user want to enroll the device on their >>>> public key infrastructure like they does with some routers using SCEP/CMP. >>>> >>>> I wonder if it was explored to enroll devices, and renew certificates >>>> on PKI only using CoAP and not HTTP? >>>> >>>> -- >>>> Julien Vermillard >>>> >>> >> > --001a114447ccc71ff105349d6635 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, but since you need some random numbers for doing a TL= S-PSK handshake (ClientHello random) why a TLS-PSK client should no be able= to generate ECDSA keys?

=
--
Julien Vermillard

On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
Hi Julien,

The first one that c= omes to mind would be where Pre-Shared-keys are used i.e. symmetric keys. T= hese keys could be factory keys used only to setup the PKI-keys.

If you look at EST the server generated keys is also recommended to= be wrapped in an extra layer of encryption in addition to the transport la= yer security (DTLS/TLS). So if the transport layer security is not absolute= no keys should be leaked.
<= br>
//Samuel





On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard <jv= ermillard@gmail.com> wrote:
Hi Samuel,
I wonder in which scenario a RNG= is safe enough for running a DTLS stack but not good enough for generating= a ECDSA key couple?

=
--
Ju= lien Vermillard

On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
The company I previously worked for where looking into adopting EST for= this purpose, the benefit of EST compared to cmp or scep was that it defin= ed the process for server side generated keys, which could be beneficial if= key generation would be to cumbersome for the device or if you don't t= rust the device to generate a "good" key.

Mayb= e Shahid could give sold more updates=C2=A0since he was helpin= g us with this project


On Thursday, 2 June 2016, Julien Ve= rmillard <jve= rmillard@gmail.com> wrote:
Hi,
In industrial or enterprise M2M/IoT a= pplication we often use PSK for authentication, but more and more user want= to enroll the device on their public key infrastructure like they does wit= h some routers using SCEP/CMP.

I wonder if it was explored to = enroll devices, and renew certificates on PKI only using CoAP and not HTTP?=

--
Julien Vermillard
=



--001a114447ccc71ff105349d6635-- From nobody Mon Jun 6 11:31: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 4A64012D528; Mon, 6 Jun 2016 11:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 AOS5qbpBEA_O; Mon, 6 Jun 2016 11:31:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4602112D0ED; Mon, 6 Jun 2016 11:31:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 098EF2015D; Mon, 6 Jun 2016 14:38:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18B7D638BF; Mon, 6 Jun 2016 14:31:05 -0400 (EDT) From: Michael Richardson To: Samuel Erdtman , anima-bootstrap@ietf.org, anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 06 Jun 2016 18:31:08 -0000 --=-=-= Content-Type: text/plain Samuel Erdtman wrote: > The company I previously worked for where looking into adopting EST for > this purpose, the benefit of EST compared to cmp or scep was that it > defined the process for server side generated keys, which could be > beneficial if key generation would be to cumbersome for the device or > if you don't trust the > device to generate a "good" key. Hi, these are definitely important considerations. I would invite you to read the ANIMA bootstrap keying documents, and possibly join the design team. At this point I believe the bootstrap is out of scope for ACE. We are considering whether to use OSCOAP for 6tisch though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1XBZoCLcPvd0N1lAQLTuQgAtuaOs6hVleoaAsZoicJbXplyQssSdPSf ALSBHxtzq4dqyYqw4v0SSQ0cT4H2KTNINbdLND3VBocqNU9XiqmZgmvlOkpbCwZ+ KyzlOBhuWh8f+S8cnZk4DboUbeXPAiR7NQP3ROZoTcHk75x5EYjpav4LK8qM0W3w oOaKdh0Q/Ui9sUqTAIxyplA72Nk15F4UBZxm83HlktQIlL6fTTFvRMNH8Y8xHyJq EHZbe/3erD+M2jGXUFNdO4gEYCZ7HG1YbLwHYN8sX6o/SWbKK5cnxE1d0rPXyYR2 MrY8O+3TA9vBIJj38lvU0FFiGIa40bGRhBgC3+u4OFs2pWGm1t/qPw== =iS1x -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 6 11:33:34 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 750B512D529 for ; Mon, 6 Jun 2016 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 IqUSYlqo8yGm for ; Mon, 6 Jun 2016 11:33:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2B512D528 for ; Mon, 6 Jun 2016 11:33:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AA29C2015D; Mon, 6 Jun 2016 14:40:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6887638BF; Mon, 6 Jun 2016 14:33:29 -0400 (EDT) From: Michael Richardson To: Julien Vermillard In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Samuel Erdtman , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 06 Jun 2016 18:33:32 -0000 --=-=-= Content-Type: text/plain Julien Vermillard wrote: > I wonder in which scenario a RNG is safe enough for running a DTLS > stack but > not good enough for generating a ECDSA key couple? Particularly since my understanding is that ECDSA signatures (like DSA ones) require good RNG. This attribute has also bugged me about DSA, and made me prefer RSA :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1XB9oCLcPvd0N1lAQLYzAf/bKvDOY+AIWAwzNlfDoxn4fSTh+fUIAHZ faCeMCqYoKMvoYPr5zN9sWsQGv6xftGAlfwpzZSCaAiMFCr2RQx/zofQ7LjA8V8G mjR1E+Pnw9lNsqkZEsDFT6IoNlNydN8NDSaTyqBH2/kPO6eWAs8wGupshOiUk0yM 90XCqrYcNd9AytmcCvINP1XlINEZgs2skrM+f1h1wAF4Al7WFrPzdoo9fUSwWFCO Psud2JAlyZUvzFVr4M7+jYdruo2EJXgaZM04GQLFo7UYzynErGzu+m9CGVQIBZwd h+J7KeYjE3SEVnJhJ5WgVRw15Jyq1R85+8q9ZeAOQh/G0h5ek6wBTw== =5Lk9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 6 21:58: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 A7DC712D1B9 for ; Mon, 6 Jun 2016 21:57:59 -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 lJvWG7SK5PUL for ; Mon, 6 Jun 2016 21:57:57 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1710112D0BB for ; Mon, 6 Jun 2016 21:57:56 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n184so119083943wmn.1 for ; Mon, 06 Jun 2016 21:57:56 -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=AYGjuh7+RUKpD3DmbGLob8kYQh6p9dumoRMqy7eEC00=; b=y532acUN9vkK2+jDB68smnkvA2qaj3MekyOKHcLSI8WFIJA5YULL3nvjqbB9PnKY34 DizevJeSzeVAvf7ehZSDwsEJLF7GnRcn+QyjX0gAvujW8Qyd6re34YdWeWeJ1oAQKaeB 4uMtFQi6czObLMd9zY50MT9h+EU0cjUmDyckOSIzBqHEJ/Qhg1Vu2AxuNyLiv1iY3etH DrHqRIlk5lKILIbb4NcIBeTnmdu3ZYh0SUMLWpNJC5ph1aPzbIUYo0ne63L7JlBrqiuN rsHt7iIUkV7BzG0NTwwWEz7wAP5lo/QgIFW6AgD2LRzOwUpkDHeN8ih1OV12aU08eaaW UgMw== 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=AYGjuh7+RUKpD3DmbGLob8kYQh6p9dumoRMqy7eEC00=; b=DyMNESMoIEmBZTTmi/X5WEJkxhUOnw76pPFnPrR+O3YA4qpEVBc6iACxgoVWhsTgdh ZiVxmBhp6qH5IgMwgAF3a24qBrKCykzNRBWA0FJGkOiWc1YVNva//k5ixIMR43TJaNOj l8qtFoYlv6CEOf7A6/6sQE/HzmZT8kjnXRChjMu0D25poqkZ3C3ZtJYu23IcT7WWTL61 LvfV/L+3up9NrllyMubXWFy17w5j3M1XSgnQ0QOk3yeM1Cle+uonnLaps+SUYMt6b9SA Vfa8nvESGUET74QqsKRYW1YfORdO7pwT97O2BS7Qp6EWCDVJGAWqmiHEkfgGct3nf0iy ew1A== X-Gm-Message-State: ALyK8tJxZpHvS8iI35XYJPagtWKAHmGaKgijXUXi724MliNCOpBZH4QSxl7i+yUi2guHS4R/lHsRNB8QiVxpmg== X-Received: by 10.194.203.226 with SMTP id kt2mr4332199wjc.75.1465275474649; Mon, 06 Jun 2016 21:57:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.119.163 with HTTP; Mon, 6 Jun 2016 21:57:53 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Tue, 7 Jun 2016 06:57:53 +0200 Message-ID: To: Julien Vermillard Content-Type: multipart/alternative; boundary=047d7bacc82a2a3d320534a90856 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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, 07 Jun 2016 04:57:59 -0000 --047d7bacc82a2a3d320534a90856 Content-Type: text/plain; charset=UTF-8 Okay so there needs to be some sort of random number generation for the TLS-PSK handshake, I was not aware of that. (is the requirements on it as rigor as for the key generation) The other reason I could think of that is kind of mentioned previously, it is the "quality" of the generated key, in some deployments, FIPS certified key generation is required and that could be easier to guarantee server-side. But it might be that there are no absolute situations where server-side key-generation but rather a design option. //Samuel On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard wrote: > Yes, but since you need some random numbers for doing a TLS-PSK handshake > (ClientHello random) why a TLS-PSK client should no be able to generate > ECDSA keys? > > -- > Julien Vermillard > > On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman wrote: > >> Hi Julien, >> >> The first one that comes to mind would be where Pre-Shared-keys are used >> i.e. symmetric keys. These keys could be factory keys used only to setup >> the PKI-keys. >> >> If you look at EST the server generated keys is also recommended to be >> wrapped in an extra layer of encryption in addition to the transport layer >> security (DTLS/TLS). So if the transport layer security is not absolute no >> keys should be leaked. >> >> //Samuel >> >> >> >> >> >> On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard >> wrote: >> >>> Hi Samuel, >>> I wonder in which scenario a RNG is safe enough for running a DTLS stack >>> but not good enough for generating a ECDSA key couple? >>> >>> -- >>> Julien Vermillard >>> >>> On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman >>> wrote: >>> >>>> The company I previously worked for where looking into adopting EST for >>>> this purpose, the benefit of EST compared to cmp or scep was that it >>>> defined the process for server side generated keys, which could be >>>> beneficial if key generation would be to cumbersome for the device or if >>>> you don't trust the device to generate a "good" key. >>>> >>>> Maybe Shahid could give sold more updates since he was helping us with >>>> this project >>>> >>>> >>>> On Thursday, 2 June 2016, Julien Vermillard >>>> wrote: >>>> >>>>> Hi, >>>>> In industrial or enterprise M2M/IoT application we often use PSK for >>>>> authentication, but more and more user want to enroll the device on their >>>>> public key infrastructure like they does with some routers using SCEP/CMP. >>>>> >>>>> I wonder if it was explored to enroll devices, and renew certificates >>>>> on PKI only using CoAP and not HTTP? >>>>> >>>>> -- >>>>> Julien Vermillard >>>>> >>>> >>> >> > --047d7bacc82a2a3d320534a90856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay so there needs to be some sort of random nu= mber generation for the TLS-PSK handshake, I was not aware of that. (is the= requirements on it as rigor as for the key generation)

The ot= her reason I could think of that is kind of mentioned previously, it is the= "quality" of the generated key, in some deployments, FIPS certif= ied key generation is required and that could be easier to guarantee server= -side.

But it might be that there are no absolute situati= ons where server-side key-generation but rather a design option.

//Samuel


On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard <= jvermillard@gmail.com> wrote:
Yes, but since you need some random numbers for doing a= TLS-PSK handshake (ClientHello random) why a TLS-PSK client should no be a= ble to generate ECDSA keys?

--
Julien Vermillard

On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
Hi Julien,

The first one that c= omes to mind would be where Pre-Shared-keys are used i.e. symmetric keys. T= hese keys could be factory keys used only to setup the PKI-keys.

If you look at EST the server generated keys is also recommended to= be wrapped in an extra layer of encryption in addition to the transport la= yer security (DTLS/TLS). So if the transport layer security is not absolute= no keys should be leaked.
<= /div>

//Samuel


=


=
On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillar= d <jvermillard@gmail.com> wrote:
Hi Samuel,
I wonder in which scen= ario a RNG is safe enough for running a DTLS stack but not good enough for = generating a ECDSA key couple?

--
Julien Vermillard

On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtm= an <samuel@erdtman.se> wrote:
The company I previously worked for where looking into adopting EST for= this purpose, the benefit of EST compared to cmp or scep was that it defin= ed the process for server side generated keys, which could be beneficial if= key generation would be to cumbersome for the device or if you don't t= rust the device to generate a "good" key.

Mayb= e Shahid could give sold more updates=C2=A0since he was helpin= g us with this project


On Thursday, 2 June 2016, Julien Ve= rmillard <jve= rmillard@gmail.com> wrote:
Hi,
In industrial or enterprise M2M/IoT a= pplication we often use PSK for authentication, but more and more user want= to enroll the device on their public key infrastructure like they does wit= h some routers using SCEP/CMP.

I wonder if it was explored to = enroll devices, and renew certificates on PKI only using CoAP and not HTTP?=

--
Julien Vermillard
=




--047d7bacc82a2a3d320534a90856-- From nobody Wed Jun 8 17:05:31 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 DC7A112D6AD for ; Wed, 8 Jun 2016 17:05:29 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 k1GG6JzXgqje for ; Wed, 8 Jun 2016 17:05:28 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A2E12D51D for ; Wed, 8 Jun 2016 17:05:28 -0700 (PDT) Received: from hebrews (augustcellars.com [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 71D6D38F1F; Wed, 8 Jun 2016 17:05:27 -0700 (PDT) From: "Jim Schaad" To: "'Michael Richardson'" , "'Julien Vermillard'" References: <15088.1465238009@obiwan.sandelman.ca> In-Reply-To: <15088.1465238009@obiwan.sandelman.ca> Date: Wed, 8 Jun 2016 17:05:17 -0700 Message-ID: <04d701d1c1e2$a0e66b40$e2b341c0$@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: AQLRosrherudxMir+lGnXQLlywaTdwKIPZAGAcf68gcBfKqPlJ2yGCJw Content-Language: en-us Archived-At: Cc: 'Samuel Erdtman' , ace@ietf.org Subject: Re: [Ace] Constrained Environment PKI enrollment 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, 09 Jun 2016 00:05:30 -0000 ECDSA can be run in a deterministic fashion if desired (see RFC 6979). Note that the new EdDSA is only a deterministic signature and no random component is needed. Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Monday, June 06, 2016 11:33 AM > To: Julien Vermillard > Cc: Samuel Erdtman ; ace@ietf.org > Subject: Re: [Ace] Constrained Environment PKI enrollment > > > Julien Vermillard wrote: > > I wonder in which scenario a RNG is safe enough for running a DTLS > > stack but > > not good enough for generating a ECDSA key couple? > > Particularly since my understanding is that ECDSA signatures (like DSA ones) > require good RNG. This attribute has also bugged me about DSA, and made me > prefer RSA :-) > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > From nobody Wed Jun 8 17:09:19 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 2E8D912D856 for ; Wed, 8 Jun 2016 17:09:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgCg5zYuTmtM for ; Wed, 8 Jun 2016 17:09:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6F812D845 for ; Wed, 8 Jun 2016 17:09:16 -0700 (PDT) Received: from hebrews (augustcellars.com [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id B06572CA4F; Wed, 8 Jun 2016 17:09:15 -0700 (PDT) From: "Jim Schaad" To: "'Samuel Erdtman'" , "'Julien Vermillard'" References: In-Reply-To: Date: Wed, 8 Jun 2016 17:09:15 -0700 Message-ID: <04d801d1c1e3$28f0c620$7ad25260$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04D9_01D1C1A8.7C9597A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLRosrherudxMir+lGnXQLlywaTdwKIPZAGAcf68gcBo3GeHQMmLkopAPPlUTKdkBIGkA== Content-Language: en-us Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Constrained Environment PKI enrollment 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, 09 Jun 2016 00:09:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04D9_01D1C1A8.7C9597A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The client random value does not need the same quality of randomness = that would be desired for a private key generation process =E2=80=93 = especially a long term key. I would need to sit down and think about = it, but it is quite possible that a counter would work for the client = random value. The main thing you want with this is non-repeating so = that the final secret is always uniquely generated. There have been = cases where time has been part of this random value and I don=E2=80=99t = believe that it makes the final key any less secure. =20 Jim =20 =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Samuel Erdtman Sent: Monday, June 06, 2016 9:58 PM To: Julien Vermillard Cc: ace@ietf.org Subject: Re: [Ace] Constrained Environment PKI enrollment =20 Okay so there needs to be some sort of random number generation for the = TLS-PSK handshake, I was not aware of that. (is the requirements on it = as rigor as for the key generation) The other reason I could think of that is kind of mentioned previously, = it is the "quality" of the generated key, in some deployments, FIPS = certified key generation is required and that could be easier to = guarantee server-side. But it might be that there are no absolute situations where server-side = key-generation but rather a design option. //Samuel =20 =20 On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard > wrote: Yes, but since you need some random numbers for doing a TLS-PSK = handshake (ClientHello random) why a TLS-PSK client should no be able to = generate ECDSA keys? -- Julien Vermillard =20 On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman > wrote: Hi Julien, The first one that comes to mind would be where Pre-Shared-keys are used = i.e. symmetric keys. These keys could be factory keys used only to setup = the PKI-keys. If you look at EST the server generated keys is also recommended to be = wrapped in an extra layer of encryption in addition to the transport = layer security (DTLS/TLS). So if the transport layer security is not = absolute no keys should be leaked. =20 //Samuel =20 On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard > wrote: Hi Samuel, I wonder in which scenario a RNG is safe enough for running a DTLS stack = but not good enough for generating a ECDSA key couple? -- Julien Vermillard =20 On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman > wrote: The company I previously worked for where looking into adopting EST for = this purpose, the benefit of EST compared to cmp or scep was that it = defined the process for server side generated keys, which could be = beneficial if key generation would be to cumbersome for the device or if = you don't trust the device to generate a "good" key. =20 Maybe Shahid could give sold more updates since he was helping us with = this project On Thursday, 2 June 2016, Julien Vermillard > wrote: Hi, In industrial or enterprise M2M/IoT application we often use PSK for = authentication, but more and more user want to enroll the device on = their public key infrastructure like they does with some routers using = SCEP/CMP. I wonder if it was explored to enroll devices, and renew certificates on = PKI only using CoAP and not HTTP? -- Julien Vermillard =20 =20 =20 =20 ------=_NextPart_000_04D9_01D1C1A8.7C9597A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The client = random value does not need the same quality of randomness that would be = desired for a private key generation process =E2=80=93 especially a long = term key.=C2=A0 I would need to sit down and think about it, but it is = quite possible that a counter would work for the client random = value.=C2=A0 The main thing you want with this is non-repeating so that = the final secret is always uniquely generated.=C2=A0 There have been = cases where time has been part of this random value and I don=E2=80=99t = believe that it makes the final key any less = secure.

 

Jim

 

 

From:<= /b> = Ace [mailto:ace-bounces@ietf.org] On Behalf Of Samuel = Erdtman
Sent: Monday, June 06, 2016 9:58 PM
To: = Julien Vermillard <jvermillard@gmail.com>
Cc: = ace@ietf.org
Subject: Re: [Ace] Constrained Environment PKI = enrollment

 

Okay so there needs to = be some sort of random number generation for the TLS-PSK handshake, I = was not aware of that. (is the requirements on it as rigor as for the = key generation)

The other reason I could think of that is = kind of mentioned previously, it is the "quality" of the = generated key, in some deployments, FIPS certified key generation is = required and that could be easier to guarantee = server-side.

But it might be that there are no = absolute situations where server-side key-generation but rather a design = option.

//Samuel

 

 

On Mon, = Jun 6, 2016 at 5:05 PM, Julien Vermillard <jvermillard@gmail.com> = wrote:

Yes, = but since you need some random numbers for doing a TLS-PSK handshake = (ClientHello random) why a TLS-PSK client should no be able to generate = ECDSA keys?


--
Julien = Vermillard

 

On Mon, = Jun 6, 2016 at 4:30 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

Hi = Julien,

The first one that comes to mind would be = where Pre-Shared-keys are used i.e. symmetric keys. These keys could be = factory keys used only to setup the = PKI-keys.

If you look at = EST the server generated keys is also recommended to be wrapped in an = extra layer of encryption in addition to the transport layer security = (DTLS/TLS). So if the transport layer security is not absolute no keys = should be leaked.

 

//Samuel




 

On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard = <jvermillard@gmail.com> = wrote:

Hi Samuel,

I = wonder in which scenario a RNG is safe enough for running a DTLS stack = but not good enough for generating a ECDSA key = couple?


--
Julien = Vermillard

 

On Fri, = Jun 3, 2016 at 5:08 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

The = company I previously worked for where looking into adopting EST for this = purpose, the benefit of EST compared to cmp or scep was that it defined = the process for server side generated keys, which could be beneficial if = key generation would be to cumbersome for the device or if you don't = trust the device to generate a "good" = key.

 

Maybe Shahid could give sold more updates since = he was helping us with this project



On Thursday, 2 June 2016, Julien Vermillard = <jvermillard@gmail.com> = wrote:

Hi,

In industrial or enterprise M2M/IoT = application we often use PSK for authentication, but more and more user = want to enroll the device on their public key infrastructure like they = does with some routers using SCEP/CMP.

I wonder if it was explored to enroll devices, and = renew certificates on PKI only using CoAP and not = HTTP?


--
Julien = Vermillard

=

 

 

 

 

------=_NextPart_000_04D9_01D1C1A8.7C9597A0-- From nobody Fri Jun 10 04:23:32 2016 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 B52C012D177; Fri, 10 Jun 2016 04:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610112328.15484.41412.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 04:23:28 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:23:29 -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 of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-02.txt Pages : 53 Date : 2016-06-10 Abstract: This specification defines the ACE framework for authentication and authorization in Internet of Things (IoT) deployments. The ACE framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the limitations of IoT devices require it, profiles and extensions are provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-02 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 Fri Jun 10 04:29:13 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 1A66D12D56D for ; Fri, 10 Jun 2016 04:29:12 -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 EC8GAcOMNSWK for ; Fri, 10 Jun 2016 04:29:08 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D02E12D54F for ; Fri, 10 Jun 2016 04:29:07 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id f6so23199807lfg.0 for ; Fri, 10 Jun 2016 04:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ygio3ItxtL8Mdb12W4NvW+iiVPqKpxE0+4LMFOJTRww=; b=yVo44Yz0Dwp2+rR2CyLRZhFbboS1JXvFHGt9cIpmAeFPxZQVxZ4EQQr6BMcSxxn5qO Q01U9hww29LWSgK/8F7mK3qWmBQLbHAmX7dK+/lbV4ensWi9q/oIVCm/YubjK9ns0MQm OFYW1nYW4vDIyZ4ICHh5aT92hukEhYUkb4K7fuDv8JAjhD54O+ZI5ciumdHs9AUfw9p0 THPz8rwMR5NjqNstuNdRmLNhmfHDEwJaFcRHgfy8+C6Phr+PW74Gsel5tUfx+azTb8GJ 0jCKrDKz78EjIvu43ybFe76DOs6NvhCO//tMF5fOqdI4XwCKrYXzWXuOpxp+PonQawfm dDRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ygio3ItxtL8Mdb12W4NvW+iiVPqKpxE0+4LMFOJTRww=; b=fv8Ts3jM1bLsG4hH4liGexgEJEfBrjtIF1DY7J68uLn9H8+tuYCPG9BfLYQX4hxwg7 RWOXgdxCVRZzTehWaJ/33agptAeSENj1EdxIADeD/5zgvvn/x/5wzi+kwBY6BRLrZLW6 oCQE4MwxuZmEkBFYeuGhsO9236zEtt/y9LlujOyYuZj942yNcx9anxa09UXzMOIkSf6U vbOidx5p6tNiNix4r2F10EoCi6q9SCfw1Vq6zGZ4DSkr4HbVpBnlPoymiyXJfGSOjLN3 30lwpk7zw7UTgqoBHN+OaqpHnPwo0G8mP85Qz0ZTrHNg3sH0cc1Cun80QIGDzyFTzRKa ORtg== X-Gm-Message-State: ALyK8tJ5xqL9c0hCUbqMEc+ZN7HA4ivN5ACgesyg4Jeoca+Ps+hHcc4gVIYW9X9mUNIlSx9I X-Received: by 10.25.169.17 with SMTP id s17mr523215lfe.57.1465558145217; Fri, 10 Jun 2016 04:29:05 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id zo8sm1140019lbb.15.2016.06.10.04.29.04 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 04:29:04 -0700 (PDT) References: <20160610112328.15484.9746.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <20160610112328.15484.9746.idtracker@ietfa.amsl.com> Message-ID: <575AA47F.4050703@sics.se> Date: Fri, 10 Jun 2016 13:29:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160610112328.15484.9746.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020301050703020508070205" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-02.txt 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: Fri, 10 Jun 2016 11:29:12 -0000 This is a cryptographically signed message in MIME format. --------------ms020301050703020508070205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello ACE, we have submitted a new version of the ACE-OAuth draft. Hopefully you=20 will have time to review it before the interim meeting. You can also follow the draft (and submit pull requests or raise issues) = at https://github.com/LudwigSeitz/ace-oauth/ Regards, Ludwig Seitz -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-02.txt Date: Fri, 10 Jun 2016 04:23:28 -0700 From: internet-drafts@ietf.org To: Goeran Selander , Erik Wahlstroem=20 , Ludwig Seitz , Goran=20 Selander , Hannes Tschofenig=20 , Samuel Erdtman A new version of I-D, draft-ietf-ace-oauth-authz-02.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 02 Title: Authentication and Authorization for Constrained Environments (AC= E) Document date: 2016-06-10 Group: ace Pages: 53 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-aut= hz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02= Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-02 Abstract: This specification defines the ACE framework for authentication and authorization in Internet of Things (IoT) deployments. The ACE framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the limitations of IoT devices require it, profiles and extensions are provided. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms020301050703020508070205 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 MBwGCSqGSIb3DQEJBTEPFw0xNjA2MTAxMTI5MDNaMC8GCSqGSIb3DQEJBDEiBCCTQW+lnLyN qIjM9K1HoEtOq4cBnwMlUS6SlehplkRgFzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQAC+IfiBPt34AxHPvOx2eDR 3eaWYrPZtTUeFiDDdIUn9eUCO04fDg+pKMZxSA95mATsP+fFfANTkC8Kb3esBJCbGZCqvF+C hs6rPB3zRnhB5ujxxWg7LNRv7ZN8RiZ2C831OMqoS9bXAih8x8bIGne2ELXJXGewUZsR5yrh sAA3oGa41IzlCp39an/UUgqF+VmXNyhjgSSOYlf1AqjRoGrI1waKpKm9HVB4d+HzEz1wPnw+ bN/sllMm4QLqUgtlu9O1smnsmqOJLpJL3udkSUffDOtkJ6gSPe/ovuKK+Jzpl0OPsIOxppUe 5yk8H0JIKyjMXf8I9JRoCXC7QFYQXyj0AAAAAAAA --------------ms020301050703020508070205-- From nobody Thu Jun 16 04:07:45 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 C1A0912D0AC for ; Thu, 16 Jun 2016 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 4T80gAezb-N3 for ; Thu, 16 Jun 2016 04:07:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5D112D0F8 for ; Thu, 16 Jun 2016 04:07:37 -0700 (PDT) Received: from [192.168.10.132] ([80.92.123.182]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LnUna-1btj7A3MxK-00hakR for ; Thu, 16 Jun 2016 13:07:35 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57628879.8010102@gmx.net> Date: Thu, 16 Jun 2016 13:07:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lpFWhHQPWDGvB3HwALQEJlarbr1XUahbm" X-Provags-ID: V03:K0:bUbw8qcO5VMIqJVLoRkpRnKo9XpO6Ka0Qk0/2JKorDqUxeTpbi2 FY/FoldMNJGl6dN8Ct4FsfS6SYsdsVVGwl6haOI2ocWRT1kbTCtsfL0x48J/UGLIOwQALrk uIm1SvmHLlg7IMqmAuenvuxlApsU4DCgVMgEsU3I9ue/94ctsAD9vamL+3/HksvyE1pb6E/ dTWIe44HlzRw2DjNGaRvQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:CdWCE7Vyvmg=:CQLyhLcwekh/OvMC7oG+My isuAxwMZeJKxQqMhZqE1tDJ08XP4J+ftKQ1jyo732cbGQ1V+r38VzsCWNurQ7UZ96UoyxOq7I NFUrn5E/onv3Ovxjkq7HAtlNmXZRr193zUOMhcmI2EXvcjhTxlexEuNh6H09xtpGCPLlz4Ujf a6DmlTwluWmdI2OMow3ilgWiNKzJZ3Ed8go5g/Q9M8EKH3tvt0zKF7OWb83g2K3pOs09Hxvnn UGYwwEnFf1F6Pom/fEOJurd+zlGgM8eB2Rb/xkFiDSy22/anaOOpDSE7LQuSiugq3KcEGtljt VQBB7mvypqF2ukSX9jCdDBGlSdQbkzVZLPqt10LwZPgCH7SA1U5ExrHMonunwl8Q4rHPEYO8R vQBrXO5Ksh4aZsyWaAYnNJtXwafhOXTx/3G1MFPC18SCxGiSyrtWE8KlmmRGHZ4ld3P4TxWJu jzpSzBeTQ4+7otifAGWZBPBVOOUlbRPpPU3/TJwbbmSeZuLJiNo8TeiUQF8kfgZf6Bt7zWIHY qFX74i2duPguZvkI+rSGihjWJsG58JTNXRZo+sVedK14jquhFj8BlyFekAMzEcbijFoEn54xF I1IBkEsOffAtuInW8zYaaJbLApZPTwVYcOdhYauVQE+2YriRZrNi9weo7opyQsg0hDQ935FT9 VRYGGV1elk8eCqnOrPFOqN3UkgyFfeEtSW9rsZ9IU1bGuFC18mcx9LlMyYarXZnomj0U4GdUB OyKD2Sg9/qdVWhNqcNc7m14bo52WdAQhhbzbGrbWJS8kgN1YkertnWxa05E= Archived-At: Subject: [Ace] Reminder: ACE Virtual Interim Meeting 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, 16 Jun 2016 11:07:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lpFWhHQPWDGvB3HwALQEJlarbr1XUahbm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just want to remind you that we are going to have our virtual interim meeting today (in ~1 hour). There are three agenda items: * OAuth-ACE draft: Where are we and what are the open issues? * Design Team: What has the design team doing? * CWT: What are the open issues since the document became a WG item? You can find the meeting details in my mail to the list: http://www.ietf.org/mail-archive/web/ace/current/msg01820.html Ciao Hannes --lpFWhHQPWDGvB3HwALQEJlarbr1XUahbm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXYoh6AAoJEGhJURNOOiAtwFAIAJKCpS5LGv5wozns36qRXmeu drNJ5BQ1isXQo6PR9lb0kfGZpvKtVzsulLlvsAYgaZs1Xu1ZKywUOHKyp+N+MifU eb0++Lm4MimWiq/5R7w5IZFcvwn3CSCMImOl93x051xbpLr01BYoZqPtwtfM/s85 jvHBK6oNM+VsArAvtVl2N5DOAcnihQZY3i+lnwkn+iIp4SafKu0PrHd9s3+tm1ra zyk7d2VyfIqtPRnn4CNc1wtJOGy7PJ8CeYR7rll5gqiUYzH7ZYcc6+jeLVP4AeKi wsQcgEyezwLiazN12MtFZujnqnElNq4al/FZwiM1difUEKAvcfbL62zieEXjEcU= =dicD -----END PGP SIGNATURE----- --lpFWhHQPWDGvB3HwALQEJlarbr1XUahbm-- From nobody Fri Jun 17 14:12:09 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 6EBBC12DAE2; Fri, 17 Jun 2016 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_gf7LMKox5r; Fri, 17 Jun 2016 14:12:02 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E236012D178; Fri, 17 Jun 2016 14:12:01 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 342E5C5A50; Fri, 17 Jun 2016 23:12:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Zi4rXm0pti56; Fri, 17 Jun 2016 23:11:58 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 986F5C5A4E; Fri, 17 Jun 2016 23:11:57 +0200 (CEST) Message-ID: <5764679C.5010608@tzi.org> Date: Fri, 17 Jun 2016 23:11:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "ace@ietf.org" , "core@ietf.org WG" , "cose@ietf.org" , dtls-iot@ietf.org, "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF96: DRAFT AGENDA 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: Fri, 17 Jun 2016 21:12:04 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF96. Remember that there is still quite some potential for changes. Apart from COSE on PLUS (ouch), and the maybe more personal conflicts of ACE on QUIC and 6LO on ARTAREA, I'm not seeing a lot of hurt this time. Moves due to other conflict avoidance may make this worse, though. All times are CEST (UTC-0200). (The browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten MONDAY, July 18, 2016 1000-1230 Morning Session I Potsdam II ART artarea Applications and Real-Time Area Open Meeting - Combined with DISPATCH Potsdam III INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG 1400-1530 Afternoon Session I Potsdam II ART httpbis Hypertext Transfer Protocol WG Bellevue INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Potsdam I INT homenet Home Networking WG Tiergarten SEC oauth Web Authorization Protocol WG Ch_burg I SEC openpgp Open Specification for Pretty Good Privacy WG Potsdam III TSV tsvarea Transport Area Open Meeting 1540-1740 Afternoon Session II Ch_burg II/III INT *** lpwan Low-Power Wide Area Networks BOF Potsdam II SEC acme Automated Certificate Management Environment WG 1800-2000 Afternoon Session III Potsdam I IRTF maprg Proposed Measurement and Analysis for Protocols Research Group Potsdam II OPS anima Autonomic Networking Integrated Model and Approach WG Schoeneberg RTG bier Bit Indexed Explicit Replication WG Bellevue RTG detnet Deterministic Networking WG Potsdam III SEC lurk Limited Use of Remote Keys BOF TUESDAY, July 19, 2016 1000-1230 Morning Session I Potsdam I INT 6man IPv6 Maintenance WG Potsdam III SEC tls Transport Layer Security WG Bellevue TSV rmcat RTP Media Congestion Avoidance Techniques WG 1400-1600 Afternoon Session I Ch_burg II/III ART *** core Constrained RESTful Environments WG Bellevue SEC tokbind Token Binding WG Potsdam I TSV l4s Low Latency Low Loss Scalable throughput BOF 1620-1820 Afternoon Session II Potsdam II ART uta Using TLS in Applications WG Schoeneberg ART webpush Web-Based Push Notifications WG Potsdam III IRTF*** t2trg Thing-to-Thing Potsdam I RTG rtgarea Routing Area Open Meeting Ch_burg II/III TSV tcpinc TCP Increased Security WG WEDNESDAY, July 20, 2016 1000-1230 Morning Session I Bellevue SEC *** ace Authentication and Authorization for Constrained Environments WG Ch_burg I SEC curdle CURves, Deprecating and a Little more Encryption WG Potsdam I TSV quic QUIC BOF 1400-1530 Afternoon Session I Ch_burg II/III INT dnssd Extensions for Scalable DNS Service Discovery WG Potsdam III IRTF cfrg Crypto Forum 1550-1720 Afternoon Session II Schoeneberg RTG *** roll Routing Over Low power and Lossy networks WG Lincke SEC oauth Web Authorization Protocol WG Ch_burg II/III TSV tsvwg Transport Area Working Group WG THURSDAY, July 21, 2016 1000-1230 Morning Session I Schoeneberg ART ice Interactive Connectivity Establishment WG Ch_burg I SEC *** cose CBOR Object Signing and Encryption WG - 11:30-12:30 Potsdam I TSV plus Path Layer UDP Substrate BOF 1400-1600 Afternoon Session I Bellevue INT its Intelligent Transportation Systems BOF Potsdam I OPS v6ops IPv6 Operations WG Potsdam III SEC saag Security Area Open Meeting 1620-1820 Afternoon Session II Tiergarten ART *** core Constrained RESTful Environments WG Potsdam III OPS anima Autonomic Networking Integrated Model and Approach WG Potsdam II RTG babel Babel routing protocol WG 1830-1930 Afternoon Session III Potsdam III INT intarea Internet Area Working Group WG Bellevue TSV taps Transport Services WG FRIDAY, July 22, 2016 1000-1200 Morning Session I Bellevue ART httpbis Hypertext Transfer Protocol WG Ch_burg II/III TSV tsvwg Transport Area Working Group WG 1220-1320 Afternoon Session I Schoeneberg INT *** lwig Light-Weight Implementation Guidance WG Ch_burg I SEC spasm Some PKIX and SMIME WG From nobody Sat Jun 18 03:38: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 8D24012D770 for ; Sat, 18 Jun 2016 03:38:16 -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 A6pIIzQNsfyv for ; Sat, 18 Jun 2016 03:38:14 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B7312D76C for ; Sat, 18 Jun 2016 03:38:14 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f126so15875252wma.1 for ; Sat, 18 Jun 2016 03:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xDu7EpxQiJkXJZC97UO0m0A/HJp+/OOKuBb1Ymrk7FM=; b=f9v7Lh3/BRh66eeWZOycMkzdN0J4/q/LCdrer2sqNk+C7sFb3woh4M3iKAwE5WACLG eCzsP0VgnueP7+uImKxx8j5F1st7EeZS3KEfGzjLEFg2GK7b40GMFpFGMhq/ZDS7ZnmD 56fUUa/snjnGH1df6/BBaHwDf9VV9eV2i4qSAt2p8+lFLG17d5yNsGiBQKfiYyOCIQKq mW2jeP5REItFpcbySC0G2CMD6YWstRbBv7P139UwlbH2kVkvIsgBJSel18h9JI5i9VVu sOWfaah5oBEac14hAdVM9oHCCzRK9Jq7QKpB2FlzM4fGR2EHX4bmcb6HH5jeVUVk5Z0j riDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xDu7EpxQiJkXJZC97UO0m0A/HJp+/OOKuBb1Ymrk7FM=; b=gO9xmPkOeOsLxMsAi6/gNhrXbObqzuAZU/TTdKXG4w4vjbD6Ll4osPwvfCyU9INMxr Cp5XwmKtXsz1PlyYi42DAXtjKmg+was3kLfPHXV7ew4ZOQ9QgwFEj2iHCvKmK9ygKZUK 2gTDG8rCUTGnjtnqv5qLR9sN5TIEDw0Cxgg16Tt+8m/FGqMXheRRaR4bsQ8FbrESzkYQ 7ad9xNc/5gpj0XVPUx21eahXRh6JzKrOckXHXfwXhTVYjf2ZMoVDrxgHnP2rY/wUugvG SmzZ2wc9CsDjcD84tiCQVTO1jIc1O6RO2Kb9cHpAv8+l/CjsNGKQ7tBZa7D2AFGX2ZpH Oi6w== X-Gm-Message-State: ALyK8tJOj2jyKSbR4j29917eeeG09y7VeWBJpIPf4RJ4UneUH2JnFc3v4+3swKjBhXLOakGYB/ByIuBc/10pxQ== X-Received: by 10.28.191.90 with SMTP id p87mr2507628wmf.69.1466246292426; Sat, 18 Jun 2016 03:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.119.163 with HTTP; Sat, 18 Jun 2016 03:38:11 -0700 (PDT) From: Samuel Erdtman Date: Sat, 18 Jun 2016 12:38:11 +0200 Message-ID: To: Ace@ietf.org Content-Type: multipart/alternative; boundary=94eb2c06ddb269f21205358b116f Archived-At: Subject: [Ace] A question for the ACE framework and CWT 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: Sat, 18 Jun 2016 10:38:16 -0000 --94eb2c06ddb269f21205358b116f Content-Type: text/plain; charset=UTF-8 Hi When writing the IANA mapping sections for the ACE framework and CWT I first required registrations to include the CBOR major type, Later I did not (e.g. https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02#section-10.7). I would like to here the preferences of the group so that we can update mapping registries to have the same format. The benefit of having the CBOR major type in the registry is that one then has more of the important information in one place. On the other hand it is not relay necessary to have it there, the reason for the mapping registries is to avoid CBOR label/key conflicts between attributes. So information about In COSE (https://tools.ietf.org/html/draft-ietf-cose-msg-13) it is included "value This contains the CBOR type for the value portion of the label." I would vote to keep data in registries at a minimum, i.e. exclude CBOR Major type from there. Opinions? Best regards //Samuel --94eb2c06ddb269f21205358b116f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

When writing= the IANA mapping sections for the ACE framework and CWT I first required r= egistrations to include the CBOR major type, Later I did not (e.g. https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02#section-10.7= ). I would like to here the preferences of the group so that we can update = mapping registries to have the same format.

The benefit of hav= ing the CBOR major type in the registry is that one then has more of the im= portant information in one place.

On the other hand it is not = relay necessary to have it there, the reason for the mapping registries is = to avoid CBOR label/key conflicts between attributes. So information about =

In COSE (https://tools.ietf.org/html/draft-ietf-cose-msg-13) it is included= "value=C2=A0 This contains the CBOR type for the value portion of the= label."

I would vote to keep data in registries at = a minimum, i.e. exclude CBOR Major type from there.

Opinions?

Best regards
//Samuel

--94eb2c06ddb269f21205358b116f-- From nobody Mon Jun 20 00:19: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 3DE6712D0DC for ; Mon, 20 Jun 2016 00:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 EpviGfPPpgi2 for ; Mon, 20 Jun 2016 00:19:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E965412B02E for ; Mon, 20 Jun 2016 00:19:22 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEFqW-1bChcV3Lzs-00FPYv for ; Mon, 20 Jun 2016 09:19:19 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <576798F7.5050702@gmx.net> Date: Mon, 20 Jun 2016 09:19:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BcvLmiOBWTine4Uf9gs1dSnbfEPMBMjvn" X-Provags-ID: V03:K0:wcfl1hW+P4ta/fC9WXfQ4II0ofQPHgMHMEBhAEjJpHIpJEnDV8e NyH7E//PoFB50R9mlzDOZleIGHyCwpCICAh9y3WxUB5COXrCC2t3X3qzVhPdJBcLuJrW+fX nu6R6YsWXQQShSWPK5SQN7J/CU0IySH3adoMzxotb7BIUm9dqBaf1ejNIN4Bk8B2pM3GDJd bKUD149mwEK5e3LL3KBuQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:/AdK7D6ne/Y=:gtr6OQGXYBtjU3axbumAyf 181+TbvbqDjvzYYxK2tJNE2/t5TyF+5Uj5igCJYhHub+OfH10gAgktr7JbperEO/9yn6O7Q16 h8JFlpGS+eV5ViKyy9JieS3dI0sYtW7MiHOcaIfrqz9n+Of5lsLfEWTw+ubHU0j0ZRacBA7Ro kaf5fVKeqi5PCXnONUqDlRiN7SSBwa22Rd7wYTKHtQqdzYuWUpNE9kmD4H2W+Eg3OqmlG4KyC PCK1Vz1MTLPvxc8CBNBMh5L0OsQV7pc9Z1+eM8zTflgQ2YeEvPcmh/O84ulI6jlLsr75F/HUE qZBdO1JMDZU5MCPbIGJbkRfU6ap7vqpxKwHisxlppLrI5Om/O3ppbDtccxn+SfLiGlYjeYvz8 QoYZG5gIBpqtrtRptfPlNIbczXP2NnbZsmPkfE0ruAjh/zEAUDvNEmtBGCK4Yub9y/cLaCX83 JXekDClOR3l+2rCimg8xkbDjtkXOFS+QaWLq9K/Sn/pNIPBx1hJQ8lFCBRUKgj8+QeK1Aroqk HW5rDKA2LUy0yocxP3P4AXNtTKwBFo6GoCTDZ4SH8UMu9wBo01k6qDKN0TL/m9j+MeAvar4c7 5hEI9ADQPEHI8rQkBynMtJMLF5HlFeVl6ZNhjGK1x8ABt7ajC3BP0yjjjxmvW5qtCL7l3Z2Es AbBKrx1lS8glwFMIzNFjuJv9VIYAKGQU02bwCHHUpWoaZcWJWeowT943agwLvJT4u2HUN4qzn 6oEckRDVy8xbL2ZMLyxcyaot9pASr8yHjRW3/5nQAcmaEnQgVkoyAXrWjq0= Archived-At: Subject: [Ace] Meeting Notes 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: Mon, 20 Jun 2016 07:19:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BcvLmiOBWTine4Uf9gs1dSnbfEPMBMjvn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I would like to thank those who took the time to attend the virtual interim meeting last week. Here are the notes: https://www.ietf.org/proceedings/interim/2016/06/16/ace/minutes/minutes-i= nterim-2016-ace-2 (Thanks Samuel.) Here are the pointers to the presented material: * Clock Design Team Report https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-int= erim-2016-ace-2-0.pdf * CBOR Web Tokens https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-int= erim-2016-ace-2-1.pdf * ACE-OAuth https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-int= erim-2016-ace-2-2.pdf Here are two additional documents from the design team, which were mentioned during the call: - https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-int= erim-2016-ace-2-3.pdf - https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-int= erim-2016-ace-2-4.pdf Ciao Hannes & Kepeng --BcvLmiOBWTine4Uf9gs1dSnbfEPMBMjvn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ5j4AAoJEGhJURNOOiAtfS8H/juxrdKS/qA+NNXONPdGsqkm V89d4BpNLUuK1iClS6SvWah8p1+d833d41GpNKcs7OAuTGixd0KrtE3JdkoXApnV As35A1aHpp8HxGrgaB+6shvQL4wQloazxE27ia7wtw8cWVw19adlA1pnw5iAcxIc XLm0JbnX9kk7MMhwkDRpED5X8GJQtabPy9GHhDc5b7wmfFX94USbeqONYPyutfGg PJVKin4xz/ztVWw3LxNTsy5Dqi2dO3GDR6AGVdK3tiaUBpMh3X1mNykqyYl7KAlv FYZaqtUGum1AW4Elrv9H0linkMPcUyJPTxNVANQDNNn6GeJCDTXaiGGC3C9E6KU= =Kvl0 -----END PGP SIGNATURE----- --BcvLmiOBWTine4Uf9gs1dSnbfEPMBMjvn-- From nobody Mon Jun 20 00:27:33 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 16A1112D9AC for ; Mon, 20 Jun 2016 00:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 a5weKPRz3rLL for ; Mon, 20 Jun 2016 00:27:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2247012D0DC for ; Mon, 20 Jun 2016 00:27:29 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LnwxU-1buWt51eOm-00g1KE for ; Mon, 20 Jun 2016 09:27:27 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <57679AE0.5000906@gmx.net> Date: Mon, 20 Jun 2016 09:27:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qt3xsfaolvMppBio3IhIueRflWVp7MArg" X-Provags-ID: V03:K0:lke0WWqk4Zf0rFT3KA/q98Y9g128vd4h6BBIkrRS6AZzTg0WXFq 0M8jYf07zD9EucYNhNGy2sjMHsFGClSkBEhv5H6eL9EQhfl59RzHW+efbqiYZhEpTbdJNdl iKT+7qtDA9uOfH48t09L+O8IzxGsandIc+LPxteZilWwC2yhHCNe3V6smVbx0uhTB1z/uOE P3d8Of1c3yX0G//8WzKhQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:u/8yh+FuzME=:lbGCRr3j6IqGujAN3tFtKj 5ysEY3YyyOg3WhoEJEXHdu0b6smfwlhKYaR9VBNeQDChVeH9staz0D7lSPHFaVsdRYtzCTTsJ dnx5j8HW9AvFmt0bo+THXYvcS8Sf1vwl29Gcp6OA6iBtjpwCCT8XMH1740ykcMfyB3bp8Mglf utwd80V4e6pi6Agx1T1BOfXjiikSHBH36vUUvAb4ETqViCbsqpdwdwaW2mdI9p6WnmXdB+Oxr Zsm02eKu8HxaVctq7rwAL4aGcxdKdmipj0jRCB6ieIKMTnXDtvRIjK5YCQuv4ujUQA+4CwRev +s1Zi5J5UgjTB91d6Itr4JOXJ/eXbapSY06IIkM7gAdc/43OC+7bcl3ndevkZkeyMh8UJElt8 W/ztuNhLYX56RBBBSxlD5P8IdOtgzpvWKzRU9PJ6z+xjJujgHc2V/gqqsllaktll+tJJn0MgG d20bGw/RGcZectGdm+C2trn0LX8ODVKL6+TUracAH1esV2w4aeFRKzD+m8hUiKMNN5PWpp15m ph5MdU7VZlkN9ct+2eg0DO5w9nH8oYrmi76PPcrk/pm2tNb2kQUI6JVchDV/vUlrpjI61b1Cs X9d7e+jrLX/parx7yub0Vz0Kd/NOLMg2g4qPjvL84LXqCxspSObdSYtj+wKTE+pD0LYlkTLBH sW0331IUIrsXBPHajAOoRZqIadvYg8SRtUr+4nCHaMw6OVl9sXaSdpaVaP6fc4e0+xvRsXs4H uupEmK2uF+p5/R8lL44vXOs44MOBNc/zXivuaYqNqEchpieg/X3ohcmCxWM= Archived-At: Subject: [Ace] Clock Design Team Conference Call 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: Mon, 20 Jun 2016 07:27:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qt3xsfaolvMppBio3IhIueRflWVp7MArg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, those who attended the virtual interim meeting last week have received a status update about the work in clock design team. We are having regular conference call and today is yet another one. This time we invited Peter Aldworth from ARM to chat with us about the support of real-time clocks of microprocessors. Please think about some questions for Peter. You are welcome to join the chat and here are the dial-in details: Date: 20.06.2016 Time: 3pm CEST (=3D9am EDT) Webex: https://arm-onsite.webex.com/arm-onsite/j.php?MTID=3Dm96aa2120a72cff74bdd= 5ab31d756bade Meeting number: 805 387 005 Meeting password: sp2JE8uP Phone: +1-408-792-6300 Call-in toll number (US/Canada) +1-877-668-4490 Call-in toll-free number (US/Canada) Access code: 805 387 005 Global dial-in numbers: https://arm-onsite.webex.com/arm-onsite/globalcallin.php?serviceType=3DMC= &ED=3D458176357&tollFree=3D1 Ciao Hannes Ciao Hannes --Qt3xsfaolvMppBio3IhIueRflWVp7MArg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ5rgAAoJEGhJURNOOiAtNa0H/32n9RbdEeEZy+gGyP2wG3IK Svypw798Kd9as+HJNu+7/4lM4Yst/LGBEYDL1Ad1KlFQchPsVIoZ0cirG8MFBFpX d43yglWUUSidnTtfHO0eo2mLp5fG5wDOUI0yDW++qAaZdjC/26qu00aR7MZvvKWa NpAnp9/977Vl5f7uhg6lyxpo2mBUCYEYYk/fjTT33Ej89ua4Hzrd2X/0no2sf0Mf umCgekNxSCzHYzmP/nJdtfxTFpl25+U8R4w1+vxQgnu5lsFhMirZ71s+i+nMh6FX bnGRhglprIYdZo5xwwiQa9QfWo4V4WzTUBXDCKFQ1Fi4U5/MGxmhQjZ9/vGctXA= =h4B3 -----END PGP SIGNATURE----- --Qt3xsfaolvMppBio3IhIueRflWVp7MArg-- From nobody Mon Jun 20 00:39: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 40A4C12B03E for ; Mon, 20 Jun 2016 00:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 hzYh2Yv0OHNK for ; Mon, 20 Jun 2016 00:39:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFD012B02E for ; Mon, 20 Jun 2016 00:39:53 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MNdxu-1bKvQV0zLG-007GZy; Mon, 20 Jun 2016 09:39:49 +0200 To: Shahid Raza , Samuel Erdtman References: <0EB38F45-003A-42DA-92F6-E166D9642010@sics.se> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57679DC6.9050101@gmx.net> Date: Mon, 20 Jun 2016 09:39:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <0EB38F45-003A-42DA-92F6-E166D9642010@sics.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jVNbdLPB6OW1LkVh15DjKaVeoIeSfcdPM" X-Provags-ID: V03:K0:nbHfGIPS0jSOvaeCteq7/s1dkFxkxy3z7/y3YfPCnDd87mV3Hsu 2L8OvOoVruTwsmgHGE5/UA9zBeXg1XsFA+zo6o2gAD9iseDrW5IRCmCwZpBZIThrS1PJHdp GQ01zB1L+TiK00VUNZIqRCUQY9S9wK0cdRJ3n5HCQvT00bPxvxXQ++7zof/AB8so4oRlO8/ yxrzjf1F20iocGfU731dQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ijY5hwBnGDU=:I0/jn9nvcmAO9X3/Soq5Xm A+Rym9zO1J6nBuNpmGrXaBiOd4PlGmFWVwSc5hsxwHdBVK8bWUdWMFHFmZgb0E5JhP3YjOXlD gO2CzEuiu2RXSLQ9TmSVOrru6Mu4dLuRrDMEQ68e7zADrixIQ1zxS8WSxX5wIF6gyfmSuhyHn y0aKtWQ4ffuM0J16POPk16b6AD3OqDAepeS8F7VafG5Gd+NhHaL8BQKEDw84nuAoDiy+PiLOD bDcRGv/Dtr6hpAnu+b1umoEVk0LQcO/k+NI8q5fWKBsC+UrTy04S3VT5DjhYdRho7LbvzuBuw EpRUSTnI64rvCPgNctHJpqwzxUzCgh5pKnQlCvH+eOrPmAFqR9yLzMl/Vr96HgpfYydEDNCSB XquOM7qv2FgK6pAsYTwrb2UFCvVzG2bRRBrCKK2f0rkQWQZm4VsM/D2kBp8rn8+24g5uBqLAq 4yrolNzx71i8XNo57Hq53KgdPBcEoOdJuuFUOeRGAeKZ8lu6G9Su96/M+qjFwQc7x60CqDPWb D30PpNMII/rzMvxoOipgzmAqVAN1BRdDOlEHk8yf7/U7Gcj9/SJkMRJVUXSASj+4pSKTaWLWj ClYIyEXnip/vn9EX+odeqipB5s7R8cu60Q62ej+HAT4ampUjWRn+W9Q80eECYsOaOBSlV+OBK M+YktiAxHQ9EjZDPtjUDUlph6gCNzcnpQcxYJdBXF33JWs704AgCN4pOJhy/DDoAl0X/SFtmB ee+5ukBTyX41UccZRxi3wbkHwAShBD4MFRpaZWS79B4ntXCF9dE//1s0cFU= Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 07:39:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jVNbdLPB6OW1LkVh15DjKaVeoIeSfcdPM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahid, have you had a chance to look at the work done by the OMA with LWM2M since it provides this support as well? Ciao Hannes On 06/04/2016 01:01 AM, Shahid Raza wrote: > We (SICS and neXus) have been working on this since September last year= > and designed and implemented an enrollment protocol over secure CoAP. > Both the specifications and the Contiki source code will be available > soon. This is done under the umbrella of a Swedish project called > CEBOT: Certificate Enrollment in Billions of Things. >=20 > Regards, > Shahid >=20 >> On 03 Jun 2016, at 17:08, Samuel Erdtman > > wrote: >> >> The company I previously worked for where looking into adopting EST >> for this purpose, the benefit of EST compared to cmp or scep was that >> it defined the process for server side generated keys, which could be >> beneficial if key generation would be to cumbersome for the device or >> if you don't trust the device to generate a "good" key. >> >> Maybe Shahid could give sold more updates since he was helping us with= >> this project >> >> On Thursday, 2 June 2016, Julien Vermillard > > wrote: >> >> Hi, >> In industrial or enterprise M2M/IoT application we often use PSK >> for authentication, but more and more user want to enroll the >> device on their public key infrastructure like they does with some= >> routers using SCEP/CMP. >> >> I wonder if it was explored to enroll devices, and renew >> certificates on PKI only using CoAP and not HTTP? >> >> -- >> Julien Vermillard >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --jVNbdLPB6OW1LkVh15DjKaVeoIeSfcdPM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEbBAEBCgAGBQJXZ53GAAoJEGhJURNOOiAt1CwH919usf1QfXrmN+sEeH6U5hGo RXonuNtQInBTb6JNBBhNJj7pJQlfBywM6/u0g7i4TM1IVCme07XvkJooC8wZZW6u sMfPtnUF7zXuPEGqPkX99mJ1tcO8IGaad8I45hH0sKeJ4HC0oHy3Z6ehhbXN6p7S TxYAox37FpEaQSGKXE79z2LW8aKKXGSJY0ceFQbtL+rkezXM0DI8v2UAcpSl3K3y 77FrEkYnQ3dN/buaRlc+wC7S1+F8fmoxMxcnAqgf4zluOqkeg8B0t3HA7lhii4jC yDKjuwfSh8NriUdRSDJZSxOkMcqHrwmd8lYStcEQ4J/kIOwIsKWLRSMFrq2S4A== =dtq1 -----END PGP SIGNATURE----- --jVNbdLPB6OW1LkVh15DjKaVeoIeSfcdPM-- From nobody Mon Jun 20 00:41:59 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 8B54112D804; Mon, 20 Jun 2016 00:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 2FFT5ACHphsv; Mon, 20 Jun 2016 00:41:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C2212D5D2; Mon, 20 Jun 2016 00:41:49 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LmKOI-1bnPNM2Fgg-00ZxkC; Mon, 20 Jun 2016 09:41:42 +0200 To: Michael Richardson , Samuel Erdtman , anima-bootstrap@ietf.org, anima@ietf.org References: <14558.1465237865@obiwan.sandelman.ca> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57679E36.1060806@gmx.net> Date: Mon, 20 Jun 2016 09:41:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <14558.1465237865@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO" X-Provags-ID: V03:K0:rML6Ak0rb3RQp27Z/FRXCbryheVgZDHOSFWdnfBTlxtta25ghQK OxLTBlYNvq1rUsmRN+pgH+abEviVjlFdIGpAD8qC5ACfozuBu2GGA+sziCNurF8xAxTvH0z S00/DbuW7KC7rPkPR/wOfFzPhsbygVUuz3hbqWZYq1jDNEXqq22pZ7BUMGEn7GyvHdDlPuy 6gnwBrhiVnD3QFmb3Iq8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:0FdlAYwqIoM=:GxhHeIiIbD1jtF2/ShrJmt rJMPqhUULR6INmujN/YmDyVopLSbnICQ3vr4Eugz4UTEzkqmocNI4fN56HLS4xdStTmrkTTgb kRVf5oY0ZP/wWYtUbjoDIA3rVII0pebDvWtWXlhC+DbQKOQee43QyO1VGypn2YiXivT8Zw4wf hpx6o8izvAzo620cg8olxfLv0A8sgHNDdUwD0zAZrJcztS4xnoMtkW1+OmfsSUX9tCQmP8FyH qCyf6uzqLJRETUf2Oec/hTkHZTecsZMle1jaGjbqK+Ow/JFily9dAQmV/8EuiZYBDip1dyjv4 nZhaDaYLPKzXrFUz3sW0W4aMmC7w97Xk0Dl6DSrrLQP4PccRfGQmvSswW3MoTIHobdRx/lzle DujlDzas8qZ77Oh7yMGMf/S1OshrgLos/nX/0rYuQI0FoYwdCLgHB8Gr9saGWyfsW9LIcnFd9 SwBIkE8h7K6St576Aq+KqPCe5WUc0mSyFusLtoLprtKI+1HmW8QrTysZvwep87eGonvVjht9g UbJ4ouxdTpKmX91107hdhf5YCpVZ3Zj2MYEdwH205pWxO9yi0/vAEfN5m5GUIW/FLj7XogKc6 Xr58B1PLoMXhIgsfkcynjazDNe6ogC8lT+gKbKjxWp/1atwKwDK5H40FYgoMOATD4eMxYkPYX SsUpXMGo8NeBWds3jF118XUT4Kp8eWdc5/HmiLb00fdMdcOP6OdeRtdAH1Hr2emyc2oUgVA1k NYyNYwc7btVwbPrWo4rQNKZlkxOuHy/r+yEyTc/cdbpQ0061zo0og529/8o= Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] [Anima] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 07:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Michael, it depends what "bootstrapping" means. We have a key distribution mechanism in the OAuth-ACE document (which is relevant to this specific discussion thread). Ciao Hannes On 06/06/2016 08:31 PM, Michael Richardson wrote: >=20 > Samuel Erdtman wrote: > > The company I previously worked for where looking into adopting E= ST for > > this purpose, the benefit of EST compared to cmp or scep was that= it > > defined the process for server side generated keys, which could b= e > > beneficial if key generation would be to cumbersome for the devic= e or > > if you don't trust the > > device to generate a "good" key. >=20 > Hi, these are definitely important considerations. > I would invite you to read the ANIMA bootstrap keying documents, and > possibly join the design team. > At this point I believe the bootstrap is out of scope for ACE. >=20 > We are considering whether to use OSCOAP for 6tisch though. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ542AAoJEGhJURNOOiAteIwH+wdjEKA6C8ccnpnRtazcPf0j 3m3loppRcCUECOaXIY/QY9jLneXkSLuFLZMPIwxEaQYsjF4CaA2zG3hFerSd1szV b8bLYYyVVVplLwHHP0uOgvfXOi/1bovx5Nd3s3XbzzA5A6qBoo4PcX5A6GZhsDGB 9NP+DcGE4Cg35yiymrK60E+rSlknCCcxZE+DeMgnuU8iOo/rD1vk6KcpWNIKsuvu uJfF5cw2IH0jK1hO/FjPkJj+lUAM9UTpG3knNmhs8Wy6XN+xjcj6lPq6qNYWgApF Fm7vXgWoqCGG4l6uS0J7xwrYVpPn/f3Vevo4lE223Jklg4ji191U0TIfdk5yRFk= =e8m7 -----END PGP SIGNATURE----- --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO-- From nobody Mon Jun 20 00:47:02 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 7AFB412D804 for ; Mon, 20 Jun 2016 00:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 kXlFK1cT-qwq for ; Mon, 20 Jun 2016 00:46:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201F212D5D2 for ; Mon, 20 Jun 2016 00:46:57 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LsPwa-1bPrE329Jw-011wx1; Mon, 20 Jun 2016 09:46:19 +0200 To: Jim Schaad , 'Samuel Erdtman' , 'Julien Vermillard' References: <04d801d1c1e3$28f0c620$7ad25260$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57679F4B.2080405@gmx.net> Date: Mon, 20 Jun 2016 09:46:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <04d801d1c1e3$28f0c620$7ad25260$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sxnlEd4RQcfmgs9fJ3WB8CPbSDO1HTIAA" X-Provags-ID: V03:K0:KsCdnZz7y2ZOkdLp9yauKHeg+DsYrBO9U7Q3zDwqTaJbNfv0DQs 6U6xseilKgRlKhIle/6sK21MoX9eGKQ2azSKcz87Q+PHmGe1ElCnlfgMKBXI8qgpUCjBXMs 0TPXxc+9fhAy/K42UfNMPjk4hmYzQh8UFnqsS7I1WzN1U94PXAfEHZ5ZNw6g/Er96Y3+fdz AxRbI8sT5zvi6SsoiIZVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:H7XbggXU5W4=:R4IisD4A0yIj18avrDbLC5 I6ywapA3gE9zWz4eTH1m3cGV71QYhO+MqS2KvUeAni8pfN8g+Got/BxaVtsVNnw8EIgEFcLPG HE21jrfVAb2jgZG3uob7WVkyg0qJevNMjIWKMlIIFtduk9ELWHhTpEt/iYvgz5+EOa0RyBt0B u2TdC/BORKR/AcaMQ8J5nPnJh/X3vZEVznvpoXBPK/Fxg+WIfqDow6/sFNzvvoOHWUfUDhN1Q zHJRNw4O577qBj2CRKnQgVJSGdqGKuQ2tyiBNYy8c0umSU8OUNq3bzS60KtVYqpRqq93m4wRs +d7nBel2wFM7Wy8YtapDSRusmSfPu2hN7J2vJeYvIzJOrEe+SWrEkYSh3t67ZG95GmYEKgykJ sgMRvlU038uCcThLBMdGeMfuMC8lm+P6rQZ5NYuKtUOBD+yyNN/KimZhBMwbbz8esRR2kLQgo i9z64TnSmYZcne79OayfBJLn0/1YrwYe73x4L/3tpq0teQ0UXAi6Vpzv2+ZkOffc3+q+Sh8Dp zZlQKC961FvUakPIcT3A7EFqIUsMdlrnGxdWmA1mnCviePkXuLKjw/af3rkSXjmDUkkorXlZn KezYnBYIi4+N7rTWpuwkvn9GnMUnJY1/syvasIzpWKBhOOPrrO73co2JmEDvpeOuSlujsVqKg WfSdiBxU420pnV2LnDm4v39olZGB1/FGYc597VVnhX194JIDbkLPF80wPYNpQCcw20yuiYAUn kVLXvK18JNgWF4c0OcQ8V83InohlHKxNF5L32bT6CYm82J7cLiQyFtuhg+8= Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 07:47:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sxnlEd4RQcfmgs9fJ3WB8CPbSDO1HTIAA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jim, the random value in the DTLS/TLS handshake needs to be random. In the OAuth-ACE framework we assume some initial keying material provided to the device (for example using some commissioning tool or during manufacturing). That key is the long-term key. Generating further keys that are bound to access tokens is then something provided by the OAuth-ACE protocol and also there randomness is needed when deriving the keys (except for the PSK case at the moment where that key is generated on the server-side). Note that some ciphers in TLS also utilize ECDHE and therefore also need to generate those keys. Ciao Hannes PS: Assuming wall-time support is yet another challenge. It is easier to find micro-controllers with a hardware-based random number generator than it is to integrate time into the solution. On 06/09/2016 02:09 AM, Jim Schaad wrote: > The client random value does not need the same quality of randomness > that would be desired for a private key generation process =96 especial= ly > a long term key. I would need to sit down and think about it, but it i= s > quite possible that a counter would work for the client random value.=20 > The main thing you want with this is non-repeating so that the final > secret is always uniquely generated. There have been cases where time > has been part of this random value and I don=92t believe that it makes = the > final key any less secure. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Samuel Erdtman > *Sent:* Monday, June 06, 2016 9:58 PM > *To:* Julien Vermillard > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] Constrained Environment PKI enrollment >=20 > =20 >=20 > Okay so there needs to be some sort of random number generation for the= > TLS-PSK handshake, I was not aware of that. (is the requirements on it > as rigor as for the key generation) >=20 > The other reason I could think of that is kind of mentioned previously,= > it is the "quality" of the generated key, in some deployments, FIPS > certified key generation is required and that could be easier to > guarantee server-side. >=20 > But it might be that there are no absolute situations where server-side= > key-generation but rather a design option. >=20 > //Samuel >=20 > =20 >=20 > =20 >=20 > On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard > wrote: >=20 > Yes, but since you need some random numbers for doing a TLS-PSK > handshake (ClientHello random) why a TLS-PSK client should no be > able to generate ECDSA keys? >=20 >=20 > -- > Julien Vermillard >=20 > =20 >=20 > On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman > wrote: >=20 > Hi Julien, >=20 > The first one that comes to mind would be where Pre-Shared-keys= > are used i.e. symmetric keys. These keys could be factory keys > used only to setup the PKI-keys. >=20 > If you look at EST the server generated keys is also recommende= d > to be wrapped in an extra layer of encryption in addition to th= e > transport layer security (DTLS/TLS). So if the transport layer > security is not absolute no keys should be leaked. >=20 > =20 >=20 > //Samuel >=20 >=20 >=20 >=20 > =20 >=20 > On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard > > wrote: >=20 > Hi Samuel, >=20 > I wonder in which scenario a RNG is safe enough for running= > a DTLS stack but not good enough for generating a ECDSA key= > couple? >=20 >=20 > -- > Julien Vermillard >=20 > =20 >=20 > On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman > > wrote: >=20 > The company I previously worked for where looking into > adopting EST for this purpose, the benefit of EST > compared to cmp or scep was that it defined the process= > for server side generated keys, which could be > beneficial if key generation would be to cumbersome for= > the device or if you don't trust the device to generate= > a "good" key. >=20 > =20 >=20 > Maybe Shahid could give sold more updates since he was > helping us with this project >=20 >=20 >=20 > On Thursday, 2 June 2016, Julien Vermillard > > > wrote: >=20 > Hi, >=20 > In industrial or enterprise M2M/IoT application we > often use PSK for authentication, but more and more= > user want to enroll the device on their public key > infrastructure like they does with some routers > using SCEP/CMP. >=20 > I wonder if it was explored to enroll devices, and > renew certificates on PKI only using CoAP and not H= TTP? >=20 >=20 > -- > Julien Vermillard >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --sxnlEd4RQcfmgs9fJ3WB8CPbSDO1HTIAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ59MAAoJEGhJURNOOiAtTaQH/idolw3bO70lj99GFl+PHSML BdXL/iTAzRbqpFeyW4GgolsMd8fe2NuJN/qlCcQZUpEe7JygdhnaludmjcTav3PD 9SbaZw3GZWVjEzYD2L7YX3G25rgstdTWzIwwYpwbtigGQTuZLObM3zqJdqPG+qlk MF6lY0xKFyYFe3EzdLMgf/f64KXEmlwXVtGSnZ0jiVrl9CIyy/HNwljIiotwNj+g VF1HNjnnoK4d0fJSoc4SMJGi4qEMAkJrmP1HhQosR9k32uY1I+T5KT4AAaPUsnLz upDfCz7NSkpc7frHoPOlT4Y+UX+hC9XRVrORs3iY9sFQOyBTo1iGl42mzK3UsmM= =2OIr -----END PGP SIGNATURE----- --sxnlEd4RQcfmgs9fJ3WB8CPbSDO1HTIAA-- From nobody Mon Jun 20 00:49:55 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 5FF6912D094 for ; Mon, 20 Jun 2016 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 eEiO6QH3LqYM for ; Mon, 20 Jun 2016 00:49:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E5E12B035 for ; Mon, 20 Jun 2016 00:49:51 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MFuWk-1b8qE62dyY-00Eyze; Mon, 20 Jun 2016 09:49:48 +0200 To: Samuel Erdtman , Julien Vermillard References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5767A01D.6060802@gmx.net> Date: Mon, 20 Jun 2016 09:49:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DBAPwBsTADn1WN3uEcj3pejaPipeCPHxw" X-Provags-ID: V03:K0:N8QIopNtBkiYJC75ciGvu/VIjc1k6w58GP9RUx6fBvTyYGusurb 7zZhlOJCo3Q0/cLVl48oBIGtvZFCcb3n8cCh69Q5sREW8w4rjbZgeIJkRO8bUN9L42raM0p jwvD16331S2JxuvlGRx3p6CFW34Gfidya+ZhYOVlOU2liNR3R2s9nAg6ZT2wSZBmJCn4uFc 7orI+aKgHl/kU1as2+PBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TFn8Io/jtC8=:u7IKr0Nh8/DnaFG6WI01kG Fe841Z/2C+NfaqQ9gTUGsOL6wa284fuBQc6AgDsnTjHtGFz4cTAghvIN/ZCoF3+W2CNbU4Oi/ Ti+fBE/xMojw4ts3WPKdOR7Y14tpnyiZU2wTGOsg8J0AGaI3v2NrTfGwyY/6NdU+uUEkgmSMj pHDW9Iw3/a2NGlDUIICiwPfzlE5K+Iyy/Njw4D/J+Ws3xIFdJz8yZ2Sn0GcaH06OgfFvV9PSm HOLSHbopsvLfKsoF1CUwMVpU/rHWtyjh3agtl9UEB5Cm+0YFp3y4Mt7Bp0eUkLMUhiNWTvyh6 8YVNu6E0HbYoPnfFe/82GWuTzTnCcCxp4V8swUs5MyPntrmxmveBvAFep9wVrHmR5KQxqbi3F H8YB6XqbbV+ybI7FwZXM+SfHWPhAwSLAkiX6UDF3tpwip6EtgGpHZq2iqet1YyachLUBL1OPG tAxVsNmMh7guMD0Z71fQtacr0taqFIc7EbDF7Y4CRsck0QyDUzKi42maxE87+420rIqsMjfFZ swbAP4+oTb1vVj888oRM6lwqsj5jwrM9/UNOXMti1azyJWxNUWjHFbicxnExMmEjfvZ+Ph/pU cvLqFBSjUSU4N3TOSHiZIkNHSeZzD6/Y4sRUfR7+6SyoZp9SLTK3tEvsSErd6+SEGUwzBVe7I 2cOPvRCyFdqwoV64q6FDiQjz0FMfR5WeII+vj+iVG5BmC/2MiNiN7VizAR00r0TO52Ms1AUUz TeWKplayZu5Y9O+8CesQvy3b+TFX4yzBEnLSaxaPrwdI/rusbEQzj+3ELrI= Archived-At: Cc: Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 07:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DBAPwBsTADn1WN3uEcj3pejaPipeCPHxw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Julien, for our current work in OAuth-ACE we don't need such support since the equivalent functionality is already provided in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02 It is work we re-use from OAuth and it nicely integrated into the rest of the flow exchange. Ciao Hannes On 06/03/2016 05:08 PM, Samuel Erdtman wrote: > The company I previously worked for where looking into adopting EST for= > this purpose, the benefit of EST compared to cmp or scep was that it > defined the process for server side generated keys, which could be > beneficial if key generation would be to cumbersome for the device or i= f > you don't trust the device to generate a "good" key. >=20 > Maybe Shahid could give sold more updates since he was helping us with > this project >=20 > On Thursday, 2 June 2016, Julien Vermillard > wrote: >=20 > Hi, > In industrial or enterprise M2M/IoT application we often use PSK fo= r > authentication, but more and more user want to enroll the device on= > their public key infrastructure like they does with some routers > using SCEP/CMP. >=20 > I wonder if it was explored to enroll devices, and renew > certificates on PKI only using CoAP and not HTTP? >=20 > -- > Julien Vermillard >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --DBAPwBsTADn1WN3uEcj3pejaPipeCPHxw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ6AdAAoJEGhJURNOOiAt6wsH/Asdrq5Jr5RolwBRdP1zgl3Y cp/z8KV2aBMI4U9FBn0bM6cG816NqX3RYOEA8GkQlN6aT92GVfvj3LRTmOhcRZ6U jQan3PGgir5ZWpeW6aMVkQhFUY0Ub3V7W0VQ+MudfFWtpmcj0aEXQcd8iD1JV/Mm u/VDNGF1AWmtV2DJot/6bTpnGNHZI2ySBnmaCbhsOiv2U/9uCmUn4CjOzZhG221Y GpPIreDzOJMOEnjTy2AvPxSEjXChyae+ie07FD9olnP+D86cft1MnA42mJDX/7xC OiexsTJL4G4DLssnkc5m3aR3DIcZ3sHbgWguJ6bQgr5CFsO+Xhlvh0dcdsen5Tw= =0dFE -----END PGP SIGNATURE----- --DBAPwBsTADn1WN3uEcj3pejaPipeCPHxw-- From nobody Mon Jun 20 03:39:56 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 9A11212D5AF for ; Mon, 20 Jun 2016 03:39:55 -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 VxHD1eki_Zm5 for ; Mon, 20 Jun 2016 03:39:53 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3BB12B025 for ; Mon, 20 Jun 2016 03:39:53 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h129so34075530lfh.1 for ; Mon, 20 Jun 2016 03:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YhHRObPMvNtvMXF/EYZ+Y8v371KiT4VzY06kf+Qu83s=; b=SSxdNKP0xAZVad/1NoMvHtucd7w+AJbVwCOXypJKk7/c8ZSMNJwd9SkGUpysCyaWg6 A1XNmY4SK41JYy+98OzrsQPICaSnEp31LPzZpd981sKuuMMbTxlWlNMW51IK1RTX7dsb 5TsliMNij7jvALdJrNlmPBvG0K1UpqXaxWtKyZxRvpcKndcyVOnZhLtX9nqunsxgv/bL VQPmMHL5R8alJHpzBFm+sECoDoahn2SmdkWh3//6pps2aAWSkOaHi+B8V1KmuVVNRB7F tzNKWtXUNlNwNxssxRlD8T1JMp4yxJvVz4GrhEGsG1lb76Dzm8s4IUixIEHiUB004ak6 3DfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YhHRObPMvNtvMXF/EYZ+Y8v371KiT4VzY06kf+Qu83s=; b=JH4XtQQ6ca3JGHbbv+vNbmvZEH2j0XbVxlNDfdaY9Bi9DN56b1zsXMqHPXYu/d002O IQstR6MzG+0oElKoIsYKwfNLoPNXUxiX9Ml/12IQ/6KvxaOO9v+GwygNcFGOwyUQ92Oo sSIPBL3jUgjqqjgcOzs5DmXZyzroiDIrEsISntO5sWL/3rZpUG3/q5KwKoUOS8oKSfcX ME76LoPcGiFlPU57iCaOBJ8bDSzmncx28dErz3x8UeQiB2QmB2Vz62G1ZBMJbS/8O1ii ZtRVZv/4T0HnsWph/yrupVgc9L4qVSaf8tvuR1PXnp+MshUVnopGzs1Dw/g9jwht4neB RJ8Q== X-Gm-Message-State: ALyK8tL12WYHYvddqBVYK9HzC94a4lQLYK78yXpsJt/Xgm2V1Tvbq7NPO2wYo2VLQ+323/2n X-Received: by 10.25.28.21 with SMTP id c21mr3160991lfc.68.1466419191126; Mon, 20 Jun 2016 03:39:51 -0700 (PDT) Received: from ?IPv6:2001:6b0:3a:1:8099:4d9c:a8e4:372f? ([2001:6b0:3a:1:8099:4d9c:a8e4:372f]) by smtp.gmail.com with ESMTPSA id d184sm3070279lfg.11.2016.06.20.03.39.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 03:39:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shahid Raza In-Reply-To: <57679DC6.9050101@gmx.net> Date: Mon, 20 Jun 2016 12:39:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7547AD74-672C-40E3-9881-193CFDBE3245@sics.se> References: <0EB38F45-003A-42DA-92F6-E166D9642010@sics.se> <57679DC6.9050101@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Julien Vermillard , Samuel Erdtman , Shahid Raza , =?windows-1252?Q?Erik_Wahlstr=F6m?= , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 10:39:55 -0000 Hi Hannes, We have looked at it a while ago.=20 Unless something is added in near past, LWM2M, in relation to the UDP = channel security, discusses certificate provisioning in high-end IoT = devices. Also. LWM2M demands the keys to be generated on server side.=20 In any case, our work should complement than compete LwM2M.=20 Soon leaving for summer vacations and will look into it when back. Regards, Shahid > On 20 Jun 2016, at 09:39, Hannes Tschofenig = wrote: >=20 > Hi Shahid, >=20 > have you had a chance to look at the work done by the OMA with LWM2M > since it provides this support as well? >=20 > Ciao > Hannes >=20 >=20 > On 06/04/2016 01:01 AM, Shahid Raza wrote: >> We (SICS and neXus) have been working on this since September last = year >> and designed and implemented an enrollment protocol over secure CoAP. >> Both the specifications and the Contiki source code will be available >> soon. This is done under the umbrella of a Swedish project called >> CEBOT: Certificate Enrollment in Billions of Things. >>=20 >> Regards, >> Shahid >>=20 >>> On 03 Jun 2016, at 17:08, Samuel Erdtman >> > wrote: >>>=20 >>> The company I previously worked for where looking into adopting EST >>> for this purpose, the benefit of EST compared to cmp or scep was = that >>> it defined the process for server side generated keys, which could = be >>> beneficial if key generation would be to cumbersome for the device = or >>> if you don't trust the device to generate a "good" key. >>>=20 >>> Maybe Shahid could give sold more updates since he was helping us = with >>> this project >>>=20 >>> On Thursday, 2 June 2016, Julien Vermillard >> > wrote: >>>=20 >>> Hi, >>> In industrial or enterprise M2M/IoT application we often use PSK >>> for authentication, but more and more user want to enroll the >>> device on their public key infrastructure like they does with = some >>> routers using SCEP/CMP. >>>=20 >>> I wonder if it was explored to enroll devices, and renew >>> certificates on PKI only using CoAP and not HTTP? >>>=20 >>> -- >>> Julien Vermillard >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >=20 From nobody Mon Jun 20 08:13:09 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 7A16D12D15E for ; Mon, 20 Jun 2016 08:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCBDx7Aa-1Nj for ; Mon, 20 Jun 2016 08:13:06 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6ED12D155 for ; Mon, 20 Jun 2016 08:13:06 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p10so165908565qke.3 for ; Mon, 20 Jun 2016 08:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RlPKF0+nXmgrwaaaIywOWo9elQWsgbdBHR05xgG2tHA=; b=KXOcEH7FSByUvWPscnT/T9886PDdQ8LOu3SuweZGrT8OyDGNQBl5eaenPJSnhcNl5v JvTv9oeKBuBtbqAYUdWE3fkOxEFNC/3ImrUGeTTp7ltYh3uXYi6BqA+SOwjNC+KJ7Zz8 QS7/XQDs1iqs037DOe7b5Df3Ne0H909o1gKuKqBVI0AaqdZ6jaLhtnluJiQhLsgKL6R3 BTcJTEJ84QYZh+ZB0b9PkA0AlYNKkgGiPHzBD3Y/eE0IgniHuXFJgDG/G7o3IvcWdQIr B4ik7Q3I1M43ckMJuuKkMjzraCmijrDAVoAlnKA3IG+tussyL4XLWTtiBBwRPFOLzh5g z/WQ== 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=RlPKF0+nXmgrwaaaIywOWo9elQWsgbdBHR05xgG2tHA=; b=Ud1A10DC0o9Z0/1DBV9i2DSy2e/vHpnRx6gAtCo+jrVyA62mrP++WsqM0HqKTSBFcH y1yzBcEe8RhVPyK2ll9wjfFxE9HNuJGUsKb4CpNzDwBkqyTPRoo2p/IQRFdMDU3dfsqd ZlVrH4k5ptR1Hswg6T+T3qBrrpJ/8KNMC809OAq5QrL1HlAeskooUiRU87yIJ8EJZi5a fgTDZjU7lZn+X23fpUPpKUjxGSjGveXWCzISLGzf1j/9njN4Gn61dnALhgvB0uLnN6R3 j8NLSgTkLoqqR9IgF/FJqZrVxYn21yatI8zObdpLbLYCeLwscJNhrPzyjoCmf7o21FmZ U8ZA== X-Gm-Message-State: ALyK8tK7ipLs5wW0E2eA16Guhw85EKzvdhg3wlBCoL33RCbLWUm4Hw8Xcnc3OWVhR3YgdoPOItRTxQrUndWnKg== X-Received: by 10.55.69.69 with SMTP id s66mr23736365qka.117.1466435585563; Mon, 20 Jun 2016 08:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.160.82 with HTTP; Mon, 20 Jun 2016 08:12:46 -0700 (PDT) In-Reply-To: <576798F7.5050702@gmx.net> References: <576798F7.5050702@gmx.net> From: Renzo Navas Date: Mon, 20 Jun 2016 17:12:46 +0200 Message-ID: To: "Ace@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig Subject: Re: [Ace] Meeting Notes 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: Mon, 20 Jun 2016 15:13:08 -0000 Hi All, The document I've prepared, about tls ciphersuites and time awareness: https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-4.pdf Incorrectly omits the use of raw public keys, as has been noted on the interim meeting. Specified on RFC7250 ( https://tools.ietf.org/html/rfc7250 ) , So RPK in TLS (that can be applied to almost any ciphersuite using certs I think) is a solution that does not need time awareness of any kind, hence joins the club with PSK and SRP-based . Authentication on the RPK case must be done by an out-of-band method. Its discussed on Section 6 of RFC7250 (https://tools.ietf.org/html/rfc7250#section-6) I am very sorry for the omission on my original research, Saludos, Renzo On Mon, Jun 20, 2016 at 9:19 AM, Hannes Tschofenig wrote: > Hi all, > > I would like to thank those who took the time to attend the virtual > interim meeting last week. > > Here are the notes: > https://www.ietf.org/proceedings/interim/2016/06/16/ace/minutes/minutes-interim-2016-ace-2 > > (Thanks Samuel.) > > Here are the pointers to the presented material: > > * Clock Design Team Report > https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-0.pdf > > * CBOR Web Tokens > https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-1.pdf > > * ACE-OAuth > https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-2.pdf > > Here are two additional documents from the design team, which were > mentioned during the call: > - > https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-3.pdf > - > https://www.ietf.org/proceedings/interim/2016/06/16/ace/slides/slides-interim-2016-ace-2-4.pdf > > Ciao > Hannes & Kepeng > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Mon Jun 20 10:25:47 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 7B2FA12D839; Mon, 20 Jun 2016 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 V50z7WsFTRxl; Mon, 20 Jun 2016 10:25:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E35512D838; Mon, 20 Jun 2016 10:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1466443540; x=1467653140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hF4iKYZm1fgaXotTnw3uubQPoB6BopIJ4vgf3MGdHaM=; b=gYOfmWooGZpVHVvJdf07prFpFkfNWyDLCo4+hPrm43PLNzo3r0iU86vX xUmSXULNAwZ1SK0/P8RLx2dvl9v5duVQItu1k7CJfRDWy9YKIP393HrtH pnICF6jdOE6wlXDmtVlLiiQDP2qUhqmtWUo6ADpm2ph8nWi0MN87wj4aW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAPJmhX/5pdJa1dgz5WfQa6bYF6F?= =?us-ascii?q?wuCPoM3AoE0OBQBAQEBAQEBZSeESwEBAQMBAQEBawsFCwIBCBguJwslAgQOBYg?= =?us-ascii?q?WAw8IDsEeAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWIHgiCToJDgWcWgyyCLwWYd?= =?us-ascii?q?gGGBYgkCoFfh3+FOo92AR42g3BuiUl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,499,1459814400"; d="scan'208";a="120601083" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 17:25:39 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5KHPdF7004967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 17:25:39 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 12:25:38 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 12:25:38 -0500 From: "Max Pritikin (pritikin)" To: Hannes Tschofenig Thread-Topic: [Anima-bootstrap] [Anima] [Ace] Constrained Environment PKI enrollment Thread-Index: AQHRysc5Ayl2YWl+EUKJLE6BGfIPoZ/y78kA Date: Mon, 20 Jun 2016 17:25:38 +0000 Message-ID: References: <14558.1465237865@obiwan.sandelman.ca> <57679E36.1060806@gmx.net> In-Reply-To: <57679E36.1060806@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , Shahid Raza , "anima-bootstrap@ietf.org" , "ace@ietf.org" , Julien Vermillard , Samuel Erdtman , "anima@ietf.org" Subject: Re: [Ace] [Anima-bootstrap] [Anima] Constrained Environment PKI enrollment 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: Mon, 20 Jun 2016 17:25:42 -0000 > On Jun 20, 2016, at 1:41 AM, Hannes Tschofenig wrote: >=20 > Michael, >=20 > it depends what "bootstrapping" means. >=20 > We have a key distribution mechanism in the OAuth-ACE document (which is > relevant to this specific discussion thread). >=20 > Ciao > Hannes Hannes, are referencing this statement? https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02 This framework supports a wide variety of communication security mechanisms between the ACE entities, such as client, AS, and RS. We assume that the client has been registered (also called enrolled or onboarded) to an AS using a mechanism defined outside the scope of this document. In practice, various techniques for onboarding have been used, such as factory-based provisioning or the use of commissioning tools. Regardless of the onboarding technique, this registration procedure implies that the client and the AS share credentials, and configuration parameters. These credentials are used to mutually authenticate each other and to protect messages exchanged between the client and the AS. My working definition of bootstrapping is exactly the things that are decla= red out-of-scope in the ace-oauth-authz doc.=20 If you meant a different doc could you provide a more specific reference? T= hanks, - max >=20 > On 06/06/2016 08:31 PM, Michael Richardson wrote: >>=20 >> Samuel Erdtman wrote: >>> The company I previously worked for where looking into adopting EST for >>> this purpose, the benefit of EST compared to cmp or scep was that it >>> defined the process for server side generated keys, which could be >>> beneficial if key generation would be to cumbersome for the device or >>> if you don't trust the >>> device to generate a "good" key. >>=20 >> Hi, these are definitely important considerations. >> I would invite you to read the ANIMA bootstrap keying documents, and >> possibly join the design team. >> At this point I believe the bootstrap is out of scope for ACE. >>=20 >> We are considering whether to use OSCOAP for 6tisch though. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Mon Jun 20 23:32:11 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 0D62212D0E5 for ; Mon, 20 Jun 2016 23:32:10 -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 jPnbEKZ0-6LO for ; Mon, 20 Jun 2016 23:32:08 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA8E128E19 for ; Mon, 20 Jun 2016 23:32:07 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id xp5so3641990lbb.0 for ; Mon, 20 Jun 2016 23:32:07 -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; bh=B5mAuZ2JRGSnGjxmxeePDZjit4RCjhLt7pPJvMGkDQ4=; b=Kf41KZriNhoyvcNrJ1Gsi8ssSvw2+G/09HxFGWJNzADODSgcYY8rWd3LerS3rkm4Fp 4lb935dLlUfOCdRFl9lqoVJpfIgfNpTRDMZybIgCg5/ZeMcaCkBXfY+KPOtkF51zeDue ObsDEQ/JF2jwBEjTiBX4B2eCsSNxVp3wOzuLa7BhS7nESQTia9jp0gGwWUWGZOg8MJnG ACk7d9XnJDDGgWRCMIf205jC5dktbIdh8KIrNP9aUvc+U1rqGJVbOKACOfFXWoUForS9 k//TOnm9wEh6CaCOTqemLFpcE9+Vror7GfhTZHDlT866gl3h80wiHtPDs8/gupneopiN RYMg== 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; bh=B5mAuZ2JRGSnGjxmxeePDZjit4RCjhLt7pPJvMGkDQ4=; b=BDtDyW4XhUX8kE47HHUpO/wYsBiocgQ+AonB2Yw64zPdwk6ucqSNnfB8X+oO67J/ow VIKFe0m+tSK3DyxhTJzSC+5AwIJqbezPTGU07VxQTD6xfwOazYdHamie/HWGpyLXQHiN Hg8UMU+5jzeNRNfuxAKN4wZoB62dq5GDQZ1qvN/caEVy72Ek8ahvj0KQmaeVpbZmGu6n v/XEAVwvb17HnhzC4RTn8ymCi+GlqqviBG/zwTFpTRzOULcmNwV3Bf1Zzgnz2Vdr53CP TfJkc89i8yD3CLL94cAlA05f/KG8Tnx1W0GjZFEPK9L26Oz/Y5wbIw+iqIHllXL1y7uT i/Cg== X-Gm-Message-State: ALyK8tKYGJml5TDpszJ50e8TObejfY1IYzJtLNLugozPH8JdZXJ3uF9BnBvwui5US6RHAXuKnDUfO55gHk6/Nw== X-Received: by 10.194.109.232 with SMTP id hv8mr18137197wjb.115.1466490725378; Mon, 20 Jun 2016 23:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.114.232 with HTTP; Mon, 20 Jun 2016 23:32:04 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Tue, 21 Jun 2016 08:32:04 +0200 Message-ID: To: Ace@ietf.org Content-Type: multipart/alternative; boundary=089e010d8676c0c6a00535c3fa5b Archived-At: Subject: Re: [Ace] A question for the ACE framework and CWT 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, 21 Jun 2016 06:32:10 -0000 --089e010d8676c0c6a00535c3fa5b Content-Type: text/plain; charset=UTF-8 It was pointed out to me that the sentence below ended abruptly (thanks Ludwig) "On the other hand it is not relay necessary to have it there, the reason for the mapping registries is to avoid CBOR label/key conflicts between attributes. So information about" It should be On the other hand it is not relay necessary to have it there, the reason for the mapping registries is to avoid CBOR label/key conflicts between attributes. So information about major type can just as well be kept in the specification defining the mapping. //Samuel On Sat, Jun 18, 2016 at 12:38 PM, Samuel Erdtman wrote: > Hi > > When writing the IANA mapping sections for the ACE framework and CWT I > first required registrations to include the CBOR major type, Later I did > not (e.g. > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02#section-10.7). > I would like to here the preferences of the group so that we can update > mapping registries to have the same format. > > The benefit of having the CBOR major type in the registry is that one then > has more of the important information in one place. > > On the other hand it is not relay necessary to have it there, the reason > for the mapping registries is to avoid CBOR label/key conflicts between > attributes. So information about > > In COSE (https://tools.ietf.org/html/draft-ietf-cose-msg-13) it is > included "value This contains the CBOR type for the value portion of the > label." > > I would vote to keep data in registries at a minimum, i.e. exclude CBOR > Major type from there. > > Opinions? > > Best regards > //Samuel > > > --089e010d8676c0c6a00535c3fa5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It was pointed out to me that the sentence below ende= d abruptly (thanks Ludwig)

"On the other hand it is not relay n= ecessary to have it there, the reason for the mapping registries is to avoid CBOR label/key conflicts between attributes. So information about"

It should be

On the = other hand it is not relay necessary to have it there, the reason for the mapping registries is to avoid CBOR label/key conflicts between attributes. So information about major type can just as well be kept in th= e specification defining the mapping.

//Samuel

On Sat, Jun 18, 2016 at= 12:38 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
H= i

When writing the IANA mapping sections for the ACE framework= and CWT I first required registrations to include the CBOR major type, Lat= er I did not (e.g. https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-authz-02#section-10.7). I would like to here the pre= ferences of the group so that we can update mapping registries to have the = same format.

The benefit of having the CBOR major type in the = registry is that one then has more of the important information in one plac= e.

On the other hand it is not relay necessary to have it ther= e, the reason for the mapping registries is to avoid CBOR label/key conflic= ts between attributes. So information about

In COSE (https://= tools.ietf.org/html/draft-ietf-cose-msg-13) it is included "value= =C2=A0 This contains the CBOR type for the value portion of the label."= ;

I would vote to keep data in registries at a minimum, i= .e. exclude CBOR Major type from there.

Opinions?
Best regards
=
//Samuel=



--089e010d8676c0c6a00535c3fa5b-- From peter.aldworth@arm.com Thu Jun 23 00:20:37 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 E340212DCF2 for ; Thu, 23 Jun 2016 00:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55cradrHJkVo for ; Thu, 23 Jun 2016 00:20:36 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE9B1288B8 for ; Thu, 23 Jun 2016 00:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V9R3KpoVPtV8h1nlAAB809rBFFM522pUVyi0VjtJR8E=; b=LUxjXIkw5FzDjtbwKv9K/Ruh/Kp6rHU8fGtpRT9Lcr2Tn6ENCs5P2YfDy4orGjxiDIXHeUJuaWLESnswCOGoxoh5Z3zZQ2F9ANCQD0urUss3JkBsEO2Nxx7JBNEp5OiBUHzKJcA6usDLX2DCkAWrhEeOuFtvOtLwa4YQhjYTa0E= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0245.outbound.protection.outlook.com [213.199.154.245]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-63-ZMGd6nBxP6SCgKNeaDaiRw-1; Thu, 23 Jun 2016 08:20:32 +0100 Received: from HE1PR0801MB1594.eurprd08.prod.outlook.com (10.167.191.14) by HE1PR0801MB1593.eurprd08.prod.outlook.com (10.167.191.13) with Microsoft SMTP Server (TLS) id 15.1.523.12; Thu, 23 Jun 2016 07:20:29 +0000 Received: from HE1PR0801MB1594.eurprd08.prod.outlook.com ([10.167.191.14]) by HE1PR0801MB1594.eurprd08.prod.outlook.com ([10.167.191.14]) with mapi id 15.01.0523.019; Thu, 23 Jun 2016 07:20:28 +0000 From: Peter Aldworth To: "ace@ietf.org" Thread-Topic: ACE Clock Synchronization Design Team Conference Call Thread-Index: AQHRzR+3f2UaFqxEpki6z2qmk2Fz0w== Date: Thu, 23 Jun 2016 07:20:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.29.250.60] x-ms-office365-filtering-correlation-id: 56d5b8bc-1718-48d9-75d1-08d39b36daab x-microsoft-exchange-diagnostics: 1; HE1PR0801MB1593; 20:8J+5DRNNH7agZ2KtozGDQPyVq0zgZ2l+GuG+Q8YwWk3gkbwdB9+laG/x86+9ZKZLUcDbXCl7fqRD40/dm6V7VJzx0qJJv68Am9jEwrjzD60lkie6Ey8Kgm6nAaxFII6DwDQlyKegmn+j4ZCKMts649odzzLmWUs+zjHtd9TCZHU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1593; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR0801MB1593; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0801MB1593; x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(40434004)(199003)(189002)(30513003)(2906002)(1730700003)(2351001)(189998001)(5640700001)(81166006)(81156014)(8676002)(77096005)(122556002)(68736007)(2900100001)(3660700001)(36756003)(87936001)(3280700002)(8936002)(10400500002)(86362001)(5002640100001)(110136002)(92566002)(4001350100001)(97736004)(83506001)(102836003)(2501003)(586003)(6116002)(3846002)(106356001)(106116001)(105586002)(107886002)(5890100001)(7736002)(450100001)(101416001)(7846002)(54356999)(66066001)(305945005)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB1593; H:HE1PR0801MB1594.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <900822454400DC409C90DF9464549BD3@eurprd08.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2016 07:20:28.6469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1593 X-MC-Unique: ZMGd6nBxP6SCgKNeaDaiRw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 23 Jun 2016 04:57:22 -0700 Subject: Re: [Ace] ACE Clock Synchronization Design Team Conference Call 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, 23 Jun 2016 11:08:21 -0000 All, Just following up from our discussions in the call on 20th June: Typically an off-the-shelf commodity MCU standby power draw (with RTC enabled) would be less than 2uA at the battery terminals (including power draw of constantly running 32kHz crystal oscillator). So using a 150 mAh coin cell (with a rated 5 year self discharge time) with an MCU in a low power mode (RTC running) you would theoretically get greater than 8.5 years of battery life - ignoring self discharge. Using a "state-of-the-art" low power MCU you might get this up to 34 years (again ignoring self discharge). Basically standby power draw is not a limit here. The above assumes a commodity 32768 Hz watch crystal which gives 20ppm clock accuracy "at room temperature". Expect a volume cost for the crystal in the range $0.10-$0.25. If you need better timing/temperature stability then it could become significantly more expensive in both BoM cost and power consumption. Regards, Peter Aldworth IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Jun 24 04:10:08 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 B76ED12D0C7; Fri, 24 Jun 2016 04:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 QvCehclwKCBV; Fri, 24 Jun 2016 04:10:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEC512D0BF; Fri, 24 Jun 2016 04:09:59 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.20]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M0gww-1bVSsE1KV4-00unBs; Fri, 24 Jun 2016 13:09:56 +0200 To: "Ace@ietf.org" , "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <576D1500.3030403@gmx.net> Date: Fri, 24 Jun 2016 13:09:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB" X-Provags-ID: V03:K0:zO4xZNfsMmZhLXzAe8QZcZO/f3YaJfMQtQWIE4oC3MFjgfXt624 6rf+OWASZLurr8pkzFsMpsTfuZutJi0VhJP/WUuQDCdTFlhv29x6u+HFEboWslWuotR48q/ PT3HUDzeGekfulkkO/SPEAbslAUcNnM2fJnAip5VKPloqtgWENAeaPd/2UDmNvkhXgA7TvY kq0rqpy06Ky74YqeDamhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NT8ZL6wd/zE=:6AC3d8Gy7cr/miCuYAdJPH 62wMn2lV1PiyIjsmgwoTEawj+dtocdoeg5Xg2+PA/NTgQ3+1/pTIJfmZZ5UZXT+/xcxe3zVGd OJVbmHjs9ow0esjVaB7tyLoOS15u5778j6zEftEHwK3lAltoshY1xLruJUnlHd6o0oaRlrIaH h5E2FTWnM3fzXH0LPuDLyu+LgSmG9MjN65+JJb4xwWz8EHDde308KXaPBn8iMfP4Vedi+0RMp l5A0aBav8oz/h3oLKyMqc1VplJSwEJAF54KDICwbfUlatikjYYpqYFfMlF2xZe0YBywO9DMkP e9jsghWFx1H37s3qUGPhSQmfBGlENV51nAv3U3CHLozePD8rXnesCfN4fYjA054S/4muNbMiH QjUeWgxFzhp8Ge0Tvv8KTD+3+0yGkXVyDL8wTLig6gqxgsaEyWLN0aXyEbr0Kd7ymB2WfVo4n oBgi/33qu1YAzqhQAdBdZc//0SSNDIiH8aKoWXwKAiipV8dmFoBc5pAWLcfmNvbp0yuZjGbXE GW7m+OKHcYsmy5nO6JI85dgDOrPGKFHX6mgRqfU9oN+nVdLidl7gpUtIcDDsHHUKDg9aI9u1V z5oO9tcg1sMXN7/rCcQp69VV8qYLmNB+dN4ayj1GGfuDUL61QkGK3Ff4fTfTxMl+qbOVn7Cbm yJc4YfmJ0oMts+89xqB5VK6sAgcBeY3E1n4IIBR2UHBJu5I8umPsSc1m0OPezKhurAcGVVGql KWN0LyS0fZ350laPeDOv3tp6/dzjUG3ijnxU8d93O6X/AA4QWoJfOFxNk3g= Archived-At: Subject: [Ace] Reminder: OAuth Security Workshop Registration Deadline 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: Fri, 24 Jun 2016 11:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, if you are planning to attend the OAuth Security Workshop in Trier/Germany, 14th & 15th July (i.e, during the week before the Berlin IETF meeting) then please registering today (since today is the deadline)= =2E Here is the link to the webpage again: https://infsec.uni-trier.de/events/osw2016 I will again be an interesting security workshop. We have great keynote speakers, interesting papers, and also left time for discussing future work. Ciao Hannes --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXbRUCAAoJEGhJURNOOiAtjRoH/iZhnP7h/+7XCEAGgretNzIs GClKEpYoBuGQNTJ96662udw7cPqQJcZJuVdon+DGoxwlvl5lzIFJaj2M258rOVQV IPIlj3uPHezN0Q+TFJ2D1a5u6m7YCYUWrUDmMBV0wXX08Fu/jxlI1GqaCCvSOUHG GE48S/8Ylr4T4mMmYIZEC3p/oj5H+meXYTqZuYjFFpdGti8bbQYZGbraGzuiR/tG Ea9/Lss1yHFr3MThuwFZbNiqcRbRttCC42huRBsOSaQSJTfiKthMbDm1uIKkfKDb zr/EBSIhG8jAUsNJsxNJf3dg3ACBRvsf4I6SmtdjGTr3W/PEtpL+QpJyof1xlqU= =G8qA -----END PGP SIGNATURE----- --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB-- From nobody Fri Jun 24 09:07:24 2016 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 CC83D12DC64; Fri, 24 Jun 2016 09:00:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160056.10933.88688.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:56 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, ace@ietf.org Subject: [Ace] ace - Requested session has been scheduled for IETF 96 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 16:00:57 -0000 Dear Hannes Tschofenig, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (2:30:00) Wednesday, Morning Session I 1000-1230 Room Name: Bellevue size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: core cose oauth saag lwig tokbind tls Special Requests: Avoid entire SEC areas. Please avoid a session on Friday! ---------------------------------------------------------