From nobody Fri Dec 1 01:48:11 2017 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 C776612785F for ; Fri, 1 Dec 2017 01:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZqXltGLBLtU for ; Fri, 1 Dec 2017 01:48:06 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0070.outbound.protection.outlook.com [104.47.2.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35A9127333 for ; Fri, 1 Dec 2017 01:48:05 -0800 (PST) Received: from AM4P121CA0002.EURP121.PROD.OUTLOOK.COM (129.75.24.16) by VI1P121MB0064.EURP121.PROD.OUTLOOK.COM (129.75.190.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.11; Fri, 1 Dec 2017 09:48:03 +0000 Received: from AM5EUR02FT062.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::202) by AM4P121CA0002.outlook.office365.com (2a01:111:e400:e2b1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.11 via Frontend Transport; Fri, 1 Dec 2017 09:48:03 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by AM5EUR02FT062.mail.protection.outlook.com (10.152.9.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4 via Frontend Transport; Fri, 1 Dec 2017 09:48:03 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (94.245.120.80) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Fri, 1 Dec 2017 09:47:53 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0040.EURP121.PROD.OUTLOOK.COM (129.75.191.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.11; Fri, 1 Dec 2017 09:47:52 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0239.013; Fri, 1 Dec 2017 09:47:52 +0000 From: Esko Dijk To: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thread-Index: AQHTY/Ja/17ZfrzpmEybigwONFOQFKMuQr4w Date: Fri, 1 Dec 2017 09:47:52 +0000 Message-ID: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> In-Reply-To: <20171123003050.GZ82825@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [83.85.149.7] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0040; 6:3R/9O2ohrx2pa+g26PHQCD/qr0mkwxfPIEwx9xg2fFhZXWy5Z078/OOsTz4yrUYmuTIUfrxx4alTQTQ9y+tb1CggOlE1ptObNTz0lSolZhZ63t0XPwL1OKAGqAsP1JGBOYeUynaTOUWaR2IVESI/+kHNatTY9lWldhw1XUfN4SrXAsK05xzyf2InCzrhOiIeUWLKtYw+m9q59WA9G5IQl48/0F49tORop//PqTNvLuqG1tFSq0tc6jn/9RR0xNF6luMl4rQ7xfJcPghVqrk99hdoKz/bsKFSdsb7rYQzyYPPCX/KmRg5KMaivhDspe5RT0EJX8H2bI2TmmZHOBBoJ6/j90EfVyI2kC7zyQUBId8=; 5:oTsKnwe9OG3T6EiTnMRSD47HTfjEGMB7R7t6U5zA2XnS4GA9Xg9fOlSVClcTQjh6T62VdWEhEprEk1mYtrFQxekDuKq7IBpLnGhYkpKSxI/G9GhmswyuSXV9Ze8oTS6Y/SHn8wzIq5AXw/7H3qGry5MZvsv6hGI1sXyAuuFhg98=; 24:u9GrDjtPi6wz8XzpZAG8hbktMEtlevMSdNlRrtcgRsywg4C6qveoO/q0NSVi26GEIMSyc4a8xLPnRljPo2HUsDC7Hk4trDNpZIIgd6TDVbo=; 7:uswcltPa0RsTniNN7jXTH5nEVTmjHiQT5CfK16KG3uRJcxE+yAXzDiou5xTwuMWp+L2mJDlGYhLmtUubh5Hgugzn/ZtKzditkEHU86XkGgxW5CgnSOE7XGQJeRldcb+mkDOwOQHIfg743SvAmzJunb0GkCrFpN8jPuPc0Kv5l735UAliFnH2MoPL41fszBiS3iKCl1ZTg262YDiF5/jou4UmC6gtv5vIfUAilJX2HUEXcN5XIaUAQrPHa0ded8Oh x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 14c23ef6-fd1f-4203-3665-08d538a09d9c X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB6P121MB0040; X-MS-TrafficTypeDiagnostic: DB6P121MB0040:|VI1P121MB0064: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(788757137089); UriScan:(278428928389397)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(6095135)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231022)(93006095)(93003095)(6055026)(6096035)(20161123561025)(20161123556025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123563025)(20161123565025)(20161123559100)(201708071742011); SRVR:VI1P121MB0064; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:VI1P121MB0064; x-forefront-prvs: 05087F0C24 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(366004)(24454002)(189002)(85714005)(199003)(13464003)(99286004)(105586002)(106356001)(33656002)(5660300001)(230783001)(413944005)(966005)(478600001)(68736007)(7696005)(3846002)(6116002)(102836003)(316002)(110136005)(97736004)(54356011)(2501003)(76176011)(3660700001)(8936002)(2906002)(3280700002)(53546010)(229853002)(2171002)(6246003)(53936002)(74316002)(2900100001)(189998001)(6306002)(9686003)(6506006)(6436002)(55016002)(25786009)(305945005)(7736002)(8676002)(81166006)(81156014)(66066001)(101416001)(86362001)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0040; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0040 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131565952832976485; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR02FT062.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39860400002)(39380400002)(346002)(376002)(2980300002)(85714005)(199003)(13464003)(24454002)(189002)(8746002)(7736002)(8936002)(106466001)(3846002)(23726003)(102836003)(6116002)(356003)(74316002)(2501003)(230783001)(105586002)(66066001)(316002)(22756006)(53546010)(189998001)(33656002)(25786009)(6246003)(86362001)(2950100002)(53936002)(305945005)(8676002)(47776003)(81166006)(2900100001)(81156014)(2171002)(50466002)(5660300001)(498600001)(6306002)(97756001)(99286004)(2906002)(46406003)(110136005)(229853002)(9686003)(55016002)(97736004)(7696005)(68736007)(6506006)(966005)(413944005)(76176011)(54356011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P121MB0064; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT062; 1:7n1xUIT+bAGbqyIwn5m5Q7XDAGRhwyAQkJ6K31gSzZaZQrGvBrronNeRRhVqt83wLhEjuWmVTsPZPvDhIpjDELAgRESH7ugZjA3zCqTpu0KNBBNAUb5E0drHlOoe28nL X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4628075)(201703131517081)(2017052603286); SRVR:VI1P121MB0064; X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0064; 3:sSf0FvvQWBGKM83H0BHVCNHAFgGE2+4xhUzwUWQcNsAGOG4LFxLmYEMLhOcYMcsBVBiEW9B6XQI5y7f3Ru31jnuRFsKUSCYxLdRzvIdvgjw11896Y0M9zKZhZqnc9hQ3qMJJQKxXg58gDbXQ7U0tnZNyTuhCg82IC9NywyLW25mx3ioL/wSsHITMvIsHK1nyiiJerQK6rNs2XX6PgXW9a9JWTLHfINuZNMoF1nKBmY0PVK83s6fJANUMTC4trLSeYSixK0mYIM2dSqVdIlMLYNfOb7GT2sH51Bd/VxNgh/bK02pI4EdTbaxfG/wukKwX6lLDJ+dpvmN6dSFDiCanSs0MnOMb85p6SzKBboI/ib4=; 25:5cQRHDb3Nuoe+t/yEuZCMPWKBjEJ0Cb3V+pjvFtjkemUyz+UoAuEh8GcuCDLQWINMRc2mExz2u45sCOSI1dtVDYOtWOjpBRUdhzCg1l4oAmEcH9HEX7AAUCaUFDmHObN7tn0cxhfeo47+VZRwRkhUhi6n1igLOPWILDh5P9TMAuaSEPhSSwG8r7aa6+iNEb5szaM+MlHjk7M80e3F3xz2kAmZIgJlrVahgIX87iaa/l5LRLpzpKP5S8NS4SUIqlj4floHBkZvt40Ntgj89P/QhS7OPWEOvPv1il+rFg3hgaQ0TbeEIvwkh8vM+DDkVnAvovuDmAE2cdgx4N1Q23kPg== X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0064; 31:wcFw7VUfLwab+ngaKyhaz2S5ZvaCy00ZDCotJANipQ9OqBuaAvlcb+bCxem5xQsGYZNEi7TgNxLSpWFljQcba72ZZG0tacpaznuFQ8mv+VLQ8uM3ziI4XoBkmm56B9rCKJ7FHSDwj3Fo5xOGvYN0B/mqnCIQhKH/9NsU7gnJZ8w8m7SRTvGui8w96UvCpxylDRbB06AOmNcpE3wn0RF+aR3RrnaT5JDqUnzpVUOYacg=; 4:EIEj8VGn1IAsCVZoCTEIWS76ih+mR1FKKINVjIEyoB5CH9glCVJIQErlc/9m7agr+J0gCzjCTnvEVeS+yf5olSIDS7lgG0Y964jAqMFxOVkWp/qLyUDCuZzkDZxgHcSGk7hDK3Qze84o+aE94f4Qy/E+qETOh/kMCeOkiRwch5ERv+e0MnSZCgFSUkhHRM7JvXQKujdHhPxhlPlIO+tcoqDf8ECusM6OWOO7R7TJrNZ0WW4+msQTQwkRgysngPKkwsVCZhspPSfN4u8Lrhmok/N1ukPp6gPVNJywL31gzdi0f9DFymk4+gr3JEYuVzY4dhKDaKnGgPSDFnyKNJpgAcaTgM8b0BWnp50l0/8tU8AbD7pruKo3sE6sCr25EmCN X-Forefront-PRVS: 05087F0C24 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P121MB0064; 23:2pMZV+yQTMCEl1XfYqh/q+LGMk9kEjtfGR8BKNwTX?= =?us-ascii?Q?KU+tLNZyToD6UHzCqoaa1HFjUXAcpBi8q89zDSoZI4s3/wEll/qULipZ1fpx?= =?us-ascii?Q?qnVNQcBneJRi1QqJq/Zxj8XzgDkscZPFbxrr3kfarz9vvFbi3eegCs9s29Vq?= =?us-ascii?Q?H4tYHLGdhSHtBU2dLdPL2fLJNbtaFEPH69LNH9UakTio8KSc8lk5B5pW+VD6?= =?us-ascii?Q?GtyFFHHlSVwn8H+n41IwNhg/RoVglRfnm+S7slU9QV5aNcjuMqSzK8MCSZz4?= =?us-ascii?Q?EDICgUbGI1C/TwVKkMhax3Re1TDF/jxodww/FIijLwIxL4sWn1zzTKJXCHe5?= =?us-ascii?Q?9/xbZFy31NCIFLeAwVVnp7U+67vem3d4c9jf6ATt310V4OthjASqBpkoMoh5?= =?us-ascii?Q?ZzUF4gs9IC94PKC0VXIXTtqzGBLCiwgKIIQieWheXRBvxVvdvadG5VSz+nn5?= =?us-ascii?Q?pFKk0V8w0LmvJGX5Rh89ChXidro/sNSB2fjFtpRfcBmKvXAkAboKlxH2hu6G?= =?us-ascii?Q?0B2W3rOfBwSe5T571t2NZg28FWytHwxQlKnNjEgpG/GTcZtoYaaCrjFhvLW0?= =?us-ascii?Q?A8zptyOxv6t6ntmh4J85JIsmIG3YnU9a2MidWpdVIkz54zjBQnf60XDmAkZ3?= =?us-ascii?Q?FLXclAgdYhoXmIS2zeqeV9nspzO1cw9XeJf66imvJK3M1BWLuBEQH4s2+xbQ?= =?us-ascii?Q?y0gISGslS25PdaHTQ5nyLsl7XwCGY2OaOOSjH6ym90nK9WRSldDKs1UhWfEs?= =?us-ascii?Q?uE1nWYAdk4qEjGAtwt1w0SWYm9QHUpLXViJH0VATB/B9dl+KtzE9AeSgHpIl?= =?us-ascii?Q?6ex1EFAGVTOwYOZv/5LwkgtL+mIT07W/Ebn9BaJe4ujYHvGowjc1e9SqMhTv?= =?us-ascii?Q?WgEjSSlTTQDrbXEFf/CI+ljtFF9kQei93zcGDRvMzi8DS3bbctbngkPiZcTT?= =?us-ascii?Q?kfC7z13zHOlcAb/cQqSKtOP/5PTEQvw9rjPx2JVk4HdY7/glR5vakNITmPNn?= =?us-ascii?Q?dPOAD0/qOvgS9YRRl5DcOeSNMAgV5XFKYLJ/sgTAnMAHfFQdI3/W1szv1mqh?= =?us-ascii?Q?E7ObfwruQsNuFpl7DyYOaihqnsFjkmYH0RO6HZfErLu2U+1GJy/MEekJDsYQ?= =?us-ascii?Q?qot8srTSBV96+hpWKbfPF4vNCTN/V0hnm8Vo/hfOPt5H+QTVzPG5QOGk67C1?= =?us-ascii?Q?qmFjnTLvcJ1gFwk/XOybCtLGvQpbHR0hx66UYy91Gy1nvgZZOyZcKTZxfG9O?= =?us-ascii?Q?4KV9Z+gAjFVK8pvf3jJN1TDldViPP1kOM3W05m9t7DNkKW4siaP2BxvlDQ8f?= =?us-ascii?Q?zcnS2S/4uE4Z9izvS4J0mUXkbdd0wfOtyOhfkXoXw1eo3mro5AZXcrteEEJJ?= =?us-ascii?Q?3VSvEbi8XJaZC0rPZc9amUqwSZkYR/AIhj6untKAoPITiTXEe4B+Hja4QORG?= =?us-ascii?Q?7Yz+Qcisp3ypqS+uQDlHKq7EXo+Vck=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0064; 6:/JZrfcn4+acLC9AgX0x0kN7phq74eHZ6sW5NoBh5MYlCWQDhvW5jO8S+6lfJoMiEwHRbOGzS6i93lCm4xwZ3NY9m3sAUPgvRIOz9g89ThfNI7GxnZnmsFXmQ5VhdtEWk5yjhh6w0jlyNxypOxxObYPyx29ypuzyR2Fehn0DRxz+e8Xi5XGDcc8K+t8tWKEE97ASzktinV+HuiVSCiwq8dtedjzItlV4kMzHMum3GZk2JGRsVru0QMvExLR+V0QpR2CPdieOnW/Alp+5Jfwan+Gcx1sqDA9fpKTEdLoMOhVQoEn2Kfyed3cSpiYHNw9ZsEkYdHiWCMGX+CFwXMWCMSCISY3vW9caiXuk/UttIVaM=; 5:jiLe0zj9POcuLHsuIk6ocmv3n+7N9HwpftsNrujkXQWRI2viAZ5zQao7Qg+W/Qz1/lYfn11SgIK0Ks/16KlJe0v5fWxYFktbvL3tvTjSBu10z6GIShAtf9/BkxkmPMy93SEwuSoK9wyhNIRfidinqAEro0aZ0GstZ/3J8aEXrlI=; 24:kFBJgBFWzSe7I1xI4XEoOu9/Wg1wBA3/UZq29RNJIynulNJ9GjNjG2gzwhGIOVj6lP9V8Sn3k+f+K8Ae0ADxWcjVPM+EbgSI/xiDUtkR6Ko=; 7:b5K1KnjgoQTwMjd0xwkTngKPDP4zh+fqGfp1rSAqsizjMoUIWJ1A5ku2Rl8Vje3jsCYyY62d29niyP4uAxedQUUJr6zyqPCWOmxHnKNpesYz6vVs+DYW5EmQI7oDO92Vy5FCbkPVYR+an433ZCc/nRrXmYXtJUN8cRsJJxwO9+7tBhl18BvARyzOFXMF/DJ2lZBN+MUXjCxdCFNv0F7Jb2s17Bbkzilsh9u0h0ZSgdlwWVCsb2IbvFeg9DJaaLHO X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 09:48:03.2507 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 14c23ef6-fd1f-4203-3665-08d538a09d9c X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0064 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 09:48:10 -0000 Dear all, Overall the document looks in good shape to go forward if the earlier menti= oned issue of multiple values for "audience" (reported by Hannes) is addres= sed; and the below issue I see for Section 5. Other comments are minor. (Btw sorry for being late responding to this WGLC.) My review comments to specific sections: Entire document: Replace "binary string" by "byte string". The latter is the name used in R= FC 7049. 3.1.1 / 3.1.2 / 3.1.3 "except that the value is of type StringOrURI" -> May be slightly confusing to readers, since JWT also has StringOrURI nam= ed type. So it seemingly says "don't use StringOrURI, but use StringOrURI."= This is most likely intended, as in "don't use JWT StringOrURI, but use = our CWT StringOrURI". So also fine if we leave this formulation in, but it = could still cause some confusion. 3.1.4 / 3.1.5 / 3.1.6 "except that the value is of type NumericDate" -> same comment as above. 5 Text states the sender MUST NOT use a tag, but future specs may introduce t= ags for claim values. Then it seems required to also include some text abou= t how a receiver implementing the *current* version of CWT should handle ta= gs for claim values, which may come from a sender implementing a future ver= sion of CWT. E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim val= ue." That should help robustness and future extendibility. E.g. we don't want re= ceivers of a CWT to go check if tags are present and reject the CWT if a Ta= g is found. 7.1 Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the app= ropriate COSE CBOR tag" -> could we clarify where this is added, e.g. say "prepend with the matchin= g COSE CBOR tag"? 9.2.1 "Applications that use this media type: IoT applications sending security t= okens over HTTP(S) and other transports" -> can already mention CoAP/CoAPs here ? Best regards Esko Dijk -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Thursday, November 23, 2017 01:31 To: ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Reminder: there is only one week left in this WGLC. -Ben On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. > > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > Thanks, > > Ben and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. From nobody Fri Dec 1 17:53:01 2017 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 C4168129442 for ; Fri, 1 Dec 2017 17:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jNJBZcO-Stst for ; Fri, 1 Dec 2017 17:52:58 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C468A12943C for ; Fri, 1 Dec 2017 17:52:58 -0800 (PST) X-AuditID: 1209190d-05fff700000050d7-9e-5a22077866bc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 19.7D.20695.977022A5; Fri, 1 Dec 2017 20:52:57 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vB21qrEw018575; Fri, 1 Dec 2017 20:52:54 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vB21qoXZ030024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2017 20:52:52 -0500 Date: Fri, 1 Dec 2017 19:52:50 -0600 From: Benjamin Kaduk To: Esko Dijk Cc: "ace@ietf.org" Message-ID: <20171202015249.GR39477@kduck.kaduk.org> References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6nrlvJrhRlMHu3rsX3bz3MFpeWzWd0 YPJYsuQnk8eBA7uZApiiuGxSUnMyy1KL9O0SuDIu/mtjLzjBXDHzcQdzA+Nzpi5GTg4JAROJ 59O7mbsYuTiEBBYzScz7cYcFwtnAKHGg5z4bhHOFSeL+s2Ygh4ODRUBFYtU3FZBuNiCzofsy M4gtIqAqcbBhKTtICbOAosTfS6ogYWEBb4lPM6+zgdi8QMtWrb0HNX8jo8SW7U2sEAlBiZMz n7CA2MwCWhI3/r1kgpgjLbH8HwdImFMgRuLg2ZVgc0QFlCX29h1in8AoMAtJ9ywk3bMQuhcw Mq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIClJOSd4djP/ueh1iFOBgVOLh DQhSjBJiTSwrrsw9xCjJwaQkynvtNVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/1s0A53pTE yqrUonyYlDQHi5I477agXZFCAumJJanZqakFqUUwWRkODiUJXns2pSghwaLU9NSKtMycEoQ0 EwcnyHAeoOGcIDW8xQWJucWZ6RD5U4zGHDceXv/DxPFs5usGZiGWvPy8VClx3r+sQKUCIKUZ pXlw00CJRiJ7f80rRnGg54R5nUEG8gCTFNy8V0CrmIBWZS6XB1lVkoiQkmpgnF38ptnV24yR c/ZT5sNPr0+NXOIc9zxJPIN1aw0r21TGD2k/b9SHP2oLmbV1u+zcJnslxcJMh7pdVcET8jZ3 Z66Tk3k3+XV1nNj2dZ/TBWccXWglc/tAYN5xVrPlsa/FlwunKM3JYtA+pbxiQof8PYO0KsOX QmkTU8TffIhPk79q9/zVxpB6JZbijERDLeai4kQA9+3oIw8DAAA= Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 02 Dec 2017 01:53:01 -0000 Hi Esko, On Fri, Dec 01, 2017 at 09:47:52AM +0000, Esko Dijk wrote: > Dear all, > > Overall the document looks in good shape to go forward if the earlier mentioned issue of multiple values for "audience" (reported by Hannes) is addressed; and the below issue I see for Section 5. Other comments are minor. > (Btw sorry for being late responding to this WGLC.) Thanks for the review; it's always good to have more eyes on the document. -Ben From nobody Wed Dec 6 04:48:12 2017 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 7975F126E01 for ; Wed, 6 Dec 2017 04:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 JcLa2JKtNLme for ; Wed, 6 Dec 2017 04:48:02 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846C2124207 for ; Wed, 6 Dec 2017 04:48:02 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id a90so2226298pfk.1 for ; Wed, 06 Dec 2017 04:48:02 -0800 (PST) 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=IRGoxFx8IyBy7B1ATpp2HMA0l82deFq3F9IstxJZMTI=; b=GYea72qoBfIwO/vbGsv+L9weG5lEHoScHRAXXx057neXDRGH3w14HvFwiDP527fY3u hMvKtXWne0UatUViDN4Tx+PVtfiskNgXfhaLF1DqHgco6Oktwi9NAsRneRoJkQirOKzx oPSy28suU1kznZPsCQVQ9A2ktYaZa5767Bums76eFWdtmn9jXYuZQc38vgIHSSJOLOr4 Hxp8be7rP1yEIpMdhoGR2HcIVwo8z1ft+dK9crTigL2Ck9fjY6s/fnfrqhG6HLCRuQda zSVKEOwG8dHhbe92VUg6fsfdp630sGDn5Slj0GyemDOdGRWWoNk15Cm1Js2AVvBwXMfV 2WOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IRGoxFx8IyBy7B1ATpp2HMA0l82deFq3F9IstxJZMTI=; b=bdWYaXqqgsP+O77kRjWR7gZ/y0CiMwq99kOY7XLVQOMuzlTZ4KG7RcSTTz2aRxJY2+ jvzFePJbzovEO+glGLkO+OozntTAj9r83QsxuX+TsFWzvM6UVwFkbp/dXuGZgNUQoYBY +/Y4HS3yRY7hqd1Pc301oqPdYV/fAqT6r8WAbFQ3/A9UpfrC9sRX0rycBQsvm079MKVZ 74m2v702cMqlhsvkdeS+qRZcqGrZZjDapkAx1lWanUNeZERXgrv8YCJNVJO5kcS+mRtU ipcAayGdNXVY6j1vshQMJl6XRib/mlIfhO98dQWLkTnq/8YJaZmxynMocEdMcObdwEiC GsEA== X-Gm-Message-State: AJaThX4F00NQQRoFMNPgiBr4SiPMoYC2p1ivfD2CSP9oOAuzJEUb/skR OUojrZkcBJz77Q9s+usIfnC8EYWy5CIBbo1c9KOcvpWuC9M= X-Google-Smtp-Source: AGs4zMY7oIZtqBm0KTHgXgG1/VJT1SgtfvXOA7E89W7j7Fwn55jeorEAV91L5F79PxOfLGpy+iEXPHYepiC9wAOM1fk= X-Received: by 10.99.160.96 with SMTP id u32mr21210066pgn.25.1512564481492; Wed, 06 Dec 2017 04:48:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.169.15 with HTTP; Wed, 6 Dec 2017 04:48:00 -0800 (PST) In-Reply-To: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> From: Samuel Erdtman Date: Wed, 6 Dec 2017 13:48:00 +0100 Message-ID: To: Esko Dijk Cc: Benjamin Kaduk , "ace@ietf.org" Content-Type: multipart/alternative; boundary="f403043636ea9eb672055fab5c74" Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 12:48:10 -0000 --f403043636ea9eb672055fab5c74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Esko for your review it is greatly appreciated. see comments inline On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk wrote: > Dear all, > > Overall the document looks in good shape to go forward if the earlier > mentioned issue of multiple values for "audience" (reported by Hannes) is > addressed; and the below issue I see for Section 5. Other comments are > minor. > (Btw sorry for being late responding to this WGLC.) > > My review comments to specific sections: > > Entire document: > Replace "binary string" by "byte string". The latter is the name used in > RFC 7049. > Good point. I have created a PR waiting for review by the co-authors > > 3.1.1 / 3.1.2 / 3.1.3 > "except that the value is of type StringOrURI" > -> May be slightly confusing to readers, since JWT also has StringOrURI > named type. So it seemingly says "don't use StringOrURI, but use > StringOrURI." This is most likely intended, as in "don't use JWT > StringOrURI, but use our CWT StringOrURI". So also fine if we leave this > formulation in, but it could still cause some confusion. > I see your point, but I don=C2=B4t think it will be an issue. JWT is in JSO= N context and CWT is in CBOR context so whenever string is refereed to in CWT the reader should think CBOR string and vice verse for JWT. If you don=C2=B4t have a strong opinion here or a great suggestion for a ne= w name I would like to keep it as it is. > > 3.1.4 / 3.1.5 / 3.1.6 > "except that the value is of type NumericDate" > -> same comment as above. > Same as above. > 5 > Text states the sender MUST NOT use a tag, but future specs may introduce > tags for claim values. Then it seems required to also include some text > about how a receiver implementing the *current* version of CWT should > handle tags for claim values, which may come from a sender implementing a > future version of CWT. > E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim > value." > That should help robustness and future extendibility. E.g. we don't want > receivers of a CWT to go check if tags are present and reject the CWT if = a > Tag is found. > I think the language in section 3 is enough to get robust implementations. "all claims that are not understood by implementations MUST be ignored." > > 7.1 > Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the > appropriate COSE CBOR tag" > -> could we clarify where this is added, e.g. say "prepend with the > matching COSE CBOR tag"? > I think adding the tag in itself has this semantic. But I have created a PR with the change, so that my co-authors can consider it. > > 9.2.1 > "Applications that use this media type: IoT applications sending security > tokens over HTTP(S) and other transports" > -> can already mention CoAP/CoAPs here ? > It is not obvious that we should mention CoAP(S) here since the media type is for HTTP(S) and not CoAP(S) and it does state that "and other transports". For CoAP(S) we register the CoAP Content-Format that maps to this media type. > > Best regards > Esko Dijk > > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: Thursday, November 23, 2017 01:31 > To: ace@ietf.org > Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 Novembe= r) > > Reminder: there is only one week left in this WGLC. > > -Ben > > On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > > This message begins a working group last call for > > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > > ending at 23:59 PST on Wednesday 29 November, 2017. > > > > The current (-09) version of the document is available at: > > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > > > Thanks, > > > > Ben and Jim > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > ________________________________ > The information contained in this email may be confidential and/or legall= y > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > email is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destro= y > all copies of the original email. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --f403043636ea9eb672055fab5c74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Esko for your review it is greatly appreciated.
=
see comments inline

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <= esko.dijk@philip= s.com> wrote:
Dear all,

Overall the document looks in good shape to go forward if the earlier menti= oned issue of multiple values for "audience" (reported by Hannes)= is addressed; and the below issue I see for Section 5. Other comments are = minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".=C2=A0 The lat= ter is the name used in RFC 7049.

Good = point.
I have created a PR waiting for review by the co-authors <= br>
=C2=A0

3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI = named type. So it seemingly says "don't use StringOrURI, but use S= tringOrURI."=C2=A0 =C2=A0This is most likely intended, as in "don= 't use JWT StringOrURI, but use our CWT StringOrURI". So also fine= if we leave this formulation in, but it could still cause some confusion.<= br>

I see your point, but I don=C2=B4t thin= k it will be an issue. JWT is in JSON context and CWT is in CBOR context so= whenever string is refereed to in CWT the reader should think CBOR string = and vice verse for JWT.
If you don=C2=B4t have a strong opinion h= ere or a great suggestion for a new name I would like to keep it as it is.<= br>
=C2=A0

3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.

Same as ab= ove.


5
Text states the sender MUST NOT use a tag, but future specs may introduce t= ags for claim values. Then it seems required to also include some text abou= t how a receiver implementing the *current* version of CWT should handle ta= gs for claim values, which may come from a sender implementing a future ver= sion of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a clai= m value."
That should help robustness and future extendibility. E.g. we don't wan= t receivers of a CWT to go check if tags are present and reject the CWT if = a Tag is found.

I think the language in= section 3 is enough to get robust implementations. "all claims that a= re not understood by implementations MUST be ignored."
= =C2=A0

7.1
Step 5 & 6: text states "add the matching COSE CBOR tag" resp= . "add the appropriate COSE CBOR tag"
-> could we clarify where this is added, e.g. say "prepend with the= matching COSE CBOR tag"?

I think = adding the tag in itself has this semantic. But I have created a PR with th= e change, so that my co-authors can consider it.
=C2=A0
=

9.2.1
"Applications that use this media type: IoT applications sending secur= ity tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?

=
It is not obvious that we should mention CoAP(S) here since the media = type is for HTTP(S) and not CoAP(S) and it does state that "and other = transports". For CoAP(S) we register the CoAP Content-Format that maps= to this media type.
=C2=A0

Best regards
Esko Dijk


-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)=

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,=
> ending at 23:59 PST on Wednesday 29 November, 2017.
>
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/dr= aft-ietf-ace-cbor-web-token-09 .
>
> Thanks,
>
> Ben and Jim
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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

________________________________
The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email.

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

--f403043636ea9eb672055fab5c74-- From nobody Wed Dec 6 05:48:45 2017 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 651F212896F for ; Wed, 6 Dec 2017 05:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifDkca4UB18K for ; Wed, 6 Dec 2017 05:48:41 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0085.outbound.protection.outlook.com [104.47.2.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A83312895E for ; Wed, 6 Dec 2017 05:48:39 -0800 (PST) Received: from HE1P121CA0007.EURP121.PROD.OUTLOOK.COM (129.75.191.145) by DB6P121MB0040.EURP121.PROD.OUTLOOK.COM (129.75.191.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 6 Dec 2017 13:48:37 +0000 Received: from VE1EUR02FT033.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::202) by HE1P121CA0007.outlook.office365.com (2603:10a6:23:2b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.13 via Frontend Transport; Wed, 6 Dec 2017 13:48:37 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; erdtman.se; dkim=none (message not signed) header.d=none;erdtman.se; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by VE1EUR02FT033.mail.protection.outlook.com (10.152.12.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.282.5 via Frontend Transport; Wed, 6 Dec 2017 13:48:37 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.211) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Wed, 6 Dec 2017 13:48:27 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0037.EURP121.PROD.OUTLOOK.COM (129.75.191.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 6 Dec 2017 13:48:26 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0260.008; Wed, 6 Dec 2017 13:48:26 +0000 From: Esko Dijk To: Samuel Erdtman , Esko Dijk CC: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thread-Index: AQHTY/Ja/17ZfrzpmEybigwONFOQFKMuQr4wgAgWQgCAAAufcA== Date: Wed, 6 Dec 2017 13:48:25 +0000 Message-ID: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.246.199.210] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0037; 6:abn4iHa7Pe+vu7kz4EFLdcEkOfzWOLITwwlCuLXPaFvgImcav5qRBGtQpqRqTJORUYfiFUFUCNI8ZTwHmH/DunHqb9tFa0Hu3VuqxfdqkPHpl4p/MNss6j5ZXASIAGvcH30Q1c7mKv6eDl/LP6yiL4NCr0fz+L2VnbQj9mVErdmHpY2D/Nxcen5W00EXLFc5HrftKeKFeJGgXGgyU1bw5nC5qq+g3DuirevT62ZYMdBnwll8mCZayS4+IwYBUVDQBfUV+8yM/dPJEAzi/381haT2ERVVxK1iwm3Wf4/uABTlDMXQ+OeO2vIl10eXDsfMz5809b0Wj6ClpVL6rHhA645vfr1YhkxSq4LR9ioDk58=; 5:oM3hb1Fu+EHKgcDG3RFq/tNBaTnQ8hUQBnt8EM9kiSxA2q8V+XL/NsdphcJMnyFvd00cJSQjj93HPXIZk23VL52l/+rYo9e64f/rs/W3AIrMsZjLvly/fVIoCqM+IgHvYq0YbZEZX3QT/KlSYDbWXmVJUGhlenI76EMdh24wwUU=; 24:2novsLFqFJXNOZ4WFsPVgEKXF7jmqd48elIZIgvxIQt28GxUtMrh7CzQL8G36/lcjh8Kw9SjjRk5kQmhsYQSsh3u1YT60mtWtc1Oj7E6QPQ=; 7:cc4389HCiCvHI51iSkx2k1R9Qha40/kYPNyxheSOCI0gpLkk28wxbB4gnjrO9pjZ4XM1AUnfWNuwgDolmhQs5NSU4XRjrcTl7SyZl8WCq6v2vrWjVGXNvFpLTJtozvF7xdjRRDaI8sGhEAXx2k4aa0nfKOOZAI/LvQeKRn2x8q+0u/L+pO5fPGM+aNQd2sexu8kDe5XpgNTsz2Y1GFA2rKGDsolEUEBlgiWXweFidELhscat0DL44M78PKwGibNw x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 13115798-8181-403f-b041-08d53cb00cec X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB6P121MB0037; X-MS-TrafficTypeDiagnostic: DB6P121MB0037:|DB6P121MB0040: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(788757137089)(21748063052155)(260087099026482)(240460790083961); UriScan:(278428928389397)(192374486261705)(788757137089)(21748063052155)(260087099026482)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011); SRVR:DB6P121MB0037; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6P121MB0037; BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(93006095)(93003095)(10201501046)(3231022)(3002001)(6055026)(6096035)(20161123561025)(20161123563025)(20161123565025)(20161123559100)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123556025)(201708071742011); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:DB6P121MB0040; x-forefront-prvs: 05134F8B4F X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(85714005)(24454002)(199004)(189003)(13464003)(74316002)(5660300001)(86362001)(68736007)(93886005)(478600001)(66066001)(2950100002)(33656002)(101416001)(966005)(81166006)(81156014)(105586002)(76176011)(230783001)(229853002)(6306002)(55016002)(19609705001)(8676002)(9686003)(54896002)(8936002)(106356001)(236005)(6506006)(606006)(25786009)(3846002)(6436002)(7696005)(99286004)(110136005)(54906003)(53546010)(4326008)(102836003)(6116002)(316002)(2906002)(790700001)(2900100001)(53936002)(3280700002)(97736004)(3660700001)(7736002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0037; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6P121MB0038ECF1ECA11E8546446B839B320DB6P121MB0038EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0037 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131570417171542081; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR02FT033.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(39380400002)(39860400002)(376002)(346002)(2980300002)(13464003)(199004)(189003)(85714005)(24454002)(2906002)(790700001)(3846002)(6116002)(102836003)(93886005)(81156014)(512874002)(6246003)(55016002)(33656002)(81166006)(6306002)(97736004)(54896002)(356003)(316002)(105586002)(236005)(9686003)(966005)(8676002)(53936002)(230783001)(8936002)(106466001)(74316002)(498600001)(99286004)(86362001)(16586007)(84326002)(54906003)(7736002)(110136005)(25786009)(2950100002)(68736007)(61614004)(66066001)(229853002)(22756006)(53546010)(6506006)(33964004)(606006)(76176011)(7696005)(2900100001)(5660300001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P121MB0040; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT033; 1:cjd12LztgAUS7SizLPtjLtdZlWy8TrYuFZ8jyTiTYC+ms/Gr7GGUakoUneXg7whnExdmGyrGYwG8Tei28DoesZOUKyTVvNQIlMPXAdCurM14hua+v1IenRjTUV11vLDS X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4628075)(201703131517081)(2017052603286); SRVR:DB6P121MB0040; X-Microsoft-Exchange-Diagnostics: 1; DB6P121MB0040; 3:iDZBUe0xl3DM9YgaP+A+1wgSHJmsGiSDgtaapOmstloDVZn4F44QWjkOf7F0/oAsdzwqgoSD0nM0iGSinoEao+I+wO4Hi0cfC/upqAJp7zW2Y70ktIYqxGQreTP6FApO/zUYwQH3L2gOm+SHRtrP57LTD62AC2iaVjXj3gk7MUvznik4VL8+5ZDMSJHkiUT419tFbquNR0wNu+cdy0m3CEJtITS6Vcw5BsNaJfadgt5NAMzF7137bVbM6YwjC61xtsip1ecv3BTEmI0nMHqryPMY21HAzQpBqNacoDqLdVyxgYVSKSRiFZa81VeT/evO+WlhRrBKvk0qHGUwhaDIW/+c1SWzWGm4iQvdhVldWE0=; 25:luY+pPqxfZVJ97vwM5sUHkXzmBNwKsllz7ZAVfGpl+EfT022qMeQgOeWCk58sWE8TS4BkT+IqJXbfBSKDTny1fvPq58jhwdhOTmpsnHcXEGQbWDm/r3ZdR+RNuL2IPDZsSbgnU46hyzVzUoqJYjjOktcJNknHCR1P4PSAb6yHvmsm+niS15dP8fap6ZR90TtYKvnuN9vAbFevG6LtN8Z99d+MYyr/pkN0XpneK2ONXaPJW0hvi2DpP1GDx1GiXxZe/Ysbv/bNVnKohbV5U+weZsEfv8eYITrzxM0FORiHgQ1a82K0PVzF16GEn22PmLHeDPee3jQzerR5jrmDyqCmw== X-Microsoft-Exchange-Diagnostics: 1; DB6P121MB0040; 31:Uyo8LeauX4e6Xf9KMWf9LvzBkGtI3KuuWANyMnf4kdYWwTmB6GbmtbCM6Ar42oqFSGf7ROTFFuuzkHMQ8Oq8VhT/61FLkYWSpKsmWH3+ZjyYc8kQwnrl83znOZ38FwkhR8MWAps3FdSBc30RaUj4GhZCWYmTefwssjw9OvRIionUOGHbzvVec6trJPgWecpJm63/NzwJfPuhB2GXU0Gi2M9tqwvviiIYan7DQOFxjDg=; 4:GhMJQdWKIHtMeu4IYhIA9wxTzQwEUTJmWSPzS+72ng7th65j4xRXEZVJ5zbbDTjsqhFTMZz/ekUUDkcGnS+FGkp2GQwJZGpNMZAtMQ8PlYjpe2AsTtrFMq+XibPj4Dr7ELukZvkwn8wzKkklW7yfI5Ydb/6zMMJH9z1tGHFWxKDpYaElgUsLkmJClF+kn7J03/AMgJt5EHVtV6LZHDm6QRpUi1g57sNoqwu0fHR+oMI7AmHP1fYkyTAigRLY3lBLD/FGZkKpPEha/nKaObnyCUZIVYqDXVHRJcXcbDM1CNkyT+Ns6exbL5VaKKRLTyWNbOK4T4LdswRFr6mL2ukq38SjbtpjvmfMnp1A7GOlJe9gf1V7GqhP0IIo0Be0HXwdHsxRD7R04dgvQoM0FuA7JrcbbceEJka9/Otrh1EFyA94pmDcBxuFnul2wzgDeoEF2Molbv2JRqxhWlJrTUZh4Fpus90j2bOypJ6NKF9ETmc= X-Forefront-PRVS: 05134F8B4F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6P121MB0040; 23:T9JXwlFjGYMqwDgE35PtzGpK01Xy5it5WLZ85fnmm?= =?us-ascii?Q?N2d1I30Q9SmUsi5RUnUfpg83FhIjIliY0v8mPo++4SJ/o61EFaOPCkFEkGYX?= =?us-ascii?Q?mc1s8sPdcTEL3BBps7qqdVN4GEA0cNjwOvEWrWEp/aFBh+qnSDmlnq5vHCxc?= =?us-ascii?Q?UPphqe0DbZd7bq0tKQZlH9MIHZFncbMnp8gxrUsK4+Gy1HZ3jIz2+WEYdPeM?= =?us-ascii?Q?GnZF5lUc7zkMl9jSuwWlbmz8kUTeU2eDYVqi+xWrQM6nzRzNmvd/ltu62Ur3?= =?us-ascii?Q?iuPwfT8gMSbb0324tcpDmW8hFCng0LfhN8soOEATHHW6WYVfxlF0ZGPRtigI?= =?us-ascii?Q?lbNBPjNn+5BFnG8zwLyqIaxDNrehmuBLIS0kXDWe+uFWgDoXzojNxzMlwmDC?= =?us-ascii?Q?dqUcgK3tqyjlDlrl/uVI08QPgjR/QtGgPJZcaPNP82z1u/w0CJeh0ILwKSuz?= =?us-ascii?Q?EqyWbAfg9c98jp4TeoH/CllvQNtFWRMch474iVMgS/aIKwwTZSShO2HwWnpZ?= =?us-ascii?Q?X9ZPZl40H0HKIpjfHCBTPf9fNKbR7RlVEGWRjE9DvGl7N9TXu3Sda4FteEbV?= =?us-ascii?Q?77R076asktUdIvl26PPurSFbIdvxeqN1gUyphaJtuYWeshMSWZ5r68nDoVY2?= =?us-ascii?Q?YNNVbVazIOmvnZYwPx9mW4iTFoTIhue5bhKdtKC572zZOo90yCE8AF2uSUCb?= =?us-ascii?Q?HJOpDX55ZJDq2B1qhUR0Vn9xMCjn0PLk51guwJjn+IR2+zL7551OeFOCAGsJ?= =?us-ascii?Q?8Pt6VvWzHYhLJQsijvrMUWtkMzeXO44aVDkUa0ruXp2/X5Nu8xUTywInr/PG?= =?us-ascii?Q?yGemwPxq7zf6uZg8/QPMd6qilRN+glLjPqCLsMm4uDSHWbJT36ITrwNvYQZ2?= =?us-ascii?Q?D+/DYXP2wlafSrIx0SPauk4QIRHThuzljdTOeLJTfrxLFxBpLDn/omisHKXi?= =?us-ascii?Q?cfui6e3K0j6z9S1wuMB7Bj/8B5XEXZIar37IH2o2P/47NZabStgvf0TWXP7k?= =?us-ascii?Q?MV5Y+BNo2wtUFiL38DlWncOh8ufy3IKFiBak0Zb34iIxNHXLCepF/GDOPBMv?= =?us-ascii?Q?HF580LIMfhC8ya/THrcpa9qDh6hdhwPHMCndQGwhBLCINYIYTDxGtlAvqK7/?= =?us-ascii?Q?80IQzQCtLLmQP5iTFLM66EP2ZjeQHNlO/C7G8p8xGRXT+oTRNYKCbSgCpVC1?= =?us-ascii?Q?moP1s+4aVvt4JTPFGtDzFU6YuzpXOF6SCDTWvPjQ8omglO9P5WO/KW911HwJ?= =?us-ascii?Q?wyBBHVpg8909gag2ZoHtrkjt2gp44fwCACHGF2nExBSjPxDgI+G9JOzzoyuF?= =?us-ascii?Q?LUKF+ZPnHH5Uaeh1iQeNGtvYD/7mexVMYtEHVbj8hJOQ6Lml/NF0CmsXJUXp?= =?us-ascii?Q?XA/idV3xQCEqVOqt/nV4qY+Kv8bRIqsCr6bcQ6Jg7a2lFYMDEUqUvGX73WAT?= =?us-ascii?Q?05WjP4r2A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6P121MB0040; 6:22QzX1agD5uTHa3JNfg6i0ZytMRFQ2BNP9EUX/Qrfhoq/JZjBoYrKnd7Q0uZS6EiXNteVLPV7i1/64VYJncfgASV79bCsuTnGVzFp2d8mj9oal1zrrmMwncAw+i7U0r2uCYh0zOfqntKifxd0J0dDtNmHT3Jo+ABIXGvtMzIQGL+tIeEKB2UHc/D4BVf+JntAv+ZUeOUqtGDsMbY4q42kZO7v+GY8bzNdl82yCx7tSTFIOkMY/MCVgKg8ZEh3bHNx0WeNAXE23M20HL7stJeK+PBIdTlzDmijsvEC+78PwU5Bz/NiQ+3KMK6rx5yBq+wMh+J7R6MHrbGmzZwjW6dEkgpWexLv+eornEURVjcNFg=; 5:dp11lTyNcFM/r5ucW8hZxAkHWV2F3IW8lpbW6D8+PRoAxavB8PYvW7flcLd/buXnkDMjE9t53qgtpkU2qm2rjkH0/thgONGhUMZpGx3rJY0ep98xLkPRktvxxS+GzJpiXTo4VdEJi6kp6/kxKBjG0+MacDi1FE6RjR2kOk50HLY=; 24:HG3nTEB40SEApE2CZjJlWr83Fb9anLOSZSrJjRkP8wyr9/L2/OHt7SMb+SKkX74q0/0tyFIH06ZLX5YNDdgnGpD8oBh0X11lavQiKOWArXU=; 7:Gqm/v+XLhCC8dXJ7Kl8LruBDGkJTlV9v2VaCsKi5oF0waPZzXGfE0kIUr/a6G6B9Iijs0kSdYA4apHMFCMV8ChkGFhO+AY2tTpOBpWHeJHccMaHDMJe8bqsrabuPN+PuXx7DPo3nJWPyzm+6PPK86jEhpoF25D285hgllT9HUHEkh74GmtkVUCv3u+URmD2EzPEy4eqnEu7X0BEgSFpm9WkwBrjsaaNIebYRXtv9scnhRn9/sgEMIn5MFa6l613P X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 13:48:37.0292 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 13115798-8181-403f-b041-08d53cb00cec X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0040 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 13:48:44 -0000 --_000_DB6P121MB0038ECF1ECA11E8546446B839B320DB6P121MB0038EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFNhbXVlbCwNCg0KSSBhZ3JlZSB3aXRoIHlvdXIgYW5zd2VycyBhbmQgcHJvcG9zZWQg YWN0aW9ucyBleGNlcHQgZm9yIHRoZSBiZWxvdzoNCg0KPiBJIHRoaW5rIHRoZSBsYW5ndWFnZSBp biBzZWN0aW9uIDMgaXMgZW5vdWdoIHRvIGdldCByb2J1c3QgaW1wbGVtZW50YXRpb25zLiAiYWxs IGNsYWltcyB0aGF0IGFyZSBub3QgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgTVVTVCBi ZSBpZ25vcmVkLiINCg0KSWdub3JpbmcgYSBjbGFpbSBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGln bm9yaW5nIGFuIHVucmVjb2duaXplL3Vuc3VpdGFibGUgdGFnIHRoYXQgcHJlZml4ZXMgYSBjbGFp bS4gVGhlIGxhdHRlciB3aWxsIGluIGZhY3QgYWNjZXB0IHRoZSBjbGFpbSB3aGlsZSB0aGUgZm9y bWVyIHdpbGwgcmVqZWN0IHRoZSBjbGFpbS4NClRvIGdldCB0aGUgZGVzaXJlZCByb2J1c3RuZXNz IGFuZCBmdXR1cmUgZXh0ZW5kaWJpbGl0eSwgYW5kIG1ha2UgdGFncyB1c2VmdWwgZm9yIGV4aXN0 aW5nIGNsYWltcywgYW4gaW1wbGVtZW50YXRpb24gbXVzdCBpZ25vcmUgdGhlIHVucmVjb2duaXpl ZCB0YWcg4oCTIGJ1dCBub3QgdGhlIGNsYWltLiAoQXNzdW1pbmcgYW55IGNhc2VzIHdoZXJlIHRo ZSByZWNlaXZlciBzaG91bGQgdW5kZXJzdGFuZCB0aGUgY2xhaW0gYnV0IGEgZnV0dXJlLXZlcnNp b24gc2VuZGVyIGhhcyBhZGRlZCBhbiBhZGRpdGlvbmFsIGZ1dHVyZS12ZXJzaW9uIHRhZyB0byBp dC4pDQpXaGF0IHRoaXMgY2FuIGFjaGlldmUgaXMga2VlcCB1c2luZyDigJhvbGTigJkgdmVyc2lv biBjbGFpbXMgd2hpbGUgYXVnbWVudGluZyB0aGVzZSB3aXRoIOKAmG5ldyB2ZXJzaW9u4oCZIHNl bWFudGljcyBieSB1c2Ugb2YgdGFncywgaW4gYSBmdXR1cmUgdmVyc2lvbiBvZiB0aGUgc3BlY2lm aWNhdGlvbi4NCg0KQmVzaWRlcyB3aXRoIGN1cnJlbnQgU2VjdGlvbiAzICYgNSBsYW5ndWFnZSBv bmUgY2xhaW0gcGFyc2VyICMxIG1heSBzdGlsbCBjb25zaWRlciBhbiDigJxleHDigJ0gY2xhaW0g YXMg4oCcdW5kZXJzdG9vZOKAnSBiZWNhdXNlIGl0IGlnbm9yZXMgYW55IHRhZ3MgZm9yIGl0LCB3 aGlsZSBwYXJzZXIgIzIgbWF5IHJlamVjdCB0aGF0IOKAnGV4cOKAnSBjbGFpbSBiZWNhdXNlIGl0 IHNlZXMgYSB0YWcgdGhhdCBpcyBub3QgMS4gV2hpbGUgcGFyc2VyICMzIG1heSByZWplY3QgYW4g 4oCcZXhw4oCdIGNsYWltIGV2ZW4gd2l0aCBhIHRhZyAxIGJlY2F1c2UgaXQgY29uc2lkZXJzIGl0 IG91dCBvZiBzY29wZSBvZiB0aGUgc3BlYyAod2hpY2ggc2F5cyBzZW5kZXIgTVVTVCBOT1QgdXNl IHRoaXMgdGFnIGhlbmNlIGFueSB0YWcgdXNhZ2UgaXMgbm90IGFjY29yZGluZyB0byBzcGVjIHNv IG5vdCB1bmRlcnN0b29kLikuDQoNCkluIGEgd2F5IHRoaXMgaXNzdWUgaXMgc2ltaWxhciB0byB0 aGUgYXJjaGV0eXBpY2FsIHNwZWMgcmVxdWlyZW1lbnQgb2Yg4oCcc2VuZGVyIE1VU1QgcHV0IDBz IGluIHRoaXMgZmllbGQgYW5kIGEgcmVjZWl2ZXIgTVVTVCBpZ25vcmUgdGhlIHZhbHVlIG9mIHRo aXMgZmllbGTigJ0uICBCb3RoIGFyZSBuZWVkZWQuDQoNCkJlc3QgUmVnYXJkcw0KRXNrbw0KDQpG cm9tOiBTYW11ZWwgRXJkdG1hbiBbbWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNlXQ0KU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciA2LCAyMDE3IDEzOjQ4DQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtA cGhpbGlwcy5jb20+DQpDYzogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+OyBhY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBXR0xDIG9uIGRyYWZ0LWlldGYtYWNlLWNib3Itd2Vi LXRva2VuIChlbmRzIDI5IE5vdmVtYmVyKQ0KDQpUaGFua3MgRXNrbyBmb3IgeW91ciByZXZpZXcg aXQgaXMgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0Kc2VlIGNvbW1lbnRzIGlubGluZQ0KDQpPbiBG cmksIERlYyAxLCAyMDE3IGF0IDEwOjQ3IEFNLCBFc2tvIERpamsgPGVza28uZGlqa0BwaGlsaXBz LmNvbTxtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tPj4gd3JvdGU6DQpEZWFyIGFsbCwNCg0K T3ZlcmFsbCB0aGUgZG9jdW1lbnQgbG9va3MgaW4gZ29vZCBzaGFwZSB0byBnbyBmb3J3YXJkIGlm IHRoZSBlYXJsaWVyIG1lbnRpb25lZCBpc3N1ZSBvZiBtdWx0aXBsZSB2YWx1ZXMgZm9yICJhdWRp ZW5jZSIgKHJlcG9ydGVkIGJ5IEhhbm5lcykgaXMgYWRkcmVzc2VkOyBhbmQgdGhlIGJlbG93IGlz c3VlIEkgc2VlIGZvciBTZWN0aW9uIDUuIE90aGVyIGNvbW1lbnRzIGFyZSBtaW5vci4NCihCdHcg c29ycnkgZm9yIGJlaW5nIGxhdGUgcmVzcG9uZGluZyB0byB0aGlzIFdHTEMuKQ0KDQpNeSByZXZp ZXcgY29tbWVudHMgdG8gc3BlY2lmaWMgc2VjdGlvbnM6DQoNCkVudGlyZSBkb2N1bWVudDoNClJl cGxhY2UgImJpbmFyeSBzdHJpbmciIGJ5ICJieXRlIHN0cmluZyIuICBUaGUgbGF0dGVyIGlzIHRo ZSBuYW1lIHVzZWQgaW4gUkZDIDcwNDkuDQoNCkdvb2QgcG9pbnQuDQpJIGhhdmUgY3JlYXRlZCBh IFBSIHdhaXRpbmcgZm9yIHJldmlldyBieSB0aGUgY28tYXV0aG9ycw0KDQoNCjMuMS4xIC8gMy4x LjIgLyAzLjEuMw0KImV4Y2VwdCB0aGF0IHRoZSB2YWx1ZSBpcyBvZiB0eXBlIFN0cmluZ09yVVJJ Ig0KLT4gTWF5IGJlIHNsaWdodGx5IGNvbmZ1c2luZyB0byByZWFkZXJzLCBzaW5jZSBKV1QgYWxz byBoYXMgU3RyaW5nT3JVUkkgbmFtZWQgdHlwZS4gU28gaXQgc2VlbWluZ2x5IHNheXMgImRvbid0 IHVzZSBTdHJpbmdPclVSSSwgYnV0IHVzZSBTdHJpbmdPclVSSS4iICAgVGhpcyBpcyBtb3N0IGxp a2VseSBpbnRlbmRlZCwgYXMgaW4gImRvbid0IHVzZSBKV1QgU3RyaW5nT3JVUkksIGJ1dCB1c2Ug b3VyIENXVCBTdHJpbmdPclVSSSIuIFNvIGFsc28gZmluZSBpZiB3ZSBsZWF2ZSB0aGlzIGZvcm11 bGF0aW9uIGluLCBidXQgaXQgY291bGQgc3RpbGwgY2F1c2Ugc29tZSBjb25mdXNpb24uDQoNCkkg c2VlIHlvdXIgcG9pbnQsIGJ1dCBJIGRvbsK0dCB0aGluayBpdCB3aWxsIGJlIGFuIGlzc3VlLiBK V1QgaXMgaW4gSlNPTiBjb250ZXh0IGFuZCBDV1QgaXMgaW4gQ0JPUiBjb250ZXh0IHNvIHdoZW5l dmVyIHN0cmluZyBpcyByZWZlcmVlZCB0byBpbiBDV1QgdGhlIHJlYWRlciBzaG91bGQgdGhpbmsg Q0JPUiBzdHJpbmcgYW5kIHZpY2UgdmVyc2UgZm9yIEpXVC4NCklmIHlvdSBkb27CtHQgaGF2ZSBh IHN0cm9uZyBvcGluaW9uIGhlcmUgb3IgYSBncmVhdCBzdWdnZXN0aW9uIGZvciBhIG5ldyBuYW1l IEkgd291bGQgbGlrZSB0byBrZWVwIGl0IGFzIGl0IGlzLg0KDQoNCjMuMS40IC8gMy4xLjUgLyAz LjEuNg0KImV4Y2VwdCB0aGF0IHRoZSB2YWx1ZSBpcyBvZiB0eXBlIE51bWVyaWNEYXRlIg0KLT4g c2FtZSBjb21tZW50IGFzIGFib3ZlLg0KDQpTYW1lIGFzIGFib3ZlLg0KDQoNCjUNClRleHQgc3Rh dGVzIHRoZSBzZW5kZXIgTVVTVCBOT1QgdXNlIGEgdGFnLCBidXQgZnV0dXJlIHNwZWNzIG1heSBp bnRyb2R1Y2UgdGFncyBmb3IgY2xhaW0gdmFsdWVzLiBUaGVuIGl0IHNlZW1zIHJlcXVpcmVkIHRv IGFsc28gaW5jbHVkZSBzb21lIHRleHQgYWJvdXQgaG93IGEgcmVjZWl2ZXIgaW1wbGVtZW50aW5n IHRoZSAqY3VycmVudCogdmVyc2lvbiBvZiBDV1Qgc2hvdWxkIGhhbmRsZSB0YWdzIGZvciBjbGFp bSB2YWx1ZXMsIHdoaWNoIG1heSBjb21lIGZyb20gYSBzZW5kZXIgaW1wbGVtZW50aW5nIGEgZnV0 dXJlIHZlcnNpb24gb2YgQ1dULg0KRS5nLiBhZGQgdGV4dCAiQSByZWNlaXZlci9kZWNvZGVyIE1V U1QgaWdub3JlIGFueSBUYWdzIHVzZWQgZm9yIGEgY2xhaW0gdmFsdWUuIg0KVGhhdCBzaG91bGQg aGVscCByb2J1c3RuZXNzIGFuZCBmdXR1cmUgZXh0ZW5kaWJpbGl0eS4gRS5nLiB3ZSBkb24ndCB3 YW50IHJlY2VpdmVycyBvZiBhIENXVCB0byBnbyBjaGVjayBpZiB0YWdzIGFyZSBwcmVzZW50IGFu ZCByZWplY3QgdGhlIENXVCBpZiBhIFRhZyBpcyBmb3VuZC4NCg0KSSB0aGluayB0aGUgbGFuZ3Vh Z2UgaW4gc2VjdGlvbiAzIGlzIGVub3VnaCB0byBnZXQgcm9idXN0IGltcGxlbWVudGF0aW9ucy4g ImFsbCBjbGFpbXMgdGhhdCBhcmUgbm90IHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIE1V U1QgYmUgaWdub3JlZC4iDQoNCg0KNy4xDQpTdGVwIDUgJiA2OiB0ZXh0IHN0YXRlcyAiYWRkIHRo ZSBtYXRjaGluZyBDT1NFIENCT1IgdGFnIiByZXNwLiAiYWRkIHRoZSBhcHByb3ByaWF0ZSBDT1NF IENCT1IgdGFnIg0KLT4gY291bGQgd2UgY2xhcmlmeSB3aGVyZSB0aGlzIGlzIGFkZGVkLCBlLmcu IHNheSAicHJlcGVuZCB3aXRoIHRoZSBtYXRjaGluZyBDT1NFIENCT1IgdGFnIj8NCg0KSSB0aGlu ayBhZGRpbmcgdGhlIHRhZyBpbiBpdHNlbGYgaGFzIHRoaXMgc2VtYW50aWMuIEJ1dCBJIGhhdmUg Y3JlYXRlZCBhIFBSIHdpdGggdGhlIGNoYW5nZSwgc28gdGhhdCBteSBjby1hdXRob3JzIGNhbiBj b25zaWRlciBpdC4NCg0KDQo5LjIuMQ0KIkFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlh IHR5cGU6IElvVCBhcHBsaWNhdGlvbnMgc2VuZGluZyBzZWN1cml0eSB0b2tlbnMgb3ZlciBIVFRQ KFMpIGFuZCBvdGhlciB0cmFuc3BvcnRzIg0KLT4gY2FuIGFscmVhZHkgbWVudGlvbiBDb0FQL0Nv QVBzIGhlcmUgPw0KDQpJdCBpcyBub3Qgb2J2aW91cyB0aGF0IHdlIHNob3VsZCBtZW50aW9uIENv QVAoUykgaGVyZSBzaW5jZSB0aGUgbWVkaWEgdHlwZSBpcyBmb3IgSFRUUChTKSBhbmQgbm90IENv QVAoUykgYW5kIGl0IGRvZXMgc3RhdGUgdGhhdCAiYW5kIG90aGVyIHRyYW5zcG9ydHMiLiBGb3Ig Q29BUChTKSB3ZSByZWdpc3RlciB0aGUgQ29BUCBDb250ZW50LUZvcm1hdCB0aGF0IG1hcHMgdG8g dGhpcyBtZWRpYSB0eXBlLg0KDQoNCkJlc3QgcmVnYXJkcw0KRXNrbyBEaWprDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCZW5qYW1pbiBL YWR1aw0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIzLCAyMDE3IDAxOjMxDQpUbzogYWNlQGll dGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjZV0gV0dMQyBvbiBk cmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbiAoZW5kcyAyOSBOb3ZlbWJlcikNCg0KUmVtaW5k ZXI6IHRoZXJlIGlzIG9ubHkgb25lIHdlZWsgbGVmdCBpbiB0aGlzIFdHTEMuDQoNCi1CZW4NCg0K T24gV2VkLCBOb3YgMDEsIDIwMTcgYXQgMTI6MjQ6NTZQTSAtMDUwMCwgQmVuamFtaW4gS2FkdWsg d3JvdGU6DQo+IFRoaXMgbWVzc2FnZSBiZWdpbnMgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBm b3INCj4gZHJhZnQtaWV0Zi1hY2UtY2Jvci13ZWItdG9rZW4gZm9yIHN1Ym1pc3Npb24gYXMgYSBT dGFuZGFyZHMtVHJhY2sgUkZDLA0KPiBlbmRpbmcgYXQgMjM6NTkgUFNUIG9uIFdlZG5lc2RheSAy OSBOb3ZlbWJlciwgMjAxNy4NCj4NCj4gVGhlIGN1cnJlbnQgKC0wOSkgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1hY2UtY2Jvci13ZWItdG9rZW4tMDkgLg0KPg0KPiBUaGFua3MsDQo+DQo+IEJl biBhbmQgSmltDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGlu ZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGVtYWlsIG1heSBiZSBjb25m aWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBU aGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUg b3JpZ2luYWwgZW1haWwuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg== --_000_DB6P121MB0038ECF1ECA11E8546446B839B320DB6P121MB0038EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0K CW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzIFNhbXVlbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3 aXRoIHlvdXIgYW5zd2VycyBhbmQgcHJvcG9zZWQgYWN0aW9ucyBleGNlcHQgZm9yIHRoZSBiZWxv dzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIHRoaW5rIHRoZSBsYW5ndWFnZSBpbiBz ZWN0aW9uIDMgaXMgZW5vdWdoIHRvIGdldCByb2J1c3QgaW1wbGVtZW50YXRpb25zLiAmcXVvdDth bGwgY2xhaW1zIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyBNVVNU IGJlIGlnbm9yZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklnbm9yaW5nIGEgY2xh aW0gaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBpZ25vcmluZyBhbiB1bnJlY29nbml6ZS91bnN1aXRh YmxlIHRhZyB0aGF0IHByZWZpeGVzIGEgY2xhaW0uIFRoZSBsYXR0ZXIgd2lsbCBpbiBmYWN0IGFj Y2VwdCB0aGUgY2xhaW0gd2hpbGUgdGhlIGZvcm1lciB3aWxsIHJlamVjdCB0aGUgY2xhaW0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBnZXQgdGhlIGRlc2lyZWQgcm9i dXN0bmVzcyBhbmQgZnV0dXJlIGV4dGVuZGliaWxpdHksIGFuZCBtYWtlIHRhZ3MgdXNlZnVsIGZv ciBleGlzdGluZyBjbGFpbXMsIGFuIGltcGxlbWVudGF0aW9uIG11c3QgaWdub3JlIHRoZSB1bnJl Y29nbml6ZWQgdGFnIOKAkyBidXQgbm90IHRoZSBjbGFpbS4gKEFzc3VtaW5nIGFueSBjYXNlcyB3 aGVyZSB0aGUgcmVjZWl2ZXIgc2hvdWxkIHVuZGVyc3RhbmQgdGhlIGNsYWltDQogYnV0IGEgZnV0 dXJlLXZlcnNpb24gc2VuZGVyIGhhcyBhZGRlZCBhbiBhZGRpdGlvbmFsIGZ1dHVyZS12ZXJzaW9u IHRhZyB0byBpdC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHRo aXMgY2FuIGFjaGlldmUgaXMga2VlcCB1c2luZyDigJhvbGTigJkgdmVyc2lvbiBjbGFpbXMgd2hp bGUgYXVnbWVudGluZyB0aGVzZSB3aXRoIOKAmG5ldyB2ZXJzaW9u4oCZIHNlbWFudGljcyBieSB1 c2Ugb2YgdGFncywgaW4gYSBmdXR1cmUgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzaWRlcyB3aXRoIGN1cnJlbnQgU2VjdGlvbiAzICZhbXA7 IDUgbGFuZ3VhZ2Ugb25lIGNsYWltIHBhcnNlciAjMSBtYXkgc3RpbGwgY29uc2lkZXIgYW4g4oCc ZXhw4oCdIGNsYWltIGFzIOKAnHVuZGVyc3Rvb2TigJ0gYmVjYXVzZSBpdCBpZ25vcmVzIGFueSB0 YWdzIGZvciBpdCwgd2hpbGUgcGFyc2VyICMyIG1heSByZWplY3QgdGhhdCDigJxleHDigJ0gY2xh aW0gYmVjYXVzZSBpdCBzZWVzIGEgdGFnIHRoYXQgaXMgbm90IDEuIFdoaWxlDQogcGFyc2VyICMz IG1heSByZWplY3QgYW4g4oCcZXhw4oCdIGNsYWltIGV2ZW4gd2l0aCBhIHRhZyAxIGJlY2F1c2Ug aXQgY29uc2lkZXJzIGl0IG91dCBvZiBzY29wZSBvZiB0aGUgc3BlYyAod2hpY2ggc2F5cyBzZW5k ZXIgTVVTVCBOT1QgdXNlIHRoaXMgdGFnIGhlbmNlIGFueSB0YWcgdXNhZ2UgaXMgbm90IGFjY29y ZGluZyB0byBzcGVjIHNvIG5vdCB1bmRlcnN0b29kLikuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gYSB3YXkgdGhpcyBpc3N1ZSBpcyBzaW1pbGFyIHRvIHRoZSBhcmNoZXR5cGljYWwgc3Bl YyByZXF1aXJlbWVudCBvZiDigJxzZW5kZXIgTVVTVCBwdXQgMHMgaW4gdGhpcyBmaWVsZCBhbmQg YSByZWNlaXZlciBNVVNUIGlnbm9yZSB0aGUgdmFsdWUgb2YgdGhpcyBmaWVsZOKAnS4gJm5ic3A7 Qm90aCBhcmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVza288bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IFNhbXVlbCBFcmR0bWFuIFttYWlsdG86c2FtdWVsQGVyZHRtYW4u c2VdIDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDYsIDIwMTcgMTM6NDg8 YnI+DQo8Yj5Ubzo8L2I+IEVza28gRGlqayAmbHQ7ZXNrby5kaWprQHBoaWxpcHMuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7OyBhY2VA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBY2VdIFdHTEMgb24gZHJhZnQtaWV0 Zi1hY2UtY2Jvci13ZWItdG9rZW4gKGVuZHMgMjkgTm92ZW1iZXIpPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MgRXNrbyBmb3IgeW91ciByZXZpZXcgaXQgaXMgZ3JlYXRseSBh cHByZWNpYXRlZC48YnI+DQo8YnI+DQpzZWUgY29tbWVudHMgaW5saW5lPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgMSwgMjAxNyBhdCAxMDo0NyBBTSwg RXNrbyBEaWprICZsdDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZXNrby5kaWprQHBoaWxpcHMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPGJyPg0K PGJyPg0KT3ZlcmFsbCB0aGUgZG9jdW1lbnQgbG9va3MgaW4gZ29vZCBzaGFwZSB0byBnbyBmb3J3 YXJkIGlmIHRoZSBlYXJsaWVyIG1lbnRpb25lZCBpc3N1ZSBvZiBtdWx0aXBsZSB2YWx1ZXMgZm9y ICZxdW90O2F1ZGllbmNlJnF1b3Q7IChyZXBvcnRlZCBieSBIYW5uZXMpIGlzIGFkZHJlc3NlZDsg YW5kIHRoZSBiZWxvdyBpc3N1ZSBJIHNlZSBmb3IgU2VjdGlvbiA1LiBPdGhlciBjb21tZW50cyBh cmUgbWlub3IuPGJyPg0KKEJ0dyBzb3JyeSBmb3IgYmVpbmcgbGF0ZSByZXNwb25kaW5nIHRvIHRo aXMgV0dMQy4pPGJyPg0KPGJyPg0KTXkgcmV2aWV3IGNvbW1lbnRzIHRvIHNwZWNpZmljIHNlY3Rp b25zOjxicj4NCjxicj4NCkVudGlyZSBkb2N1bWVudDo8YnI+DQpSZXBsYWNlICZxdW90O2JpbmFy eSBzdHJpbmcmcXVvdDsgYnkgJnF1b3Q7Ynl0ZSBzdHJpbmcmcXVvdDsuJm5ic3A7IFRoZSBsYXR0 ZXIgaXMgdGhlIG5hbWUgdXNlZCBpbiBSRkMgNzA0OS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QgcG9pbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgY3JlYXRl ZCBhIFBSIHdhaXRpbmcgZm9yIHJldmlldyBieSB0aGUgY28tYXV0aG9ycyA8bzpwPg0KPC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQoz LjEuMSAvIDMuMS4yIC8gMy4xLjM8YnI+DQomcXVvdDtleGNlcHQgdGhhdCB0aGUgdmFsdWUgaXMg b2YgdHlwZSBTdHJpbmdPclVSSSZxdW90Ozxicj4NCi0mZ3Q7IE1heSBiZSBzbGlnaHRseSBjb25m dXNpbmcgdG8gcmVhZGVycywgc2luY2UgSldUIGFsc28gaGFzIFN0cmluZ09yVVJJIG5hbWVkIHR5 cGUuIFNvIGl0IHNlZW1pbmdseSBzYXlzICZxdW90O2Rvbid0IHVzZSBTdHJpbmdPclVSSSwgYnV0 IHVzZSBTdHJpbmdPclVSSS4mcXVvdDsmbmJzcDsgJm5ic3A7VGhpcyBpcyBtb3N0IGxpa2VseSBp bnRlbmRlZCwgYXMgaW4gJnF1b3Q7ZG9uJ3QgdXNlIEpXVCBTdHJpbmdPclVSSSwgYnV0IHVzZSBv dXIgQ1dUIFN0cmluZ09yVVJJJnF1b3Q7LiBTbyBhbHNvIGZpbmUNCiBpZiB3ZSBsZWF2ZSB0aGlz IGZvcm11bGF0aW9uIGluLCBidXQgaXQgY291bGQgc3RpbGwgY2F1c2Ugc29tZSBjb25mdXNpb24u PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHNlZSB5b3VyIHBvaW50LCBidXQgSSBkb27CtHQgdGhpbmsgaXQgd2lsbCBiZSBhbiBp c3N1ZS4gSldUIGlzIGluIEpTT04gY29udGV4dCBhbmQgQ1dUIGlzIGluIENCT1IgY29udGV4dCBz byB3aGVuZXZlciBzdHJpbmcgaXMgcmVmZXJlZWQgdG8gaW4gQ1dUIHRoZSByZWFkZXIgc2hvdWxk IHRoaW5rIENCT1Igc3RyaW5nIGFuZCB2aWNlIHZlcnNlIGZvciBKV1QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgZG9uwrR0IGhhdmUg YSBzdHJvbmcgb3BpbmlvbiBoZXJlIG9yIGEgZ3JlYXQgc3VnZ2VzdGlvbiBmb3IgYSBuZXcgbmFt ZSBJIHdvdWxkIGxpa2UgdG8ga2VlcCBpdCBhcyBpdCBpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KMy4xLjQgLyAzLjEu NSAvIDMuMS42PGJyPg0KJnF1b3Q7ZXhjZXB0IHRoYXQgdGhlIHZhbHVlIGlzIG9mIHR5cGUgTnVt ZXJpY0RhdGUmcXVvdDs8YnI+DQotJmd0OyBzYW1lIGNvbW1lbnQgYXMgYWJvdmUuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYW1l IGFzIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo1PGJyPg0KVGV4dCBzdGF0ZXMgdGhlIHNlbmRlciBNVVNUIE5P VCB1c2UgYSB0YWcsIGJ1dCBmdXR1cmUgc3BlY3MgbWF5IGludHJvZHVjZSB0YWdzIGZvciBjbGFp bSB2YWx1ZXMuIFRoZW4gaXQgc2VlbXMgcmVxdWlyZWQgdG8gYWxzbyBpbmNsdWRlIHNvbWUgdGV4 dCBhYm91dCBob3cgYSByZWNlaXZlciBpbXBsZW1lbnRpbmcgdGhlICpjdXJyZW50KiB2ZXJzaW9u IG9mIENXVCBzaG91bGQgaGFuZGxlIHRhZ3MgZm9yIGNsYWltIHZhbHVlcywgd2hpY2ggbWF5IGNv bWUNCiBmcm9tIGEgc2VuZGVyIGltcGxlbWVudGluZyBhIGZ1dHVyZSB2ZXJzaW9uIG9mIENXVC48 YnI+DQpFLmcuIGFkZCB0ZXh0ICZxdW90O0EgcmVjZWl2ZXIvZGVjb2RlciBNVVNUIGlnbm9yZSBh bnkgVGFncyB1c2VkIGZvciBhIGNsYWltIHZhbHVlLiZxdW90Ozxicj4NClRoYXQgc2hvdWxkIGhl bHAgcm9idXN0bmVzcyBhbmQgZnV0dXJlIGV4dGVuZGliaWxpdHkuIEUuZy4gd2UgZG9uJ3Qgd2Fu dCByZWNlaXZlcnMgb2YgYSBDV1QgdG8gZ28gY2hlY2sgaWYgdGFncyBhcmUgcHJlc2VudCBhbmQg cmVqZWN0IHRoZSBDV1QgaWYgYSBUYWcgaXMgZm91bmQuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBsYW5ndWFn ZSBpbiBzZWN0aW9uIDMgaXMgZW5vdWdoIHRvIGdldCByb2J1c3QgaW1wbGVtZW50YXRpb25zLiAm cXVvdDthbGwgY2xhaW1zIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9u cyBNVVNUIGJlIGlnbm9yZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjcuMTxicj4NClN0ZXAgNSAmYW1wOyA2 OiB0ZXh0IHN0YXRlcyAmcXVvdDthZGQgdGhlIG1hdGNoaW5nIENPU0UgQ0JPUiB0YWcmcXVvdDsg cmVzcC4gJnF1b3Q7YWRkIHRoZSBhcHByb3ByaWF0ZSBDT1NFIENCT1IgdGFnJnF1b3Q7PGJyPg0K LSZndDsgY291bGQgd2UgY2xhcmlmeSB3aGVyZSB0aGlzIGlzIGFkZGVkLCBlLmcuIHNheSAmcXVv dDtwcmVwZW5kIHdpdGggdGhlIG1hdGNoaW5nIENPU0UgQ0JPUiB0YWcmcXVvdDs/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIGFkZGluZyB0aGUgdGFnIGluIGl0c2VsZiBoYXMgdGhpcyBzZW1hbnRpYy4gQnV0IEkgaGF2 ZSBjcmVhdGVkIGEgUFIgd2l0aCB0aGUgY2hhbmdlLCBzbyB0aGF0IG15IGNvLWF1dGhvcnMgY2Fu IGNvbnNpZGVyIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo5LjIuMTxicj4NCiZxdW90O0FwcGxpY2F0aW9ucyB0aGF0 IHVzZSB0aGlzIG1lZGlhIHR5cGU6IElvVCBhcHBsaWNhdGlvbnMgc2VuZGluZyBzZWN1cml0eSB0 b2tlbnMgb3ZlciBIVFRQKFMpIGFuZCBvdGhlciB0cmFuc3BvcnRzJnF1b3Q7PGJyPg0KLSZndDsg Y2FuIGFscmVhZHkgbWVudGlvbiBDb0FQL0NvQVBzIGhlcmUgPzxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgbm90IG9idmlv dXMgdGhhdCB3ZSBzaG91bGQgbWVudGlvbiBDb0FQKFMpIGhlcmUgc2luY2UgdGhlIG1lZGlhIHR5 cGUgaXMgZm9yIEhUVFAoUykgYW5kIG5vdCBDb0FQKFMpIGFuZCBpdCBkb2VzIHN0YXRlIHRoYXQg JnF1b3Q7YW5kIG90aGVyIHRyYW5zcG9ydHMmcXVvdDsuIEZvciBDb0FQKFMpIHdlIHJlZ2lzdGVy IHRoZSBDb0FQIENvbnRlbnQtRm9ybWF0IHRoYXQgbWFwcyB0byB0aGlzIG1lZGlhIHR5cGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCkJlc3QgcmVnYXJkczxicj4NCkVza28gRGlqazxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQWNlIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+YWNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQmVuamFtaW4gS2FkdWs8 YnI+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjMsIDIwMTcgMDE6MzE8YnI+DQpUbzogPGEg aHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFjZUBpZXRmLm9yZzwv YT48YnI+DQpTdWJqZWN0OiBSZTogW0FjZV0gV0dMQyBvbiBkcmFmdC1pZXRmLWFjZS1jYm9yLXdl Yi10b2tlbiAoZW5kcyAyOSBOb3ZlbWJlcik8YnI+DQo8YnI+DQpSZW1pbmRlcjogdGhlcmUgaXMg b25seSBvbmUgd2VlayBsZWZ0IGluIHRoaXMgV0dMQy48YnI+DQo8YnI+DQotQmVuPGJyPg0KPGJy Pg0KT24gV2VkLCBOb3YgMDEsIDIwMTcgYXQgMTI6MjQ6NTZQTSAtMDUwMCwgQmVuamFtaW4gS2Fk dWsgd3JvdGU6PGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgd29ya2luZyBncm91cCBs YXN0IGNhbGwgZm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbiBmb3Ig c3VibWlzc2lvbiBhcyBhIFN0YW5kYXJkcy1UcmFjayBSRkMsPGJyPg0KJmd0OyBlbmRpbmcgYXQg MjM6NTkgUFNUIG9uIFdlZG5lc2RheSAyOSBOb3ZlbWJlciwgMjAxNy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGUgY3VycmVudCAoLTA5KSB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBhdmFpbGFi bGUgYXQ6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hY2UtY2Jvci13ZWItdG9rZW4tMDkiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbi0wOTwvYT4g Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZW4gYW5k IEppbTxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBBY2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86QWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYub3JnPC9h Pjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FjZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 QWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZW1haWwgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1p bmF0aW9uLA0KIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBk ZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86QWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB6P121MB0038ECF1ECA11E8546446B839B320DB6P121MB0038EURP_-- From nobody Wed Dec 6 06:41:57 2017 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 080A5126DC2 for ; Wed, 6 Dec 2017 06:41:56 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7mw43qXxCQg for ; Wed, 6 Dec 2017 06:41:54 -0800 (PST) Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A741A128DE7 for ; Wed, 6 Dec 2017 06:41:53 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8736"; a="27178080" X-IronPort-AV: E=Sophos; i="5.45,368,1508799600"; d="scan'208,217"; a="27178080" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 06 Dec 2017 14:43:19 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id E44FAFA10 for ; Wed, 6 Dec 2017 13:24:11 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id CD5CAFA02 for ; Wed, 6 Dec 2017 13:24:11 +0000 (GMT) Received: from UK-MAL-OWA-02.dyson.global.corp (10.1.108.7) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Dec 2017 14:41:50 +0000 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-OWA-02.dyson.global.corp ([fe80::f9b6:1719:a6d9:1eca%10]) with mapi id 14.03.0319.002; Wed, 6 Dec 2017 14:41:50 +0000 From: Tony Putman To: "ace@ietf.org" Thread-Topic: Independent I-D for new TLS authentication (triple-ECDH) Thread-Index: AdNunu5LAYHjPeXuQ9yxIzFFHOI3OA== Date: Wed, 6 Dec 2017 14:41:49 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC0B04238CUKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 14:41:56 -0000 --_000_140080C241BAA1419B58F093108F9EDC0B04238CUKMALMBOX01dyso_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I recently produced an I-D for a TLS authentication method using pre-shared= ECDH asymmetric keys, which I believe will be useful for constrained envir= onments. IMHO the key benefits are: - a breach of server security does not result in client impersonation (unli= ke PSK) - a single EC algorithm is used (ECDH), though it is used several times - static public keys are not exchanged, so protocol messages are smaller I would like to know if people working with constrained devices agree with = me that these are useful benefits and whether people feel that this is wort= h pursuing. The draft is at https://datatracker.ietf.org/doc/draft-putman-tls-preshared= -ecdh/ Thanks, Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. --_000_140080C241BAA1419B58F093108F9EDC0B04238CUKMALMBOX01dyso_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

 

I recently produced an I-D for a TLS authentication = method using pre-shared ECDH asymmetric keys, which I believe will be usefu= l for constrained environments.  IMHO the key benefits are:=

- a breach of server security does not result in cli= ent impersonation (unlike PSK)

- a single EC algorithm is used (ECDH), though it is= used several times

- static public keys are not exchanged, so protocol = messages are smaller

 

I would like to know if people working with constrai= ned devices agree with me that these are useful benefits and whether people= feel that this is worth pursuing.

 

The draft is at https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/<= /o:p>

 

Thanks,

Tony

 


Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g. --_000_140080C241BAA1419B58F093108F9EDC0B04238CUKMALMBOX01dyso_-- From nobody Wed Dec 6 07:04:49 2017 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 B99E3128BBB for ; Wed, 6 Dec 2017 07:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIqC_eP-UiUJ for ; Wed, 6 Dec 2017 07:04:40 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9543A126DD9 for ; Wed, 6 Dec 2017 07:04:40 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id E2ABB204C1D for ; Wed, 6 Dec 2017 15:04:36 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 6 Dec 2017 16:04:38 +0100 To: References: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> From: Ludwig Seitz Message-ID: Date: Wed, 6 Dec 2017 16:04:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=N659UExz7-8A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=M1CJqV53AVGseO2_dkwA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:04:48 -0000 On 2017-12-06 15:41, Tony Putman wrote: > Hi, > > I recently produced an I-D for a TLS authentication method using > pre-shared ECDH asymmetric keys, which I believe will be useful for > constrained environments.  IMHO the key benefits are: > > - a breach of server security does not result in client impersonation > (unlike PSK) > > - a single EC algorithm is used (ECDH), though it is used several times > > - static public keys are not exchanged, so protocol messages are smaller > > I would like to know if people working with constrained devices agree > with me that these are useful benefits and whether people feel that this > is worth pursuing. > > The draft is at > https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/ > > Thanks, > > Tony > > Hi Tony, could you explain the differences between your draft and the (D)TLS handshake with raw public keys (https://tools.ietf.org/html/rfc7250)? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Dec 6 07:06:50 2017 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 09499120725 for ; Wed, 6 Dec 2017 07:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmpL_vDN9jpz for ; Wed, 6 Dec 2017 07:06:46 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0079.outbound.protection.outlook.com [104.47.2.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E03126DD9 for ; Wed, 6 Dec 2017 07:06:45 -0800 (PST) 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=7rTDO3ngdVxpUzjV3seXSUUDTr69v3iC3Tm6tjE0FDQ=; b=gDl2D9qR+OxIV4H9u9ZCDvKlyPrno8UMTeNzkeHXuIFkbt5VPeXyxcKZfpAQC7p7FS3zthwtJeZU+w/BJZWz9WH3jjOO5HQANJZgUbHJ6os+DFKtGO9K2hQ4fuZI1JwE5fGj6mkjVp6qS/3zXasDtpPq7Mbzh3/AH3Pv5s/+dLU= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Wed, 6 Dec 2017 15:06:43 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0282.012; Wed, 6 Dec 2017 15:06:43 +0000 From: Hannes Tschofenig To: Tony Putman , "ace@ietf.org" Thread-Topic: Independent I-D for new TLS authentication (triple-ECDH) Thread-Index: AdNunu5LAYHjPeXuQ9yxIzFFHOI3OAABNEmA Date: Wed, 6 Dec 2017 15:06:43 +0000 Message-ID: References: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> In-Reply-To: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:lF4k28wbIzKrbe86X8ATXXU4KtKvXPLSbIoDtXqNap5HsYd5c1RgAsU8o6ldZ6Ek35Hi/gYtrpNmrJ/tHIhonJIBqMZYZa0KbhbdlyqDFo1fBmn2WwfmlxmmLhu8tlIvjZH/eWVGLwG34LX24xcnECfJNSUT4+36TFv48feEXRcjZdZDhf6Ei8eFqZELEg3LE5W5dWRejqBR55ssU/KwyFJAF1rNOTFtopDu/zqAHLfktcyuSCPgz2ME/90ju7QLpishYImydryMue4NnASXLJ5KqQO1E8fTQUK+aqkgoye/lM4iUqmmKfF3RqWm/Tr+cV+N/WdtHbakipWprlU0kJ0y9yCgB6G9TrB9aOkJXGQ=; 5:OBcA+7vtYDyGE/CLSSd+42mVFTbFu8MtKgMoHx3JPRCnBNmP1uv5s2tMG1Ce8dU0CSXV5zHbHcDqMEdawiPpC1zWQQ25b53wz9HYiG+HKZ4BM9K1AgK4MlNS7loOGbNqMOc+zb7yj21P3aW4XsOnUAi5hDT46/Y9YZcxNePgs+M=; 24:JwXp0GV8VIpxRGnZadJVHRi7UOLTP2lAaeEXDQGVodlrOcUFJ44mbq3hv3Kskzz+MJMK6D4BLcikaKCZbyYNcOuAP4Ge1hGwdALuQvqASLc=; 7:0YY+ux7gmxU2c3EipAK/uqhlfSSxIRvPJLmoPpPKj2t80pjz0e6wXc2yYZ2yJukUep9O2b3O6VPIZeBnVzume+2jEqdJATal7k0uZmUl5CT5Pz4bbarX3hB7xEUAaru9G0qB0dXYEEscgRSxvo3e4qC3/8xJKtKSVq4m/MOCYk79GvomzLXtRyCNrIdjfiJRdPqfxFi5d3B925KhEh7T0WHBtgl5GS/AB8FYBf9QkbWqQH/Im0I8CEbm8V58RpgT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 39dfe8c7-bc9b-41e6-596f-08d53cbaf661 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(40434004)(199004)(189003)(81156014)(68736007)(2501003)(7696005)(3280700002)(105586002)(101416001)(229853002)(97736004)(6506006)(110136005)(66066001)(3660700001)(2906002)(76176011)(8676002)(5890100001)(9326002)(81166006)(8936002)(86362001)(2900100001)(5660300001)(316002)(14454004)(6306002)(74316002)(99286004)(25786009)(966005)(72206003)(5250100002)(53936002)(7736002)(55016002)(606006)(6246003)(236005)(478600001)(106356001)(102836003)(6436002)(54896002)(9686003)(6116002)(33656002)(3846002)(53546010)(790700001)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706C1773B6BF82E16ACA3B5FA320AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39dfe8c7-bc9b-41e6-596f-08d53cbaf661 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 15:06:43.7014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:06:49 -0000 --_000_AM4PR0801MB2706C1773B6BF82E16ACA3B5FA320AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tony, If I understand your idea correctly then you have just re-invented the raw = public key concept defined in https://tools.ietf.org/html/rfc7250 Ciao Hannes From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Tony Putman Sent: 06 December 2017 14:42 To: ace@ietf.org Subject: [Ace] Independent I-D for new TLS authentication (triple-ECDH) Hi, I recently produced an I-D for a TLS authentication method using pre-shared= ECDH asymmetric keys, which I believe will be useful for constrained envir= onments. IMHO the key benefits are: - a breach of server security does not result in client impersonation (unli= ke PSK) - a single EC algorithm is used (ECDH), though it is used several times - static public keys are not exchanged, so protocol messages are smaller I would like to know if people working with constrained devices agree with = me that these are useful benefits and whether people feel that this is wort= h pursuing. The draft is at https://datatracker.ietf.org/doc/draft-putman-tls-preshared= -ecdh/ Thanks, Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706C1773B6BF82E16ACA3B5FA320AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tony,

 

If I understand your i= dea correctly then you have just re-invented the raw public key concept def= ined in https://tools.ietf.org/html/rfc7250

 

Ciao=

Hannes

 

 

From:= Ace [mailto:ace-bounces@ietf.org] On Behalf Of Tony Putman
Sent: 06 December 2017 14:42
To: ace@ietf.org
Subject: [Ace] Independent I-D for new TLS authentication (triple-EC= DH)

 

Hi,

 

I recently produced an I-D for a TLS authentication = method using pre-shared ECDH asymmetric keys, which I believe will be usefu= l for constrained environments.  IMHO the key benefits are:=

- a breach of server security does not result in cli= ent impersonation (unlike PSK)

- a single EC algorithm is used (ECDH), though it is= used several times

- static public keys are not exchanged, so protocol = messages are smaller

 

I would like to know if people working with constrai= ned devices agree with me that these are useful benefits and whether people= feel that this is worth pursuing.

 

The draft is at https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/<= /o:p>

 

Thanks,

Tony

 


Dyson Technology Limited,= company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706C1773B6BF82E16ACA3B5FA320AM4PR0801MB2706_-- From nobody Wed Dec 6 07:33:07 2017 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 BF031126DD9 for ; Wed, 6 Dec 2017 07:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 n8KyIyEn7IOo for ; Wed, 6 Dec 2017 07:33:05 -0800 (PST) Received: from esa3.dyson.c3s2.iphmx.com (esa3.dyson.c3s2.iphmx.com [68.232.139.42]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84830126D45 for ; Wed, 6 Dec 2017 07:33:04 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8736"; a="25891065" X-IronPort-AV: E=Sophos;i="5.45,368,1508799600"; d="scan'208";a="25891065" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa3.dyson.c3s2.iphmx.com with ESMTP; 06 Dec 2017 15:36:51 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 7FEF4FA10; Wed, 6 Dec 2017 14:15:21 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 726DFFA02; Wed, 6 Dec 2017 14:15:21 +0000 (GMT) Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-02.dyson.global.corp ([fe80::d0fe:1c2d:58fc:2dbb%17]) with mapi id 14.03.0319.002; Wed, 6 Dec 2017 15:33:00 +0000 From: Tony Putman To: Ludwig Seitz , Hannes Tschofenig CC: "ace@ietf.org" Thread-Topic: [Ace] Independent I-D for new TLS authentication (triple-ECDH) Thread-Index: AdNunu5LAYHjPeXuQ9yxIzFFHOI3OAABJoKAAACXunA= Date: Wed, 6 Dec 2017 15:32:59 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC0B0423C8@UK-MAL-MBOX-01.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:33:07 -0000 Ludwig, Hannes, The differences with RFC7250 are twofold: 1. The raw public keys are not exchanged in the handshake sequence. Even w= ith cached info (RFC7924), a fingerprint of the certificate (or raw public = key) is exchanged. Also, a ClientVerify message is needed if mutual authent= ication is required (which is automatic with 3ECDH). These extra elements a= dd to the size of the handshake exchange. They also identify the sender (wh= ereas my draft encrypts the client identity), which can be an issue if priv= acy of the session endpoints is important. = 2. ECDH cannot be used as a raw public key; instead ECDSA or EdDSA is need= ed. But ECDH is also needed if the handshake includes perfect forward secre= cy (highly recommended/mandatory, depending on usage). Therefore the client= has to implement two algorithms and may need to implement fast versions of= both of them to reduce latency in session establishment. Using 3ECDH, the = client only needs a single algorithm; if EdDSA is needed anyway (e.g. for c= ode signing), then a slow version may be used which saves code-space and da= ta-space. = -- = Tony > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz > Hi Tony, > = > could you explain the differences between your draft and the (D)TLS > handshake with raw public keys (https://tools.ietf.org/html/rfc7250)? > = > /Ludwig > https://www.ietf.org/mailman/listinfo/ace Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. From nobody Wed Dec 6 07:42:53 2017 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 142A4127077 for ; Wed, 6 Dec 2017 07:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_uVd2aErHpM for ; Wed, 6 Dec 2017 07:42:49 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0062.outbound.protection.outlook.com [104.47.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D531E12708C for ; Wed, 6 Dec 2017 07:42:48 -0800 (PST) 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=R9EDTaIg80RCKMtHMOKC+xpTVwFV2Zqn2hNu+84nne0=; b=hKJ22+Axkku7qu8h+uRA0YbIvIhvLYnvaCeTRWluAm8XBAvenl/ptrnOcdY6sAraaVG+2z4uGxnPfl2ZpoDf8QmdBJZu9rvuwdPAqCDvNIZgaOc3kmwkLxqPqoOpcD5KX4M9wdgOCvgbSwZotRE30iExlE9lUtPgbSTCG+G1KS0= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Wed, 6 Dec 2017 15:42:46 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0282.012; Wed, 6 Dec 2017 15:42:46 +0000 From: Hannes Tschofenig To: Tony Putman , Ludwig Seitz CC: "ace@ietf.org" Thread-Topic: [Ace] Independent I-D for new TLS authentication (triple-ECDH) Thread-Index: AdNunu5LAYHjPeXuQ9yxIzFFHOI3OAABJoKAAACXunAAAGpHcA== Date: Wed, 6 Dec 2017 15:42:46 +0000 Message-ID: References: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC0B0423C8@UK-MAL-MBOX-01.dyson.global.corp> In-Reply-To: <140080C241BAA1419B58F093108F9EDC0B0423C8@UK-MAL-MBOX-01.dyson.global.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:I29E3WKsEwrK+3SesWYYwdstJb2VHnJcIDaA7Dol4SxtnOuG7jae+2mAU+kFhtxIUI74+xGKyzqYmd/ydk0NcE0B+XfqG5zguFm0/xDrkHj58oAkIM7IoEEhmusMg949rgOYcj6F0+E9zLRmR53ceOr9lEe5tXsK+3Z/Wzxgccy0Gvsrpv7yioIp5E+pNNZNhUoyAm/aAf/vsUD/eU2lr5qxkbJrVIu2ZcoEoq9khbdFAclWqYcuAgXsLvyiqONQy8RKglCwlc9EC735GXu2/EcBSAtv1W3P/5GUrTlVAhz4nFzl6iXieT0PHH25ll6khStHoKgeabHvRoFb54qvqs29uk55vbs19/bLQZs0yec=; 5:ijIxwCam1MwoSa452NpIRVaBxELQ0qlh6O2tlvGZfWQkhNrSLwe0OOWNUffndCywlNqcl2FuhkYSlXl7smJujQfUUfW3qvZw937+J39OqGi/LgJGegp2SqipTo/IG+hdLKoEtZTDR+CBaTo5eobDHrzkz3QYSZKgewZ+CRl2hRM=; 24:VCSWdCtm5zbgIScpTLsBcVXxdEvhrTlacM/rOFUB/vhkmPC7KRB7k+fpv0Ix7PI8PzUb2jVxysKSuh8CUdOkcDRFWTxb6x7vrHbhacijoKk=; 7:9ltKwLmezrgIy6tYwz0VqmgcqDD1xE6kPooo2ODAoJ0/ThUUz3rIqxcI53PLu57WUaXIqEE+iZgF3okWNuft1CtQ9Vihcnev/AQgJUCoFTxsH9/6zrxySh1oaWSMwCAk4KP5Lzlph9+1ZAAzdWcNEJU6q6df8GcXC7m/g9U9DUEiC+Tg3jf9eCf0bNjG3ogLI+LsQirqxmVrH5BB3g/l/F71qXgwAovtLOHx8v8Jl2zyw+rzZD0x+UElpDLH5XiY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 40d73358-8c38-4e9f-97fa-08d53cbfff4f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(366004)(13464003)(40434004)(199004)(189003)(229853002)(102836003)(2950100002)(6116002)(3846002)(97736004)(53546010)(2906002)(5660300001)(66066001)(3280700002)(3660700001)(53936002)(99286004)(8936002)(14454004)(55016002)(6246003)(6506006)(81166006)(6436002)(86362001)(81156014)(8676002)(9686003)(6306002)(68736007)(5250100002)(25786009)(33656002)(966005)(305945005)(110136005)(478600001)(72206003)(74316002)(5890100001)(2900100001)(76176011)(105586002)(106356001)(316002)(7696005)(101416001)(4326008)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40d73358-8c38-4e9f-97fa-08d53cbfff4f X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 15:42:46.1525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:42:52 -0000 Hi Tony, Remarks below. -----Original Message----- From: Tony Putman [mailto:Tony.Putman@dyson.com] Sent: 06 December 2017 15:33 To: Ludwig Seitz; Hannes Tschofenig Cc: ace@ietf.org Subject: RE: [Ace] Independent I-D for new TLS authentication (triple-ECDH) Ludwig, Hannes, The differences with RFC7250 are twofold: 1. The raw public keys are not exchanged in the handshake sequence. Even w= ith cached info (RFC7924), a fingerprint of the certificate (or raw public = key) is exchanged. Also, a ClientVerify message is needed if mutual authent= ication is required (which is automatic with 3ECDH). These extra elements a= dd to the size of the handshake exchange. They also identify the sender (wh= ereas my draft encrypts the client identity), which can be an issue if priv= acy of the session endpoints is important. [Hannes] It is true that the raw public keys are exchanged unless you use c= ached info where only the fingerprint of the client side raw public key is = provided. For the privacy aspect you are also correct for TLS / DTLS 1.2 bu= t 1.3 changes this procedure. 2. ECDH cannot be used as a raw public key; instead ECDSA or EdDSA is need= ed. But ECDH is also needed if the handshake includes perfect forward secre= cy (highly recommended/mandatory, depending on usage). Therefore the client= has to implement two algorithms and may need to implement fast versions of= both of them to reduce latency in session establishment. Using 3ECDH, the = client only needs a single algorithm; if EdDSA is needed anyway (e.g. for c= ode signing), then a slow version may be used which saves code-space and da= ta-space. [Hannes] It is true that the raw public key RFC does not use long-term ECDH= keys but instead uses those only in an ephemeral way. I would consider a = design feature rather than a bug. [Hannes] Thanks for clarifying your design. What I am wondering is, however= , whether the issues you raised are a concern in deployments (I haven't hea= rd them) and whether it makes sense to continue working on TLS / DTLS 1.2 w= hen 1.3 is already looming on the horizon where the raw public key mode is = nicely integrated as well. Ciao Hannes -- Tony > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Hi > Tony, > > could you explain the differences between your draft and the (D)TLS > handshake with raw public keys (https://tools.ietf.org/html/rfc7250)? > > /Ludwig > https://www.ietf.org/mailman/listinfo/ace Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. 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 Wed Dec 6 08:53:02 2017 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 EAE881275F4 for ; Wed, 6 Dec 2017 08:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 86ZxA9vwQLUo for ; Wed, 6 Dec 2017 08:52:59 -0800 (PST) Received: from esa3.dyson.c3s2.iphmx.com (esa3.dyson.c3s2.iphmx.com [68.232.139.42]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07506127517 for ; Wed, 6 Dec 2017 08:52:58 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8736"; a="25895313" X-IronPort-AV: E=Sophos;i="5.45,368,1508799600"; d="scan'208";a="25895313" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa3.dyson.c3s2.iphmx.com with ESMTP; 06 Dec 2017 16:57:04 +0000 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 9E6E494711; Wed, 6 Dec 2017 15:56:23 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 8E33894702; Wed, 6 Dec 2017 15:56:23 +0000 (GMT) Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-02.dyson.global.corp ([fe80::d0fe:1c2d:58fc:2dbb%17]) with mapi id 14.03.0319.002; Wed, 6 Dec 2017 16:52:56 +0000 From: Tony Putman To: Hannes Tschofenig , Ludwig Seitz CC: "ace@ietf.org" Thread-Topic: [Ace] Independent I-D for new TLS authentication (triple-ECDH) Thread-Index: AdNunu5LAYHjPeXuQ9yxIzFFHOI3OAABJoKAAACXunAAAGpHcAACA35w Date: Wed, 6 Dec 2017 16:52:56 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC0B04342C@UK-MAL-MBOX-01.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC0B04238C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC0B0423C8@UK-MAL-MBOX-01.dyson.global.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 16:53:01 -0000 Hi Hannes, From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > [Hannes] It is true that the raw public key RFC does not use long-term EC= DH keys > but instead uses those only in an ephemeral way. I would consider a desi= gn > feature rather than a bug. I'm certainly not calling it a bug, but it unavoidably results in the use o= f two different algorithms. How important this is to people is one of the t= hings that I'm asking about. > [Hannes] Thanks for clarifying your design. What I am wondering is, howev= er, > whether the issues you raised are a concern in deployments (I haven't hea= rd > them) Internally, I am working with a number of product teams, and their products= have different capabilities. What drove me to produce this I-D was a desir= e to push non-PSK security into the lowest-powered devices possible. So eff= ectively I am trying to minimise the processing costs of (D)TLS authenticat= ion. I am curious to know how many people face the same sort of pressures. = > [Hannes] and whether it makes sense to continue working on TLS / DTLS 1.2= when > 1.3 is already looming on the horizon where the raw public key mode is ni= cely > integrated as well. I have read up on (D)TLS 1.3, but don't have any practical experience with = it yet. Even so, I think that the advantages I enumerated (shorter messages= , single algorithm, but not the privacy concerns) are fundamental and will = also apply to (D)TLS 1.3. In other words, I believe that 3ECDH authenticati= on will still offer advantages for constrained devices. If there is interes= t, then I'd be happy to work on the (D)TLS equivalent 3ECDH authentication = exchange. = -- Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. From nobody Fri Dec 8 04:31:37 2017 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 F0872124B17 for ; Fri, 8 Dec 2017 04:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 DzkyJ_clzc-I for ; Fri, 8 Dec 2017 04:31:33 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 EF0421200C1 for ; Fri, 8 Dec 2017 04:31:32 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id y6so6798829pgp.4 for ; Fri, 08 Dec 2017 04:31:32 -0800 (PST) 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=h0Nn+PtlJUWixW0cXPV8aTtte9RWS/gxkK9gqT39twE=; b=CAr3zMFCvnHmuZHive/iG3xwGQb6YzcTLe/s4St3qplXVu57e94hrwWkHoYHrYuX5k 0yeZBr8HIWtA7utEw5tAKItJm1wSSnwnsmcx+gr9h4em+ybaZIcmqdBIhQHYrQMdrPnx 9Q4HO3OjSQJwY3iF0UwOs8KdHxK35wcw7HjJsTae/mBKUfyifG8zS0ReuCYCkdgBwsPb Zpw690xXIWsXx82Uw46qNKPcMWiKVgTwKhhgOvB40zX/QRBMjRR7IIMrFunj3L5DqlFI NEpsFNw52li/CLbgcIPI6Up3NyXO1b656G7iLeubzv/jwAgYMHuJhUC0eQws5mhu6DIg BmkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0Nn+PtlJUWixW0cXPV8aTtte9RWS/gxkK9gqT39twE=; b=exu9gT/MMSba0s3TKBPPCSMPrAjIgLqfHfij6VoOhqxYIKG8xqivtxEu9P+E40XSHr 0P0GApHWu7mKxa6VSYYhv3gtydfrS7YDMals+wDfKRY2m4lT9tfXYZval0U6lMKV/x/4 +Ao1PdvJHTRzw0VECVhyTwm//Z89azOFBIrrsWesMW9VqWw6yKak4nTO1K64Vx6n1yoy wCiC2DDZ8Qp9oR31bkIACvW291YedWxiNYe2RpVGuXr+7wFUqlEKgK8VJ2Scw4Tp79rb KJTe9Ko+wM6j7aBmqt+AXg6ht/M6A9grbXPyBNRBUvnbopcrKTn6Gz3kj7bmgyGAxP9s ig/w== X-Gm-Message-State: AJaThX7RXFVzqvwCS8A5BEJxTyY65iUqev9wxH03PX+G1orCwP3K0MLk 596AfHKk+CLd0jzO1fAdD1IlLCHxBvzqO9bOGYU2nlUKas8= X-Google-Smtp-Source: AGs4zMYHrA3y1nvtaaQGIttDYNwACCyP7/8OktRNldQdrJ2EgHiP00V6TfPCnkz207+dSZFr0IOWyFBgEHQgJ9Ug8vE= X-Received: by 10.84.240.193 with SMTP id l1mr30259680plt.240.1512736291983; Fri, 08 Dec 2017 04:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.169.15 with HTTP; Fri, 8 Dec 2017 04:31:31 -0800 (PST) In-Reply-To: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> From: Samuel Erdtman Date: Fri, 8 Dec 2017 13:31:31 +0100 Message-ID: To: Esko Dijk Cc: Benjamin Kaduk , "ace@ietf.org" Content-Type: multipart/alternative; boundary="089e0821469c52ab01055fd35d3d" Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Dec 2017 12:31:36 -0000 --089e0821469c52ab01055fd35d3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks for persisting See inline On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk wrote: > Thanks Samuel, > > > > I agree with your answers and proposed actions except for the below: > > > > > I think the language in section 3 is enough to get robust > implementations. "all claims that are not understood by implementations > MUST be ignored." > > > > Ignoring a claim is very different from ignoring an unrecognize/unsuitabl= e > tag that prefixes a claim. The latter will in fact accept the claim while > the former will reject the claim. > > To get the desired robustness and future extendibility, and make tags > useful for existing claims, an implementation must ignore the unrecognize= d > tag =E2=80=93 but not the claim. (Assuming any cases where the receiver s= hould > understand the claim but a future-version sender has added an additional > future-version tag to it.) > > What this can achieve is keep using =E2=80=98old=E2=80=99 version claims = while augmenting > these with =E2=80=98new version=E2=80=99 semantics by use of tags, in a f= uture version of > the specification. > > > > Besides with current Section 3 & 5 language one claim parser #1 may still > consider an =E2=80=9Cexp=E2=80=9D claim as =E2=80=9Cunderstood=E2=80=9D b= ecause it ignores any tags for it, > while parser #2 may reject that =E2=80=9Cexp=E2=80=9D claim because it se= es a tag that is > not 1. While parser #3 may reject an =E2=80=9Cexp=E2=80=9D claim even wit= h a tag 1 because > it considers it out of scope of the spec (which says sender MUST NOT use > this tag hence any tag usage is not according to spec so not understood.)= . > > > > In a way this issue is similar to the archetypical spec requirement of > =E2=80=9Csender MUST put 0s in this field and a receiver MUST ignore the = value of > this field=E2=80=9D. Both are needed. > I have added created a PR with some text to make this more specific. please have a look at https://github.com/erwah/ietf/pull/74 > > Best Regards > > Esko > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se] > *Sent:* Wednesday, December 6, 2017 13:48 > *To:* Esko Dijk > *Cc:* Benjamin Kaduk ; ace@ietf.org > > *Subject:* Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 > November) > > > > Thanks Esko for your review it is greatly appreciated. > > see comments inline > > > > On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk wrote: > > Dear all, > > Overall the document looks in good shape to go forward if the earlier > mentioned issue of multiple values for "audience" (reported by Hannes) is > addressed; and the below issue I see for Section 5. Other comments are > minor. > (Btw sorry for being late responding to this WGLC.) > > My review comments to specific sections: > > Entire document: > Replace "binary string" by "byte string". The latter is the name used in > RFC 7049. > > > > Good point. > > I have created a PR waiting for review by the co-authors > > > > > 3.1.1 / 3.1.2 / 3.1.3 > "except that the value is of type StringOrURI" > -> May be slightly confusing to readers, since JWT also has StringOrURI > named type. So it seemingly says "don't use StringOrURI, but use > StringOrURI." This is most likely intended, as in "don't use JWT > StringOrURI, but use our CWT StringOrURI". So also fine if we leave this > formulation in, but it could still cause some confusion. > > > > I see your point, but I don=C2=B4t think it will be an issue. JWT is in J= SON > context and CWT is in CBOR context so whenever string is refereed to in C= WT > the reader should think CBOR string and vice verse for JWT. > > If you don=C2=B4t have a strong opinion here or a great suggestion for a = new > name I would like to keep it as it is. > > > > > 3.1.4 / 3.1.5 / 3.1.6 > "except that the value is of type NumericDate" > -> same comment as above. > > > > Same as above. > > > > > 5 > Text states the sender MUST NOT use a tag, but future specs may introduce > tags for claim values. Then it seems required to also include some text > about how a receiver implementing the *current* version of CWT should > handle tags for claim values, which may come from a sender implementing a > future version of CWT. > E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim > value." > That should help robustness and future extendibility. E.g. we don't want > receivers of a CWT to go check if tags are present and reject the CWT if = a > Tag is found. > > > > I think the language in section 3 is enough to get robust implementations= . > "all claims that are not understood by implementations MUST be ignored." > > > > > 7.1 > Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the > appropriate COSE CBOR tag" > -> could we clarify where this is added, e.g. say "prepend with the > matching COSE CBOR tag"? > > > > I think adding the tag in itself has this semantic. But I have created a > PR with the change, so that my co-authors can consider it. > > > > > 9.2.1 > "Applications that use this media type: IoT applications sending security > tokens over HTTP(S) and other transports" > -> can already mention CoAP/CoAPs here ? > > > > It is not obvious that we should mention CoAP(S) here since the media typ= e > is for HTTP(S) and not CoAP(S) and it does state that "and other > transports". For CoAP(S) we register the CoAP Content-Format that maps to > this media type. > > > > > Best regards > Esko Dijk > > > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: Thursday, November 23, 2017 01:31 > To: ace@ietf.org > Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 Novembe= r) > > Reminder: there is only one week left in this WGLC. > > -Ben > > On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > > This message begins a working group last call for > > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > > ending at 23:59 PST on Wednesday 29 November, 2017. > > > > The current (-09) version of the document is available at: > > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > > > Thanks, > > > > Ben and Jim > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > ________________________________ > The information contained in this email may be confidential and/or legall= y > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > email is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destro= y > all copies of the original email. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > --089e0821469c52ab01055fd35d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks for persisting

See inline

On Wed, Dec 6, 2017 a= t 2:48 PM, Esko Dijk <esko.dijk@philips.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Thanks Samuel,

=C2=A0

I agree with your answers and proposed actions= except for the below:

=C2=A0

> I think the language in section 3 is enou= gh to get robust implementations. "all claims that are not understood = by implementations MUST be ignored."

=C2=A0

Ignoring a claim is very different from= ignoring an unrecognize/unsuitable tag that prefixes a claim. The latter w= ill in fact accept the claim while the former will reject the claim.=

To get the desired robustness and future exten= dibility, and make tags useful for existing claims, an implementation must = ignore the unrecognized tag =E2=80=93 but not the claim. (Assuming any case= s where the receiver should understand the claim but a future-version sender has added an additional future-version tag to = it.)

What this can achieve is keep using =E2=80=98o= ld=E2=80=99 version claims while augmenting these with =E2=80=98new version= =E2=80=99 semantics by use of tags, in a future version of the specificatio= n.

=C2=A0

Besides with current Section 3 & 5 languag= e one claim parser #1 may still consider an =E2=80=9Cexp=E2=80=9D claim as = =E2=80=9Cunderstood=E2=80=9D because it ignores any tags for it, while pars= er #2 may reject that =E2=80=9Cexp=E2=80=9D claim because it sees a tag tha= t is not 1. While parser #3 may reject an =E2=80=9Cexp=E2=80=9D claim even with a tag 1 beca= use it considers it out of scope of the spec (which says sender MUST NOT us= e this tag hence any tag usage is not according to spec so not understood.)= .

=C2=A0

In a way this issue is similar to the archetyp= ical spec requirement of =E2=80=9Csender MUST put 0s in this field and a re= ceiver MUST ignore the value of this field=E2=80=9D.=C2=A0 Both are needed.=


I have added created a PR = with some text to make this more specific.

=C2=A0

Best Regards

Esko

=C2=A0

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <esko.dijk@philips.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>; ace@ietf.org


Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 No= vember)

=C2=A0

Thanks Esko for your review it is greatly appr= eciated.

see comments inline

=C2=A0

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <= ;esko.dijk@phili= ps.com> wrote:

Dear all,

Overall the document looks in good shape to go forward if the earlier menti= oned issue of multiple values for "audience" (reported by Hannes)= is addressed; and the below issue I see for Section 5. Other comments are = minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".=C2=A0 The lat= ter is the name used in RFC 7049.

=C2=A0

Good point.

I have created a PR waiting for review by the = co-authors

=C2=A0


3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI = named type. So it seemingly says "don't use StringOrURI, but use S= tringOrURI."=C2=A0 =C2=A0This is most likely intended, as in "don= 't use JWT StringOrURI, but use our CWT StringOrURI". So also fine if we leave this formulation in, but it could still cause some confusion.<= u>

=C2=A0

I see your point, but I don=C2=B4t think it wi= ll be an issue. JWT is in JSON context and CWT is in CBOR context so whenev= er string is refereed to in CWT the reader should think CBOR string and vic= e verse for JWT.

If you don=C2=B4t have a strong opinion here o= r a great suggestion for a new name I would like to keep it as it is.

=C2=A0


3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.

=C2=A0

Same as above.

=C2=A0


5
Text states the sender MUST NOT use a tag, but future specs may introduce t= ags for claim values. Then it seems required to also include some text abou= t how a receiver implementing the *current* version of CWT should handle ta= gs for claim values, which may come from a sender implementing a future version of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a clai= m value."
That should help robustness and future extendibility. E.g. we don't wan= t receivers of a CWT to go check if tags are present and reject the CWT if = a Tag is found.

=C2=A0

I think the language in section 3 is enough to= get robust implementations. "all claims that are not understood by im= plementations MUST be ignored."

=C2=A0


7.1
Step 5 & 6: text states "add the matching COSE CBOR tag" resp= . "add the appropriate COSE CBOR tag"
-> could we clarify where this is added, e.g. say "prepend with the= matching COSE CBOR tag"?

=C2=A0

I think adding the tag in itself has this sema= ntic. But I have created a PR with the change, so that my co-authors can co= nsider it.

=C2=A0


9.2.1
"Applications that use this media type: IoT applications sending secur= ity tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?

=C2=A0

It is not obvious that we should mention CoAP(= S) here since the media type is for HTTP(S) and not CoAP(S) and it does sta= te that "and other transports". For CoAP(S) we register the CoAP = Content-Format that maps to this media type.

=C2=A0


Best regards
Esko Dijk



-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)=

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,=
> ending at 23:59 PST on Wednesday 29 November, 2017.
>
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 = .
>
> Thanks,
>
> Ben and Jim
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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

________________________________
The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. = If you are not the intended recipient, please contact the sender by return = e-mail and destroy all copies of the original email.


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

=C2=A0


--089e0821469c52ab01055fd35d3d-- From nobody Fri Dec 8 05:45:59 2017 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 98598124D6C for ; Fri, 8 Dec 2017 05:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYeub9jl4a9e for ; Fri, 8 Dec 2017 05:45:54 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0116.outbound.protection.outlook.com [104.47.41.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0C7126C89 for ; Fri, 8 Dec 2017 05:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L+2gtdvMk7hJpzCLZuTA7uFJ/A8wLZ1Wz9K8yae9Irc=; b=g7p/ouXakoqJfLiOBhvRUaBvmWv1UTC9V06ILr4sPiXg6KxmC3VCQZq1bb9hCXVLETZIjgNob07wtx6ub0urjd9yBVXlgoENTyKmwlTO9FYNnVbmfRnscyTQJSfkK4Kpday1gLCJxL1FjUFFiOHP0bfgO6oeUVyps8lwSPiGI9Q= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0502.namprd21.prod.outlook.com (10.172.122.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.0; Fri, 8 Dec 2017 13:45:52 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0323.001; Fri, 8 Dec 2017 13:45:52 +0000 From: Mike Jones To: Esko Dijk , Samuel Erdtman CC: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thread-Index: AQHTY/JYkrdvoN32BUatgkHzFRtL3KMuSwQAgAgN/ACAABDhgIADDy6AgAAUxac= Date: Fri, 8 Dec 2017 13:45:52 +0000 Message-ID: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0502; 6:1oz4QYRKLPpchvDpHwN3obagFhJvW5UAfDrvbBI8E+hsccxa0EANA83oP0zkpCdV513rMmIMvd3LH9dH2I5kCZnzzUvobizDD8l6Kuiba4cRobLJgz97iEcWi+5hUgzZDQQMpTPEQd2j1TJmU+yO8lvhKWrGAgXAQtGmy2gmdN5X4n+wVBBmkNEYYEKYoS9tKgo5xmEx0xVDRbrMBbzvmED0jnafpJYxxegzIUSJWLgdPKOGXcaaU6040oXJLcK/kn3GO4dAuB1Zz2Bb94j6mtYovtr5mOvg4Bg2B36eTGn6pA1juTjotlKDXH+Ko/xzlwKu3U1Iyv13eUlUIOiyoNGLIXFTt+sj3gSAGQd/IkY=; 5:FqRAFykha4Cf2K3rRXldhEU4LSym7ZsqIY/sDvXzUiKI9DUEcMe2mcqLPcMNv/aor/sfkWGfzaL/wIfZElZT0aaAhTxbs6OHGhONSzyuY9qIbWC0nZh0L4tr/FqfEoEb4y6Qlg4V5SxdTI+l5rGQzL6Rw48EZPKHVjPDA8RklE0=; 24:XhOgyK7bM2SBExYoVeHlnD8y/fWlfiFIANFWsiDQ6PgT2LyduuWbWnP9FvXfzN5f8EpBFfrGqMk3XlhFZDJ/8KMZvMUPdB5fGP3MjwrN+fs=; 7:dFCM24VjFMf4w//PHfcZTJuiC0q2FRDyR/yZBaM1Sc4m4vvotjdQaGb6rAQ27ZmhjTl5WqOIKUHLmamG7lqKE36UzdyYyzB8FdF8DYcIwdNwYVRpENIrT8tDtMry6HwsJVSAsIXwNVTYDyAr+ao7n9Km+zAX5K2zkSMtfHF5kj9BB8hncZ2f+kUuFRasC/EV3oTSNQ9t63wTjwTSMBzFGAfDQ5TyBrHIbSidCJ6SdiGMxsLm8CKcRh16yShCQbP2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c8d315c0-97c7-4ce1-bba0-08d53e41ff8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:CY4PR21MB0502; x-ms-traffictypediagnostic: CY4PR21MB0502: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(192374486261705)(788757137089)(260087099026482)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011); SRVR:CY4PR21MB0502; BCL:0; PCL:0; RULEID:(100000803110)(100110400104); SRVR:CY4PR21MB0502; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(24454002)(13464003)(199004)(189003)(85714005)(25786009)(14454004)(22452003)(316002)(105586002)(110136005)(6436002)(106356001)(6506006)(54906003)(77096006)(10290500003)(81156014)(81166006)(2906002)(6246003)(3660700001)(8676002)(236005)(3280700002)(4326008)(76176011)(229853002)(966005)(72206003)(93886005)(66066001)(53936002)(478600001)(7696005)(5660300001)(606006)(53546010)(10090500001)(102836003)(6116002)(3846002)(68736007)(33656002)(97736004)(74316002)(2950100002)(8936002)(86362001)(7736002)(230783001)(86612001)(8990500004)(2900100001)(6306002)(55016002)(9686003)(99286004)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0502; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05048360C3417CC4A30E9503F5300CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8d315c0-97c7-4ce1-bba0-08d53e41ff8b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 13:45:52.1593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0502 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 08 Dec 2017 13:45:58 -0000 --_000_CY4PR21MB05048360C3417CC4A30E9503F5300CY4PR21MB0504namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Requiring extra code in recipients to ignore tags that already must not be = present would make them needlessly more complicated and hurt interop. It's = virtually certain that many implementations will not include this extra cod= e that should never be executed. We shouldn't put developers in the positio= n of deciding whether to add code for a case that already must not occur. -- Mike ________________________________ From: Ace on behalf of Samuel Erdtman Sent: Friday, December 8, 2017 4:31:31 AM To: Esko Dijk Cc: Benjamin Kaduk; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) thanks for persisting See inline On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk > wrote: Thanks Samuel, I agree with your answers and proposed actions except for the below: > I think the language in section 3 is enough to get robust implementations= . "all claims that are not understood by implementations MUST be ignored." Ignoring a claim is very different from ignoring an unrecognize/unsuitable = tag that prefixes a claim. The latter will in fact accept the claim while t= he former will reject the claim. To get the desired robustness and future extendibility, and make tags usefu= l for existing claims, an implementation must ignore the unrecognized tag = =96 but not the claim. (Assuming any cases where the receiver should unders= tand the claim but a future-version sender has added an additional future-v= ersion tag to it.) What this can achieve is keep using =91old=92 version claims while augmenti= ng these with =91new version=92 semantics by use of tags, in a future versi= on of the specification. Besides with current Section 3 & 5 language one claim parser #1 may still c= onsider an =93exp=94 claim as =93understood=94 because it ignores any tags = for it, while parser #2 may reject that =93exp=94 claim because it sees a t= ag that is not 1. While parser #3 may reject an =93exp=94 claim even with a= tag 1 because it considers it out of scope of the spec (which says sender = MUST NOT use this tag hence any tag usage is not according to spec so not u= nderstood.). In a way this issue is similar to the archetypical spec requirement of =93s= ender MUST put 0s in this field and a receiver MUST ignore the value of thi= s field=94. Both are needed. I have added created a PR with some text to make this more specific. please have a look at https://github.com/erwah/ietf/pull/74 Best Regards Esko From: Samuel Erdtman [mailto:samuel@erdtman.se] Sent: Wednesday, December 6, 2017 13:48 To: Esko Dijk > Cc: Benjamin Kaduk >; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thanks Esko for your review it is greatly appreciated. see comments inline On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk > wrote: Dear all, Overall the document looks in good shape to go forward if the earlier menti= oned issue of multiple values for "audience" (reported by Hannes) is addres= sed; and the below issue I see for Section 5. Other comments are minor. (Btw sorry for being late responding to this WGLC.) My review comments to specific sections: Entire document: Replace "binary string" by "byte string". The latter is the name used in R= FC 7049. Good point. I have created a PR waiting for review by the co-authors 3.1.1 / 3.1.2 / 3.1.3 "except that the value is of type StringOrURI" -> May be slightly confusing to readers, since JWT also has StringOrURI nam= ed type. So it seemingly says "don't use StringOrURI, but use StringOrURI."= This is most likely intended, as in "don't use JWT StringOrURI, but use = our CWT StringOrURI". So also fine if we leave this formulation in, but it = could still cause some confusion. I see your point, but I don=B4t think it will be an issue. JWT is in JSON c= ontext and CWT is in CBOR context so whenever string is refereed to in CWT = the reader should think CBOR string and vice verse for JWT. If you don=B4t have a strong opinion here or a great suggestion for a new n= ame I would like to keep it as it is. 3.1.4 / 3.1.5 / 3.1.6 "except that the value is of type NumericDate" -> same comment as above. Same as above. 5 Text states the sender MUST NOT use a tag, but future specs may introduce t= ags for claim values. Then it seems required to also include some text abou= t how a receiver implementing the *current* version of CWT should handle ta= gs for claim values, which may come from a sender implementing a future ver= sion of CWT. E.g. add text "A receiver/decoder MUST ignore any Tags used for a claim val= ue." That should help robustness and future extendibility. E.g. we don't want re= ceivers of a CWT to go check if tags are present and reject the CWT if a Ta= g is found. I think the language in section 3 is enough to get robust implementations. = "all claims that are not understood by implementations MUST be ignored." 7.1 Step 5 & 6: text states "add the matching COSE CBOR tag" resp. "add the app= ropriate COSE CBOR tag" -> could we clarify where this is added, e.g. say "prepend with the matchin= g COSE CBOR tag"? I think adding the tag in itself has this semantic. But I have created a PR= with the change, so that my co-authors can consider it. 9.2.1 "Applications that use this media type: IoT applications sending security t= okens over HTTP(S) and other transports" -> can already mention CoAP/CoAPs here ? It is not obvious that we should mention CoAP(S) here since the media type = is for HTTP(S) and not CoAP(S) and it does state that "and other transports= ". For CoAP(S) we register the CoAP Content-Format that maps to this media = type. Best regards Esko Dijk -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Beh= alf Of Benjamin Kaduk Sent: Thursday, November 23, 2017 01:31 To: ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Reminder: there is only one week left in this WGLC. -Ben On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. > > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > Thanks, > > Ben and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_CY4PR21MB05048360C3417CC4A30E9503F5300CY4PR21MB0504namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Requiring extra code in recipients to ignore tags that already must not be = present would make them needlessly more complicated and hurt interop. It's = virtually certain that many implementations will not include this extra cod= e that should never be executed. We shouldn't put developers in the position of deciding whether to add cod= e for a case that already must not occur.

-- Mike
From: Ace <ace-bounces@i= etf.org> on behalf of Samuel Erdtman <samuel@erdtman.se>
Sent: Friday, December 8, 2017 4:31:31 AM
To: Esko Dijk
Cc: Benjamin Kaduk; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 No= vember)
 
thanks for persisting

See inline

On Wed, Dec 6, 2017 at 2:48 PM, Esko Dijk <esko.dijk@ph= ilips.com> wrote:

Thanks Samuel,

 

I agree with your answers and proposed actions= except for the below:

 

> I think the language in section 3 is enou= gh to get robust implementations. "all claims that are not understood = by implementations MUST be ignored."

 

Ignoring a claim is very different from ignori= ng an unrecognize/unsuitable tag that prefixes a claim. The latter will in = fact accept the claim while the former will reject the claim.=

To get the desired robustness and future exten= dibility, and make tags useful for existing claims, an implementation must = ignore the unrecognized tag =96 but not the claim. (Assuming any cases wher= e the receiver should understand the claim but a future-version sender has added an additional future-version t= ag to it.)

What this can achieve is keep using =91old=92 = version claims while augmenting these with =91new version=92 semantics by u= se of tags, in a future version of the specification.

 

Besides with current Section 3 & 5 languag= e one claim parser #1 may still consider an =93exp=94 claim as =93understoo= d=94 because it ignores any tags for it, while parser #2 may reject that = =93exp=94 claim because it sees a tag that is not 1. While parser #3 may reject an =93exp=94 claim even with a tag 1 because it= considers it out of scope of the spec (which says sender MUST NOT use this= tag hence any tag usage is not according to spec so not understood.).

 

In a way this issue is similar to the archetyp= ical spec requirement of =93sender MUST put 0s in this field and a receiver= MUST ignore the value of this field=94.  Both are needed.


I have added created a PR with some text to make this more specific.

 

Best Regards

Esko

 

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <esko.dijk@philips.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>; ace@ietf.org


Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 No= vember)

 

Thanks Esko for your review it is greatly appr= eciated.

see comments inline

 

On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk <= ;esko.dijk@phili= ps.com> wrote:

Dear all,

Overall the document looks in good shape to go forward if the earlier menti= oned issue of multiple values for "audience" (reported by Hannes)= is addressed; and the below issue I see for Section 5. Other comments are = minor.
(Btw sorry for being late responding to this WGLC.)

My review comments to specific sections:

Entire document:
Replace "binary string" by "byte string".  The lat= ter is the name used in RFC 7049.

 

Good point.

I have created a PR waiting for review by the = co-authors

 


3.1.1 / 3.1.2 / 3.1.3
"except that the value is of type StringOrURI"
-> May be slightly confusing to readers, since JWT also has StringOrURI = named type. So it seemingly says "don't use StringOrURI, but use Strin= gOrURI."   This is most likely intended, as in "don't u= se JWT StringOrURI, but use our CWT StringOrURI". So also fine if we leave this formulation in, but it could still cause some confusion.<= u>

 

I see your point, but I don=B4t think it will = be an issue. JWT is in JSON context and CWT is in CBOR context so whenever = string is refereed to in CWT the reader should think CBOR string and vice v= erse for JWT.

If you don=B4t have a strong opinion here or a= great suggestion for a new name I would like to keep it as it is.

 


3.1.4 / 3.1.5 / 3.1.6
"except that the value is of type NumericDate"
-> same comment as above.

 

Same as above.

 


5
Text states the sender MUST NOT use a tag, but future specs may introduce t= ags for claim values. Then it seems required to also include some text abou= t how a receiver implementing the *current* version of CWT should handle ta= gs for claim values, which may come from a sender implementing a future version of CWT.
E.g. add text "A receiver/decoder MUST ignore any Tags used for a clai= m value."
That should help robustness and future extendibility. E.g. we don't want re= ceivers of a CWT to go check if tags are present and reject the CWT if a Ta= g is found.

 

I think the language in section 3 is enough to= get robust implementations. "all claims that are not understood by im= plementations MUST be ignored."

 


7.1
Step 5 & 6: text states "add the matching COSE CBOR tag" resp= . "add the appropriate COSE CBOR tag"
-> could we clarify where this is added, e.g. say "prepend with the= matching COSE CBOR tag"?

 

I think adding the tag in itself has this sema= ntic. But I have created a PR with the change, so that my co-authors can co= nsider it.

 


9.2.1
"Applications that use this media type: IoT applications sending secur= ity tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?

 

It is not obvious that we should mention CoAP(= S) here since the media type is for HTTP(S) and not CoAP(S) and it does sta= te that "and other transports". For CoAP(S) we register the CoAP = Content-Format that maps to this media type.

 


Best regards
Esko Dijk



-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Thursday, November 23, 2017 01:31
To: ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)=

Reminder: there is only one week left in this WGLC.

-Ben

On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote:
> This message begins a working group last call for
> draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC,=
> ending at 23:59 PST on Wednesday 29 November, 2017.
>
> The current (-09) version of the document is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 = .
>
> Thanks,
>
> Ben and Jim
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

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

________________________________
The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. = If you are not the intended recipient, please contact the sender by return = e-mail and destroy all copies of the original email.


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

 


--_000_CY4PR21MB05048360C3417CC4A30E9503F5300CY4PR21MB0504namp_-- From nobody Mon Dec 11 03:03:38 2017 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 D11E3120724 for ; Mon, 11 Dec 2017 03:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ6nOHvPEIcx for ; Mon, 11 Dec 2017 03:03:33 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0050.outbound.protection.outlook.com [104.47.0.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5185124205 for ; Mon, 11 Dec 2017 03:03:31 -0800 (PST) Received: from HE1P121CA0008.EURP121.PROD.OUTLOOK.COM (129.75.191.146) by VI1P121MB0048.EURP121.PROD.OUTLOOK.COM (129.75.190.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.13; Mon, 11 Dec 2017 11:03:28 +0000 Received: from HE1EUR02FT008.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::202) by HE1P121CA0008.outlook.office365.com (2603:10a6:23:2b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.14 via Frontend Transport; Mon, 11 Dec 2017 11:03:28 +0000 Authentication-Results: spf=neutral (sender IP is 40.115.29.120) smtp.mailfrom=philips.com; microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 40.115.29.120 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-1.lighting.com (40.115.29.120) by HE1EUR02FT008.mail.protection.outlook.com (10.152.10.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6 via Frontend Transport; Mon, 11 Dec 2017 11:03:27 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.209) by autodiscover.lighting.com (10.0.0.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Mon, 11 Dec 2017 12:02:59 +0100 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0040.EURP121.PROD.OUTLOOK.COM (129.75.191.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.14; Mon, 11 Dec 2017 11:02:58 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0282.014; Mon, 11 Dec 2017 11:02:58 +0000 From: Esko Dijk To: Mike Jones , Samuel Erdtman CC: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thread-Index: AQHTY/Ja/17ZfrzpmEybigwONFOQFKMuQr4wgAgWQgCAAAufcIADFHCAgAAUxQCABINP4A== Date: Mon, 11 Dec 2017 11:02:58 +0000 Message-ID: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [83.85.149.7] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0040; 6:EoWbKlvAEog3Gt3xulnksnDSTvuqNl6zZqw+RswCDqtCwSZKUfCcHpTFzbcjHLjdMrtfyLwLse7Nop8qEeS0AYTY9T8qJ8FzlYrHI9/xv/rxJBDw7S7JbDsKHWPaym2l/pgsAvZ82YEgCOou4Qkm+ysF8KkM2zDSAGYYbCyy23xsfTKU6SfAvahGu7A4AE2+f+23VXCMtfhqxfNTtWhHLQ870xsfUSzlieIp8LFtsxli6dOQqgYHfxP/ByFX8Y+QQwMC+xloVuywXxmlwjct7u8IA/HicU1KPCk0aljCCG6gl3TpvSMm3+apzy2EO8T+HnZofcwA/emXTF6ewUKLj1y9zY64v+Tckyp5OI86Pxw=; 5:fLxpmT4l50Xk6qsGBk9IoicmSumKet21ESjl5c+KWcfEwHxybYGP58H7RzfVBiH3BgX9u+De5oSzqqWkXYHisDcsc9pdCVDAwyiGPs9L36hAYwMYQcmdTKPqTfxqDYuuHP+hVoxIy82t0n1mZ1qOufKOGDOXsb6Ob+q+btf1+C0=; 24:dw2qgeuErZJh77HuztmEIHRrzupDYDekygnP5RTOd1D2piOdl+j5oZpqzSRWVOtdcafEY/0VVLHD8Yhi8TfG71ay+PsuFm8mNVXM3k2EVMc=; 7:9ktr+XLZc4NIb1Wu/WbwDz4hiWOOUT6Ex1SlEzrbgOjWYQ8VWMKqlgQjjAbg4/S28WazZMNl1zfwOadFbRgBudUMQzjPW0s7eZ7zgNKd4fyzAhXJwqcSGs3WPRtq0heGPfGQ/xJA8IngZ1UXCLGfH04JGnfqQjau0+poFP6vuJCiMMwtvN3kHsWOlGuzM5TyDHRGIkOM+QM6ceJkDBrFXvEuDBK2kTMojGieoKW91J75p9TVYgCoABIGGDOLJSzF x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: de10a069-2ca4-4145-b15d-08d54086ce91 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DB6P121MB0040; X-MS-TrafficTypeDiagnostic: DB6P121MB0040:|VI1P121MB0048: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(21748063052155)(260087099026482)(240460790083961); UriScan:(21748063052155)(260087099026482)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93003095)(6055026)(6096035)(20161123565025)(20161123561025)(20161123563025)(201703131430075)(201703131433075)(201703131448075)(201703161259150)(201703151042153)(20161123559100)(20161123556025)(201708071742011); SRVR:VI1P121MB0048; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:VI1P121MB0048; x-forefront-prvs: 0518EEFB48 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(189003)(199004)(85714005)(7736002)(106356001)(2421001)(81166006)(81156014)(105586002)(74316002)(9686003)(2561002)(68736007)(6306002)(5660300001)(54896002)(2950100002)(230783001)(86362001)(8676002)(3846002)(6116002)(102836003)(66066001)(790700001)(1511001)(9326002)(53546010)(97736004)(7696005)(76176011)(99286004)(8936002)(2900100001)(229853002)(33656002)(6436002)(6506006)(316002)(2906002)(5890100001)(93886005)(3280700002)(3660700001)(4326008)(55016002)(59450400001)(25786009)(45080400002)(53936002)(110136005)(54906003)(478600001)(6246003)(8666007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0040; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6P121MB0038C6139AB28FA0AF2D0CB39B370DB6P121MB0038EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0040 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131574638078243165; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT008.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:40.115.29.120; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(39860400002)(346002)(39380400002)(376002)(2980300002)(199004)(189003)(85714005)(260700001)(99286004)(84326002)(6306002)(45080400002)(16586007)(2421001)(93886005)(69596002)(97736004)(6116002)(316002)(7696005)(25786009)(8936002)(68736007)(9326002)(59450400001)(356003)(3846002)(53936002)(230783001)(53546010)(2950100002)(5890100001)(5660300001)(6246003)(2900100001)(74316002)(105586002)(790700001)(7736002)(81156014)(33656002)(8676002)(8666007)(1511001)(9686003)(4326008)(2561002)(86362001)(66066001)(76176011)(102836003)(498600001)(6506006)(54906003)(81166006)(61614004)(2906002)(512954002)(55016002)(54896002)(229853002)(110136005)(106466001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P121MB0048; H:LIGHT-EDGE-1.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT008; 1:7FYHd3iNfxp4SsIM1wiyzbwatVAcEt/XJEcTz8Pz4gN/MdYBWyx9IvTCWKifI37dyXuUzefH0KX/k+8KCOsYRm1EbFQ2gZrFieJgqqvTFcl/BoPKFCxfUZgKr0d6eDrZ X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4628075)(201703131517081)(2017052603307); SRVR:VI1P121MB0048; X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0048; 3:BmX5Ouxf+8jgsbD06vLeU5vM6lIuKI4CfM2mE4EWpk+j1dv4NOgjs7RRfbQjd5qC4k8PpeGhpK2UOi4jBXe6/uWf44hC71k47fT7Jxlq2L0wlqKUdkopG1kadoKepZJaWEkPhyGIYNjga7ShOzC3mSBFAjggLFMe36SAOGqtP6iqsz6BtDqn8s813uHgFJ9e28P5uSB2+NV7i95M1hhJ2aX3gHKGuYKxKMFvEMPVKQgVeFD9EcS9qAgV9Mt2bLhGGHSKERpitOEju68Fxv+0PdHkXyM7lkyBM3gnoiQnLC1Vgh1cNiLQgt5bn+WgF/irvaL2kTYHuKuyNBbzuD9nzWxp8x+H2TT0kqLchC8DbYI=; 25:EhzGV+H6mbTWuJdbm8U1ZSNfqeZr7MZS+U/c+jY2BIw4gXIAUJ4/tUPUUOBKWsEF/Wu1CofA9883z4u//POg7DidGdt2zvFqhavy0je/Zy8sbdGRIHHaye6s0XK8iKLRrvXZUypj9L6bPwrrM5lEzuadAvw4zzPrkeVt2qATW77HLfZdKgePTGJgto4cNyyc49V5z/3qt80N7K5SAGIT4mTkHplDyGGs9kRTE5iEywxdZVyF8bXTt+w5FtyR/KdaVksPZwjPMuxSLFf8vBVbaxODmfH79AAC706GIujEx6apSMO5TgRGs1bUf22FIM8/p/bc0nIBR9XzSeHyivz/Mw== X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0048; 31:tYdXErhqFOzWgfACvzC0wCofRpPmU7XqzI+9ItXKCp354xWSrqJ4QGFNe1ytpJa7zfjJ9A5lKO2Omd9O+l3sWiwgdgGSkOEWsnA7VmrWAmxkFzuSmSQqVOYbxKXI6WYOXUQR1b1hgtsBvo9xKRBhpIIuGKM/OjW5lEfuwp5K513RA1b/UvbhXxhWr90iajY4SODm62ASrSG9geb8sGywgCsX/BET9p8gr7OiHNMo8Uo=; 4:Fh6iyABIMQWoxH2mDLGNSFjnaHyHmLPSA9QstBFw0Ii9qPe3PXMVP52YKVVMeiai8klmy83pNB5mjE5H+2IcFJtlSvggCou9zV5m68eGMH0hGaqhCkGMUZAJB8yBmXRU1uCXYWNlCAbw+ONEJXpslb9GbYefZgxwTBv14nvw7S4WkamtFSAvnuuzl5wgg61s9gzLXMqKSA1pGTeba3g/EpSNM8Vq6ajPiA35UbNAPAQh1IGVcyoC/qu58j/QKpa4mcsKbT5sNiHa8AUY0ZRRWCk7uMYowvz563e3WrA6rhtU8qPe7xRpiTEXfzvetyz7sQznD/t6vfTgU+3zfY4T1LUw81l9YqW/R9v3muSjRESNDuhL5gmuXp4+YE/hVzTL X-Forefront-PRVS: 0518EEFB48 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P121MB0048; 23:NoXzFIC3Qz7nBHCCbffhLXRhRrB3x8KDw6EX2pAzw?= =?us-ascii?Q?gtoI3jE9SRCBV64PjIBtHqT08OFhcG2x2d3j9yGvRRQYCuoXEEyLGkuCYWZJ?= =?us-ascii?Q?PLazmzIva0EuoE+ZA077P1ipAWKnqPAdEy6fkf56W9hhozFkzjtdWkExoSqN?= =?us-ascii?Q?LiFf8ykf13uBN3t8P3/71x6TritX+oHvpRab9QHuq8ITtsyoXhFLYPBN3bNU?= =?us-ascii?Q?ub2R8JpVH8GIGL3422BvEzkKeClRfHOCZ2mmlCPB/HD0t1Auo4QgDF6SBVZl?= =?us-ascii?Q?3zxi2g84IgGxzKsvD50pSqPrsA7k5Z7dJX7GWOMp76SmnBnbWhyr+gNwKyh6?= =?us-ascii?Q?97Xv/BPJYG5+0/2eAIUzn7SljKEhluUS13YCwug+guDzhkN3kfFQ0DDwze0g?= =?us-ascii?Q?0KuK+wpY5MA0ltJ5o2DuQKVez76SibUw4XbdEWN225nnffYDz4rDm1ZxBL/+?= =?us-ascii?Q?Tl4eV9Qxx8LogTnEc7m6Zuj2rnyB/qM3wFYx6rU90BIx8E/PWxWyG0HC5LLR?= =?us-ascii?Q?6eyL/BLdoNfg7ASfdcI5I/UD71a+1wV7yORjCYd8FFO0Omun+d8Va1ewhxSJ?= =?us-ascii?Q?P3K/CrjVAY5zpNpYiGUWJtFe9M5X0+9uGsK3qk0Iq0i3AcI2O+81LbhOROx9?= =?us-ascii?Q?oLzn4wq9FjqXNpHBqXsVlAZdCVJHrvQfZ2iYNWE5i2Y3Ldtt3e19vEHYAnqw?= =?us-ascii?Q?TXNaDNUprkASjcFEirCbKVn6KvXjPgZF0XedCiHn9/btobrHOdKtypVsmIW5?= =?us-ascii?Q?oXAqBp/1Gb9dl2lXlhAGcP2mxHcLBKaJrNBuKq3Yz3uzKQZuhNhGSekglSy+?= =?us-ascii?Q?N9RWkWowc2DrK71hx2uPcmbaNsms4QYeOmHd2Pk5AnDE4Lz7oKpTpRabpwYS?= =?us-ascii?Q?GI/PtwAfP+W6dZ7CSoW6K7BHwVWvcyEJYinPgr75X6L86lV7o60dYj5niFpJ?= =?us-ascii?Q?TbdbFIAPkMwg0uxYh7TP50kGeYsNtMbh4MktOEzYmCsykpW8ICkhnY/5/k47?= =?us-ascii?Q?34R0zm26qi/DIUyY73KEmpIlDWwKbXpFac4mC9DEAZ4NE772SitEDf5Tc8l+?= =?us-ascii?Q?oaciZRI25kfdwC+SjM9FJk+Byf4GvJt35yp1Ry4kkhFe7bZg1CBz8Asq39ml?= =?us-ascii?Q?gzD9oIPJklxUM2sckR2GBVWGk4JvlapaKhMXyIMJLbZ2+YZDQM81tC2lV92C?= =?us-ascii?Q?mZr4LmIjmqS2APLcAn/9c7lUwl4h+rSDHchAzZJ5M5BO0ozIauF5GTHJ/I1O?= =?us-ascii?Q?xNlUONoBgTz1l1zPOim1WwEsUU1pxsolKiK+BTINAvNf8tEk8GDZJL9Yf1Qm?= =?us-ascii?Q?LkhrtmOcOSy/GmfoFM8XX5R1updvVTpkujSdEkqKvfMIASJjBH67hGDQcR29?= =?us-ascii?Q?OaW+PORo58/OOUFOdXu3CJbIKlViTuqdUhRv125MNPVpNFoTWcFIvL0/yGGr?= =?us-ascii?Q?ISGlDK4ci3dSSgCKs7I3/hcblmoJ8wKOCz564MP0stqVHg3uPQwUdbsiYGVA?= =?us-ascii?Q?kSSsVbFY+5KVB9CFPZ7qw9nWjnwJcob4ac=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0048; 6:lI1GNd3FNnENDq/p9kUnTGClFAo9zluw6W+Y3SX06cX8EiAmz+YjKMYIVbqY55HnWEH/Eomwi6IFqevmYM13aNZJef9ad8qq428hPgCRDQbLHX435KfMpfRj3nUEykmOxLfG2oL+3tZoRaJNtx0I/rXVZSmBm/ETRIfrPa1OoNk1Czg2qfKmoXLL/f488MQ5AoV2Tjee0FyF4VDcVmYsnEYcTwUpiHP9kDWRVK/brMi0zVvpnpGaBYrduFcxtmFmSNNbLIB7Eb3kHW7cu95AVfZVgyU9IAw+NdazQpUQOswmzwUlfyMfmRfppZDQG31zR+cf3cdqqDCk7j1idksnI8v8EPOBwYRVUjeWenAKs1Y=; 5:z76v0CucKpiNvj30Vg94qpYkSGIc1IlC93+3EVH9VRuSyhdPA269hFMwpoFjkrWmnqiAqkssaCznkz+tlEx0XL58WodvwJ6tg4pD3922UxWqxic4mKwVRxrRIQ1qE9nSHB/lqZOKBKcbrCcL24uJ3Y8qt/nhxiY6lX8E3wJqYYg=; 24:5ZQeqkyXB2gIiLpdWEpYumosufPo4oxXiB3VujccyILEINSusJ7zwDTgXAyqpc8BRaw+Ei7t2tZJ3GCUQ2YAk0vpvAYZBKHRQXtgZS/zkvI=; 7:5YQjKtksvyoBdJjjnFoNYRZC6OL7Im1h2J2fGN04QiuFSiQh6cS1t+agzD24CMMOUH3JrTZe726V/A7fauosBYRkKo4llconzCfyh8Y4pIuYJWqxBlGcmk0gkcOQUtS9EywEGTicZ315JZrzMG0V+A/G65LuOev7yNUCTiyOG0J2OLdvcCSHwPqSy/HSGyWp1YTWsigUH8i0SdCVgNWhRLqJr4HEGHMwXIP3pvm8j2tJ4ujoR8gOr4B1+yzvl9V0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2017 11:03:27.4024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de10a069-2ca4-4145-b15d-08d54086ce91 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[40.115.29.120]; Helo=[LIGHT-EDGE-1.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0048 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 11 Dec 2017 11:03:37 -0000 --_000_DB6P121MB0038C6139AB28FA0AF2D0CB39B370DB6P121MB0038EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mike, My intention was to have "no extra code in recipients that verifies absence= of tags". I did not intend to propose modification to the CBOR decoder (a= generic decoder would skip over i.e. ignore any tags already - which is th= e right behavior in my view). I don't see how an additional sentence in the spec "MUST ignore tags" can p= ossibly lead to extra code? A generic CBOR decoder will already skip over a= ny tags. And besides these tags are not present because the spec states the= y must not be used. So there's nothing a receiver would have to do extra or= different. The benefit then seemingly comes for free; and this benefit is the potentia= l usage of tags attached to existing claims, for future versions of the spe= c. But given that a CBOR decoder would normally ignore tags already, I'm also = fine with not changing the text if it is confusing for developers. They mig= ht think they need to implement something while the requirement actually as= ks them *not* to implement something. Most developers would not bother to i= mplement such extra checks anyhow. thanks Esko From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, December 8, 2017 14:46 To: Esko Dijk ; Samuel Erdtman Cc: Benjamin Kaduk ; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Requiring extra code in recipients to ignore tags that already must not be = present would make them needlessly more complicated and hurt interop. It's = virtually certain that many implementations will not include this extra cod= e that should never be executed. We shouldn't put developers in the positio= n of deciding whether to add code for a case that already must not occur. -- Mike ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. --_000_DB6P121MB0038C6139AB28FA0AF2D0CB39B370DB6P121MB0038EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mike,

 

My intention was to have “no extra code in rec= ipients that verifies absence of tags”.  I did not intend to pro= pose modification to the CBOR decoder (a generic decoder would skip over i.= e. ignore any tags already – which is the right behavior in my view).

 

I don’t see how an additional sentence in the = spec “MUST ignore tags” can possibly lead to extra code? A gene= ric CBOR decoder will already skip over any tags. And besides these tags ar= e not present because the spec states they must not be used. So there’s nothing a receiver would have to do extra or dif= ferent.

The benefit then seemingly comes for free; and this = benefit is the potential usage of tags attached to existing claims, for fut= ure versions of the spec.

 

But given that a CBOR decoder would normally ignore = tags already, I’m also fine with not changing the text if it is confu= sing for developers. They might think they need to implement something whil= e the requirement actually asks them *not* to implement something. Most developers would not bother to implement such= extra checks anyhow.

 

thanks

Esko

 

From: Mike Jones [mailto:Michael.Jones@micros= oft.com]
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk <esko.dijk@philips.com>; Samuel Erdtman <samu= el@erdtman.se>
Cc: Benjamin Kaduk <kaduk@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 No= vember)

 

Requiring extra code in rec= ipients to ignore tags that already must not be present would make them nee= dlessly more complicated and hurt interop. It's virtually certain that many implementations will not include this extra co= de that should never be executed. We shouldn't put developers in the positi= on of deciding whether to add code for a case that already must not occur.<= o:p>

-- Mike

 


The information contained in= this email may be confidential and/or legally protected under applicable l= aw. The message is intended solely for the addressee(s). If you are not the= intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original email.
 --_000_DB6P121MB0038C6139AB28FA0AF2D0CB39B370DB6P121MB0038EURP_-- From nobody Mon Dec 11 13:24:41 2017 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 2418E1289C3 for ; Mon, 11 Dec 2017 13:24:39 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMJ7QVZc2sqA for ; Mon, 11 Dec 2017 13:24:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E29128959 for ; Mon, 11 Dec 2017 13:24:36 -0800 (PST) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 11 Dec 2017 13:23:14 -0800 From: Jim Schaad To: 'Esko Dijk' , 'Mike Jones' , 'Samuel Erdtman' CC: 'Benjamin Kaduk' , References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> , In-Reply-To: Date: Mon, 11 Dec 2017 13:24:26 -0800 Message-ID: <003801d372c6$6e628dc0$4b27a940$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01D37283.60401110" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHuB5qI0OWkWMPnfP2AkP4xyaElbgJMfy2NATEVWWkCZHdt1AKJDXxMAaPpZ1ABNaPXyQHdalP9oqBjM/A= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 11 Dec 2017 21:24:39 -0000 ------=_NextPart_000_0039_01D37283.60401110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Esko, Whether a generic encode would automatically skip over tags is going to depend on the data model presented to the user by the parser. I have worked with one where the tags are ignored by the data model unless the user explicitly asks about them. I have worked with another where the tags are explicitly modeled in the result of the parser. There is a node in the resulting tree that is of node type tag with a value. Consider the case of something that could be either a string or an url encoded string. In this case the only difference in the encoding is the tag value. In this case the tag is significant so should not be ignored. I agree with Mike that this additional requirement could be misleading. Jim From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Esko Dijk Sent: Monday, December 11, 2017 3:03 AM To: Mike Jones ; Samuel Erdtman Cc: Benjamin Kaduk ; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Hello Mike, My intention was to have "no extra code in recipients that verifies absence of tags". I did not intend to propose modification to the CBOR decoder (a generic decoder would skip over i.e. ignore any tags already - which is the right behavior in my view). I don't see how an additional sentence in the spec "MUST ignore tags" can possibly lead to extra code? A generic CBOR decoder will already skip over any tags. And besides these tags are not present because the spec states they must not be used. So there's nothing a receiver would have to do extra or different. The benefit then seemingly comes for free; and this benefit is the potential usage of tags attached to existing claims, for future versions of the spec. But given that a CBOR decoder would normally ignore tags already, I'm also fine with not changing the text if it is confusing for developers. They might think they need to implement something while the requirement actually asks them *not* to implement something. Most developers would not bother to implement such extra checks anyhow. thanks Esko From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, December 8, 2017 14:46 To: Esko Dijk >; Samuel Erdtman > Cc: Benjamin Kaduk >; ace@ietf.org Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Requiring extra code in recipients to ignore tags that already must not be present would make them needlessly more complicated and hurt interop. It's virtually certain that many implementations will not include this extra code that should never be executed. We shouldn't put developers in the position of deciding whether to add code for a case that already must not occur. -- Mike _____ The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email. ------=_NextPart_000_0039_01D37283.60401110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Esko,

 

Whether a = generic encode would automatically skip over tags is going to depend on = the data model presented to the user by the parser.  I have worked = with one where the tags are ignored by the data model unless the user = explicitly asks about them.  I have worked with another where the = tags are explicitly modeled in the result of the parser. =   There is a node in the resulting tree that is of node type = tag with a value.

 

Consider the = case of something that could be either a string or an url encoded = string.  In this case the only difference in the encoding is the = tag value.   In this case the tag is significant so should not = be ignored. 

 

I agree with = Mike that this additional requirement could be = misleading.

 

Jim

 

 

From: Ace = [mailto:ace-bounces@ietf.org] On Behalf Of Esko = Dijk
Sent: Monday, December 11, 2017 3:03 AM
To: = Mike Jones <Michael.Jones@microsoft.com>; Samuel Erdtman = <samuel@erdtman.se>
Cc: Benjamin Kaduk = <kaduk@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC on = draft-ietf-ace-cbor-web-token (ends 29 = November)

 

Hello = Mike,

 

My intention was to have “no extra code in = recipients that verifies absence of tags”.  I did not intend = to propose modification to the CBOR decoder (a generic decoder would = skip over i.e. ignore any tags already – which is the right = behavior in my view).

 

I = don’t see how an additional sentence in the spec “MUST = ignore tags” can possibly lead to extra code? A generic CBOR = decoder will already skip over any tags. And besides these tags are not = present because the spec states they must not be used. So there’s = nothing a receiver would have to do extra or different.

The benefit then seemingly comes for free; and this = benefit is the potential usage of tags attached to existing claims, for = future versions of the spec.

 

But given = that a CBOR decoder would normally ignore tags already, I’m also = fine with not changing the text if it is confusing for developers. They = might think they need to implement something while the requirement = actually asks them *not* to implement something. Most developers = would not bother to implement such extra checks anyhow.

 

thanks

Esko

 

From: Mike Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Friday, December 8, 2017 14:46
To: = Esko Dijk <esko.dijk@philips.com>; = Samuel Erdtman <samuel@erdtman.se>
Cc:= Benjamin Kaduk <kaduk@mit.edu>; ace@ietf.org
Subject: Re: = [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 = November)

 

Requiring extra = code in recipients to ignore tags that already must not be present would = make them needlessly more complicated and hurt interop. It's virtually = certain that many implementations will not include this extra code that = should never be executed. We shouldn't put developers in the position of = deciding whether to add code for a case that already must not = occur.

-- = Mike

 

 

The = information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the = addressee(s). If you are not the intended recipient, you are hereby = notified that any use, forwarding, dissemination, or reproduction of = this email is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and = destroy all copies of the original = email.

------=_NextPart_000_0039_01D37283.60401110-- From nobody Mon Dec 11 13:59:04 2017 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 D7193127137 for ; Mon, 11 Dec 2017 13:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RO2cf1T9HX3 for ; Mon, 11 Dec 2017 13:59:01 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BA41200F1 for ; Mon, 11 Dec 2017 13:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vBBLwu5N023694; Mon, 11 Dec 2017 22:58:56 +0100 (CET) Received: from [172.20.10.2] (ip-109-47-1-245.web.vodafone.de [109.47.1.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ywcKq6jK9zDWwh; Mon, 11 Dec 2017 22:58:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 11 Dec 2017 22:58:54 +0100 Cc: Mike Jones , Samuel Erdtman , Benjamin Kaduk , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 534722334.0112-8617bae9781dd4d0d11e3c021995afae Content-Transfer-Encoding: quoted-printable Message-Id: <1EECC5BF-CD3B-4219-9670-A72A9A7055BB@tzi.org> References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> To: Esko Dijk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 11 Dec 2017 21:59:03 -0000 On Dec 11, 2017, at 12:02, Esko Dijk wrote: >=20 > given that a CBOR decoder would normally ignore tags If you are talking about CBOR tags (I=E2=80=99ve lost the context of the = current discussion):=20 A generic CBOR decoder would normally present those to the application. Simply ignoring them would not be very helpful. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 11 17:51:19 2017 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 0E258128DF2; Mon, 11 Dec 2017 17:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5NXHGq_Hsmoz; Mon, 11 Dec 2017 17:51:16 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336DF128D86; Mon, 11 Dec 2017 17:51:16 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 11 Dec 2017 17:49:33 -0800 From: Jim Schaad To: CC: Date: Mon, 11 Dec 2017 17:50:46 -0800 Message-ID: <00a801d372eb$a259c6f0$e70d54d0$@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: AdNy608nijxOOl60TBma2/v5+SN/aQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Please post a new draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Dec 2017 01:51:18 -0000 In processing the minutes, I noticed that we have made a call on the adoption for this draft. Please post a new version of the document as working group document. Jim From nobody Tue Dec 12 01:54:31 2017 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 21983129404 for ; Tue, 12 Dec 2017 01:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QiiZ-9UCCPf for ; Tue, 12 Dec 2017 01:54:27 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0041.outbound.protection.outlook.com [104.47.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EFC1293F3 for ; Tue, 12 Dec 2017 01:54:25 -0800 (PST) Received: from DB5P121CA0002.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b3::16) by HE1P121MB0012.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.14; Tue, 12 Dec 2017 09:54:23 +0000 Received: from HE1EUR02FT038.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::200) by DB5P121CA0002.outlook.office365.com (2a01:111:e400:e2b3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.14 via Frontend Transport; Tue, 12 Dec 2017 09:54:23 +0000 Authentication-Results: spf=neutral (sender IP is 13.81.48.91) smtp.mailfrom=philips.com; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.81.48.91 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-2.lighting.com (13.81.48.91) by HE1EUR02FT038.mail.protection.outlook.com (10.152.11.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6 via Frontend Transport; Tue, 12 Dec 2017 09:54:22 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (213.199.154.183) by autodiscover.lighting.com (10.0.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Tue, 12 Dec 2017 10:54:08 +0100 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0040.EURP121.PROD.OUTLOOK.COM (129.75.191.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.14; Tue, 12 Dec 2017 09:54:05 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0282.014; Tue, 12 Dec 2017 09:54:05 +0000 From: Esko Dijk To: Carsten Bormann CC: Samuel Erdtman , Mike Jones , Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) Thread-Index: AQHTY/Ja/17ZfrzpmEybigwONFOQFKMuQr4wgAgWQgCAAAufcIADFHCAgAAUxQCABINP4IAAvXAAgADEhvA= Date: Tue, 12 Dec 2017 09:54:05 +0000 Message-ID: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> <1EECC5BF-CD3B-4219-9670-A72A9A7055BB@tzi.org> In-Reply-To: <1EECC5BF-CD3B-4219-9670-A72A9A7055BB@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [83.85.149.7] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0040; 6:RtmGZAX+imGQlHJGo67R+IPCfJ7N3m89kcZHjvK/DmaKaeZJ6M2KcZEyRc7CumMqne4BazGgp5Q83GuZp/bYlIXN3GnWI/KzuHlHIwJAcENRQhlVTOH9gN712hheHm7sfJsoVRit2hh0nsxGwFjyasjz0bGQQOJyydnuebQVoqZ+LgIizK8c89v5CXxlTQACVqnG7Owy62Z7et4UHFY8/kkIGlk5VYXDDxJ/LQGzHQTyRjOoBx2dl80/SMUREb7h8raISy/kuO3qKdm4q/KDdUaOEXzhBtfEwbonrysmeuDQRI5qy+GFtKt9F2tcOnoDEUHsPi6SNopQ/F1+i5yzL9IbUscI5ee4UDe5QCD9ooc=; 5:8yiD7UzN69rtC4dm/TVGOsGjm6Zl1P/B9yRIJtkeEAk4BTLRlKwBbVJH3ORHFrEJupSPy3hCiif2AaaCsfvQ7D3WQmuGhfy+jGrwHpdwNeVEepdJPKpirezvSTVuUgjqol7n9Sz1WETBSSfBlX5onn0pB3NGzKDPqO/XxHPQFL8=; 24:YZRak3Yv/BvH4qtqylfxkqV+Ni8qBA+ZbteYkS5uupgkZqSG9CDRm68QgS85duTLg/QxhgZJ+hezoSIPj7nm+NVBjviTvnoN3ZgWwvK/iIc=; 7:DRWkeymveXyQDSgU+V2MhPxy7vQoUzMJ2JwiVcrT/A1l8pbBjE8s8d1CGwCwM37m9F+282YGbfBw1b4tlxa/x7B4BeI+HgV77f1X7aH/kaCBoUOVtqXRGuqBO/TyzWykDhJrLoe3CQKn6sxpC7/WgIUZqiIeH0RBwDDz4t2imMN1/IVOs3QEmF5SSUy4RVxjjVJTR3ej4K8XYtRmYGWemFmHy6c3aFaRddDDxKknmXcslVaWUCOmtwoLbw+4+Y2v x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 6f7efca0-ef23-4304-8eb0-08d541465271 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DB6P121MB0040; X-MS-TrafficTypeDiagnostic: DB6P121MB0040:|HE1P121MB0012: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(89211679590171)(260087099026482)(240460790083961); UriScan:(89211679590171)(260087099026482)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6P121MB0040; BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(3231023)(3002001)(10201501046)(93006095)(93003095)(6055026)(6096035)(20161123556025)(20161123559100)(20161123565025)(20161123561025)(201703131430075)(201703131448075)(201703131433075)(201703161259150)(201703151042153)(20161123563025)(201708071742011); SRVR:HE1P121MB0012; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:HE1P121MB0012; x-forefront-prvs: 051900244E X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(13464003)(24454002)(85714005)(199004)(189003)(6436002)(33656002)(8936002)(2906002)(6506006)(316002)(7696005)(76176011)(229853002)(99286004)(2900100001)(966005)(54906003)(53936002)(59450400001)(4326008)(6246003)(478600001)(8666007)(3660700001)(93886005)(55016002)(25786009)(9686003)(5660300001)(6306002)(74316002)(68736007)(8676002)(6916009)(2950100002)(230783001)(7736002)(3280700002)(305945005)(106356001)(81156014)(105586002)(81166006)(97736004)(86362001)(102836003)(6116002)(66066001)(3846002)(53546010); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0040; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0040 X-CrossPremisesHeadersFilteredBySendConnector: LIGHT-EDGE-2.lighting.com X-OrganizationHeadersPreserved: LIGHT-EDGE-2.lighting.com X-EOPAttributedMessage: 0 X-Matching-Connectors: 131575460629483184; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT038.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.81.48.91; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(346002)(39380400002)(376002)(39860400002)(2980300002)(189003)(13464003)(85714005)(199004)(24454002)(76176011)(69596002)(74316002)(8676002)(45080400002)(2486003)(23676004)(229853002)(9686003)(55016002)(99286004)(305945005)(68736007)(7736002)(7696005)(6506006)(25786009)(33656002)(6306002)(86362001)(3846002)(53546010)(59450400001)(97736004)(966005)(498600001)(6246003)(53936002)(102836003)(6116002)(50466002)(105586002)(106466001)(8936002)(5660300001)(230783001)(316002)(4326008)(2900100001)(66066001)(47776003)(54906003)(356003)(8666007)(93886005)(81166006)(6916009)(81156014)(2906002)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P121MB0012; H:LIGHT-EDGE-2.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT038; 1:oDCZnKFn/Uua+knwLjoVLNM7wCI5ACU4SrYI7CNWNC3twPyks9DMuIYFT5TUgnE1o/vVYzpiCErf1hvW1XAuYvgDPaX7aXKgyPxnP6mD9q6QneWXv2nQUyZqhzBmN3HK X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4628075)(201703131517081)(2017052603307); SRVR:HE1P121MB0012; X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0012; 3:22Rll5kUc9hB24WxX6y5xWytzbCLMZBDHGKiLXQbXBNvbNqorSa6vkZ+Cgj+EvSwB87az8/Mja7I0GX7OkQxEH0gjjChd0SBwylRKNspkxWqpENBRTUgFKLQTNFlExLrYrBYSNLPerANOnJiC9gRLB2jY6+LLkfL19JPaisqbCVyFCppnUiSQKOj15KwftRix3a1vB4Kuz3GwP+dAFm+koiZsBCN3AM01a+KG08FXEBvo4vvZbTKpNXc/qR9pxuEaoly8HdT6jsbl/Om1lavSnL9HkiY9qn4TGX30vRghzNBrF+wczvRDUYmEmtYocBU1jIzaGYnjnyqR9RQaoR5FA==; 25:JMbobeTfbS8Y+/UUng/Sr2yqIpF7etnjUWPjlhkxfosRtCOE2eFr+uw+zLxia8GgcAqw1IG7Clh1u0EhlmPGZHzqVNDst/ogiwE5+7at2cfloRYOBXfCPg3vFtM/cjmHhDSPPwLohGwTF9IG5v1nyV7+4Rkkbg4UZX2gG3qNOgX9JfXR/U+GUlUAtwZrRir8JCJdvCwLtoDQ6kBn8uWZvyiHkPSRoeytMs1X3eZwwuSiKzp3Tx+nb7SyvEW2FnSzWpYZkkJmZEGrvSWNMCSdhnYriQX/EvwRGv/wSB+dpD6edzedwIddJ8tVwDKOdm2916Eu4fg77IULIpT3EZs0TQ==; 31:ws/mZ44yggNC8CnL45PPZzBH/CNA55yTMjWMoxrZKXt/Hg8cyv925uC1XB80UQV7HOlRTPmxhST0/flVP2pO9sKhmy61m0h8os+xfn8B0AHY49DlQiGxipe2OQ080BUJwyVSsaD5WSVbV6HFDkflaWXi32I+le+MAX3gYnPim29olsoWflchdV8PZbJWu/MOxuOQr5KkdVwYl1bN0W/OgW8WLiKMZzWsmqj85leEyTg= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0012; 4:BSIz2ccgB0IX+o3dRzsp4SLEplW6zDBHQRPOalqaqZ1G686dLZRaHyBMKYo7OOLILe860qcoKZXmEcOH5n9hxAwNy6IlaDsffeZKuQ9ismCHxpbtPIcCfi5Czbo1R+gQ4reD3qho5EU+uUBSEjbrYQF2gq4nIgws8vhLAJvvi5i9yFEY4YJtwyMouc9Y2i7blk6i0mmi+trbqaycXQ0b8Sn0jB9JrCtNAIkqg/tGg0F+yGdrUPiu2Q5djvluoZ6r53fumNTWe2Bkxsx+osT5CGdpzEw0Mu6fWrftZ55JYJV9Hkgdgs/6n36QO51DiL/bMQKwDtmGy9ClgLk9Yp4VzDRA8iX+lBn/vBfbZ7UsPP5Sk0xt/asDpDRxTghpsDsM X-Forefront-PRVS: 051900244E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTIxTUIwMDEyOzIzOk4yTUI2Wlg2RDUxWWNYa1UwQzgzNHRyMmZ2?= =?utf-8?B?Y2M0SUZmTENNd0x3MnhTeGdOTmtrMitMbVd1QTVHWjBTRWx6aldibnYrbkpx?= =?utf-8?B?RGptSDhRNW9DL0ozNnJBRkQ2T2M3ejh4QkFaNFdHNmpHb1UvWVVOd3RQbmZS?= =?utf-8?B?c2JhY1NYU2k1MlBiT3JFMHN4TGNXVG1MWFNQZVdtVExtZG9RaStXQk1zYU5a?= =?utf-8?B?OTAzdHkrSWwxNmNkZkdMeXU3UGE3emJhRFJFME1XZnRidTE2NGRVbGZkNU9p?= =?utf-8?B?cCs0Y2FtRUU4aHppTGx3N2ZqWDJHY2FyclROVHhWNmZGRW9iUGVVaDlBVXNX?= =?utf-8?B?REsxOTdDQXpyUTI1bCtzYk9lS0NkV241L2hXV3RiTUpzZGp5YzVKQ3d5aEdU?= =?utf-8?B?Tk53eWlBOVlrOC9DczY0K1lQek91ZWs3UlRSdnBVdytDNWd1ZElrdEtaUTQ4?= =?utf-8?B?TDcvSytpWWxxcVlxMGp1YVhodzBMcGJrc1VEWjRWU3BFZnFWWXBQWVhHZWRR?= =?utf-8?B?ZjFkRzRpcGM2L01rOXBwcmZHYlBKdGlRdHdEY3NCam9wWmtDamh4aVMxWmF4?= =?utf-8?B?WXYrSStJUXVRVTNVRTJEMzdDZXNnekFUcC9JKzQrdk55aC9tODZnSTlLTDJP?= =?utf-8?B?ZzRxWXFpdTU1d1JwQVY2M1ZZQzZxY2NmY2p4bjloSVB1eUxZdHZGRERWR21U?= =?utf-8?B?bFEwd1ZET1JZTUxPaWtNV3RXdU1pSFJVajdhcmh4UlhTYVBtNzZIOG5vSEN4?= =?utf-8?B?MWVIaXl0Z1pWS00rd05DaGk1ek1aZ05VUk5hYUpJRERIY3JlamViN2I4NXlm?= =?utf-8?B?SnJyQjV3THM1RlBNK3hINEZtU2k5clFDYlRtUVNNaHNURkRYdnhWUjR4MjVz?= =?utf-8?B?UFFMU0MyaFgvVGdrZmdEdjRtcFhidWVnNnlnQW5ETDlWUUJyaDVHajZmcHBZ?= =?utf-8?B?TC9OWHhrR1luSk9EdzN5Ynlabk9RTlhxTk94UDZHSVZhZmNzc0JkME9VQWFD?= =?utf-8?B?a2dRZUFFM05mbExJQmsvUzJBQWVabDFNOHZaRVBqT1VPWm9xdTdFdHp4bG56?= =?utf-8?B?bFVJTTA5OFpieG81YklweHY5alZlc2hCVXdSRi8xQ0pSdGd4VFNjNVE1MVNS?= =?utf-8?B?dE5DUWN5Z1h2OCt5QlZieUp0VzJkbEJPaUZDVHNOR3JCRHg0a05sNWl4L1RH?= =?utf-8?B?NkpsNWJNU3ZubElTUEJRcjZ6MnlwRTN1RC9SKzd4NFZsS2NmVGgvN2RCdHZZ?= =?utf-8?B?SVdjaWxTd2hmZEFQRmFraWFwWHdGaDFpSlVlMEhlT05wRGFWYTB2bGRMTHQ0?= =?utf-8?B?cnJlbjdKNXFrR2Q5L2JhNXVkVStJU1ZLNHFMTkUzQ1ZCbXE4UkNwVVQzTjlR?= =?utf-8?B?OEVKQmdTL05tVWRuNVF3ZnpoY2pMdm03cERZb01Yd2F6WTI4VkV3blZ4Tjk4?= =?utf-8?B?ajFtL054NStqZnU1dFozNFIyM0IwaThCRTB5SmowY3l5bE9PSktaUy9PT25h?= =?utf-8?B?Zm0vN1MxRkEyYUFpQzZENitvTFRndmZXOEcxaEtFNlRGbEN3ZkVhWmF6N1Ew?= =?utf-8?B?R1p5TnhtQmdGSlVPRmpoZlBQZndMbVQ1V1ZJcURMa3ZXQit0blhNN204MjNT?= =?utf-8?B?K3czN004MnpCWWFlRUJJNi94WTRBYUI4RmMvTHJVOWN1aFVFanRaTmVzdWJj?= =?utf-8?B?Rm5wZVlzNjNCbnJHVnlkM0Mrb20yNEZWZnIwV1hmVzZhc05ZY2hEVUsvbmR6?= =?utf-8?B?TG15QzhJczRWSS9ESXR1cUczNStXOGNmaVA5blYrdi9PYWFrbUZrT05WcEF3?= =?utf-8?B?VnZ5WE1Uc0tzZDNCZVhUOTk1bnZhY0Y3L1lJTW4zejAwRE4rYjVNY3VscXE1?= =?utf-8?Q?kavv5aRXTzT/9wz4dh52kHy3Mf/ioo9H?= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0012; 6:1s1wY9pvVaV944NFFfU9MN/2Q71IZLPvHAJycyGOTfyQmOc0su928wSwdMteUr04RsC0vrMNgPNVvMwhSiMtil+WaUKjWpH2ZRIh2gC+zS9M4ZzG+qVH8K3w1E8Tjs6faUZRFDw+ks65x8rqe/QdKcqJpkY6QHa/b/GBzxScoCTMRIEcgRt6MNFrFCun0b49ZG4wLrYTKQHiI3mMsb9WfaRjiZ4KtsWphXCv6wb+7P5TbU56w31tQpvGeB5ambqt3EpWLSr6JUlsd6gIzw20t+h0Mx7av+WP1ZK3mUCiYQ8WWE6LFjv+VqQ7A4VRB1eHlzINBtEu/Jq7QFRGujjY8nEEYtActdp9bZc8KIEs/FI=; 5:z08sEpEVc9LwCmtEgJMXo+O3nFkqV0QTaF7mHlNqeABra2Qnf26MEJoGiNFfaX+HIvA6eIFwmUFnRxm9Xszd5XW4m2URvwtXxfTmeJE1jmJllQVykXLwAhWh1eNS0cl4rB8z8L2HjI8QQn3cWFE4IsSucWDMMEG5JA2xpulVs34=; 24:hbAoY5pp8/pIYRj8KgaIUIltvI9Xj7N5JaG4RwmTPZGsRS8sQOaif8cxQzFdEpUhl8+xMJYKtqf3DaNh0bVv6wU+zaTXzu2hY7ku1yTrelo=; 7:2iEOZZDWGgRei3B/yE5AX9ZimXfao6TgxyZTP01dlGmbMtxsRn7I7zcXMMUr04RhpuYSAVeKCfxgEQAr2YptiEMQ21VHOHC/KkRt0iDO1rrImwsoYno6V3ST6xnw1NQ1uOurMwCaEYof+81I37GSFg9igQ8OIevTP08fIMrIPJeWKzcrDjvj6o5B0vlwJVF0CuCmPLVO/kVPRRix4n5Z3JCqLfvAHf871ukGlGWLJ22BuBDajxBkjAy54ckz+PGi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2017 09:54:22.5733 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6f7efca0-ef23-4304-8eb0-08d541465271 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.81.48.91]; Helo=[LIGHT-EDGE-2.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0012 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 12 Dec 2017 09:54:30 -0000 V2l0aCAiaWdub3JpbmciIHRhZ3MgSSBhbHNvIG1lYW4gdGhhdCB0aGUgZGVjb2RlciBwcmVzZW50 cyBpdCB0byB0aGUgYXBwbGljYXRpb247IHdoZXJlIHRoZSBhcHBsaWNhdGlvbiB0aGVuIGRvZXMg bm90IGRvIGFueSBfYWRkaXRpb25hbF8gY2hlY2tzIG9uIHRhZ3MgKGxpa2UgZS5nLiB0aGVpciBw cmVzZW5jZSBvciBhYnNlbmNlKS4NCkFueSB1c2Ugb2YsIG9yIGNoZWNrcyBvbiB0YWdzIGFzIG5l ZWRlZCBmb3IgdGhlIGFwcGxpY2F0aW9uIGFyZSBvZiBjb3Vyc2UgdG8gYmUgZG9uZSBpbiB0aGUg bm9ybWFsIHdheS4NCg0KSW4gZXNzZW5jZSBteSBjb21tZW50IGlzIGp1c3QgdG8gZW5hYmxlIGEg d2F5IG9mIGFkZGluZyBvZiB0YWdzIGluIHRoZSBmdXR1cmUgb250byB0b2RheSdzLXRhZ2xlc3Mt Y2xhaW1zLCB3aXRob3V0IHRvZGF5J3MgaW1wbGVtZW50YXRpb25zIHJlamVjdGluZyB0aGVzZSBm dXR1cmUtY2xhaW1zIGFzIGJlaW5nIG1hbGZvcm1lZC91bmV4cGVjdGVkLiAgSWYgbW9zdCB0aGlu ayB0aGF0J3MgYWxyZWFkeSBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IHRleHQgdGhlbiBJJ20gb2th eSB3aXRoIGl0Lg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBB Y2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9y bWFubg0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAxMSwgMjAxNyAyMjo1OQ0KVG86IEVza28gRGlq ayA8ZXNrby5kaWprQHBoaWxpcHMuY29tPg0KQ2M6IFNhbXVlbCBFcmR0bWFuIDxzYW11ZWxAZXJk dG1hbi5zZT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEJlbmph bWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Fj ZV0gV0dMQyBvbiBkcmFmdC1pZXRmLWFjZS1jYm9yLXdlYi10b2tlbiAoZW5kcyAyOSBOb3ZlbWJl cikNCg0KT24gRGVjIDExLCAyMDE3LCBhdCAxMjowMiwgRXNrbyBEaWprIDxlc2tvLmRpamtAcGhp bGlwcy5jb20+IHdyb3RlOg0KPg0KPiBnaXZlbiB0aGF0IGEgQ0JPUiBkZWNvZGVyIHdvdWxkIG5v cm1hbGx5IGlnbm9yZSB0YWdzDQoNCklmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBDQk9SIHRhZ3Mg KEnigJl2ZSBsb3N0IHRoZSBjb250ZXh0IG9mIHRoZSBjdXJyZW50IGRpc2N1c3Npb24pOg0KQSBn ZW5lcmljIENCT1IgZGVjb2RlciB3b3VsZCBub3JtYWxseSBwcmVzZW50IHRob3NlIHRvIHRoZSBh cHBsaWNhdGlvbi4NClNpbXBseSBpZ25vcmluZyB0aGVtIHdvdWxkIG5vdCBiZSB2ZXJ5IGhlbHBm dWwuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlbWFpbCBt YXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNh YmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJl cHJvZHVjdGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3Bp ZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsLg0K From nobody Tue Dec 12 07:57:21 2017 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 F38331294B8; Tue, 12 Dec 2017 07:57:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151309423493.8812.16778350294706812178@ietfa.amsl.com> Date: Tue, 12 Dec 2017 07:57:14 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 15:57:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Ludwig Seitz Francesca Palombini Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-00.txt Pages : 16 Date : 2017-12-12 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-00 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 Wed Dec 13 00:36:51 2017 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 240FC12700F for ; Wed, 13 Dec 2017 00:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEBbtdg0RMoV for ; Wed, 13 Dec 2017 00:36:46 -0800 (PST) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D10120726 for ; Wed, 13 Dec 2017 00:36:46 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:205]) by smtp-cloud7.xs4all.net with ESMTPA id P2WyeRjfEbYqmP2WyexY6r; Wed, 13 Dec 2017 09:36:44 +0100 Received: from 2001:983:a264:1:1863:3a7a:a3a3:d308 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 Dec 2017 09:36:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Dec 2017 09:36:44 +0100 From: peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <151315396297.30126.5000747466287809476.idtracker@ietfa.amsl.com> References: <151315396297.30126.5000747466287809476.idtracker@ietfa.amsl.com> Message-ID: <4631db3e79c6bd011c0b9537354595ca@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJqK5OKKPVbJHhJqbZ/uBaXf4hU0Bx98hWNwYWkJN4eldH91nbV1U6rIjxEpRfmQtOIAraNzB8ULroKB5a5ZQz1G3yqblToeLuwtpaAJ6Nzn8PvTVrAV rEXfhKVn1+jWsvPi4tpYXudI5LtQgT6/3lwgbJosKMWvoR43KCpWfAj3Cq62FSwkzM1Vk78cYzhzvO6SlgU7cKKc3eGEG9f3dbc= Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 08:36:50 -0000 Hi all, A new version of I-D, draft-vanderstok-ace-coap-est-03.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. This version has no reference to BRSKI and is stand-alone EST over CoAP. Other comments from the WG have been taken into account. According to me this version is now compliant with the wishes and views expressed by the ACE WG. Looking forward to your feedback. Peter Name: draft-vanderstok-ace-coap-est Revision: 03 Title: EST over secure CoAP (EST-coaps) Document date: 2017-12-12 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-ace-coap-est-03.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanderstok-ace-coap-est-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-ace-coap-est-03 Abstract: Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). Example low-resource uses cases for EST are: secure bootstrapping and certificate enrollment. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how low-resource devices are expected to use EST over secure CoAP (EST-coaps). 6LoWPAN fragmentation management and extensions to CoAP registries are needed to enable EST-coaps. 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. The IETF Secretariat From nobody Thu Dec 14 01:00:13 2017 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 5FA151273E2 for ; Thu, 14 Dec 2017 01:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 RdzMThlN8SsX for ; Thu, 14 Dec 2017 01:00:06 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E7E1271DF for ; Thu, 14 Dec 2017 01:00:06 -0800 (PST) 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=QY+Fxzq5Nm9sHtGDkZZ7J1W9sWAPYiVd3016LYu+G0U=; b=YIdy/rymswwVz9xhjctcBceO/Ondn4ZLNq+7Ugn/PSnjmC+mXCnyBNIqHiw42q/K8qY/DrhEREEsRxXJYpKQL1z2Q4414uDyx5HTZtAWh6QjZb+SmynYWYmx4ALWS8XCO8tc2XM2WjTmYUmec2Cvz5LEcZIs1CLeKY5zfjP34zQ= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 09:00:03 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0302.013; Thu, 14 Dec 2017 09:00:03 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: 3rd OAuth Security Workshop (OSW 2018) Thread-Index: AdN0uDBx6tVZ/U7xQGyT9h/tQmtX/g== Date: Thu, 14 Dec 2017 09:00:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:JzHmCbyhWsW3lQ3oh9/7FFKDTVUnttKpuKwy7f0L6oPxmLdq8z75Bd95b2ufCFPjiuDGuuyXb1l2sBFJVi00W23L2DekfUCUVRwvndSs2vE4yPSL5xwi5zEdU97fMD9YXEi2kpqj6Vp6fPwXeMxyPDnEtbj81ji7JOLC57yfhjI8Mq+u5ungU7T2AYQr1p3O/dVcvfRfo1y3xePWI/sWlD/8rJepCNAbcLsx8ABtnBaFc8O61zQaLKNqQoRzT3n5kuG8vo4pn3DWfWJYIUXB7duyuXm0B7wl5ZIc8lhOg9C9w7yemaXjAykit6kFdyDdxEYHdczJTvbtf3ZP9eCB998s9tXHNgf5saKSuhpy/LI=; 5:oaxMasDyd1k0cguzu7OADNFk0C+jHY38p1YryUSNVh+ssy+Ncu0iDvAG+kfVudqCqn7ANeCgu2tevxhA7JzuOJkUNSuZFDkwCwoKlnwipocayqKlLE52oey3rIBIr9XDFl9EuV4PDPtDzYMe/V4N4mHHjSc8FuvLZU6Rn0LQoGQ=; 24:fF88nq3H57TCsvbOysK/QlvlxnpD0Z4K5B+lvmfXLDuMRYW0cOnSkQ47VK/m0QmiTs20sDOoHt2JYtHxOk/T13D3QOdI3l+ED5ktiYBg9Ms=; 7:2iagTRQJ0Yg5p9B4p7kEZhWq4ObN8Znm5ZXJMSZdldapG7HHScjRtafAcl0pFPHG6bxDdhSwm2qAo+F092FchPYkC4tiX0PFz5x5ReRCi18dy7UiDxR1UIPwHMnsFZTdpdu07RsGN5veRBJzTWSMfMege4FaN3mtt5enupCXXJ5NabR2hsR2v2LVpB2xLHt7hoH+SDiS4IBOF3JpmbjNKf3eVxvBu+39d8/OC8ZrHN3t+ohMErgb9zpog2o54NUi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d61e0c13-78a8-4d4e-ce22-08d542d11080 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(366004)(199004)(189003)(53754006)(28244002)(40434004)(81156014)(2420400007)(15650500001)(7736002)(74316002)(33656002)(2900100001)(561944003)(10710500007)(66066001)(81166006)(2906002)(8676002)(99286004)(102836003)(6436002)(3846002)(9686003)(54896002)(5640700003)(1730700003)(53936002)(55016002)(106356001)(5890100001)(2501003)(790700001)(5250100002)(2351001)(6116002)(6306002)(105586002)(59450400001)(3660700001)(7696005)(3280700002)(7110500001)(8936002)(86362001)(316002)(14454004)(5660300001)(6916009)(25786009)(478600001)(5630700001)(97736004)(966005)(72206003)(4743002)(68736007)(6506007)(45080400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706A37D82EFFE9602A1D895FA0A0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d61e0c13-78a8-4d4e-ce22-08d542d11080 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 09:00:03.4330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [Ace] 3rd OAuth Security Workshop (OSW 2018) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 09:00:11 -0000 --_000_AM4PR0801MB2706A37D82EFFE9602A1D895FA0A0AM4PR0801MB2706_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We are going to organize another OAuth security workshop in the week before= the London IETF meeting. The deadline for submission of papers and posters= is January 19, 2018. Note that we are also look for IoT relevant contributions. For me this OAuth security workshop series has always been extremely helpfu= l since it gave the OAuth standards community time for high-bandwidth discu= ssions with security researchers. I hope to see some contributions from som= e of you! Ciao Hannes Call for Position Papers and Tutorials =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Third OAuth Security Workshop (OSW 2018) Fondazione Bruno Kessler Trento, Italy March 14-16, 2018 Workshop website: https://st.fbk.eu/osw2018 =3D=3D About OSW 2018 =3D=3D The OAuth Security Workshop (OSW) aim is to improve the security of OAuth and related Internet protocols by a direct exchange of views between academic researchers, IETF OAuth Working Group members and industry. The workshop is hosted by the Security and Trust research unit of the Bruno Kessler Foundation (FBK). While the standardization process of OAuth ensures extensive reviews (both security and non-security related), further analysis by security experts from academia and industry is essential to ensure high quality specifications. Contributions to this workshop can help to improve the security of the Web and the Internet. =3D=3D Scope and Topics =3D=3D We seek position papers related to OAuth, OpenID Connect, and other technologies using OAuth under the hood. Contributions regarding technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome. Areas of interest where OAuth can be used as enabler of innovative scenarios include: - IoT, SmartCities and Industry 4.0. - Mobile and Strong authentication. - Federated Identity. - Privacy-enhancing technologies. =3D=3D Important Dates =3D=3D - Position paper and Tutorial submission deadline: January 19, 2018 (AoE, UTC-12). - Author notification: February 5, 2018 - Workshop: Wed, March 14, 2018 (half-day), Thu, March 15, 2018 (full-day),= and Fri, March 16, 2018 (half day) =3D=3D Submissions =3D=3D We solicit position papers that highlight challenges and lesson-learned from OAuth-based work. As all papers and presentations will be shared online without formal proceedings, we accept different kinds of submissions= : from original contributions to already published or preliminary works. Submissions must be in PDF format and should feature reasonable margins and formatting. There is no page limit, but the submission should be brief (ideally not more than 3-5 pages). Submissions should not be anonymized. Authors of accepted papers will have the option to revise their papers before they are put online. One of the authors of the accepted position paper is expected to present the paper at the workshop. The workshop will host a half-day (March 14, 2018) tutorial program. Each tutorial proposal should concisely describe the content and objectives of the tutorial, and include: - title - abstract - outline of the tutorial content - intended audience, including possible assumed background of attendees - name, affiliation, email address, and brief biography of the speaker(s) - duration: 1 hour or 2 hours Tutorial proposals should be submitted as a PDF file. Submissions should be distinguished by the prefix "Tutorial:" in the title. Submission Website: https://easychair.org/conferences/?conf=3Dosw2018 =3D=3D IPR Policy =3D=3D The workshop will have no expectation of IPR disclosure or licensing related to its submissions. Authors are responsible for obtaining appropriate publication clearances. =3D=3D Workshop Chair =3D=3D - Silvio Ranise (Security & Trust, Fondazione Bruno Kessler) =3D=3D Program Committee =3D=3D Chairs - Roberto Carbone (Security & Trust, Fondazione Bruno Kessler) - Hannes Tschofenig (IETF OAuth Working Group Co-Chair) Members - Michael Jones (Microsoft) - Ralf Kuesters (University of Stuttgart) - Torsten Lodderstedt (YES Europe AG) - Chris Mitchell (Royal Holloway, University of London) - Anthony Nadalin (Microsoft) - Nat Sakimura (Nomura Research Institute) - Antonio Sanso (Adobe) - Ralf Sasse (ETH Zurich) - Joerg Schwenk (Ruhr-Universit=E4t Bochum) - Giada Sciarretta (Security & Trust, Fondazione Bruno Kessler and Univ. of= Trento) =3D=3D Conference site and contacts =3D=3D For more detailed information please refer to the workshop web site: https://st.fbk.eu/osw2018 If you have any questions on OSW18, please contact carbone [at] fbk [dot] eu, giada.sciarretta [at] fbk [dot] eu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706A37D82EFFE9602A1D895FA0A0AM4PR0801MB2706_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are going to organize another OAuth security w= orkshop in the week before the London IETF meeting. The deadline for submis= sion of papers and posters is January 19, 2018.

 

Note that we are also look for IoT relevant contr= ibutions.

 

For me this OAuth security workshop series has al= ways been extremely helpful since it gave the OAuth standards community tim= e for high-bandwidth discussions with security researchers. I hope to see s= ome contributions from some of you!

 

Ciao

Hannes

 

Call for Position Papers and Tutorials=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Third OAuth Security Workshop (OSW 2018)

Fondazione Bruno Kessler

Trento, Italy

March 14-16, 2018

Workshop website: https://st.fbk.eu/osw2018<= /o:p>

 

 

=3D=3D About OSW 2018 =3D=3D

 

The OAuth Security Workshop (OSW) aim is to impro= ve the

security of OAuth and related Internet protocols = by a direct

exchange of views between academic researchers, I= ETF

OAuth Working Group members and industry. The wor= kshop

is hosted by the Security and Trust research unit= of the

Bruno Kessler Foundation (FBK).

 

While the standardization process of OAuth ensure= s extensive reviews

(both security and non-security related), further= analysis by security

experts from academia and industry is essential t= o ensure high quality

specifications. Contributions to this workshop ca= n help to improve the

security of the Web and the Internet.<= /p>

 

 

=3D=3D Scope and Topics =3D=3D

 

We seek position papers related to OAuth, OpenID = Connect, and other

technologies using OAuth under the hood. Contribu= tions regarding

technologies that are used in OAuth, such as JOSE= , or impact the

security of OAuth, such as Web technology, are al= so welcome.

 

Areas of interest where OAuth can be used as enab= ler of innovative

scenarios include:

- IoT, SmartCities and Industry 4.0.

- Mobile and Strong authentication.

- Federated Identity.

- Privacy-enhancing technologies.

 

 

=3D=3D Important Dates =3D=3D

 

- Position paper and Tutorial submission deadline= : January 19, 2018

(AoE, UTC-12).

- Author notification:  February 5, 2018

- Workshop: Wed, March 14, 2018 (half-day), Thu, = March 15, 2018 (full-day), and

  Fri, March 16, 2018 (half day)<= /p>

 

=3D=3D Submissions =3D=3D

 

We solicit position papers that highlight challen= ges and lesson-learned

from OAuth-based work. As all papers and presenta= tions will be shared

online without formal proceedings, we accept diff= erent kinds of submissions:

from original contributions to already published = or preliminary works.

 

Submissions must be in PDF format and should feat= ure reasonable margins

and formatting. There is no page limit, but the s= ubmission should be

brief (ideally not more than 3-5 pages).  Su= bmissions should not

be anonymized.

 

Authors of accepted papers will have the option t= o revise their

papers before they are put online. One of the aut= hors of the accepted

position paper is expected to present the paper a= t the workshop.

 

The workshop will host a half-day (March 14, 2018= ) tutorial program.

Each tutorial proposal should concisely describe = the content and

objectives of the tutorial, and include:

- title

- abstract

- outline of the tutorial content

- intended audience, including possible assumed b= ackground of attendees

- name, affiliation, email address, and brief bio= graphy of the speaker(s)

- duration: 1 hour or 2 hours

 

Tutorial proposals should be submitted as a PDF f= ile.

Submissions should be distinguished by the prefix= “Tutorial:” in the title.

 

Submission Website: https://easychair.org/confere= nces/?conf=3Dosw2018

 

 

=3D=3D IPR Policy =3D=3D

 

The workshop will have no expectation of IPR disc= losure or licensing

related to its submissions. Authors are responsib= le for obtaining

appropriate publication clearances.

 

 

=3D=3D Workshop Chair =3D=3D

 

- Silvio Ranise (Security & Trust, Fondazione= Bruno Kessler)

 

 

=3D=3D Program Committee =3D=3D

 

Chairs

- Roberto Carbone (Security & Trust, Fondazio= ne Bruno Kessler)

- Hannes Tschofenig (IETF OAuth Working Group Co-= Chair)

 

Members

- Michael Jones (Microsoft)

- Ralf Kuesters (University of Stuttgart)

- Torsten Lodderstedt (YES Europe AG)<= /p>

- Chris Mitchell (Royal Holloway, University of L= ondon)

- Anthony Nadalin (Microsoft)

- Nat Sakimura (Nomura Research Institute)

- Antonio Sanso (Adobe)=

- Ralf Sasse (ETH Zurich)

- Joerg Schwenk (Ruhr-Univer= sit=E4t Bochum)

- Giada Sciarretta (Security & Trust, Fondazi= one Bruno Kessler and Univ. of Trento)

 

 

=3D=3D Conference site and contacts =3D=3D

 

For more detailed information please refer to the= workshop web site:

https://st.fbk.eu/osw2018

 

If you have any questions on OSW18, please contac= t

carbone [at] fbk [dot] eu, giada.sciarretta [at] = fbk [dot] eu

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706A37D82EFFE9602A1D895FA0A0AM4PR0801MB2706_-- From nobody Thu Dec 14 06:59:30 2017 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 3F34A1270A7 for ; Thu, 14 Dec 2017 06:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CV0prKECg1YN for ; Thu, 14 Dec 2017 06:59:26 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0064.outbound.protection.outlook.com [104.47.1.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB7F126D3F for ; Thu, 14 Dec 2017 06:59:26 -0800 (PST) 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=mRbDXKtqmDpEPE7qT99rN0kl/oS6UqEJrGA35Emb/Vg=; b=iDKA7MFIQwtIXXR6drrJWKHqBrnIjl2MK7+HImyw5sCgDbx66fOCO2yRUHZqXtEGzRMLqouTWgVSp/yXAgze+k7NMVpiGmtkcF7Op+fhn4/fbk3AIfZj6Jkq2FJEwTiDnkoHqKtW9oAInq17X+zu0IYmjERVvnK0c0o+kkUaBqY= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 14:59:23 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0302.013; Thu, 14 Dec 2017 14:59:23 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Credential Management for Internet of Things Devices Thread-Index: AdN06/29WwehXrmRSPGr3H+DBr7dkg== Date: Thu, 14 Dec 2017 14:59:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:y8EEgJJLF1+5nihvBq+oUhis71kzS7TiwJy74Nqv6H5+DnXFswg4k2GxMp2xYg8e53Pt2VSBmaxWFHA/SgAnbEQAwxdubgO+UpxEM6G0YiOuFRTDdbYY4i/y0IN8Zl7CpmmxCs4Wg9Mz1rOl9Qt1CtPZ8VE7kTe6woTMzkhDgbugN8ZXpSJfidbfJfGZw6AhRpuh4wSwosX1cJVQVWIskdlmse6oNdhuJQPIt5d+KDuk0lJJ7ybN5yxoREhEhJckIVvR7AW6IvF0P5XoKnUCV32fQzy/CVFwskwIfROSXxnL/1BPdHykzuK5tWW/APsTjbJ+O8ebPaFJIafA7XQQVPJIXYG4W89TX2BnuCv4Klc=; 5:HvEQujy0z6kZ/gAk4tsriGZ/ktSQfgQle7dHcarSw3WBs5xYDNIs6lyQH9aZ7IAdZOVJRX+/PaquE7FANVO+F1aEkcnf25ilFBxWsXQU7pD8FIMKreYe3Q7FHHBO8+zK3948nz1OIdrMZ8Svi0iZaCj7gnipqYI402aKUgNwS3s=; 24:oCctAti4CqdHYkExJLpTzsk+++URflLUgSpMrmxUsfM30zzcnfYvx4ucqwKe5pxyPZzv14Mx78zNLTMxz2v0m8y7QhHCELsO/+tdhTv6fgc=; 7:29hw4jdPjBtKalAvHAuJxPAP5TO64KqsF5PicodSJh/Jec7HdcfqSOJQG1uT23pjf2oMAUJIXxoe1zMGC+MuEHIwGPW3gAXyHWYj3LSeis04db1y89xeXc1xmKOFUaqnqdby1gu4Zdr2LjY2XpBcR2iCcVHFapr7ArL9a0+WgO48drOnkunt0gZekzUFGoNcTV0cPjnDcJjyyYsaUyv53RFcKXCielDnGmqMIHbCvQd09AkzaCIdwepB09cFKb3/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ccd07cf-7505-4df8-37e2-08d54303435d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(53754006)(40434004)(199004)(189003)(606006)(316002)(86362001)(14454004)(8936002)(59450400001)(3660700001)(7696005)(3280700002)(97736004)(478600001)(5630700001)(6506007)(68736007)(72206003)(966005)(25786009)(5660300001)(6916009)(105586002)(66066001)(2900100001)(8676002)(99286004)(2906002)(81166006)(7736002)(81156014)(5890100001)(74316002)(33656002)(106356001)(2501003)(2351001)(5250100002)(6306002)(6116002)(790700001)(3846002)(6436002)(54896002)(102836003)(236005)(55016002)(9686003)(53936002)(1730700003)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706B31F7566818779681090FA0A0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ccd07cf-7505-4df8-37e2-08d54303435d X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 14:59:23.5844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [Ace] Credential Management for Internet of Things Devices X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 14:59:29 -0000 --_000_AM4PR0801MB2706B31F7566818779681090FA0A0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here is the publication of the IPSO Alliance whitepaper about "Credential M= anagement for Internet of Things Devices": https://www.ipso-alliance.org/blog-credential-management-for-internet-of-th= ings-devices/ It may be of interest to you since it compares ACE-OAuth with LwM2M and OCF= . Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706B31F7566818779681090FA0A0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here is the publication of the IPSO Alliance whitepa= per about "Credential Management for Internet of Things Devices”= :

https://www.ipso-alliance.= org/blog-credential-management-for-internet-of-things-devices/

 

It may be of interest to you since it compares ACE-O= Auth with LwM2M and OCF.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706B31F7566818779681090FA0A0AM4PR0801MB2706_-- From nobody Sun Dec 17 15:24:05 2017 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 80ECC126C89; Sun, 17 Dec 2017 15:23:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151355303849.28790.1591082139380212651@ietfa.amsl.com> Date: Sun, 17 Dec 2017 15:23:58 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 23:23:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlström Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-10.txt Pages : 25 Date : 2017-12-17 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 17 15:31:55 2017 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 3786012706D for ; Sun, 17 Dec 2017 15:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B2VPRwmw47f for ; Sun, 17 Dec 2017 15:31:52 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0103.outbound.protection.outlook.com [104.47.42.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E864124234 for ; Sun, 17 Dec 2017 15:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=URP0b0GgpkRUJUJrbzt22moi801JE8XuhvaQzdqVTfY=; b=WogcGHyMV8Yo/43+m/u8Ny/ionK3uySyy+r35Xo/edpMMNA/VIta12vjUorJyZsOrdSVhbj5wErnEhM0GQjb2cQ19zFKbvz4Llj7r60KjkqOyX9d0N+cWp0Z7rnesCHo1Pe2wQOMUBWK2+6UZfI7kOPGAeWRmf08EG1kE9Dfou0= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0181.namprd21.prod.outlook.com (10.173.193.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.1; Sun, 17 Dec 2017 23:31:51 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0366.001; Sun, 17 Dec 2017 23:31:51 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: CBOR Web Token (CWT) addressing 2nd WGLC comments Thread-Index: AdN3i8ThBAHtGOBySeCBxn2A9Igxmg== Date: Sun, 17 Dec 2017 23:31:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.88.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0181; 6:CiBn24kC5LaJ4TXvpa+6+wMyp24tWdQyKzDO9L7bTLR0+I6VSyx2WtDRMU7VCkggouGijO557bio7crVi95caGEOpToJllMIXeZqKHfDKGRrsx5Sewlld7YDtZjWw9bmxHjvExRWGGS8SfeaAik9MBef+ymyFuRqePgMWh3yCN8kVvtljZQozmXxslIo4u1shVbkVkriS9FkAKIhTeVQv/hX2KDk/fMy8ljI7Wvn3SwPMTIMElp2Zfn71TPE2FO07WI0zIteHVqnDeyobz9dRB8wf5EzdSZgbUKi6asPsUkR2VrxEWkZrASyFX+6nTygeRknPZQ6+BS5WemoEpiJk5BFVCS4o+uOaalePbswvUU=; 5:+jkq+17A2F2nSpOjkYSVFz46MwzxoBG9xkqI3X3D1gIE9IojhOgTLQsZe9ldPYc3jRkq1hbdbse5799uoAQSpgaZ+bMDgtddDFLKEClB2v7RuGkTjHYbHNVG375ZT71clR+c0WaO37rX/VDJvieMX04D39ZANb7W60haHVuV0ro=; 24:khxCTCwFQyT5D+Fv902zS+rULzG0OIhxo0lAm6vLKBmebA2BMvc+skzmsZy12/NeI3EQPHeYe/eQQ4E5TROjGiE1InRKPqOfHpCGVvk0fqM=; 7:tcZ8V0pAA83t2rCAmOSYhlyAE/VdHS8P91Mi9MHsVS1hZOnezTX2lbHSfv1ZLz/Oj5r/Sxgf4/cI/wRM0nCRG28wLhCK905hUf0p9TOjPxpJwncQZWAdhsPC3vjvgVZ/Ktx5/IbO0pwur8txGpCLg/PxNLxD3DcIqGpQO3OcImK4qMvUrEkSmlgExaOvoZeTxE8tYRwzjLWjRXao6arNwNtlL50SW2LxDDgrSpqjpi9vRVVrOok0JYFa5F7f7KdL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3588e15a-b74a-4f4d-44a4-08d545a65980 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:CY4PR21MB0181; x-ms-traffictypediagnostic: CY4PR21MB0181: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0181; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0181; x-forefront-prvs: 05245CA661 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(209900001)(189003)(199004)(66066001)(6436002)(966005)(3280700002)(33656002)(68736007)(81156014)(1730700003)(7696005)(2900100001)(86362001)(14454004)(10290500003)(5640700003)(478600001)(8676002)(72206003)(77096006)(2906002)(86612001)(97736004)(2501003)(8936002)(53376002)(105586002)(7736002)(2351001)(53936002)(6506007)(59450400001)(99286004)(81166006)(106356001)(74316002)(102836003)(5630700001)(606006)(25786009)(6116002)(790700001)(3846002)(5660300001)(54896002)(9686003)(6916009)(236005)(6306002)(316002)(3660700001)(10090500001)(8990500004)(22452003)(55016002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0181; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504604C0FF3332CE51BA09BF5090CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3588e15a-b74a-4f4d-44a4-08d545a65980 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2017 23:31:50.9853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0181 Archived-At: Subject: [Ace] CBOR Web Token (CWT) addressing 2nd WGLC comments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 17 Dec 2017 23:31:54 -0000 --_000_CY4PR21MB0504604C0FF3332CE51BA09BF5090CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new CBOR Web Token (CWT) draft has been published that addresses comments= received during the second working group last call. Thanks to Hannes Tsch= ofenig, Esko Dijk, Ludwig Seitz, Carsten Bormann, and Benjamin Kaduk for th= eir feedback. All changes made were clarifications or formatting improveme= nts. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-10 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-10.html -- Mike P.S. This notice was also posted http://self-issued.info/?p=3D1761 and as = @selfissued. --_000_CY4PR21MB0504604C0FF3332CE51BA09BF5090CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new CBOR Web Token (CWT) draft has been published = that addresses comments received during the second working group last call.=   Thanks to Hannes Tschofenig, Esko Dijk, Ludwig Seitz, Carsten Borman= n, and Benjamin Kaduk for their feedback.  All changes made were clarifications or formatting improvements.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted http://self-issued.info/?p=3D1761 and as @selfissued.

--_000_CY4PR21MB0504604C0FF3332CE51BA09BF5090CY4PR21MB0504namp_-- From nobody Mon Dec 18 01:39:38 2017 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 95C6B127978 for ; Mon, 18 Dec 2017 01:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtryCEXIcGhA for ; Mon, 18 Dec 2017 01:39:34 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0072.outbound.protection.outlook.com [104.47.0.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025F3127909 for ; Mon, 18 Dec 2017 01:39:32 -0800 (PST) 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=pNFdhraZipB+cebieQimSpGmM/i/80b1eNu79+fP+gs=; b=c0fDkIxg27f/SedksDkKTv3rqGukmymJolqvl6VNo08CYMeu9+fjHLMM/HQ0CiaUtAD63w8tK2EJB+M+QXIYX9GnucpAvgv5ePyig/hTV3aWyozcFmhQI81pPU00c1bz84FuCD2WIM26SeWW+4b3GJmEJQbQzpy6k40rUTtfNrE= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Mon, 18 Dec 2017 09:39:29 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0323.018; Mon, 18 Dec 2017 09:39:29 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: draft-vanderstok-ace-coap-est-03 Thread-Index: AdN33RJ6nKadWltJTlKxRfoNTxbYag== Date: Mon, 18 Dec 2017 09:39:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:KUgO30JNU1Fvlyk5VCePx8hu3/53nDZ4yT4wek8SvNso/4+CgeW/Wa9nXj2eBNUp+Ba+HD1VTxMy2i8HPOZKSLTmjgJngZ4I+YtFLOAPp/wIgFzUUZ21uzSPgXTPOHX5y13M2fdOkBpEWyE+PwiZdRRo07OEt+qWnEU/aKuJUTXs8ar8Nql/0t1kMdkJsDQzIdR4G3fPKoIaoorlqSiP628XNUef2wHYv3T2TtWWNMInfUvJ3zxAtSeTE9CD3Y8bpUujdW3Q4NE/x9/H9s06Wsy8Y0JgnTsFTUotOw8FlNfnacNVvRrYxsrnYW0I7/3AKFbwyQP+b1cLO0Cs1/qynzaQTGfkhSocQO79yJy4uIk=; 5:f+BA0Qxzq79RI1zraeJtrgjC0QWGPpGYGrOYSxSqVaUbYRLFN4V2xzaa4nMJjKXrZhVbxcY1TCRlHUsnMeQr69T7kYNyeOWEVlPzoJR6O1mQzHxhw/AZ6aqEpZDFNkdWzbTDHe7NF1R8UXhiZwfxnQc6Jbckxk8kY6qsLeLRQkU=; 24:kMUssZK50ATNocsxCLZNqHay8/ohlapmHnNXvYH2apx163LyaPn5se9avjealau1GulzPVacoTHDhBR7v8Oua7xFaTvqxPkI9vKdrXJ+naw=; 7:IcS29JawzjPQYf0s4PJA8VMx+xhEbjC0bDpf2UiQ22iF/dtpqZYmQTkmcHeh4xCaQULbCkPiGWgmnWDMwokYVV2jb6lV1IrSbOymIYQTcVS623krrdVwg7Q08RIJ8v38PKSa9xLIapXyI+GFAMqPQrPD4CHq2OtvaGOPihvB3uPRvJuckKidsUzY8jiJ4E3lIj86+PV1XyJDLnBYyuiev7c88hPkvz+1jbjLnLn1ofVlqk8TdZMCXhrhaNNaQc+4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 68c9f290-01b3-4ee9-dc53-08d545fb3c94 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(376002)(366004)(189003)(199004)(40434004)(5660300001)(6916009)(74316002)(316002)(6506007)(230783001)(72206003)(2351001)(478600001)(606006)(86362001)(25786009)(14454004)(97736004)(53946003)(2906002)(53936002)(3280700002)(561944003)(8936002)(3846002)(1730700003)(59450400001)(102836003)(7736002)(105586002)(6116002)(68736007)(99286004)(81156014)(790700001)(81166006)(5630700001)(106356001)(7696005)(33656002)(66066001)(5890100001)(6436002)(9686003)(54896002)(6306002)(236005)(5640700003)(55016002)(3660700001)(8676002)(2900100001)(5250100002)(2501003)(369524004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706FACCDE64A4A79C62E707FA0E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68c9f290-01b3-4ee9-dc53-08d545fb3c94 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 09:39:29.7352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [Ace] draft-vanderstok-ace-coap-est-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 18 Dec 2017 09:39:38 -0000 --_000_AM4PR0801MB2706FACCDE64A4A79C62E707FA0E0AM4PR0801MB2706_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, Hi co-authors, Thanks a lot for the quick update. In my opinion the document made a big st= ep forward. I nevertheless have a few comments: Would it make sense to expand the title of the draft to something like "Usi= ng Enrollment over Secure Transport (EST) over the Constrained Application = Protocol (CoAP)" Abstract: Here is my proposal: FROM: Abstract Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). Example low-resource uses cases for EST are: secure bootstrapping and certificate enrollment. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how low-resource devices are expected to use EST over secure CoAP (EST-coaps). 6LoWPAN fragmentation management and extensions to CoAP registries are needed to enable EST-coaps. TO: ---- Abstract Enrollment over Secure Transport (EST) has been defined in RFC 7030 and is = used as a certificate management protocol over HTTPS. This specification defines how to convey EST payloads over the Constrained = Application Protocol (CoAP). This allows resource constrained Internet of T= hings devices to re-use existing EST functionality. ---- REASON: 802.15.4 is only one networking technology EST over CoAP can be use= d over but there is nothing in CoAP over EST that requires 802.15.4 nor 6Lo= WPAN. For that reason I prefer to keep it more generic. The same is true fo= r the introduction where you repeat this story again. As such, I would suggest to change the text in the introduction: FROM: 1. = Introduction Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). This functionality is also needed for low resource devices. IPv6 over Low-power Wireless Personal Area Networks (6LoWPANs) [RFC4944] on IEEE 802.15.4 [ieee802= .15.4] wireless networks is becoming common in many industry application domains such as lighting controls. Although IEEE 802.15.4 defines how security can be enabled between nodes within a single mesh network, it does not specify the provisioning and management of the keys. Therefore, securing a 6LoWPAN network with devices from multiple manufacturers with different provisioning techniques is often tedious and time consuming. An example use case is the application of Bootstrapping of Remote Secure Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra]. T= he low resource aspects are detailed for 6tisch in [I-D.ietf-6tisch-minimal-security] and [I-D.ietf-6tisch-dtsecurity-secure-join]. Constrained networks use DTLS [RFC6347], CoAP [RFC7252], and UDP instead of TLS [RFC5246], HTTP [RFC= 7230] and TCP. EST-coaps replaces the invocations of TLS and HTTP by DTLS and CoAP invocations thus enabling EST for CoAP-based low-resource devices. Although EST-coaps paves the way for the utilization of EST for constrained devices on constrained networks, some devices will not have enough resources to handle the large payloads that come with EST-coaps. The specification of EST-coaps is intended to ensure that EST works for networks of constrained devices that choose to limit their communications stack to UDP/CoAP. It is up to the network designer to decide which devices execute the EST protocol and which not. Because the relatively large EST messages cannot be readily transported over constrained (6LoWPAN, LLN) wireless networks, this document specifies the use of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages = at the application layer. Support for Observe CoAP options [RFC7641] is out-of-scope for this document. Observe options could be used by the server to notify clients about a change in the cacerts or csr attributes (resources) and might be an area of future work. TO: 1. = Introduction Enrollment over Secure Transport (EST) [RFC7030] is used for certificate management (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). This functionality is also needed for low resource devices. "Classical" EST uses HTTPS and this specification defines a new transpor= t for EST using CoAP. It also profiles the use of use of EST to a smaller = subset. I would omit the following two paragraphs from the introduction since you a= re discussing them again in more detail in Section 4.4. Although EST-coaps paves the way for the utilization of EST for constrained devices on constrained networks, some devices will not have enough resources to handle the large payloads that come with EST-coaps. The specification of EST-coaps is intended to ensure that EST works for networks of constrained devices that choose to limit their communications stack to UDP/CoAP. It is up to the network designer to decide which devices execute the EST protocol and which not. Because the relatively large EST messages cannot be readily transported over constrained (6LoWPAN, LLN) wireless networks, this document specifies the use of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages = at the application layer. I would also omit the following paragraph since it is not clear to me why y= ou are discussing one design item that has not been added to the spec while= there are many others as well that have not been mentioned. Support for Observe CoAP options [RFC7641] is out-of-scope for this document. Observe options could be used by the server to notify clients about a change in the cacerts or csr attributes (resources) and might be an area of future work. Terminology: I would remove this paragraph since it does not add any value. Many of the concepts in this document are taken over from [RFC7030]. Consequently, much text is directly traceable to [RFC7030]. The same document structure is followed to point out the differences and commonalities between EST and EST-coaps. 2. = EST operational differences I would move this text into the (now shorter) introduction. Section 4. Protocol Design and Layering You write: o Server-side key generation messages, to provide a private client- identity key when the client is too restricted or because of lack of an entropy source. [EDNOTE: Encrypting these keys is important. RFC7030 specifies ho= w the private key can be encrypted with CMS using symmetric or asymmetric keys. Mention how symmetric key can be derived for EST server side key generation from the TLS KEM draft.] I consider server-side key generation (for public key crypto) as problemati= c since the server obviously gets to see the private key (something that ca= n be avoided by the use of asymmetric crypto and client-side generation of = secrets). With ECC (which is what I would recommend for use on IoT devices = due to the smaller key size) the key pair generation is also much simpler. = You indeed require a TRNG on the device but you need that anyway. For publi= c key crypto the recommended ciphersuite uses an EDHE and DTLS also exchang= es nonces in the handshake. In a nutshell, if you don't have a hardware-bas= ed random number generator then you are in trouble. The good thing is that = you get these nowadays in hardware even with the most basic MCUs. 4.3. CoAP response codes Is it really necessary to create a dependency to [I-D.hartke-core-pending] since this means that this document cannot be completed for = an extended period of time?! 4.4. Message fragmentation There is a lot of text in this section for just saying that you want to use= block-wise transfer. I also don't think you need to explain what block-wis= e transfer is. Regarding the statements being made: It almost sounds like you are saying t= hat you cannot use EST over CoAP without block-wise transfer and I don't be= lieve that's is correct. First, there are a number of connectivity technolo= gies that do not have a very small MTU size and those should be supported a= s well. Second, you discuss IEEE 802.15.4 specifically. You start by saying= that "Each DTLS record MUST fit within a single datagram". You then say th= at: To avoid using IP fragmentation, which is not supported by 6LoWPAN, invokers of the DTLS record layer MUST size DTLS records so that they fit within any Path MTU estimates obtained from the record layer. This is what the DTLS specification says and does not need to be repeated h= ere. Here is the text from RFC 6347 " In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. " The difference between the two sentences is that you are saying that DTLS m= ust perform fragmentation whereas the DTLS RFC says should. I fear that you= are modifying the behaviour of the DTLS RFC. That could be a problem. My na=EFve understanding of 6LoWPAN is that it supports fragmentation while= you claim that it doesn't. So, what is the story? I wonder how you came to the following conclusion: At the CoAP level it may= be difficult to "cut" the messages exactly in such a way that they fit cor= rectly and so it might make more sense to let the lower layers, such as DTL= S and 6LoWPAN to do their job. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 network SHOULD attempt to size CoAP messages such that each DTLS record will fit within one or two IEEE 802.15.4 frames. Regarding the size indications of certificates I have so far had cases wher= e 256-bit curves have a size of ~620 bytes but not 1000 bytes. Of course, y= ou can add all sorts of extensions and long fields to the cert but maybe th= at's not a great idea if you care about over the wire overhead. 7. = Proxying Why are you introducing proxy behaviour in EST over CoAP when it is not ava= ilable in classical EST? Can PoP work with a HTTP/CoAP proxy? Editorial: s/COAP/CoAP Final remark: would it make sense to support CoAP over TCP in the draft sin= ce we are about to finish the specification work? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706FACCDE64A4A79C62E707FA0E0AM4PR0801MB2706_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Peter, Hi co-authors,

 

Thanks a lot for the quick update. In my opinion the= document made a big step forward.

 

I nevertheless have a few comments:

 

Would it make sense to expand the title of the draft= to something like “Using Enrollment over Secure Transport (EST) over= the Constrained Application Protocol (CoAP)”

 

Abstract: Here is my proposal:

 

FROM:

 

Abstract
 
   Low-resource devices in a Low=
-power and Lossy Network (LLN) can
   operate in a mesh network usi=
ng the IPv6 over Low-power Wireless
   Personal Area Networks (6LoWP=
AN) and IEEE 802.15.4 link-layer
   standards.  Enrollment o=
ver Secure Transport (EST) [RFC7030] is use=
d
   for authenticated/authorized =
endpoint certificate enrollment (and
   optionally key provisioning) =
through a Certificate Authority (CA) or
   Registration Authority (RA).&=
nbsp; Example low-resource uses cases for EST
   are: secure bootstrapping and=
 certificate enrollment.
 
   Low-resource devices often us=
e the lightweight Constrained
   Application Protocol (CoAP) [=
RFC7252] for message exchanges.&=
nbsp; This
   document defines how low-reso=
urce devices are expected to use EST
   over secure CoAP (EST-coaps).=
 6LoWPAN fragmentation management and
   extensions to CoAP registries=
 are needed to enable EST-coaps.

 

TO:

 

----

 

Abstract
 
Enrollment over Secure Transpo=
rt (EST) has been defined in RFC 7030 and is used as a certificate manageme=
nt protocol over HTTPS. 
 
This specification defines how=
 to convey EST payloads over the Constrained Application Protocol (CoAP). T=
his allows resource constrained Internet of Things devices to re-use existi=
ng EST functionality. 
 
----
 
REASON: 802.15.4 is only one n=
etworking technology EST over CoAP can be used over but there is nothing in=
 CoAP over EST that requires 802.15.4 nor 6LoWPAN. For that reason I prefer=
 to keep it more generic. The same is true for the introduction where you r=
epeat this story again. 
 
As such, I would suggest to ch=
ange the text in the introduction: 
 
FROM:

1.  Introduction

 
   Enrollment over Secure Transp=
ort (EST) [RFC7030] is used for<=
/span>
   authenticated/authorized endp=
oint certificate enrollment (and
   optionally key provisioning) =
through a Certificate Authority (CA) or
   Registration Authority (RA).&=
nbsp; This functionality is also needed for
   low resource devices.
 
   IPv6 over Low-power Wireless =
Personal Area Networks (6LoWPANs)
   [RFC4944] on IEEE 802.15.4 [ieee8=
02.15.4] wireless networks is
   becoming common in many indus=
try application domains such as lighting
   controls.  Although IEEE=
 802.15.4 defines how security can be enabled
   between nodes within a single=
 mesh network, it does not specify the
   provisioning and management o=
f the keys.  Therefore, securing a
   6LoWPAN network with devices =
from multiple manufacturers with
   different provisioning techni=
ques is often tedious and time
   consuming.  An example u=
se case is the application of Bootstrapping
   of Remote Secure Infrastructu=
res (BRSKI)
   [I-D.ietf-anima-bootstrapping-keyinfra].  The low resou=
rce aspects
   are detailed for 6tisch in [<=
a href=3D"https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-=
I-D.ietf-6tisch-minimal-security">I-D.ietf-6tisch-minimal-security] and=

   [I-D.ietf-6tisch-dtsecurity-secure-join].=

 
   Constrained networks use DTLS=
 [RFC6347], CoAP [RFC7252], and UDP
   instead of TLS [RFC5246], HTTP [RFC7230] and TCP.  ES=
T-coaps replaces
   the invocations of TLS and HT=
TP by DTLS and CoAP invocations thus
   enabling EST for CoAP-based l=
ow-resource devices.
 
   Although EST-coaps paves the =
way for the utilization of EST for
   constrained devices on constr=
ained networks, some devices will not
   have enough resources to hand=
le the large payloads that come with
   EST-coaps.  The specific=
ation of EST-coaps is intended to ensure that
   EST works for networks of con=
strained devices that choose to limit
   their communications stack to=
 UDP/CoAP.  It is up to the network
   designer to decide which devi=
ces execute the EST protocol and which
   not.
 
   Because the relatively large =
EST messages cannot be readily
   transported over constrained =
(6LoWPAN, LLN) wireless networks, this
   document specifies the use of=
 CoAP Block-Wise Transfer ("Block")
   [RFC7959] to fragment EST messages at=
 the application layer.
 
   Support for Observe CoAP opti=
ons [RFC7641<=
/a>] is out-of-scope for this
   document.  Observe optio=
ns could be used by the server to notify
   clients about a change in the=
 cacerts or csr attributes (resources)
   and might be an area of futur=
e work.
 
TO:

1.  Introduction

 
   Enrollment over Secure Transp=
ort (EST) [RFC7030] is used for<=
/span>
   certificate management (and
   optionally key provisioning) =
through a Certificate Authority (CA) or
   Registration Authority (RA).&=
nbsp; This functionality is also needed for
   low resource devices.
 
   “Classical” EST u=
ses HTTPS and this specification defines a new transport =

   for EST using CoAP. It a=
lso profiles the use of use of EST to a smaller subset. <=
/pre>



&nb=
sp;


&nb=
sp;




 


I would omit the following two=
 paragraphs from the introduction since you are discussing them again in mo=
re detail in Section 4.4. 


 


   Although EST-coaps paves the =
way for the utilization of EST for


   constrained devices on constr=
ained networks, some devices will not


   have enough resources to hand=
le the large payloads that come with


   EST-coaps.  The specific=
ation of EST-coaps is intended to ensure that


   EST works for networks of con=
strained devices that choose to limit


   their communications stack to=
 UDP/CoAP.  It is up to the network


   designer to decide which devi=
ces execute the EST protocol and which


   not.


 


   Because the relatively large =
EST messages cannot be readily


   transported over constrained =
(6LoWPAN, LLN) wireless networks, this


   document specifies the use of=
 CoAP Block-Wise Transfer ("Block")


   [RFC7959] to fragment EST messages at=
 the application layer.


 


I would also omit the following paragraph since it is not=
 clear to me why you are discussing one design item that has not been added=
 to the spec while there are many others as well that have not been mention=
ed. 


 


   Support for Observe CoAP opti=
ons [RFC7641<=
/a>] is out-of-scope for this


   document.  Observe optio=
ns could be used by the server to notify


   clients about a change in the=
 cacerts or csr attributes (resources)


   and might be an area of futur=
e work.


 


 


Terminology: 


 


I would remove this paragraph since it does not add any v=
alue. 


 


   Many of the concepts in this =
document are taken over from [RFC7030].


   Consequently, much text is di=
rectly traceable to [RFC7030].  The s=
ame


   document structure is followe=
d to point out the differences and


   commonalities between EST and=
 EST-coaps.


 


2. 
 EST operational differences


I would move this text into the (now shorter) introductio=
n. 


 


Section
4. 
 Protocol Design and Layering


 


You write: 


 


   o  Server-side key gener=
ation messages, to provide a private client-


      identity ke=
y when the client is too restricted or because of lack

      of an entro=
py source.  [EDNOTE: Encrypting these keys is


      important.&=
nbsp; RFC7030 specifies=
 how the private key can be encrypted


      with CMS us=
ing symmetric or asymmetric keys.  Mention how


      symmetric k=
ey can be derived for EST server side key generation

      from the TL=
S KEM draft.]


 


I consider server-side key generation (for public key cry=
pto) as problematic since the server obviously gets to see the private key =
(something that can be avoided by the use of asymmetric crypto and client-s=
ide generation of secrets). With ECC (which is what I would recommend for u=
se on IoT devices due to the smaller key size) the key pair generation is a=
lso much simpler. You indeed require a TRNG on the device but you need that=
 anyway. For public key crypto the recommended ciphersuite uses an EDHE and=
 DTLS also exchanges nonces in the handshake. In a nutshell, if you donR=
17;t have a hardware-based random number generator then you are in trouble.=
 The good thing is that you get these nowadays in hardware even with the mo=
st basic MCUs. 


 


4.3. 
 CoAP response codes


 


Is it really necessary to create a dependency to <=
span style=3D"color:black">[I-D.hartke-core-pendi=
ng] since this means that this document cannot be completed for an exte=
nded period of time?! 


 


4.4. 
 Message fragmentation


 


There is a lot of text in this section for just saying th=
at you want to use block-wise transfer. I also don’t think you need t=
o explain what block-wise transfer is.


 


Regarding the statements being made: It almost sounds lik=
e you are saying that you cannot use EST over CoAP without block-wise trans=
fer and I don’t believe that’s is correct. First, there are a n=
umber of connectivity technologies that do not have a very small MTU size a=
nd those should be supported as well. Second, you discuss IEEE 802.15.4 spe=
cifically. You start by saying that &quo=
t;Each DTLS record MUST fit within a single datagram". You then say that: 


 


   To avoid using IP<=
/span>


   fragmentation, which is not s=
upported by 6LoWPAN, invokers of the


   DTLS record layer MUST size D=
TLS records so that they fit within any


   Path MTU estimates obtained f=
rom the record layer.


 


This is what the DTLS specification says and does not nee=
d to be repeated here. Here is the text from RFC 6347

 


“  In order to


   avoid IP fragmentation, clien=
ts of the DTLS record layer SHOULD


   attempt to size records so th=
at they fit within any PMTU estimates


   obtained from the record laye=
r.


“


 


The difference between=
 the two sentences is that you are saying that DTLS must perform fragmentat=
ion whereas the DTLS RFC says should. I fear that you are modifying the beh=
aviour of the DTLS RFC. That could be a problem. 


 


My na=EFve understanding of 6LoWPAN is that it supports f=
ragmentation while you claim that it doesn’t. So, what is the story? =



 


 


I wonder how you came to the following conclusion: At the=
 CoAP level it may be difficult to “cut” the messages exactly i=
n such a way that they fit correctly and so it might make more sense to let=
 the lower layers, such as DTLS and 6LoWPAN to do their job. 


 


   In addition,


   invokers residing on a 6LoWPA=
N over IEEE 802.15.4 network SHOULD


   attempt to size CoAP messages=
 such that each DTLS record will fit


   within one or two IEEE 802.15=
.4 frames.


 


 


 


Regarding the size indications of certificates I have so =
far had cases where 256-bit curves have a size of ~620 bytes but not 1000 b=
ytes. Of course, you can add all sorts of extensions and long fields to the=
 cert but maybe that’s not a great idea if you care about over the wi=
re overhead.


 


7. 
 Proxying


 


Why are you introducing proxy behaviour in EST over CoAP =
when it is not available in classical EST? 


Can PoP work with a HTTP/CoAP proxy? 

 


Editorial: 


 


s/COAP/CoAP=



 


 


Final remark: would it make sense to support CoAP over TC=
P in the draft since we are about to finish the specification work? 


 


Ciao


Hannes


 
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706FACCDE64A4A79C62E707FA0E0AM4PR0801MB2706_-- From nobody Mon Dec 18 05:01:11 2017 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 E3073127333 for ; Mon, 18 Dec 2017 05:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tcOksLTtXlh for ; Mon, 18 Dec 2017 05:01:07 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60082.outbound.protection.outlook.com [40.107.6.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46867120727 for ; Mon, 18 Dec 2017 05:01:07 -0800 (PST) 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=JobBKIe4lSpWVts+iVfZPYyOMXMpcEhU2BkilucZd+w=; b=VwtQn7BUtyPtuxHANp3PqgTvqym7DcitaDzpziPifTg9tuWH4DXnleKbFjQ8bJUQm2vpji9xWjeDUcX4gZ8y5Dlr9KNn/O4XLgQ2RzJXTjbCvjX/ALsd0V0uYOISlk5OzwLA9HzTg980SFVmLQnCePXezm4GhBRNT4cczH4+U4o= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2707.eurprd08.prod.outlook.com (10.167.90.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 18 Dec 2017 13:01:05 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0323.018; Mon, 18 Dec 2017 13:01:05 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Relaxing OAuth-ACE profiles Thread-Index: AdN3/ysrdoP8lI5/QReEo7xBRgSrTQ== Date: Mon, 18 Dec 2017 13:01:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2707; 6:9yIZ0mlSLqR+nhX6JpUzeLkPv1H9U6z6cL2nVP9ncawKm1yT7vyV/i7OOoCBg086K+8c7kJpRNbMe0i9SGqD4yenzbvhFvhsQm6DYU++5gLaZadEmUvRjOh2Ur+Wx9lsALWiX+a91Z6kc1NJmn68ovlu++BRT5MVYoiO026qREfLkQ+wBNJDWVmGFzgI2v5swq4M4DLyct8lEZ32zkWRk99ei17YLdswuEW6KkgTxMazWOT0KcH4PJIgHCY5Vu2TkXVk+sK2Yr4U3OFMcgSZMHfdxbCg9dVfHhKH8n4uBBhXvnAa545/yDQqrqlpfdTjTd6nfVUSEgnp5L5JRjIKgt/+CKsM6Cb1zUegAb+460U=; 5:kVyUer0Unv57nWZZG6+a810v8ZAuz3g5CSA8KUiPRpXx0X20K6Ur0McH7N6DCtxbJcNvO17vZBron+V2wsLHSs9UlQ3+uBsSUwUG+PcrhtrskHRamzFsjAwffRw7TM0y5KiS8i3gAv/1SzsWnlwKj6PL+Gs1+yNQ3rZkoFK/lBY=; 24:h/snWGPBr3jCRahy17mHO3FShyxoQd+3ZPLTfwFbIkY/f5RpxPQTqPhpGYSGMTHjf61ZkuvP5SCmT5oFePJ5LqtpaKr/KDzQnECBCqUySFk=; 7:Wr+2bsxCtgIHyEPQA75K0m/FOPT/8+du9+5BlXx42jzjA01tUzvCv5DG3HqvMThl4Hp/rtkRPg72v2t9HeLS3dWQl/LRzW3OlP3LEDDupleQvotuLuMkaMoX5H59+KA+Gi7xiditq3KP/loGDm5+eohi551yreaUWbgv0eeTFO/yBdOcIzv853K7qXNfGjqWBT1unMuJAemiTGIc3Zk91YpxUX1YLrWsTJIdVfdF2A3D/jdhPITLolhe6DJNEbJg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9551a519-3c37-4740-e9c1-08d5461765df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM4PR0801MB2707; x-ms-traffictypediagnostic: AM4PR0801MB2707: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0801MB2707; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2707; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(39860400002)(40434004)(189003)(199004)(53754006)(3846002)(81156014)(81166006)(2900100001)(3280700002)(72206003)(2906002)(33656002)(6916009)(1730700003)(790700001)(66066001)(316002)(25786009)(3660700001)(478600001)(8676002)(6506007)(97736004)(6116002)(102836003)(53936002)(2351001)(5640700003)(59450400001)(5630700001)(236005)(2501003)(5890100001)(6306002)(8936002)(606006)(9686003)(54896002)(74316002)(99286004)(5660300001)(6436002)(7696005)(55016002)(106356001)(966005)(5250100002)(68736007)(3480700004)(105586002)(7736002)(86362001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2707; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB27061CC885236367556ABBB2FA0E0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9551a519-3c37-4740-e9c1-08d5461765df X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 13:01:04.9377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2707 Archived-At: Subject: [Ace] Relaxing OAuth-ACE profiles X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 18 Dec 2017 13:01:10 -0000 --_000_AM4PR0801MB27061CC885236367556ABBB2FA0E0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In off-list discussion the differences between OAuth-ACE, OCF and LwM2M was= discussed. One of the distinguishing features of OAuth-ACE is that it allo= ws user authentication and authorization to be conveniently provided and in= tegrated into an already existing ecosystem. However, after re-reading the OAuth-ACE draft I noticed that the use of a s= mart phone / tablet for accessing IoT devices is actually not well supporte= d due to the decisions made around profiles. Hence, I created a pull request that relaxes the OAuth-ACE profiles in the = following way: * It allows profiles to specify what protocols and encodings they use on th= e client to AS interface (in addition to the client to RS interface). * It allows the use of HTTPS and JSON encoding on the client to AS interfac= e. Hence, this allows a client to request a CWT-based PoP token using HTTPS= from an RS. Here is the pull request: https://github.com/ace-wg/ace-oauth/pull/129 Thoughts? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB27061CC885236367556ABBB2FA0E0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In off-list discussion the differences between OAuth= -ACE, OCF and LwM2M was discussed. One of the distinguishing features of OA= uth-ACE is that it allows user authentication and authorization to be conve= niently provided and integrated into an already existing ecosystem.

 

However, after re-reading the OAuth-ACE draft I noti= ced that the use of a smart phone / tablet for accessing IoT devices is act= ually not well supported due to the decisions made around profiles.

 

Hence, I created a pull request that relaxes the OAu= th-ACE profiles in the following way:

* It allows profiles to specify what protocols and e= ncodings they use on the client to AS interface (in addition to the client = to RS interface).

* It allows the use of HTTPS and JSON encoding on th= e client to AS interface. Hence, this allows a client to request a CWT-base= d PoP token using HTTPS from an RS.

 

Here is the pull request:

https://github.com/ace-wg/ace-oauth/pull/129

 

Thoughts?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB27061CC885236367556ABBB2FA0E0AM4PR0801MB2706_-- From nobody Mon Dec 18 05:14:58 2017 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 9BC9E129C6A for ; Mon, 18 Dec 2017 05:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PYSt6WQ1aRp for ; Mon, 18 Dec 2017 05:14:55 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E278F1242F7 for ; Mon, 18 Dec 2017 05:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vBIDEm83015619; Mon, 18 Dec 2017 14:14:48 +0100 (CET) Received: from [192.168.217.102] (p5DC7E04D.dip0.t-ipconnect.de [93.199.224.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3z0hMr1kRwzDX0L; Mon, 18 Dec 2017 14:14:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 18 Dec 2017 14:14:46 +0100 Cc: "ace@ietf.org" X-Mao-Original-Outgoing-Id: 535295686.585325-4c8c60bae6607032f72c1646c4a81441 Content-Transfer-Encoding: quoted-printable Message-Id: <05CFF2B1-9E19-40B9-9F40-A8C066BAAA21@tzi.org> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Relaxing OAuth-ACE profiles X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 18 Dec 2017 13:14:57 -0000 On Dec 18, 2017, at 14:01, Hannes Tschofenig = wrote: >=20 > Hence, I created a pull request that relaxes the OAuth-ACE profiles in = the following way: > * It allows profiles to specify what protocols and encodings they use = on the client to AS interface (in addition to the client to RS = interface). > * It allows the use of HTTPS and JSON encoding on the client to AS = interface. Hence, this allows a client to request a CWT-based PoP token = using HTTPS from an RS. Sure. draft-ietf-ace-actors tells you that aceclient-AS is a less-constrained = interface, so it doesn=E2=80=99t need to be limited to protocols for = constrained devices. aceclient-RS is a constrained interface. (And at = some point the client authorization manager CAM will escape from the = aceclient and we get back the more rational four-legged architecture.) Not sure why you need JSON to use HTTP, but of course this can be opened = up because it is the less-constrained CAM-SAM interface. More = generally, the CAM-SAM interface (aceclient-AS in current terminology) = really is about business logic, so go ahead and do XMLDSig and BPEL and = SOAP and whatever makes the software architect happy. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 19 03:22:01 2017 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 406A912DA44 for ; Tue, 19 Dec 2017 03:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpQbL8BF81v6 for ; Tue, 19 Dec 2017 03:21:57 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57047127909 for ; Tue, 19 Dec 2017 03:21:57 -0800 (PST) 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=Hdcq2XaymfwDG822iNVm7Pj5V3XBPuo/Y5dsLKuo33Q=; b=a2vFTE4w+Vcsk5IJlRCZVJfgjR3rzX3UBCWwXulozjNViX/9/xRRFQjUkrik+U8zsXvHPu/DaqUjOHlkJVSG94jQV3Mh6P49NLDA23nevo5xCRfUaCaa6UAsGEvC0Rzo0cldncWDfXTQ3l3Q5pccEkVXHpoNLYtvUCyOOFMN5E8= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 11:21:55 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 11:21:55 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "ace@ietf.org" Thread-Topic: [Ace] Relaxing OAuth-ACE profiles Thread-Index: AdN3/ysrdoP8lI5/QReEo7xBRgSrTQAAwGUAAC3sgiA= Date: Tue, 19 Dec 2017 11:21:54 +0000 Message-ID: References: <05CFF2B1-9E19-40B9-9F40-A8C066BAAA21@tzi.org> In-Reply-To: <05CFF2B1-9E19-40B9-9F40-A8C066BAAA21@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:lWE+PrsVtVCOXH9yblDoWQoOPDUp4RWMafH/cXnOL5VIkJfy0/gex4w/gVcGMLBty6pXCFYrKVHn7X3h/5ELbYo3+1xh/tUbbDBqFf1rjhgzfilWDg0ur+qX89egWo1TZncsWpmP02NQIcOcUBH3bLeQjM8C86iVtG7PKNyu5E53cG08sigWvTy87Kel5ryNAGdDot+R/7liw19R5TLonA9vRDG6D/hOyewITi34T3XNhlBUb3qbuRPtQ6UHvJqhsLbUtEzb57M5e3RzERzkxsE9cNGSe2KG6cLhb/Y4Ml0+lpsAufObn4W6staEZeGUaXcwTb9dEpUU7pXrfTxHkEcXEXiWV/ofYCDpTHg5UCU=; 5:hdXWSuPf9u1ay9YV1tlQTQBASWctbJ4oZIYPpNZ6MHUpjUYkigZmJrsIYfSAgm4un4BhGVnPEucekTKz3kpRLDf6R2uxfCHO5jRYSN2sddkYs4rnBeT48OlDftTODFd7oHSIx3wpuh3owzerUAl9bmDBAVZ8hKPBTqvztRIhN64=; 24:18PljyW4CwVQwe+cUJMos2nsg3KuTSKOBCokopl+yYfj8NcLXqvuwVMq7/Kdp3M5dWZqGluJyPg/3cL/B6akRdrDx8YFpT5GhtDzeA+lUUI=; 7:6jkGAgUtUjcXYnukwwribiSdb/v3S1dMB7EYWbYaIUJWwm3+5fIPCkjn8SVozSsC4m/gOl11IME7gKSbDh9/l1lpxII5eQFgk35/P1JRQCC1t+QoB0qqY/22GVHi0hKQ/U4t4V1iJKu6dtmaUntLF5vYbiN2pb9+EsuhDTjzLJHhkc/mIDxckLcXVeRXBacRS3jcJidQ0P0X9dT3y4AmIxksGZKQRON9AVCCW2Uo+PpBKaY1uCGt8H9ULFW63T2C x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2799e9c4-05f9-4f39-2b77-08d546d2b5d2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231023)(3002001)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(396003)(40434004)(199004)(189003)(76176011)(81166006)(105586002)(81156014)(6116002)(7736002)(99286004)(106356001)(59450400001)(33656002)(7696005)(8936002)(53936002)(2906002)(3280700002)(8676002)(3660700001)(5250100002)(2900100001)(5890100001)(68736007)(55016002)(6436002)(66066001)(9686003)(72206003)(3846002)(5660300001)(229853002)(102836003)(6506007)(74316002)(2950100002)(316002)(6246003)(6916009)(478600001)(4326008)(25786009)(14454004)(86362001)(305945005)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2799e9c4-05f9-4f39-2b77-08d546d2b5d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 11:21:55.0006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] Relaxing OAuth-ACE profiles X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 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, 19 Dec 2017 11:22:00 -0000 SGkgQ2Fyc3RlbiwNCg0KfnNuaXB+DQoNCj4gZHJhZnQtaWV0Zi1hY2UtYWN0b3JzIHRlbGxzIHlv dSB0aGF0IGFjZWNsaWVudC1BUyBpcyBhIGxlc3MtY29uc3RyYWluZWQgaW50ZXJmYWNlLCBzbyBp dCBkb2VzbuKAmXQgbmVlZCB0byBiZSBsaW1pdGVkIHRvIHByb3RvY29scyBmb3INCmNvbnN0cmFp bmVkIGRldmljZXMuICBhY2VjbGllbnQtUlMgaXMgYSBjb25zdHJhaW5lZCBpbnRlcmZhY2UuICAo QW5kIGF0IHNvbWUgcG9pbnQgdGhlIGNsaWVudCBhdXRob3JpemF0aW9uIG1hbmFnZXIgQ0FNIHdp bGwgZXNjYXBlIGZyb20gdGhlIGFjZWNsaWVudCBhbmQgd2UgZ2V0IGJhY2sgdGhlIG1vcmUgcmF0 aW9uYWwgZm91ci1sZWdnZWQgYXJjaGl0ZWN0dXJlLikNCg0KV2UgaGF2ZSBjZXJ0YWlubHkgZW52 aXNpb25lZCB0aGlzIHVzZSBjYXNlIGVhcmx5IG9uIGluIHRoZSBncm91cCBhbmQgaXQgaXMgZ29v ZCB0aGF0IHRoZSBhY3RvcnMgZHJhZnQgY292ZXJzIGl0LiBTYW11ZWwsIEVyaWsgYW5kIEkgaGFk IHVzZWQgdGhpcyBzY2VuYXJpbyBhdCBBUk0gVGVjaENvbiBhIGZldyB5ZWFycyBhZ28gYXMgYSBz aG93Y2FzZSB1c2luZyBhIGRvb3IgbG9jayB0byBpbGx1c3RyYXRlIHdoYXQgQUNFLU9BdXRoIGRv ZXMuIEl0IGlzIGp1c3QgdGhhdCB0aGUgY3VycmVudCBBQ0UtT0F1dGggZHJhZnQgdmVyc2lvbiBk b2Vzbid0IHN1cHBvcnQgaXQgd2VsbCBJTUhPLg0KDQpFdmVuIHRob3VnaCB0aGF0IGludGVyZmFj ZSBpcyBub3QgbGltaXRlZCB3ZSB3b3VsZCBzdGlsbCBoYXZlIHRvIHVzZSBzb21lIG9mIHRoZSBu ZXdseSBkZWZpbmVkIHBhcmFtZXRlcnMgKGFuZCBmZWF0dXJlcyAoZS5nLiwgQ1dUKS4NCg0KPiBO b3Qgc3VyZSB3aHkgeW91IG5lZWQgSlNPTiB0byB1c2UgSFRUUCwgYnV0IG9mIGNvdXJzZSB0aGlz IGNhbiBiZSBvcGVuZWQgdXAgYmVjYXVzZSBpdCBpcyB0aGUgbGVzcy1jb25zdHJhaW5lZCBDQU0t U0FNIGludGVyZmFjZS4gIE1vcmUgZ2VuZXJhbGx5LCB0aGUgQ0FNLVNBTSBpbnRlcmZhY2UgKGFj ZWNsaWVudC1BUyBpbiBjdXJyZW50IHRlcm1pbm9sb2d5KSByZWFsbHkgaXMgYWJvdXQgYnVzaW5l c3MgbG9naWMsIHNvIGdvIGFoZWFkIGFuZCBkbyBYTUxEU2lnIGFuZCBCUEVMIGFuZCBTT0FQIGFu ZCB3aGF0ZXZlciBtYWtlcyB0aGUgc29mdHdhcmUgYXJjaGl0ZWN0IGhhcHB5Lg0KDQpJIG1pZ2h0 IG5vdCBoYXZlIHVzZWQgdGhlIHRlcm1pbm9sb2d5IGFwcHJvcHJpYXRlbHkgYnV0IHdoYXQgSSB3 YXMgdHJ5aW5nIHRvIGFjY29tcGxpc2ggIGlzIHRvIHVzZSBSRkMgODI1MiBvbiB0aGUgcGhvbmUv dGFibGV0IGFuZCB0byByZXF1ZXN0IGEgQ1dUIChpbnN0ZWFkIG9mIGEgSldUKS4gUkZDIDgyNTIg dXNlcyBhIG1peHR1cmUgb2YgdGVjaG5vbG9naWVzLCBpbmNsdWRpbmcgYSBKU09OLWJhc2VkIGVu Y29kaW5nIGZvciB0aGUgQWNjZXNzIFRva2VuIFJlc3BvbnNlLiAgVGhlIEFjY2VzcyBUb2tlbiBS ZXF1ZXN0LCBvbiB0aGUgb3RoZXIgaGFuZCwgd291bGQgYmUgZm9ybSBlbmNvZGVkLiBNYXliZSBJ IHNob3VsZCBpbmNsdWRlIGFuIGV4YW1wbGUgaW4gdGhlIGFwcGVuZGl4IHRvIG1ha2UgaXQgY2xl YXJlci4NCg0KQ2lhbw0KSGFubmVzDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCg== From nobody Wed Dec 20 12:39:40 2017 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 767501200F1 for ; Wed, 20 Dec 2017 12:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tACXhLpTmeN6 for ; Wed, 20 Dec 2017 12:39:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0DC126CBF for ; Wed, 20 Dec 2017 12:39:37 -0800 (PST) Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 12:37:51 -0800 From: Jim Schaad To: Date: Wed, 20 Dec 2017 12:39:07 -0800 Message-ID: <017501d379d2$96883bc0$c398b340$@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: AdN50oSrNFD7X9JhS5Sjj/V82BdiDw== Content-Language: en-us X-Originating-IP: [192.168.0.11] Archived-At: Subject: [Ace] Minutes for IETF 100 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 20:39:39 -0000 I have uploaded the minutes for the meeting. Please feel free to look at them and send me comments. Jim From nobody Thu Dec 21 13:05:08 2017 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 6AD0712D7E6; Thu, 21 Dec 2017 13:05:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151389030242.12883.13509958896271071252@ietfa.amsl.com> Date: Thu, 21 Dec 2017 13:05:02 -0800 Archived-At: Subject: [Ace] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 21:05:02 -0000 Dear Ludwig Seitz, Göran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig: An IPR disclosure that pertains to your Internet-Draft entitled "Authentication and Authorization for Constrained Environments (ACE)" (draft-ietf-ace-oauth-authz) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3123/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ace-oauth-authz" Thank you IETF Secretariat