From nobody Tue Aug 4 08:29:04 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E693A0A39 for ; Tue, 4 Aug 2020 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 qUOe4EYI6BQm for ; Tue, 4 Aug 2020 08:29:01 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 EF5D63A0A4E for ; Tue, 4 Aug 2020 08:29:00 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id v13so20050112oiv.13 for ; Tue, 04 Aug 2020 08:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=from:subject:autocrypt:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=FtC2zIoAWyuFO+WZa2aOjw/RMwtRRZ11us2YddsLN3g=; b=xav/XD2TZzhyEDgUKBUQrl5BBfMJhQwstDKUqRY3Ccuafhh72+yOQyXjQ7b+wQijfn zO4gGJaXqt/Kd30QankdibSIcgm6MKCI/B6MhJwfq/bvU2PZMTI4Dpn11irqbQWLdf1I CoHSEnI/8W1+NPK3CnUQnkqeLgAqoutzntlS718FEDukVG2xocBdCs6cg/EiFQL2cAfA +lBQTKSiqnRuziKOZpAQcs7dz9hrUaad8SL9fNQMMapNf/W0weC/jIFW5f+F0oWFnW72 f/EfDic+twpl1S+AMyqhhzzdz+EpnDm12LSF038sU4MNkxyb3ENcVSXw7RwJ+8lXW5qE AZOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:autocrypt:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=FtC2zIoAWyuFO+WZa2aOjw/RMwtRRZ11us2YddsLN3g=; b=TMJsEK9V2k+0Ti7lsWZ7QMbCONyXkhtehmxlmQUALLL5jYubTZEEUj47Lft8WyBBXa cBRWa2lBtiqzXlDnrMZAZHAu8KOimIWxLN3v6UZVA2JV0nHjTddb22reFkfefMGPhlJ5 8cM3ispvAcfZi4ZfbhP+sd8xpWkC1/U4N2M8QmMWpB4LNYSqmxDERjAmfZA5XvU5LDKH jMGnVFEqQ4Kc525mxrbfjRQLTT9KV54OpChOeI17/v/LZOnF5u575fYyA68F+J2ya/Mo qIDEKp/JtONz+NGY0hO2Fh1+HSO1QFs2Te/fYLre4bx6i3eSX/kaM0iYG4BhwOxbPWGe Izkw== X-Gm-Message-State: AOAM531SlCVTt6D47wn6qBf0TWI1ZjX8LQLZGYln8LlhZfJ40y/PiRAz b5nb+RyWmf0RxZDgrtObVfFArpm5yas= X-Google-Smtp-Source: ABdhPJwAmPKgY4I/JhGsWd8udrEqDoo1tbBraSiUX/2ecInyaggOnbjvfQNZXSE/5ufM/tcNZme0fA== X-Received: by 2002:aca:4710:: with SMTP id u16mr3882040oia.158.1596554939597; Tue, 04 Aug 2020 08:28:59 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:e901:14bc:65c4:39e5]) by smtp.gmail.com with ESMTPSA id l23sm2518817oti.18.2020.08.04.08.28.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 08:28:58 -0700 (PDT) From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= To: cose Message-ID: <186022c9-6586-fd48-0c08-ba2535724018@outer-planes.net> Date: Tue, 4 Aug 2020 09:28:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] =?utf-8?q?=F0=9F=9B=8E_Call_for_Consensus=3A_CounterSigna?= =?utf-8?q?ture_Discussion_=F0=9F=9B=8E?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:29:03 -0000 This message is to confirm consensus to deprecate the current CounterSignature feature and replace it with one that best accounts for all COSE message types. At the synchronous WG meeting on July 29, the issue with countersignatures was heavily discussed. In summary, the currently-defined CounterSignature mechanism is not processed with the cryptographic content for certain COSE message types. The consensus from the meeting is to mark the current CounterSignature process and structure deprecated in rfc8152bis and define a new one that properly accounts for the cryptographic. Further consensus leaned toward an aggressive approach, incorporating all bstr elements in the target structure when computing the signature. To complete the new CounterSignature method, the sense in the meeting is to have a series of virtual interims. The details of the new method and where it fits as working group items is still to be determined. Jim Schaad posted a starting proposal for a method[1], and an initial discussion on how to approach this as a working group item[2]. Given the participation in the meeting is very close to the participation on the list, we are only seeking objections. If you have objections, please inform the list and why you object. A following message will propose times for interims, ideally starting this month (August). Thank you, - Ivaylo and Matthew COSE WG Chairs -- [1]: < https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/ > [2]: < https://mailarchive.ietf.org/arch/msg/cose/8Mxcnsq9sm_pXQAm-2bexKxpaMU/ > From nobody Tue Aug 4 09:27:29 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB73A0D1F for ; Tue, 4 Aug 2020 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 EQB5hxpf-R97 for ; Tue, 4 Aug 2020 09:27:25 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640091.outbound.protection.outlook.com [40.107.64.91]) (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 682FE3A0FD9 for ; Tue, 4 Aug 2020 09:23:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BHe06i6Q7A1+nsPeCaHstSE5jtXx5+A4eWhl4L3cltRYU2mDu52so9ni78zAxt0nxJ1qLcpfwbVVTMceP43rHeO44llvKnxj7jztuCHGlLF45cLQJbTVDHZ3m1+l4wIDUonqOfWwEAezZINz+395/F0g5PA1wPsxvpRzslpp9+t/AKI7dyIEgZJQu5Hnkzyj9Rx/kYfXp9OIAzRlOB4K0jwwkY/Koes9lOOJGraivRC41h2oKGgs50YO9XqhgksJjs6QeSuy+lOFEQ9oFiy3nHeKL1eha+qrkD9cOqz66psi4s35tfNTb2TeJBtXASaacSHYZJdPHmU9pxdclsiDug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RbGd2jewCxYe6E3d7e/2WgMrYwOV0gl/TELdrZDLLbw=; b=Y6zdesPURHvMBJuFR1mu/MTfXEkXrWl8q3v+IqGlBzVWtIqRFKVu1lRXVPPOoJdvI1kF8PyZGpDfLdcUA9BWW53S7+9FyeQ1QRGIwtogrOGK1zcH7UVeFJPIJEND7Ig88MgAZQs+z2EuJxO03n4oA97ZBa9yZHiahHV5WMcSJ21onORssNZUVwSABLYsOVy4kNml9UrL73nXWeNksTrR8I5GPtOM4uJoDQKRmc8T8gK/e+k+EpvjGkJljUp+zAyd48sXfRZxxObUbW4v6GMVfa8K3m0VXKNDzepm+J6GgU2qNG/i+fKD1KOOvQWIEJ0evkmQty49RtaHUjn+2CUa0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RbGd2jewCxYe6E3d7e/2WgMrYwOV0gl/TELdrZDLLbw=; b=Up7p8GdDBxHWSjb2iKYOs2rrohCl8k3iTsedZZ+A+GnafCKNYVwkgpV4McKtKXlDGTXhucqrPcoS7y5kHxlyWtI128P/r2g3nKvZOSzjvU452XBv2UYzChtpEyF+bZivxsYHYJJSMFVcie10xTNAtDdLA2zwYmkVaInmwvSq0Vk= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0711.namprd00.prod.outlook.com (2603:10b6:610:ad::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3300.0; Tue, 4 Aug 2020 16:23:49 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::e9ce:b982:5ae1:959d%9]) with mapi id 15.20.3300.000; Tue, 4 Aug 2020 16:23:49 +0000 From: Mike Jones To: "Matthew A. Miller" , cose Thread-Topic: [COSE] ? Call for Consensus: CounterSignature Discussion ? Thread-Index: AdZqe6FsIrW21PEBT+yqZnpSFD8cPQ== Date: Tue, 4 Aug 2020 16:23:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-04T16:23:23Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=c70a0d9c-f04b-4b32-9e1c-f90b7b59878b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: outer-planes.net; dkim=none (message not signed) header.d=none;outer-planes.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9d1f9a25-d1d3-4b60-5f1c-08d83892c545 x-ms-traffictypediagnostic: CH2PR00MB0711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J1Ep/xld6tyqOuB8NNPYhQcCoqwp5T/jkhnUW4VjhSbI+k/4jOqoKm6L6GWVselSYj/j2fBd372E8gSOifGxXIMkJL6/sljOdgzRUEUNjJvtCSfNlqm/7C5s1H/qMdrDi3k2CaAf9NFd7lg9tfl/KOgRmOBwJWmtj7XSykvqgeD0pm3FdXbNApOfJiWZcIR1JnUM73DTPpOict7qFBsZlioJsfI2D6jUfRqIc0O0fokDPctV8AexkAzLJgpdzowHYX/1TSCL1FY+2pjQVRDSvFowh0wyeg//Gc60qUlE/sgxAVdSpnlKD530/yiQ8I/3C6jJ08hRkW8c08H65hB8XcvK3hz8RIIpXeo6VbDw+IvQxydfQVi+HR3wJXNm874ApEiR+DJg9vYZtt1KJoN2+g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39860400002)(396003)(376002)(478600001)(966005)(10290500003)(2906002)(66446008)(76116006)(8990500004)(186003)(83380400001)(8936002)(66556008)(64756008)(66476007)(66946007)(55016002)(5660300002)(9686003)(26005)(52536014)(33656002)(6506007)(8676002)(53546011)(86362001)(316002)(7696005)(82950400001)(82960400001)(71200400001)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6oq190AmAYiI3ZRqLLckPksbHYPhEKXNoSIHJ66p1mn15/RouHh+uVpng5V6itYKp4CsNALF8WgdLZJQsn9TzhLMEgYcPKDJnvqtjzKs0LdaSakQX19DQfFYnbBu0znMYyNwgLicN8W+QBCF6k/3rIXqDRIP+k6smaI9PbHSIv3asulryh/c2sZpqCgKGmaFJeWc0I1xQ9ZTv3S1/sujRWH4okP6LJXc1RU7kH0Ygulrjqm+ocYynRm9YXHDzUZ3hKrxrFQSQZcQQVGCdhk9IuMxPVZW2/ZHWG4oXc5hkIBRdFaz3dOhIsb9fKFW//MfjiJqumcX0dgKCoHZrCE4oWTxkhQg7zAbYLeUc1Ebdw6XtboDmTvhdIstiJbh/3PBn/4+ay/ZGHsPvcV/VRwsRbVY4ZRw/Yt6i5c1Znu5MsF6tCGDmWLIrLuaQcHPFopHVgjNABGfluNaanAuBEWuyngdlLn1JOcRYoqv6TS2wMrUWWqtvp1OI+9khMpcDNNGXAbgwPk3AXRfSu2Wd/STfHZmfiGGXImI0K07uv5Gz0YBckITk+3sNvIi+xnDiyxPp/Hu/gAgA756cYSTkpGjZn8IaLEuGxWqCzLyK5WpxxEJJ2GthBup1LfcENJ3Qvm78k/ywicGf+HFXLnrSEn4Dg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1f9a25-d1d3-4b60-5f1c-08d83892c545 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 16:23:49.8276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xLjOTQXIRLipCTltptylhdx6tuAuivPjkC47MvMhr3MgPJw04f9KzlNmSKx+QYjktgPZPB3CA+663hloIEUX6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0711 Archived-At: Subject: Re: [COSE] ? Call for Consensus: CounterSignature Discussion ? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 16:27:27 -0000 I agree with this approach. -- Mike -----Original Message----- From: COSE On Behalf Of Matthew A. Miller Sent: Tuesday, August 4, 2020 8:29 AM To: cose Subject: [COSE] ? Call for Consensus: CounterSignature Discussion ? This message is to confirm consensus to deprecate the current CounterSignat= ure feature and replace it with one that best accounts for all COSE message= types. At the synchronous WG meeting on July 29, the issue with countersignatures = was heavily discussed. In summary, the currently-defined CounterSignature = mechanism is not processed with the cryptographic content for certain COSE = message types. The consensus from the meeting is to mark the current Count= erSignature process and structure deprecated in rfc8152bis and define a new= one that properly accounts for the cryptographic. Further consensus leane= d toward an aggressive approach, incorporating all bstr elements in the tar= get structure when computing the signature. To complete the new CounterSignature method, the sense in the meeting is to= have a series of virtual interims. The details of the new method and wher= e it fits as working group items is still to be determined. Jim Schaad pos= ted a starting proposal for a method[1], and an initial discussion on how t= o approach this as a working group item[2]. Given the participation in the meeting is very close to the participation o= n the list, we are only seeking objections. If you have objections, please= inform the list and why you object. A following message will propose time= s for interims, ideally starting this month (August). Thank you, - Ivaylo and Matthew COSE WG Chairs -- [1]: < https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/ > [2]: < https://mailarchive.ietf.org/arch/msg/cose/8Mxcnsq9sm_pXQAm-2bexKxpaMU/ > _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Tue Aug 4 14:16:08 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917253A10AA for ; Tue, 4 Aug 2020 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 LEDDXoEF3-le for ; Tue, 4 Aug 2020 14:16:04 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 5580B3A1096 for ; Tue, 4 Aug 2020 14:16:04 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id c80so3943041wme.0 for ; Tue, 04 Aug 2020 14:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FXB9GPD/bFhkV5WC7c4xuqRr2EbVqtOAJP6N6pgfcqk=; b=gGhL6/5+s7jZ7+8a/ZPPxr2eu+hvogLx9r4t9+LZeWVEHAQc+l2hMSQbpCGjsdOvpk jAIxVs04SdNuhszvoObEzaB+9DAJNbzFhabBVUwYNG38LUmaC+Dcnj/YuaCAiMjbEURq U1FU8y0iJOv5AxZK7mrHpaAN4jVIsd4xTEBdIXTryaSV7Sm+RwRMkymn1lKwSYSOlUiy OiyzaUlvqVbtd4ommHN4nncKc9g9ea7uH6e9Hvq6qiYHe730IEzyXza+T6YGyHrgXUqY d522N3SH68qtFWiW/A7anc1YzRx9fgc6OpMl/Hk+PqoXoa80jGAx82EaUxS+Xnji7Vh3 6MGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FXB9GPD/bFhkV5WC7c4xuqRr2EbVqtOAJP6N6pgfcqk=; b=ZrWTLakewZq/6C9Ska7pbORxaU+KkbT+YoW1C9ptPvvcSqtvZyrviO09as3zca9lr2 X/Lsyd85MrtoM16hddvr6BDCcANCilMb07u4Q7Pykdz3/ralds3nyUQo344ADVYXZUTq UwDdNe0lfw2+cqvF8zJDZemqvFslnhQwDTGu5r8aJADYdwlGGXfJntkC87OaLXAqeLNU JaOSLsLd9MmQbqZH6Mmf1upqqJ+HJy4THSx+QFoMsD408CdLSg5nJqRwgQBBH0MfhmD/ UsztomvWr1Qp6mQ/sghSQVTUksSFb3K82Y/HSt/PwM4E1AaOlSlhU0Vwdm3LR3Hl/szH jPZA== X-Gm-Message-State: AOAM533iqrKC3ok24atzfVXkD11BecNCPXs4baywxTKldpU4bkKl7nUN RR04MoAm8YxrbQ69kaOCVkZCSF+To8Yrz2YdaOGLvxBrja4= X-Google-Smtp-Source: ABdhPJwN2F9TQ4iasQs5NPPXXQ8DU255kGyNHh7ku6AOD+Eog0qLdgiK5zjDblp8o3Y+eUD+mVKBZELotQTZkSJexXE= X-Received: by 2002:a7b:c38a:: with SMTP id s10mr319663wmj.13.1596575762100; Tue, 04 Aug 2020 14:16:02 -0700 (PDT) MIME-Version: 1.0 From: Ivaylo Petrov Date: Tue, 4 Aug 2020 23:15:36 +0200 Message-ID: To: cose Content-Type: multipart/alternative; boundary="0000000000002849b505ac13c3a6" Archived-At: Subject: [COSE] =?utf-8?q?Interim_Proposed_Time_=F0=9F=93=85?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 21:16:07 -0000 --0000000000002849b505ac13c3a6 Content-Type: text/plain; charset="UTF-8" Dear all, As already mentioned [1], we believe the working group will need a number of interims, in order to better advance its work that includes at least the CounterSignature issue and the rechartering. Currently we consider that we will need at least 3 interops of 1 hour for that purpose. After taking into account other working group interims that could conflict with ours and the timezones of some of the key participants, we propose our interims to be held every two weeks starting on Wed 26 August. Our suggestion for starting time is 16:00 UTC [2]. We will be expecting any feedback on the scheduling by 9 August, in order to be able to respect the two weeks notice period before requesting the interim. Thank you, - Matthew and Ivaylo COSE WG Chairs [1]: https://mailarchive.ietf.org/arch/msg/cose/wNvQP3icGYMShhkOO4VwiJB6634/ [2]: https://www.timeanddate.com/worldclock/fixedtime.html?msg=COSE+interim&iso=20200826T16&p1=1440&ah=1 --0000000000002849b505ac13c3a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

As alr= eady mentioned [1], we believe the=C2=A0working group will need a number of= interims, in order to better advance its work that includes at least the= =C2=A0CounterSignature=C2=A0issue and the rechartering. Currently we consid= er that we will need at least 3 interops of 1 hour for that purpose. After = taking into account other working group interims that=C2=A0could conflict w= ith ours and the timezones of some of the key participants, we propose our = interims to be held every two weeks starting on Wed 26 August. Our suggesti= on for starting time is 16:00 UTC [2]. We will be expecting any feedback on= the scheduling by 9 August, in order to be able to respect the two weeks n= otice period before requesting the interim.

Thank you,

- Matthew and Ivaylo
COSE WG Chairs

[1]:=C2=A0ht= tps://mailarchive.ietf.org/arch/msg/cose/wNvQP3icGYMShhkOO4VwiJB6634/
[2]:=C2=A0https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DCOSE+inte= rim&iso=3D20200826T16&p1=3D1440&ah=3D1
<= div dir=3D"ltr">
<= div style=3D"margin:8px 0px 0px;padding:0px">
--0000000000002849b505ac13c3a6-- From nobody Wed Aug 5 09:00:58 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68473A0BB0 for ; Wed, 5 Aug 2020 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 p47FNrKbvK65 for ; Wed, 5 Aug 2020 09:00:53 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84F73A0B4C for ; Wed, 5 Aug 2020 09:00:53 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id a24so19514402oia.6 for ; Wed, 05 Aug 2020 09:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=y7sX2UpNJnjSIIMC5Ys7W0/+djr6T8ukqs/P9fKNIOo=; b=swxh011gXrlnOpk+dOJx4fLH+70wRCpdSgKgWnl8BSg9MWGQnF0E0tb94KCWwupMl/ 41GIdcI6N+7rUGsQCOKs5qRQv5pYXG9oyxrLm9o/KdGuCF8RHWmYTOLkAykTTZn9UmFt 6tZQLw4BDSa0IQsWFDCIx/hI9qTBjOI9gfLttQxyKYrWtyrp6GT8+XU6aDKrFuNGcATf 0hdzY8Obxeyuk0wfWve5pR0SuVMqAkoPtfMGDqgLPqLgPWQPJKDgWsRJ/OZvgUt2UBlP ghiRSTk9gnOVJ9B0ibt8HGQWrvkhNyFCgv0Xo/B7IMGYX6dbccTWIPjiddVdAA1O68Go F+9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y7sX2UpNJnjSIIMC5Ys7W0/+djr6T8ukqs/P9fKNIOo=; b=Txugw4NhKug/a7nonStqJSYRIU5UinqDVt5fc3pTs7axkYidqLh7zmhwxq/UqtjcvX YwFpIAs0NoUnTQelKhbe1znMGSLnss42pxfMvU9yuy5bi2jj3NkBN+EI/hr8qjEeDwPQ eNPdNfRFB3NocroXKxev/2AqcGssmUYRZcncORBi2W/pjVi/jszizc0q4osBnK04a3lf qmhynO0lddCkuUdiia3q0aOe15CW89k+hg8+xW6BUJ8qppL8DkItM2KKhweHBIuOx/HQ l/L1Ejy43Ac9iNnS6u5ruzzwVF+keoOL+d0O9SiDhE+x3KSCXFHpUGgybFuLpm/3uorx QsMQ== X-Gm-Message-State: AOAM530veJd3ZaBamEFu27ZVXikKzjpvYT2vKru3ytUOLbqRDkJquU31 llfzDUbQotM1XXQNahCsERHnlNaaWVg= X-Google-Smtp-Source: ABdhPJwnD9O085xq0MTdY6jAr55hpkYbctFh+N3LkRxR4v2PgHCsP0Zy7mB1RiadpeTZ+LB6Hv05TQ== X-Received: by 2002:aca:5bc6:: with SMTP id p189mr3225945oib.130.1596643252520; Wed, 05 Aug 2020 09:00:52 -0700 (PDT) Received: from mmiller-44677.local (c-24-8-164-51.hsd1.co.comcast.net. [24.8.164.51]) by smtp.gmail.com with ESMTPSA id g139sm410770oib.8.2020.08.05.09.00.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 09:00:51 -0700 (PDT) To: cose References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: Date: Wed, 5 Aug 2020 10:00:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] Fwd: [108all] Final reminder: IETF 108 meeting survey X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:00:56 -0000 If you participated in last weeks festivities and have not filled out the meeting survey, please consider doing so. The survey is at: < https://www.surveymonkey.com/r/T3SL7JF > Thanks! - Ivaylo and Matthew COSE WG Chairs On 20/08/05 04:30, IETF Executive Director wrote: > Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: > > https://www.surveymonkey.com/r/T3SL7JF > > Thanks in advance > From nobody Mon Aug 10 13:25:21 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6693A0D89 for ; Mon, 10 Aug 2020 13:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs4q23rKRmjp for ; Mon, 10 Aug 2020 13:25:11 -0700 (PDT) Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0583A0D71 for ; Mon, 10 Aug 2020 13:25:10 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5EM1kceYbHQQg5EM1kJp7u; Mon, 10 Aug 2020 13:25:10 -0700 X-CMAE-Analysis: v=2.3 cv=dP7YZ9Rb c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=YaPx7vO5ZZfLwkmRaMsA:9 a=QEXdDO2ut3YA:10 a=Ohn9mvRcOn01qA0XQ9UA:9 a=5SGI_DtbSNQBuw0V:21 a=_W_S_7VecoQA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Mon, 10 Aug 2020 13:25:09 -0700 To: Ace Wg , cose X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfMEnjNlliq34F0w2tytYtZpaLar2xlehdEgnVxvdsr4GkH/ugD5kC0p5DiNHo9XmYqITjHeFDExJA+U5LJE9lbkMWKSdTLC5A+u+Oun+7bK2fVuKeWEv stG72/91N60xxOfRafk+4O7+b9AJ86RGsuw2HDBDi1lDaZhFVrWhysCgr8q+rwR16fsKrTrOHAbAxw== Archived-At: Subject: [COSE] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 20:25:19 -0000 --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It doesn=E2=80=99t seem clear what the CBOR tagging requirements are = when application/cwt is used to indicate a message is a CWT. This is the text that I think it missing: The CBOR CWT tag (61) must NOT be used. It is unnecessary because the = media type already indicates it is a CWT. The COSE type indicating tag MUST be present. It is necessary to = determine whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0... Another solution could be a MIME parameter added to the application/cwt = indicating the COSE type. Step 3 in section 7.2 also seems wrong. It doesn=E2=80=99t make it an = error for the COSE type tag to be absent when the CBOR CWT tag is = present. This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. LL= --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It doesn=E2=80=99t seem clear what the CBOR tagging = requirements are when application/cwt is used to indicate a message is a = CWT.

This is = the text that I think it missing:

The CBOR CWT tag (61) must NOT be used. = It is unnecessary because the media type already indicates it is a = CWT.

The COSE = type indicating tag MUST be present. It is necessary to determine = whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0...

Another solution could be a MIME parameter added to the = application/cwt indicating the COSE type.

Step 3 in section 7.2 also seems wrong. = It doesn=E2=80=99t make it an error for the COSE type tag to be absent = when the CBOR CWT tag is present.


This= is all based on my understanding that the surrounding protocol for must = specify exactly when CBOR tags are to be used and when they are not to = be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol.

LL
= --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17-- From nobody Mon Aug 10 17:49:29 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1813A0E6B; Mon, 10 Aug 2020 17:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjDb-nNbIqk4; Mon, 10 Aug 2020 17:49:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5623A0E6A; Mon, 10 Aug 2020 17:49:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Aug 2020 17:49:15 -0700 From: Jim Schaad To: 'Laurence Lundblade' , 'Ace Wg' , 'cose' References: In-Reply-To: Date: Mon, 10 Aug 2020 17:49:13 -0700 Message-ID: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01D66F3E.9139D430" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QKq9Z/LQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 00:49:24 -0000 ------=_NextPart_000_0043_01D66F3E.9139D430 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: COSE On Behalf Of Laurence Lundblade Sent: Monday, August 10, 2020 1:25 PM To: Ace Wg ; cose Subject: [COSE] Gap in registration of application/cwt? =20 It doesn=E2=80=99t seem clear what the CBOR tagging requirements are = when application/cwt is used to indicate a message is a CWT. =20 This is the text that I think it missing: =20 The CBOR CWT tag (61) must NOT be used. It is unnecessary because the = media type already indicates it is a CWT. =20 The COSE type indicating tag MUST be present. It is necessary to = determine whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0... =20 Another solution could be a MIME parameter added to the application/cwt = indicating the COSE type. =20 [JLS] Yes that would have been an alternative that would work =E2=80=93 = However this option would require either that you use text content types = for CoAP or you allocate N different integer content types one for each = possible set of options that could be placed there. The current = solution is cleaner and smaller. =20 Step 3 in section 7.2 also seems wrong. It doesn=E2=80=99t make it an = error for the COSE type tag to be absent when the CBOR CWT tag is = present. =20 =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Jim =20 =20 LL ------=_NextPart_000_0043_01D66F3E.9139D430 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: COSE = <cose-bounces@ietf.org> On Behalf Of Laurence = Lundblade
Sent: Monday, August 10, 2020 1:25 PM
To: = Ace Wg <ace@ietf.org>; cose = <cose@ietf.org>
Subject: [COSE] Gap in registration of = application/cwt?

 

It = doesn=E2=80=99t seem clear what the CBOR tagging requirements are when = application/cwt is used to indicate a message is a = CWT.

 

This is the text that I think it = missing:

 

The CBOR CWT tag (61) must NOT be used. It is = unnecessary because the media type already indicates it is a = CWT.

 

The COSE type indicating tag MUST be present. It is = necessary to determine whether what the COSE type is, whether it is = COSE_Sign1, COSE_Mac0...

 

Another solution could be a MIME parameter added to = the application/cwt indicating the COSE type.

 

[JLS] Yes = that would have been an alternative that would work =E2=80=93 However = this option would require either that you use text content types for = CoAP or you allocate N different integer content types one for each = possible set of options that could be placed there.=C2=A0 The current = solution is cleaner and smaller.

 

Step 3 in section 7.2 also seems wrong. It = doesn=E2=80=99t make it an error for the COSE type tag to be absent when = the CBOR CWT tag is present.

 

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.

 

[JLS] What = is the text that says that this is true.=C2=A0 This would be a = surprising statement for me.

 

Jim

 

 

LL

------=_NextPart_000_0043_01D66F3E.9139D430-- From nobody Tue Aug 11 08:21:22 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1247E3A1106; Tue, 11 Aug 2020 08:21:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159715927795.29591.11471198639931991608@ietfa.amsl.com> Date: Tue, 11 Aug 2020 08:21:18 -0700 Archived-At: Subject: [COSE] CBOR Object Signing and Encryption (cose) WG Virtual Meeting: 2020-08-26 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:21:18 -0000 The CBOR Object Signing and Encryption (cose) WG will hold a virtual interim meeting on 2020-08-26 from 16:00 to 17:00 UTC. Agenda: Discuss solution to CounterSignature Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5528e10375ba600e61b9133f1f8bcfa7 Meeting number: 171 745 9639; Password: 6YZbzJ9U6d9 From nobody Tue Aug 11 08:21:48 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B3C3A1135; Tue, 11 Aug 2020 08:21:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159715929432.17315.17243079493922089315@ietfa.amsl.com> Date: Tue, 11 Aug 2020 08:21:34 -0700 Archived-At: Subject: [COSE] CBOR Object Signing and Encryption (cose) WG Virtual Meeting: 2020-09-09 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:21:41 -0000 The CBOR Object Signing and Encryption (cose) WG will hold a virtual interim meeting on 2020-09-09 from 16:00 to 17:00 UTC. Agenda: Discuss solution to CounterSignature Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5528e10375ba600e61b9133f1f8bcfa7 Meeting number: 171 745 9639; Password: 6YZbzJ9U6d9 From nobody Tue Aug 11 08:23:29 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8703A11C3; Tue, 11 Aug 2020 08:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159715940054.28832.18388275778935257606@ietfa.amsl.com> Date: Tue, 11 Aug 2020 08:23:20 -0700 Archived-At: Subject: [COSE] CBOR Object Signing and Encryption (cose) WG Virtual Meeting: 2020-09-23 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:23:25 -0000 The CBOR Object Signing and Encryption (cose) WG will hold a virtual interim meeting on 2020-09-23 from 16:00 to 17:00 UTC. Agenda: Discuss solution to CounterSignature Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5528e10375ba600e61b9133f1f8bcfa7 Meeting number: 171 745 9639; Password: 6YZbzJ9U6d9 From nobody Tue Aug 11 12:20:47 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819F63A0ACF for ; Tue, 11 Aug 2020 12:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HBbFoeMB_7Dz for ; Tue, 11 Aug 2020 12:20:40 -0700 (PDT) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (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 ADE693A0B2C for ; Tue, 11 Aug 2020 12:20:40 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5Zp9kW9axC7Kr5Zp9kZAIG; Tue, 11 Aug 2020 12:20:40 -0700 X-CMAE-Analysis: v=2.3 cv=Sb+JicZu c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=k7AfbbVJMtS5I1zSK-4A:9 a=JUj9kErCxBmwy0pV:21 a=0N83j4SsBfmt8v5G:21 a=QEXdDO2ut3YA:10 a=2w5PlCjTHkOfpIql5PAA:9 a=HQB38gyGZK4FBqPh:21 a=ehssqexYlHdPNOzM:21 a=wiBMwEmpoH3A3d4k:21 a=_W_S_7VecoQA:10 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Aug 2020 12:20:39 -0700 In-Reply-To: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfAYh/vY/OAh6QjrvQzjClzZF8gBU1gNiMhkLL/e+nyf25WkYIKAIqz3Eywx04009u1MADI+SnRSXo6JWTd1fVDBgvw8A/mVBYOv8HaQMm1iNmEE3raLy 98EGCxdqeBM7M0qpda1MR0RYEIHNN4NDy54/H5CszDZnEc2FHga2YmhyW3wGeJtKGQv7r5gu9sqdWEjDPL6cOWvskz8suG3IMbEE1AGGE6W/GZ31kZ0knhWB Archived-At: Subject: Re: [COSE] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 19:20:44 -0000 --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2020, at 5:49 PM, Jim Schaad = wrote: >=20 > This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. > =20 > [JLS] What is the text that says that this is true. This would be a = surprising statement for me. Here=E2=80=99s three things that lead me to this. CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 Email threads This thread = and this thread = . I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. It has some disadvantage because it introduces error conditions and = potential confusion. I think there are several scenarios with section 6 and application/cwt = that could be more clear. Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? LL= --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

Here=E2=80= =99s three things that lead me to this.

CBORbis
The sentence of the first = paragraph in 4.2.2 very clearly states this, though this is = only for deterministic encoding.

Typical = CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 

Email = threads
This thread and this thread.

I summarized this = behavior in this email and no where in the rest of the thread = was it indicated differently.

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a =E2=80=9Cshould= " in spirit. It is the preferred way to design a CBOR protocol.

However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.

Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged = CoSWID).

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

It has some disadvantage because it = introduces error conditions and potential confusion.

I think there are = several scenarios with section 6 and application/cwt that could be more = clear.

Can you use tag 61 or not? I think the current answer is that = in application/cwt, tag 61 is optional.

How do you know what the COSE type is? = It is somewhat obvious that COSE tags will work, but there is no = requirement to use them. A MIME parameter or other is entirely allowed = here.

Section = 6 does say that determination that something is a CWT is application = dependent, but doesn=E2=80=99t say that the COSE type is also = application dependent. Section 7 does address = this.

Said another way, my fully general CWT decoder that is called = by some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined.

I think it would have been cleanest if = CWT always indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?

LL
= --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747-- From nobody Fri Aug 14 13:59:06 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74D3A0658 for ; Fri, 14 Aug 2020 13:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 mVHi9MZmkJhb for ; Fri, 14 Aug 2020 13:58:47 -0700 (PDT) Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (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 A0BB23A08D1 for ; Fri, 14 Aug 2020 13:58:45 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 6gmikrwMSeip66gmjkFNJw; Fri, 14 Aug 2020 13:58:45 -0700 X-CMAE-Analysis: v=2.3 cv=b5LMHeOx c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=K6EGIJCdAAAA:8 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=PXcJJhn042mYNjhRpNEA:9 a=ooK1ZYYnHGwGP9pd:21 a=8S_NYmHccqdHhq-g:21 a=QEXdDO2ut3YA:10 a=ehQ0wd4UoleRMcFXBYsA:9 a=anr6qqSgD_S8I-ad:21 a=5s7gydGq379n2PzS:21 a=20_1RYVDE6hz34o0:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Aug 2020 13:58:43 -0700 In-Reply-To: Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfPCOW6soSC8d5JmY4vX4PHwXnZDR5VFHxrAdywRTaLWR5bO+Gd9+afHtO5ZFsGu2MJleX1qptlmpyiKE5fU5rN0smIRXD7tNqINCujdruwnPLvTGCTcc fFJCF19S8iFbhAmHVfVpswfxBwxqa38MbM+Owsu2VQB21yJv/AWsvfMimON2NzlmXl7AjEa3S0xvFyCHejAMwqRqnvPU/78NRfvmkK3Ke9/o8z1DsMeFkMZj Archived-At: Subject: Re: [COSE] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 20:58:54 -0000 --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. LL > On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = wrote: >=20 >=20 >=20 >> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>=20 >> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >> =20 >> [JLS] What is the text that says that this is true. This would be a = surprising statement for me. >=20 > Here=E2=80=99s three things that lead me to this. >=20 > CBORbis > The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >=20 > Typical CDDL > Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >=20 > Email threads > This thread = and this thread = . >=20 > I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >=20 > So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >=20 > However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >=20 > Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). >=20 > I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >=20 > It has some disadvantage because it introduces error conditions and = potential confusion. >=20 > I think there are several scenarios with section 6 and application/cwt = that could be more clear. >=20 > Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >=20 > How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >=20 > Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >=20 > Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. >=20 > I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >=20 > LL --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s a series of scenarios that I think are legal = CWT. These are allowed by RFC 8392, right?

1) Explicitly tagged, no external type = info needed
- Has CWT tag
- = Has COSE type tag

2) CWT identification by label, COSE type tagged
- The CWT is a CBOR data item with a label. The definition of = the label says the contents of the label are always CWT
- No CWT tag necessary as it is implied by the = label
- Has a COSE type tag

3) CWT and COSE by label
- The CWT is an item with a label. The definition of the = label says the contents of the label are always CWT and of a specific = COSE type
- No tags necessary

4) Application/CWT = identifies content as CWT, tagging for COSE type
- = No CWT tag
- Has a COSE tag

5) Application/CWT = identifies content as CWT
- Has CWT tag even though = it is redundant 
- Has a COSE = tag

6) = Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags are used
- Identification is = completely by the MIME type header
- (I understand = that the cose-type MIME parameter is not defined, but it could be. 8392 = doesn=E2=80=99t forbid it)

7) A protocol like FIDO identifies a protocol element that is = an attention type the type of which is CWT with COSE_Sign1
- No tags are used

8) A protocol like FIDO = identifies a protocol element that is an attention type the type of = which is CWT; the COSE type is determined by tag
- = No CWT tag
- Has a COSE tag

The one thing you = can=E2=80=99t do is have a CWT tag without a COSE type tag. 8392 section = 6 forbids this.

LL





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade <lgl@island-resort.com> wrote:



On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

Here=E2=80= =99s three things that lead me to this.

CBORbis
The sentence of the first = paragraph in 4.2.2 very clearly states this, though this is = only for deterministic encoding.

Typical = CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 

Email = threads
This thread and this thread.

I summarized this = behavior in this email and no where in the rest of the thread = was it indicated differently.

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a =E2=80=9Cshould= " in spirit. It is the preferred way to design a CBOR protocol.

However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.

Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged = CoSWID).

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

It has some disadvantage because it = introduces error conditions and potential confusion.

I think there are = several scenarios with section 6 and application/cwt that could be more = clear.

Can you use tag 61 or not? I think the current answer is that = in application/cwt, tag 61 is optional.

How do you know what the COSE type is? = It is somewhat obvious that COSE tags will work, but there is no = requirement to use them. A MIME parameter or other is entirely allowed = here.

Section = 6 does say that determination that something is a CWT is application = dependent, but doesn=E2=80=99t say that the COSE type is also = application dependent. Section 7 does address = this.

Said another way, my fully general CWT decoder that is called = by some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined.

I think it would have been cleanest if = CWT always indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?

LL

= --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF-- From nobody Fri Aug 14 15:35:20 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE53A0433; Fri, 14 Aug 2020 15:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyI05NOwlooe; Fri, 14 Aug 2020 15:35:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D33A041B; Fri, 14 Aug 2020 15:35:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Aug 2020 15:35:02 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Ace Wg' , 'cose' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> In-Reply-To: <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> Date: Fri, 14 Aug 2020 15:35:01 -0700 Message-ID: <00af01d6728b$27579480$7606bd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D67250.7AFB0670" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowKqQ0fmg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 22:35:14 -0000 ------=_NextPart_000_00B0_01D67250.7AFB0670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad Cc: Ace Wg ; cose Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 ------=_NextPart_000_00B0_01D67250.7AFB0670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Ace Wg = <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: = [COSE] Gap in registration of = application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

1) Explicitly tagged, no external type info = needed

- Has CWT = tag

- Has COSE type = tag

[JLS] = Yes

 

2) CWT identification by label, COSE type = tagged

- The CWT is a CBOR = data item with a label. The definition of the label says the contents of = the label are always CWT

- = No CWT tag necessary as it is implied by the = label

- Has a COSE type = tag

[JLS] Yes, the label could be = internal to the CBOR object or external such as an = media-type

 

3) CWT and COSE by label

- The CWT is an item with a label. The definition of = the label says the contents of the label are always CWT and of a = specific COSE type

- No = tags necessary

[JLS] Yes that would = be fine

 

4) Application/CWT identifies content as CWT, tagging = for COSE type

- No CWT = tag

- Has a COSE = tag

[JLS] This is the same as = 2?=C2=A0 I don=E2=80=99t think that it would be restricted to just that = media type.

 

5) Application/CWT identifies content as = CWT

- Has CWT tag even = though it is redundant 

- Has a COSE tag

[JLS] Yes

 

6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or = =E2=80=A6)

- No tags are = used

- Identification is = completely by the MIME type header

- (I understand that the cose-type MIME parameter is = not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)

[JLS] Yes you could do that, and = as I stated in a previous mail this is not a good idea for the CoAP = world.

 

7) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT with = COSE_Sign1

- No tags are = used

[JLS] = yes

 

8) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT; the COSE type is = determined by tag

- No CWT = tag

- Has a COSE = tag

[JLS] = yes

 

The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids this.

 

[JLS] There = however is a set of nested cases that you might need to look at.=C2=A0 = That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))=C2=A0 You would also = need to think about the requirements for nested COSE = layers.

 

Jim

 

 

LL

 

 

 

 



On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 



On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.

 

[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only for = deterministic encoding.

 

Typical CDDL

Most CDDL that describes tagged data describes it only = as tagged or untagged, not as optionally tagged.  COSE is one = example of this. 

 

Email threads

 

I = summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only = for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR = protocol.

 

However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally required.

 

Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).

 

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

 

It has some disadvantage because it introduces error = conditions and potential confusion.

 

I = think there are several scenarios with section 6 and application/cwt = that could be more clear.

 

Can you use tag 61 or not? I think the current answer = is that in application/cwt, tag 61 is = optional.

 

How do you know what the COSE type is? It is somewhat = obvious that COSE tags will work, but there is no requirement to use = them. A MIME parameter or other is entirely allowed = here.

 

Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

Said another way, my fully general CWT decoder that is = called by some application needs an input parameter to indicate the COSE = type because there is no requirement in 8392 that a CWT indicate which = COSE type is in use. Sometimes the caller will be able to provide the = COSE type and sometimes they won=E2=80=99t. Sometimes there will be an = error of conflicting COSE type and sometimes the error will be that the = COSE type can=E2=80=99t be determined.

 

I = think it would have been cleanest if CWT always indicated the COSE type = be used and the tagging optionality didn=E2=80=99t span two protocol = layers, but that would be an incompatible change.  Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type?

 

LL

<= p class=3DMsoNormal> 

------=_NextPart_000_00B0_01D67250.7AFB0670-- From nobody Fri Aug 14 16:39:41 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9034B3A0FC2; Fri, 14 Aug 2020 16:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 12vEwKv09l5G; Fri, 14 Aug 2020 16:39:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E2E3A0B21; Fri, 14 Aug 2020 16:39:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 40F10F40758; Fri, 14 Aug 2020 16:39:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, cose@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200814233925.40F10F40758@rfc-editor.org> Date: Fri, 14 Aug 2020 16:39:25 -0700 (PDT) Archived-At: Subject: [COSE] =?utf-8?q?RFC_8812_on_CBOR_Object_Signing_and_Encryption_?= =?utf-8?q?=28COSE=29_and_JSON_Object_Signing_and_Encryption_=28JOSE=29_Re?= =?utf-8?q?gistrations_for_Web_Authentication_=28WebAuthn=29_Algorithms?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 23:39:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8812 Title: CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms Author: M. Jones Status: Standards Track Stream: IETF Date: August 2020 Mailbox: mbj@microsoft.com Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-cose-webauthn-algorithms-08.txt URL: https://www.rfc-editor.org/info/rfc8812 DOI: 10.17487/RFC8812 The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. This document is a product of the CBOR Object Signing and Encryption Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Aug 14 16:59:00 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3370F3A0E17 for ; Fri, 14 Aug 2020 16:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 VViIEiFm-vJe for ; Fri, 14 Aug 2020 16:58:57 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650118.outbound.protection.outlook.com [40.107.65.118]) (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 7283D3A0B0C for ; Fri, 14 Aug 2020 16:58:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RnRwocVqK8FPUvsCfzwS9A/yTzadxQ+7yzlQUZxHEimKLcPYR05+ZFtEEpNxW5N/Wzx4meZRutsVFOcWeSNb0zz04OfA+hkXqxX7VtDFvmKYJJEIBzJVYkVXd/xUvqMM8o52t1NECjbivbTGyRNApzACky/qDim/NgXyqB69U6p4onh6+POJkwI6FwnpuJ48I521F7Xq+Z+RpKGZ3Eolc5waqu+ubPYaEdGsbKvvvGRytX4OQqlH3OkWTGto4y/6rPzG9Q+AGPsEJDFYUJNR0VaqcRY7qRLXhrX457nx249stPe5RLoWltmieZGTR4cg0OtVgMUZn1S4+7prxsrP5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bWVMyGPY9QRzE7do0J/vkjqhgSI4AvcIMySjg8ORlfM=; b=YYuPLyG6BiXUep/pHikJqiywuxu7nyoC1xqL24soukp4yWtvhdrvULIJdC2tVz4xuNaQMaSjbFhiZ6C2rF4rY6ARe10dhr7IfB4veS0/GI20bzeE4Pgb/lynFqK1OoWrxdAJBB1I6PxQIhGROuBZnpIf0PuMqY4lzYrjA5MTB9JU8lVIS4LLn4I/1JlDU7edL03kqTvbe0oiI31N0Zx2MLdCnyrdTDnIaBhzJRBcUZlvY0l+YhuxJi33oXTRrgk6QXBlsqZt/jBy8A4aUsB/eTkTvqPRy/1jAiPMMx1D8RyIEO1J/h7pEg8qmhoIsErdW0AzWm6AgbSqVTfZ5zFqig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bWVMyGPY9QRzE7do0J/vkjqhgSI4AvcIMySjg8ORlfM=; b=E1li55i36F0YwkSGCslfpGilyIA4JEna1bqz7zHKN3xjk3HASMAgZYxmEZK1RLimvjymj91FuK5+B6Z/rXYS3ePR1PMVoSaxUxbXvVbKH4hvkPPnrHPEo1emRdZZPWT6T2ZILlzFkmHoaBdddAUZwCap6DlwHJLzpHEiNCeFoxU= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0306.namprd00.prod.outlook.com (2603:10b6:207:1e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3331.0; Fri, 14 Aug 2020 23:58:50 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::21a7:c5f5:46ed:7417]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::21a7:c5f5:46ed:7417%6]) with mapi id 15.20.3331.000; Fri, 14 Aug 2020 23:58:50 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: COSE and JOSE Registrations for Web Authentication (WebAuthn) Algorithms is now RFC 8812 Thread-Index: AdZyh4BSl9LFZSggTm2iUuoSlKK0twADz8zQ Date: Fri, 14 Aug 2020 23:58:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-14T22:07:31Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d224b4ea-ca75-429e-9a16-aef48716560a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9ae65acd-080a-476a-0d8e-08d840adfdaa x-ms-traffictypediagnostic: BL0PR00MB0306: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ABKWys9DnJ+2sezc6IBIyKmfQ+quKmvxSst9KjZIMO/KqOV5WBTkCtPSZwQ9qC7cPuLVpsVm4k5OiRKE/Gn5EiY5N3CTIrDEc+89amawfmnD+tiitQ1n7xjosDlnw2GhQL2p/omYx18E8VWA5GnA8D9v4X1oojRrst8wrbyqnByUrN7Wqs1tpLl9YNN+ru5kLfTPrNEd5n7Vcr8tn+pQBApUs/jBUWuu//x9iiS9dv2hDkknjBD6TNstr4nc0A+q4LPwTZLNXGn9o5Ffqm9vm7CkpuriB+B5EturPZRHtUeQ9P+Tl9+QVdLQjPq8kFl5ZjgW2jTZCAw1YWH/CeH+7EDo0lb882A9icsg87CNY202+vYtd1HsspLv/oqidfkal4gPdVmxWcy/4F6Rec6DddAUBK52yr2rKxRUQshatJFVzSQGD5xgZ5lR0SNSvSBSAoy299jOb0mgiDCkywOPUg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(376002)(396003)(346002)(6916009)(6506007)(2940100002)(53546011)(966005)(10290500003)(316002)(82960400001)(166002)(82950400001)(8936002)(86362001)(66946007)(66476007)(66556008)(64756008)(76116006)(5660300002)(26005)(52536014)(8676002)(66446008)(55016002)(9686003)(71200400001)(478600001)(186003)(2906002)(33656002)(66574015)(7696005)(8990500004)(83380400001)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: QTDmkgypeZOrXGEdTYIgKy7JmDQYysW2VV4lN+acywFPJRE7a1z+4sFlWKLKGiWf+V2UY9lZv7WETuV8YQvv8TRjClWZcqhp25Di7wOGKnBpY1DnCPw76gXQcY/0uGyyJIEBP0UfHDOpelnPXJNNMSgr/pjsnVGCGEgC1nkFEYrslKJt7+41FjOr+nw/fd40CBtel+XOBYxg5RCQKoSQSKWjeESZvjzvi5z/z5ee8rmdzODH0bIauyn0N4o9iN38XevnKu/034nOt88lSCRfdjxu5qaAX5lluy/KuL2wQegov/mUM4JXyvwnm6f/NDWltiqVZYmu3Lcc+TGoBk36IHBguqUNd4rDo/MhxPHOuC0UwnMdr8ebhoWetyG+xtaTx7vR6c4DSD/hlQ+lsr3N+nVTj06uL5qNrx0fuwZrXLe6Nv8nJmou7bePuAk08fcquHk3ErxHL8BSvrnZuDkN6JtqhmhjWWbs5SMINz77WCHWc2Jdy8IJkKmiJV6Vdw+yd62E2vFYFfImHZyW+L8LbNUi/auqnpV5hoeLcUYEYVQavfGrYkXugGYWKPzTz9z3EJkOMlkoHLADjXSrR89J2Le1rApqpcVzUF5KpNYYZml9H+5x6p3g8Pk9u+c3GU//fTDwkNxYYnHKkajNjElxVA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688C5054F1D93274F97017BF5401MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ae65acd-080a-476a-0d8e-08d840adfdaa X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 23:58:50.0532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dUlg9Svp/dzTxP9MENCz/1qq1d1jjJYTgOVGzv/lHtP5ehkwr4F9Nn+3prQ6fiuSgGSy3y8WfOkhAymrnsApdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0306 Archived-At: Subject: [COSE] FW: COSE and JOSE Registrations for Web Authentication (WebAuthn) Algorithms is now RFC 8812 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 23:58:59 -0000 --_000_MN2PR00MB0688C5054F1D93274F97017BF5401MN2PR00MB0688namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again to the working group for supporting this work! -- Mike From: Mike Jones Sent: Friday, August 14, 2020 4:58 PM To: public-webauthn@w3.org Subject: COSE and JOSE Registrations for Web Authentication (WebAuthn) Algo= rithms is now RFC 8812 The W3C Web Authentication (WebAuthn) working group and the IETF COSE working group created "CBOR Object Signing and Encryption (COSE) and JSON Object= Signing and Encryption (JOSE) Registrations for Web Authentication (WebAut= hn) Algorithms" to make some algorithms and elliptic curves used by WebAuth= n and FIDO2 officially part of COSE and JOSE. The RSA algorithms are used = by TPMs. The "secp256k1" curve registered (a.k.a., the Bitcoin curve) is a= lso used in some decentralized identity applications. The completed specif= ication has now been published as RFC 8812. As described when the registrations recently occurred, the algorithms registered are: * RS256 - RSASSA-PKCS1-v1_5 using SHA-256 - new for COSE * RS384 - RSASSA-PKCS1-v1_5 using SHA-384 - new for COSE * RS512 - RSASSA-PKCS1-v1_5 using SHA-512 - new for COSE * RS1 - RSASSA-PKCS1-v1_5 using SHA-1 - new for COSE * ES256K - ECDSA using secp256k1 curve and SHA-256 - new for COSE and= JOSE The elliptic curves registered are: * secp256k1 - SECG secp256k1 curve - new for COSE and JOSE See them in the IANA COSE Registry and the IANA JOSE Registry. -- Mike P.S. This notice was also published as https://self-issued.info/?p=3D2119 = and as @selfissued. --_000_MN2PR00MB0688C5054F1D93274F97017BF5401MN2PR00MB0688namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again to the wo= rking group for supporting this work!

 

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

 

From: Mike Jones
Sent: Friday, August 14, 2020 4:58 PM
To: public-webauthn@w3.org
Subject: COSE and JOSE Registrations for Web Authentication (WebAuth= n) Algorithms is now RFC 8812

 

The W3C Web= Authentication (WebAuthn) working group and the IETF COSE working g= roup created “CBOR Object Signing and Encryption (COSE) and JS= ON Object Signing and Encryption (JOSE) Registrations for Web Authenticatio= n (WebAuthn) Algorithms” to make some algorithms and elliptic curves used by WebAuthn and FIDO2 officially part = of COSE and JOSE.  The RSA algorithms are used by TPMs.  The R= 20;secp256k1” curve registered (a.k.a., the Bitcoin curve) is also us= ed in some decentralized identity applications.  The completed specification has now been published as RFC 8812.

 

As de= scribed when the registrations recently occurred, the algorithms regist= ered are:

  • RS256<= /span> – RSASSA-PKCS1-v1_5 using SHA= -256 – new for COSE
=
·       RS384 – RSASSA-PKCS1-v=
1_5 using SHA-384 – new for COSE
=
·       RS512 – RSASSA-PKCS1-v=
1_5 using SHA-512 – new for COSE
=
·       RS1 – RSASSA-PKCS1-v1_=
5 using SHA-1 – new for COSE
=
·       ES256K – ECDSA using s=
ecp256k1 curve and SHA-256 – new for COSE and JOSE<=
/pre>

 


The elliptic curves registered are:


=
·       secp256k1 – SECG secp2=
56k1 curve – new for COSE and JOSE


 


See them in the 
IANA COSE Registry and the 
IANA JOSE Registry.


 


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


 


P.S.  This notice was also published as 
https://self-issued.info/?p=3D2119 and as 
@selfissued.


 
--_000_MN2PR00MB0688C5054F1D93274F97017BF5401MN2PR00MB0688namp_-- From nobody Sat Aug 15 10:58:32 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595F33A08A3 for ; Sat, 15 Aug 2020 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 b-dtnvF04G-r for ; Sat, 15 Aug 2020 10:58:25 -0700 (PDT) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (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 727A63A08A2 for ; Sat, 15 Aug 2020 10:58:25 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 70RkkF98s5Zij70RkkXsxV; Sat, 15 Aug 2020 10:58:24 -0700 X-CMAE-Analysis: v=2.3 cv=XP9OtjpE c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=VrHXGImtAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=bFzclpeIq9MwBgp7VhUA:9 a=8I6_VEMliVAvdM0K:21 a=48s_paRzSZvxVOPN:21 a=QEXdDO2ut3YA:10 a=eypa8oWK2F2CkhvW-8UA:9 a=X3EDfnADaIYM8snQ:21 a=N1mhsGAlisfas1Wx:21 a=LB8P8dvH4siyT6m8:21 a=_W_S_7VecoQA:10 a=rjybpTLx1R2UrS7S5igv:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 15 Aug 2020 10:58:23 -0700 In-Reply-To: <00af01d6728b$27579480$7606bd80$@augustcellars.com> Cc: cose , Ace Wg To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfGxnkWHM0/BE/KxSnQg95LVNYBQvUmtTbHAgCNZvaAf4MtSLk+5SpkrhWAahs47BKs8xeWBbq3e7P58f62bPbu6rW6nknh4j5s0pL784XEOKPqVexQqz JvX26buXs4x+2WMp9QbJMYqi3VYFFshgSUExOy71r6INHMJbzA0FBaXHfXAEdWnDWXNA5jnId0Y7fN5nue2trIyUZMhPLLedeB/LVKaYMd2QTyIMNg9L7oOk Archived-At: Subject: Re: [COSE] [Ace] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 17:58:27 -0000 --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 14, 2020, at 3:35 PM, Jim Schaad = wrote: >=20 > =20 > =20 > From: Laurence Lundblade >=20 > Sent: Friday, August 14, 2020 1:59 PM > To: Jim Schaad > > Cc: Ace Wg >; cose > > Subject: Re: [COSE] Gap in registration of application/cwt? > =20 > Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? > =20 > 1) Explicitly tagged, no external type info needed > - Has CWT tag > - Has COSE type tag > [JLS] Yes > =20 > 2) CWT identification by label, COSE type tagged > - The CWT is a CBOR data item with a label. The definition of the = label says the contents of the label are always CWT > - No CWT tag necessary as it is implied by the label > - Has a COSE type tag > [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. > =20 > 3) CWT and COSE by label > - The CWT is an item with a label. The definition of the label says = the contents of the label are always CWT and of a specific COSE type > - No tags necessary > [JLS] Yes that would be fine > =20 > 4) Application/CWT identifies content as CWT, tagging for COSE type > - No CWT tag > - Has a COSE tag > [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. You mean there could be other media types that also identify the content = as CWT? > =20 > 5) Application/CWT identifies content as CWT > - Has CWT tag even though it is redundant=20 > - Has a COSE tag > [JLS] Yes Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. > =20 > 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) > - No tags are used > - Identification is completely by the MIME type header > - (I understand that the cose-type MIME parameter is not defined, but = it could be. 8392 doesn=E2=80=99t forbid it) > [JLS] Yes you could do that, and as I stated in a previous mail this = is not a good idea for the CoAP world. > =20 > 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 > - No tags are used > [JLS] yes > =20 > 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag > - No CWT tag > - Has a COSE tag > [JLS] yes > =20 > The one thing you can=E2=80=99t do is have a CWT tag without a COSE = type tag. 8392 section 6 forbids this. > =20 > [JLS] There however is a set of nested cases that you might need to = look at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would = also need to think about the requirements for nested COSE layers. All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? LL > =20 > Jim > =20 > =20 > LL > =20 > =20 > =20 > =20 >=20 >=20 >> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = > wrote: >> =20 >> =20 >>=20 >>=20 >>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>> =20 >>> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >>> =20 >>> [JLS] What is the text that says that this is true. This would be a = surprising statement for me. >>=20 >> =20 >> Here=E2=80=99s three things that lead me to this. >> =20 >>> CBORbis >>> The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >>> =20 >>> Typical CDDL >>> Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >>> =20 >>> Email threads >>> This thread = and this thread = . >>> =20 >>> I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >>> =20 >> So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >> =20 >> However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >> =20 >> Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). >> =20 >> I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >> =20 >> It has some disadvantage because it introduces error conditions and = potential confusion. >> =20 >> I think there are several scenarios with section 6 and = application/cwt that could be more clear. >> =20 >>> Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >>> =20 >>> How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >>> =20 >>> Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >> =20 >> Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. >> =20 >> I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >> =20 >> LL >=20 > =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> wrote:

 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?
 
Here=E2=80=99= s a series of scenarios that I think are legal CWT. These are allowed by = RFC 8392, right?
 
1) Explicitly tagged, no external type = info needed
- Has CWT tag
- Has = COSE type tag
[JLS] = Yes
 
2) = CWT identification by label, COSE type tagged
- The CWT = is a CBOR data item with a label. The definition of the label says the = contents of the label are always CWT
- No CWT tag necessary as it is implied = by the label
- Has a COSE type tag
[JLS] Yes, the label could = be internal to the CBOR object or external such as an = media-type

I was being very specific with the term label, = meaning a label/key identifying an item in a CBOR map.

 
3) = CWT and COSE by label
- The CWT is an item with a label. The = definition of the label says the contents of the label are always CWT = and of a specific COSE type
- No tags necessary
[JLS] Yes that would be = fine
 
4) Application/CWT identifies content = as CWT, tagging for COSE type
- No CWT tag
- Has a = COSE tag
[JLS] = This is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

You mean there could be other media types that = also identify the content as CWT?

 
5) Application/CWT identifies content as CWT
- Has CWT = tag even though it is redundant 
- Has a = COSE tag
[JLS] = Yes

Additionally, one might interpret CBORbis 4.2.2 to = say the the CWT tag should not be present.

 
6) = Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags = are used
- Identification is completely by the MIME type = header
- (I understand that the cose-type MIME = parameter is not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)
[JLS] Yes you could = do that, and as I stated in a previous mail this is not a good idea for = the CoAP world.
 
7) A protocol like FIDO identifies a = protocol element that is an attention type the type of which is CWT with = COSE_Sign1
- No tags are used
[JLS] yes
 
8) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT; the COSE = type is determined by tag
- No CWT tag
- Has a = COSE tag
[JLS] = yes
 
The one thing you can=E2=80=99t do is = have a CWT tag without a COSE type tag. 8392 section 6 forbids this.
 
[JLS] There however is a = set of nested cases that you might need to look at.  That is 6.CWT = ( COSE_Encrypt_Tagged ( COSE_Sign ))  You would also need to think = about the requirements for nested COSE = layers.

All but the most outer COSE type are always = identified by a tag, per 7.1 step 5 and 7.2 step 6, right?

LL


 
Jim
 
 
LL
 
 
 
 


On Aug 11, 2020, at = 12:20 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
 
 


On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:
 
This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] = What is the text that says that this is true.  This would be a = surprising statement for me.
 
Here=E2=80=99s three things that lead = me to this.
 
CBORbis
The = sentence of the first paragraph in 4.2.2 very clearly states this, though this is only = for deterministic encoding.
 
Typical CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 
 
Email threads
This thread and this thread.
 
I = summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.
 
So, = it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol.
 
However you slice it, I think it is up to the surrounding = protocol to say whether a tag is always required, never required or = optionally required. If the protocol doesn=E2=80=99t say, then it = defaults to optionally required.
 
Defaulting or explicitly allowing optional tagging means the = receiver has to allow for all the tagging scenarios and makes possible = the error case where the surrounding protocol says the data is of one = type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).
 
I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.
 
It = has some disadvantage because it introduces error conditions and = potential confusion.
 
I think there are several scenarios = with section 6 and application/cwt that could be more clear.
 
Can you use tag 61 or not? I think the current = answer is that in application/cwt, tag 61 is optional.
 
How = do you know what the COSE type is? It is somewhat obvious that COSE tags = will work, but there is no requirement to use them. A MIME parameter or = other is entirely allowed here.
 
Section 6 does say that determination that something is a CWT = is application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this.
 
Said another way, my fully general CWT = decoder that is called by some application needs an input parameter to = indicate the COSE type because there is no requirement in 8392 that a = CWT indicate which COSE type is in use. Sometimes the caller will be = able to provide the COSE type and sometimes they won=E2=80=99t. = Sometimes there will be an error of conflicting COSE type and sometimes = the error will be that the COSE type can=E2=80=99t be determined.
 
I = think it would have been cleanest if CWT always indicated the COSE type = be used and the tagging optionality didn=E2=80=99t span two protocol = layers, but that would be an incompatible change.  Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type?
 
LL
 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

= --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D-- From nobody Sat Aug 15 11:43:08 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C33A0855; Sat, 15 Aug 2020 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4a1FjmLBrwu; Sat, 15 Aug 2020 11:43:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECD53A0859; Sat, 15 Aug 2020 11:42:59 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 15 Aug 2020 11:42:35 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'cose' , 'Ace Wg' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> In-Reply-To: <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> Date: Sat, 15 Aug 2020 11:42:33 -0700 Message-ID: <00d201d67333$d8449d30$88cdd790$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01D672F9.2BEE0290" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowAJ+XblxAdxq5xCqb0y90A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] [Ace] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 18:43:03 -0000 ------=_NextPart_000_00D3_01D672F9.2BEE0290 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Saturday, August 15, 2020 10:58 AM To: Jim Schaad Cc: cose ; Ace Wg Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 =20 On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad > Cc: Ace Wg >; cose > Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 You mean there could be other media types that also identify the content = as CWT? [JLS] Yes this could be done in the future. One would normally expect = this to be an application specific profile, but funny things happen. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. [JLS] For deterministic encoding, but not for general encoding. =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. Jim =20 =20 LL =20 =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 _______________________________________________ Ace mailing list Ace@ietf.org = https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_00D3_01D672F9.2BEE0290 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; = Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?

 

 



On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 1:59 = PM
To: Jim = Schaad <ietf@augustcellars.com>
= Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

1) Explicitly tagged, no external type info = needed

- Has = CWT tag

- Has = COSE type tag

[JLS] = Yes

 

2) CWT identification by label, COSE type = tagged

- The = CWT is a CBOR data item with a label. The definition of the label says = the contents of the label are always = CWT

- No CWT = tag necessary as it is implied by the = label

- Has a = COSE type tag

[JLS] Yes, = the label could be internal to the CBOR object or external such as an = media-type

 

I = was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map.



 

3) CWT and COSE by = label

- The CWT = is an item with a label. The definition of the label says the contents = of the label are always CWT and of a specific COSE = type

- No tags = necessary

[JLS] Yes that = would be fine

 

4) Application/CWT identifies content as CWT, tagging = for COSE type

- = No CWT tag

- = Has a COSE tag

[JLS] This = is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

 

You mean there could be other media types that also = identify the content as CWT?

[JLS] = Yes this could be done in the future. =C2=A0=C2=A0One would normally = expect this to be an application specific profile, but funny things = happen.

 

5) Application/CWT identifies content as = CWT

- Has CWT = tag even though it is = redundant 

- Has a COSE tag

[JLS] = Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say = the the CWT tag should not be present.

[JLS] For deterministic encoding, but not =C2=A0for = general encoding.

 

6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or = =E2=80=A6)

- No = tags are used

- = Identification is completely by the MIME type = header

- (I = understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it)

[JLS] Yes you could do that, and as I stated in a = previous mail this is not a good idea for the CoAP = world.

 

7) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT with = COSE_Sign1

- No = tags are used

[JLS] = yes

 

8) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT; the COSE type is = determined by tag

- No CWT tag

- Has a COSE tag

[JLS] yes

 

The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids = this.

 

[JLS] There however is a set of nested cases that you = might need to look at.  That is 6.CWT ( COSE_Encrypt_Tagged ( = COSE_Sign ))  You would also need to think about the requirements = for nested COSE = layers.

 

All but the most outer COSE type are always identified = by a tag, per 7.1 step 5 and 7.2 step 6, right?

[JLS] Yes I guess that is true.=C2=A0 I think my code = is more generous that this in terms of what is = accepted.

Jim

 

 

LL

 



 

Jim

 

 

LL

 

 

 

 




On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 




On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting = protocol.

 

[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only for = deterministic encoding.

 

Typical = CDDL

Most = CDDL that describes tagged data describes it only as tagged or untagged, = not as optionally tagged.  COSE is one example of = this. 

 

Email = threads

 

I summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only = for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR = protocol.

 

However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally = required.

 

Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).

 

I don=E2=80=99t think optional tagging is of any = advantage in a protocol design. It doesn=E2=80=99t enable = anything.

 

It has some disadvantage because it introduces error = conditions and potential = confusion.

 

I think there are several scenarios with section 6 and = application/cwt that could be more = clear.

 

Can you use tag 61 or not? I = think the current answer is that in application/cwt, tag 61 is = optional.

 

How do you know what the COSE type is? It is somewhat = obvious that COSE tags will work, but there is no requirement to use = them. A MIME parameter or other is entirely allowed = here.

 

Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

Said another way, my fully general CWT decoder that is = called by some application needs an input parameter to indicate the COSE = type because there is no requirement in 8392 that a CWT indicate which = COSE type is in use. Sometimes the caller will be able to provide the = COSE type and sometimes they won=E2=80=99t. Sometimes there will be an = error of conflicting COSE type and sometimes the error will be that the = COSE type can=E2=80=99t be = determined.

 

I think it would have been cleanest if CWT always = indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE = type?

 

LL

<= /div>

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org=
<= a href=3D"https://www.ietf.org/mailman/listinfo/ace">https://www.= ietf.org/mailman/listinfo/ace

 

------=_NextPart_000_00D3_01D672F9.2BEE0290-- From nobody Mon Aug 24 08:48:40 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0E3A0F5F; Mon, 24 Aug 2020 08:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159828411447.9839.2060511690316176296@ietfa.amsl.com> Date: Mon, 24 Aug 2020 08:48:34 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-struct-12.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 15:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Structures and Process Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-struct-12.txt Pages : 96 Date : 2020-08-24 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-12 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-struct-12 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 Mon Aug 24 09:01:58 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06B83A102C for ; Mon, 24 Aug 2020 09:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8f5VHSN8Nbk for ; Mon, 24 Aug 2020 09:01:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA033A102D for ; Mon, 24 Aug 2020 09:01:54 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Aug 2020 09:01:49 -0700 From: Jim Schaad To: 'cose' References: <159828411471.9839.16382613328608969605@ietfa.amsl.com> In-Reply-To: <159828411471.9839.16382613328608969605@ietfa.amsl.com> Date: Mon, 24 Aug 2020 09:01:46 -0700 Message-ID: <007001d67a2f$dfcc0630$9f641290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG/iwjP6QWxktcNROdMXqBJ5CH9R6l1SLMA X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-rfc8152bis-struct-12.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:01:57 -0000 I have pushed up a new version of the COSE structure document which has = the following changes: 1. A new countersignature algorithm has been defined. It uses the = existing countersignature CDDL structure as there is not a difference = here. =20 2. A pair of new header parameters have been defined for the new = countersignature algorithm. 3. The current countersignature algorithm has been marked as = deprecated. 4. There are a number of questions scattered throughout the document = which can be found by searching for "QUESTION" that raise a number of = questions that I think need to have some type of answer as the document = progresses. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Monday, August 24, 2020 8:49 AM To: Jim Schaad Subject: New Version Notification for = draft-ietf-cose-rfc8152bis-struct-12.txt A new version of I-D, draft-ietf-cose-rfc8152bis-struct-12.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-cose-rfc8152bis-struct Revision: 12 Title: CBOR Object Signing and Encryption (COSE): Structures and = Process Document date: 2020-08-24 Group: cose Pages: 96 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-struct-12= .txt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-12 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-rfc8152bis-struct-12 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. = =20 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 Mon Aug 24 09:17:46 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317023A10AD for ; Mon, 24 Aug 2020 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO5os2awHnlC for ; Mon, 24 Aug 2020 09:17:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28FE3A10B7 for ; Mon, 24 Aug 2020 09:17:39 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Aug 2020 09:17:33 -0700 From: Jim Schaad To: 'cose' Date: Mon, 24 Aug 2020 09:17:31 -0700 Message-ID: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZ6L+kJdxe9ddqIQLK6TJ9/jG1TJQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:17:41 -0000 At the virtual IETF meeting where had a long discussion on how the structure document should progress without getting any type of final conclusions. Since that time I have come up with a new option which I think should be added to the discussion. 1. Have a single document with the new countersignature algorithm added. This has the advantage that everything is in one place, it is easy to tag the current countersignature algorithm header parameters as deprecated because there is a new replacement in the document. 2. Have two documents (version 1): Fix the description of the current countersignature algorithm in the bis document and progress that. Create a new document which contains the new countersignature algorithm. This would be an odd choice because I am not sure how the current countersignature algorithm should be tagged. Not deprecating seems wrong but trying to deprecate later also seems to be a strange thing to do. 3. Have two documents (version 2): Pull the current countersignature algorithm out of the core document and allow it to progress to full standard without a countersignature algorithm at all. Create a new document with both the new and old countersignature algorithms tagging the old one as deprecated. This can then be added to the STD number in the future. 4. Have two documents (version 3): Pull the current countersignature algorithm out of the core document and add the new countersignature algorithm to it. Create new document which contains the old countersignature algorithm and publish it as historical. This is cleaner in many respects as the deprecated version of the countersignature algorithm would be in a document which is clearly marked as not being what is to be used. 5. Have three documents: Pull the current countersignature algorithm out of the core document and advance it to full standard. Create two new documents, one for each of the countersignature algorithms. The old countersignature algorithm would be published as historic and the new document can be cycled as needed until it is ready and then added to the STD number as a second document. I suggested the last option to the chairs in a private email mostly as an option that exists but I was not really serious about it. However, in retrospect I am starting to warmup to the way of doing things as it has several advantages. The current structure document can progress without any big problems. (Yes I still need to deal with Ben's discuss, but it is kind of meta.) It also means that the two countersignature algorithms are separated and clearly marked in the RFCs themselves as to what there statuses are. There are no issues with having multiple documents in the full standard so adding the countersignature v2 document later is not a problem. Jim From nobody Mon Aug 24 09:25:16 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436343A106C for ; Mon, 24 Aug 2020 09:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVIloVIYSu9T for ; Mon, 24 Aug 2020 09:25:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701273A1049 for ; Mon, 24 Aug 2020 09:24:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 11BAB300B75 for ; Mon, 24 Aug 2020 12:24:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 67T1aezxTDTA for ; Mon, 24 Aug 2020 12:24:49 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id A941830009B; Mon, 24 Aug 2020 12:24:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> Date: Mon, 24 Aug 2020 12:24:51 -0400 Cc: cose Content-Transfer-Encoding: quoted-printable Message-Id: <6EEEDA64-921B-4EDE-BDE8-92BA666DFB29@vigilsec.com> References: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:25:15 -0000 As I said on the call, I think that one document is better, even if it = causes a short delay for progress of the I-D toward RFC. Russ > On Aug 24, 2020, at 12:17 PM, Jim Schaad = wrote: >=20 > At the virtual IETF meeting where had a long discussion on how the = structure > document should progress without getting any type of final = conclusions. > Since that time I have come up with a new option which I think should = be > added to the discussion. >=20 > 1. Have a single document with the new countersignature algorithm = added. > This has the advantage that everything is in one place, it is easy to = tag > the current countersignature algorithm header parameters as deprecated > because there is a new replacement in the document. >=20 > 2. Have two documents (version 1): Fix the description of the = current > countersignature algorithm in the bis document and progress that. = Create a > new document which contains the new countersignature algorithm. This = would > be an odd choice because I am not sure how the current = countersignature > algorithm should be tagged. Not deprecating seems wrong but trying to > deprecate later also seems to be a strange thing to do. >=20 > 3. Have two documents (version 2): Pull the current countersignature > algorithm out of the core document and allow it to progress to full = standard > without a countersignature algorithm at all. Create a new document = with > both the new and old countersignature algorithms tagging the old one = as > deprecated. This can then be added to the STD number in the future. >=20 > 4. Have two documents (version 3): Pull the current countersignature > algorithm out of the core document and add the new countersignature > algorithm to it. Create new document which contains the old > countersignature algorithm and publish it as historical. This is = cleaner in > many respects as the deprecated version of the countersignature = algorithm > would be in a document which is clearly marked as not being what is to = be > used. >=20 > 5. Have three documents: Pull the current countersignature algorithm = out of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to = the STD > number as a second document. >=20 > I suggested the last option to the chairs in a private email mostly as = an > option that exists but I was not really serious about it. However, in > retrospect I am starting to warmup to the way of doing things as it = has > several advantages. The current structure document can progress = without any > big problems. (Yes I still need to deal with Ben's discuss, but it is = kind > of meta.) It also means that the two countersignature algorithms are > separated and clearly marked in the RFCs themselves as to what there > statuses are. There are no issues with having multiple documents in = the > full standard so adding the countersignature v2 document later is not = a > problem. >=20 > Jim From nobody Mon Aug 24 09:43:07 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1F73A108B for ; Mon, 24 Aug 2020 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB6UOPx2QhZk for ; Mon, 24 Aug 2020 09:43:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929E13A1089 for ; Mon, 24 Aug 2020 09:43:04 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07OGguBU014683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 12:42:58 -0400 Date: Mon, 24 Aug 2020 09:42:56 -0700 From: Benjamin Kaduk To: Russ Housley Cc: Jim Schaad , cose Message-ID: <20200824164256.GC45501@kduck.mit.edu> References: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> <6EEEDA64-921B-4EDE-BDE8-92BA666DFB29@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EEEDA64-921B-4EDE-BDE8-92BA666DFB29@vigilsec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:43:06 -0000 On Mon, Aug 24, 2020 at 12:24:51PM -0400, Russ Housley wrote: > As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC. IIUC, the "one document" approach would lead to a more-than-short delay in STD number assignment. -Ben From nobody Mon Aug 24 10:10:28 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC463A119F for ; Mon, 24 Aug 2020 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lVtRhEDeHnT for ; Mon, 24 Aug 2020 10:10:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED303A13E3 for ; Mon, 24 Aug 2020 10:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BF85389B6; Mon, 24 Aug 2020 12:48:30 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jY-N29Xq_YM5; Mon, 24 Aug 2020 12:48:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 353DE389B5; Mon, 24 Aug 2020 12:48:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 82C70609; Mon, 24 Aug 2020 13:09:25 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: 'cose' In-Reply-To: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> References: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 17:10:27 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > At the virtual IETF meeting where had a long discussion on how the structure > document should progress without getting any type of final conclusions. > Since that time I have come up with a new option which I think should be > added to the discussion. You have five choices, but I think that I there are actually two decisions: a) the base document will advance with: 1) no countersignature algorithm 2) the old(current) countersignature algorithm 3) the new countersignature algorithm b) one or two documents will be created to document and deprecrate the old algorithm, and document the new way. > 5. Have three documents: Pull the current countersignature algorithm out of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to the STD > number as a second document. This is A1, and B-with-two-documents. I am fine with that in the end. Russ Housley wrote: > As I said on the call, I think that one document is better, even if it > causes a short delay for progress of the I-D toward RFC. I estimate it will be a six month delay. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9D9EUACgkQgItw+93Q 3WUHOwf44uja0zbr/BKSJwXhIJlL1htK67q5bdxQAiMXC19rFYBMNQ/4XVQ01RPa DucnsTKzehUvl1h+FPd+zQ8Ll/WZm8dD+hH3ftAypaEdsAead4njROqc4PX25pYX yYUE0nycoN3eh1HBxf+9n5pXRqi3MXIV0VZKB7DA5t60Xb6yhxjprV8KCy2kEX5w or8iPlgcI4tOZ7XVbHP+BeU/Wp1rs35McVXLv2DeQwUb4v4r0w6/UgYSzcaMHrF1 XbM6qaVJQltlhIaIK/5XeNqFOjwmgTu616OV0U2HhN9tb2DuUwk87np/ASM2hh4s nLR28P/xKiSC8TZaUzY9ojqlH716 =EP/t -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 24 10:20:08 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8C3A120C for ; Mon, 24 Aug 2020 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXAhLcFKtoMH for ; Mon, 24 Aug 2020 10:20:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5774E3A1213 for ; Mon, 24 Aug 2020 10:20:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Aug 2020 10:19:53 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Russ Housley' CC: 'cose' References: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> <6EEEDA64-921B-4EDE-BDE8-92BA666DFB29@vigilsec.com> <20200824164256.GC45501@kduck.mit.edu> In-Reply-To: <20200824164256.GC45501@kduck.mit.edu> Date: Mon, 24 Aug 2020 10:19:51 -0700 Message-ID: <007401d67a3a$c84d76a0$58e863e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQCuuD9VAOL+chFsmCJFoBoPMo+YBgHuozOIAp+xOMCrcpGrYA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 17:20:07 -0000 -----Original Message----- From: Benjamin Kaduk Sent: Monday, August 24, 2020 9:43 AM To: Russ Housley Cc: Jim Schaad ; cose Subject: Re: [COSE] New option going forward for COSE struct On Mon, Aug 24, 2020 at 12:24:51PM -0400, Russ Housley wrote: > As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC. IIUC, the "one document" approach would lead to a more-than-short delay in STD number assignment. [JLS] I tend to agree with Ben on this. Stripping out all of the countersignature text could move the document back to the IESG by the end of September and then into the RFC Editor queue. Adding the new text means back to the IESG probably in Nov, add a new IETF last call and then, at least for me to feel comfortable about it, a one year minimum wait before moving the document up to full standard. I am not sure that I would consider 18 months at a minimum as a short delay. Jim -Ben From nobody Mon Aug 24 15:43:10 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11A3A0E7E for ; Mon, 24 Aug 2020 15:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 rlNKJJwNNHc2 for ; Mon, 24 Aug 2020 15:43:06 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::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 562423A0E65 for ; Mon, 24 Aug 2020 15:43:06 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id o21so9840886oie.12 for ; Mon, 24 Aug 2020 15:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=fVOKOoy98TwzwmlTN8sqpW5CIIkHEtj++OvEA9ZX6t4=; b=cNyraQBKf0oTBacWkpovdwv77/NlrivReqEKVIABHNyexNni+1sC91NT24Bzb6LJ+B +CkhJzI+okTt5OfBfgvhQDEj4pegFNLX+Bh3d7Pm8Ben490n0me1Cno2WxNxlcJY52qD elawvspHnXl9NjmYiWhInl+eoEyIug+YYdI39XIZFuNSrqpuBx7MktWh0Dm1k7Bqb1al iKPB+sHH2u2Vge2Hkrp1cn1cMVNc6jfO0eOAPjophIPFazhApdzTZon7+r3wNzsZfEMJ nVkr7HBK6GigNwO4WXkMR0Aky9VwVRMK7HOLAsRKL1jJRXobah2XOm6b1L8bHJgzbR9o JseQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=fVOKOoy98TwzwmlTN8sqpW5CIIkHEtj++OvEA9ZX6t4=; b=BV2hwIH4iZ6RyvO9ps2nll0w8aZIAm5/s5ehbS0N6atrk/RdtY1gdAmXPEbueCGTnG KHf8AXt+ldUh4pojlzXBpGkwSeYfLS+WgLrbl6srKcgfLWNpeB+5A8HcheP0dlArkas0 cJT8XrIRnucx8DJeiUh6V4Qjb3t5yeiUk6KX7yRHZzJIzJ3MXoJVhrkUXVLkdXmSUEMv NkdOY++hQsA0LPhtEQ8badmS0k3U944a+Ql9mIgexH63IYpHjbLBmCo+KewduR16TcWr QCwAlh8MJYVsGvofXMPKFVguXwTvrosUe80EuakWm3j4+5R0xwX9hAndBNZ9hjNd7n1I KRpg== X-Gm-Message-State: AOAM530hP+ux09wBj/k2J47YB5sueOGLZ7lHjjMz0DRSYf05C8xzZlKt eOG4a0ClFeLbJeicsYTiqIpfP5NMogLVj2w5PQI= X-Google-Smtp-Source: ABdhPJzhwNQ+yjc78Abt9GvgUbsXilAUXPiICT3Cadlz1zLc7VAAYus1I913aBpRkmYkUUMmOyex/A== X-Received: by 2002:aca:2418:: with SMTP id n24mr1074669oic.4.1598308984990; Mon, 24 Aug 2020 15:43:04 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:6c98:6d3b:63e5:9eb7]) by smtp.gmail.com with ESMTPSA id g23sm2495996ooa.40.2020.08.24.15.43.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Aug 2020 15:43:04 -0700 (PDT) To: Jim Schaad , 'cose' References: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0Lk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD6JAVcE EwEKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQQx11iN7JBpDWvMmODs9HJO EJ4FuwUCXg4OHwUJFTCUpQAKCRDs9HJOEJ4Fu7ReCACpMVqkxDVHW1wCcOFkvJ4yVOnN3qco 48uaJdQ85B1Hwj+tbh50FUnsfmJBKkpelYWJYjzKUpsN+mxnm2Q2GjGiyDhPaht4Ksw1RkzE iTqRqdfRByZViquzF40tUuyfUlIyHs3wqR8YXNs/5OxdjIN+eO3TnNqOVVLUU7B4Qf4Hy3NQ LVuBAJcQNJVFsemXi6w3NRIJ3AW0e54BJ/DdrWIWJSsiHfNyMldnpbhd+Ml6G2iVCSAsM+9i jV1Uu+zNOVSDUTXWUKH6Igpi80QMzfnVu9N0TUSmITLtyKeeSj3kRRm1yGDGrCmu71UhhhOV xkn6R9sfMRTYuRNlYcLqUm4UuQENBFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5t NBeQkwVrvitUjHTKKipjxB2kEkUZoxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmV HgHj7TT8spa6A/qIccdiIRNsFVvlvFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B 4K+vjbgFJAvsoLfzLZ5Bz3kb6dpuxUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4S r8CRkpoMB25rxCPS8R+ByiHxpq+U8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6 +xlJXu5U/fqDAClTj5mfABEBAAGJATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4F uwUCXjPluQUJD45YPwAKCRDs9HJOEJ4Fu2viCADQVO0d7deyyn5UKN50lKKjAS5I8aPf3ssy gG97tBY2+ZnfvREqxW9N8NWVJCi4f2+pXkxaudCCW38YA5VYJE5/49FzzpiB6Xw7VWD5wP6y ObKjM4296hTjxWRV/U4pd+tLr/WXOZpZCXDOe1+Gi0Ze8EhkVz6oe79+erPiZbyxfKwbWey1 OUqwlnqFmbv+zb6lvlDRDjj9sQJTiHeAXmFn5ZKczXEj5IQJA9l78PxpsjptuCJuxH9jubHE IRDv3Rvt41OEJ0hhbS1x53R6TTNtLw+k/rllKcqeYNuyqyBwKVqvTN6OikevKUziyazMXLYf MZhyzqbllQChAATUEQ3x Message-ID: Date: Mon, 24 Aug 2020 16:43:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <007101d67a32$12f5f230$38e1d690$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tc1X26rMOtV2RN34Bg9kGnAaPhKbRGMQz" Archived-At: Subject: Re: [COSE] New option going forward for COSE struct X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 22:43:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tc1X26rMOtV2RN34Bg9kGnAaPhKbRGMQz Content-Type: multipart/mixed; boundary="c3s0AMQsaAFeWvqlABAQE6b8bbm7B7Gcu" --c3s0AMQsaAFeWvqlABAQE6b8bbm7B7Gcu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Speaking with no hat ... My personal preference would be to deprecate counter-signatures from -struct so it can progress, and document the v2 in a separate document. I have small personal preference for deprecating the v1 counter-signature in -struct while keeping its process documented, but it's a small preference. I'm in favor of two documents, but not three. For me, I think that means either counter-signatures are consolidated into a single document, or the v1 is left in RFC 8152. As a radical opinion, maybe consider leaving the v1 mechanism behind in RFC 8152 and only discuss its deprecation in -struct. - m&m Matthew A. Miller On 20/08/24 10:17, Jim Schaad wrote: > At the virtual IETF meeting where had a long discussion on how the stru= cture > document should progress without getting any type of final conclusions.= > Since that time I have come up with a new option which I think should b= e > added to the discussion. >=20 > 1. Have a single document with the new countersignature algorithm adde= d. > This has the advantage that everything is in one place, it is easy to t= ag > the current countersignature algorithm header parameters as deprecated > because there is a new replacement in the document. >=20 > 2. Have two documents (version 1): Fix the description of the current= > countersignature algorithm in the bis document and progress that. Crea= te a > new document which contains the new countersignature algorithm. This w= ould > be an odd choice because I am not sure how the current countersignature= > algorithm should be tagged. Not deprecating seems wrong but trying to > deprecate later also seems to be a strange thing to do. >=20 > 3. Have two documents (version 2): Pull the current countersignature > algorithm out of the core document and allow it to progress to full sta= ndard > without a countersignature algorithm at all. Create a new document wit= h > both the new and old countersignature algorithms tagging the old one as= > deprecated. This can then be added to the STD number in the future. >=20 > 4. Have two documents (version 3): Pull the current countersignature > algorithm out of the core document and add the new countersignature > algorithm to it. Create new document which contains the old > countersignature algorithm and publish it as historical. This is clean= er in > many respects as the deprecated version of the countersignature algorit= hm > would be in a document which is clearly marked as not being what is to = be > used. >=20 > 5. Have three documents: Pull the current countersignature algorithm o= ut of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to th= e STD > number as a second document. >=20 > I suggested the last option to the chairs in a private email mostly as = an > option that exists but I was not really serious about it. However, in > retrospect I am starting to warmup to the way of doing things as it has= > several advantages. The current structure document can progress withou= t any > big problems. (Yes I still need to deal with Ben's discuss, but it is = kind > of meta.) It also means that the two countersignature algorithms are > separated and clearly marked in the RFCs themselves as to what there > statuses are. There are no issues with having multiple documents in th= e > full standard so adding the countersignature v2 document later is not a= > problem. >=20 > Jim >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --c3s0AMQsaAFeWvqlABAQE6b8bbm7B7Gcu-- --tc1X26rMOtV2RN34Bg9kGnAaPhKbRGMQz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAl9EQnYACgkQ7PRyThCe BbvsMwgAiJ4nZe7Fmw/JcdhWVzT8XgXO3nycp9I2EUp3kTMtPKHQePz5AVGvfwtQ eaRumusEFoKYsSFP/RI3/Ql6eBM6MsmdpLbI6M5T7DPqpErk0NFvOjE5E1W3xIqf FRcn62nqS1h+6alaHGDu7cSSScievECNwcl0RY6zm4h3hUUs6FGvZaTI10YQpe80 gIVtGy+KpgnIs6CXEUcSQfUrMQnd5U57GUCwI3BxVNFlMblgmUxcbrjWgt3VLg4T 5Qt6gbEOAK/UZElBmo8SWjC172T8ewexIC5k86gNLcl0pxDKk/+FoNMNH1LuM6dO BwMHjvkvQsJdvQ++t/0nrPacT4ZLNQ== =IA0B -----END PGP SIGNATURE----- --tc1X26rMOtV2RN34Bg9kGnAaPhKbRGMQz-- From nobody Tue Aug 25 10:55:10 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C313A0B56 for ; Tue, 25 Aug 2020 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 elxntW19ISsF for ; Tue, 25 Aug 2020 10:55:06 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 A5BCB3A0B55 for ; Tue, 25 Aug 2020 10:55:06 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o8so8389047otp.9 for ; Tue, 25 Aug 2020 10:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version; bh=cXRYg5DhSqwptu3/qqBN2p0JVe2PHumFKREvvKPaN4g=; b=pwS+KgBSVNj9vokOB8osHkp9s8/gGaUu9VsNZaEnqmeQJKzt9Y3x74FafEi1M55cwa oPKSnXwlBuGtJX+HnU91V3HKmhsGjJrm3QgCsokczStNNHwgsXfal718bT5cXTTX/7sp pqabsHRtr5tvFePXHhuHwn0zDCQaBWQA70xPxykt6Wf95y3/eFmFH/OwduMKDZqk+qVm jUE+lrYvTFZEOo0tZSJd3xL+DSnvBs62lvPObTwVAOaQZ5gVD5TcR2HbzrtB+p+P0BOw aeIr21NSQ9/ey4k9k6nNRxD5jDhkEdEoHV704RAocmIPZNe0Hnr7QQItQeXNFbvdfJzw CpzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version; bh=cXRYg5DhSqwptu3/qqBN2p0JVe2PHumFKREvvKPaN4g=; b=X/4BXbeG/Am/iz4r6d/x5Cx5LVd9ApTDvxlYKgqL7Y04yDYdyuJzUzfkkLc5lpm1W/ j6Agf7iBFG5Ea1M7YvK24ub9q6p3M2v1jx51bGgJryJC2dRPLj8zpH+pbG/nsMJdEqV+ Rlfvo0qmEzV2RjpeuQSmYzH26cEA4PLBeWh4fuFg9ZrnN+wDmMW4K9ML70h1lb0sy6Fq bSTa9OYP4kVv2ONGA7IzuOJoBR8e8judqS58MR9dU+2dwGjaBzY+tDUl0NDZMiD6XD98 +dBxAKoRvCnvXWvcR5a4wqfi/oFnolTc/wtuJyP6O2k5uE63IBKrrXDdsYSK1GvfIP7X uGXA== X-Gm-Message-State: AOAM532olaDsIoMjZvehyTo80i64qNP0sZMB211760HvHa69Fm8dF4/Q YKNxg6i79i0ds8UYLs3UTpLTKfOut/vBLvwOCa4= X-Google-Smtp-Source: ABdhPJy7oLEVBivII7UVGW+MkBF8dVZg6czMNALL1s79sK8S1Qc808mWU5n10lghCiiX+UZbGKqUyw== X-Received: by 2002:a9d:2484:: with SMTP id z4mr7631689ota.216.1598378104490; Tue, 25 Aug 2020 10:55:04 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:64c0:528f:9075:2ce]) by smtp.gmail.com with ESMTPSA id r10sm2787075otd.65.2020.08.25.10.55.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Aug 2020 10:55:03 -0700 (PDT) To: cose From: "Matthew A. Miller" Autocrypt: addr=linuxwolf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0Lk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD6JAVcE EwEKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQQx11iN7JBpDWvMmODs9HJO EJ4FuwUCXg4OHwUJFTCUpQAKCRDs9HJOEJ4Fu7ReCACpMVqkxDVHW1wCcOFkvJ4yVOnN3qco 48uaJdQ85B1Hwj+tbh50FUnsfmJBKkpelYWJYjzKUpsN+mxnm2Q2GjGiyDhPaht4Ksw1RkzE iTqRqdfRByZViquzF40tUuyfUlIyHs3wqR8YXNs/5OxdjIN+eO3TnNqOVVLUU7B4Qf4Hy3NQ LVuBAJcQNJVFsemXi6w3NRIJ3AW0e54BJ/DdrWIWJSsiHfNyMldnpbhd+Ml6G2iVCSAsM+9i jV1Uu+zNOVSDUTXWUKH6Igpi80QMzfnVu9N0TUSmITLtyKeeSj3kRRm1yGDGrCmu71UhhhOV xkn6R9sfMRTYuRNlYcLqUm4UuQENBFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5t NBeQkwVrvitUjHTKKipjxB2kEkUZoxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmV HgHj7TT8spa6A/qIccdiIRNsFVvlvFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B 4K+vjbgFJAvsoLfzLZ5Bz3kb6dpuxUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4S r8CRkpoMB25rxCPS8R+ByiHxpq+U8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6 +xlJXu5U/fqDAClTj5mfABEBAAGJATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4F uwUCXjPluQUJD45YPwAKCRDs9HJOEJ4Fu2viCADQVO0d7deyyn5UKN50lKKjAS5I8aPf3ssy gG97tBY2+ZnfvREqxW9N8NWVJCi4f2+pXkxaudCCW38YA5VYJE5/49FzzpiB6Xw7VWD5wP6y ObKjM4296hTjxWRV/U4pd+tLr/WXOZpZCXDOe1+Gi0Ze8EhkVz6oe79+erPiZbyxfKwbWey1 OUqwlnqFmbv+zb6lvlDRDjj9sQJTiHeAXmFn5ZKczXEj5IQJA9l78PxpsjptuCJuxH9jubHE IRDv3Rvt41OEJ0hhbS1x53R6TTNtLw+k/rllKcqeYNuyqyBwKVqvTN6OikevKUziyazMXLYf MZhyzqbllQChAATUEQ3x Message-ID: <1f42eddb-cf22-5edd-082c-45dd8614ccfc@outer-planes.net> Date: Tue, 25 Aug 2020 11:54:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hM5JQrpjiIBHxYj263ruHXnu2H3KCgxAd" Archived-At: Subject: [COSE] Virtual Interim Meeting 2020-08-26 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 17:55:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hM5JQrpjiIBHxYj263ruHXnu2H3KCgxAd Content-Type: multipart/mixed; boundary="5nxgZhrMiA0LjQwDASIi5BdpUZdusvtwT" --5nxgZhrMiA0LjQwDASIi5BdpUZdusvtwT Content-Type: multipart/mixed; boundary="------------619ED70B46854F4A068F45A8" Content-Language: en-US This is a multi-part message in MIME format. --------------619ED70B46854F4A068F45A8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello all, We have an interim meeting Wednesday, 26 August 2020 at 16:00 UTC. The agenda is to progress a new CounterSignature mechanism that addresses the discovered defects. This interim will be conducted via Webex < https://ietf.webex.com/ietf/j.php?MTID=3Dm5528e10375ba600e61b9133f1f8bcfa= 7 >. The fuller proposed agenda is below and is located in datatracker. The meeting iCalendar event is attached. """"" # COSE WG @ 2020-08-26 Interim Agenda Where: Webex When: 2020-08-26 @ 16:00 - 17:00 UTC * Notes/Minutes: < TBD @ codimd > * Jabber: < xmpp:cose@jabber.ietf.org?join > * Webex: https://ietf.webex.com/ietf/j.php?MTID=3Dm5528e10375ba600e61b9133f1f8bcfa= 7 ## 0. Administrivia (Chairs) - 5 minutes (16:00 - 16:05) * Bluesheets (see notes) * Note taker(s) * Jabber scribe * Agenda + Bartering ## 1. Countersignature Recap (Chairs) - 5 minutes (16:05 - 16:10) ## 1. Progression of -8152bis-struct (Jim Schaad) - 20 minutes (16:10 - 16:30) * Mail thread < https://mailarchive.ietf.org/arch/msg/cose/SdW-ployB8TCtD54RU5IZg5uQVo/ >= ## 2. CounterSignature v2 Proposal (Jim Schaad) - 25 minutes (16:30 - 16:= 55) * Mail thread < https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/ >= * -rfc1852bis-struct =C2=A7 5 < https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-12#section-= 5 > ## 3. Wrap-up (Chairs) - 5 minutes (16:55 - 17:00) * Next steps * Next meeting? (2020-09-09 @ 16:00) """"" -- Ivaylo and Matthew COSE WG --------------619ED70B46854F4A068F45A8 Content-Type: text/calendar; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="cose-webex.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cose-webex.ics" BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Brussels TZURL:http://tzurl.org/zoneinfo-outlook/Europe/Brussels X-LIC-LOCATION:Europe/Brussels BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=3DYEARLY;BYMONTH=3D10;BYDAY=3D-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200811T150947Z ATTENDEE;CN=3D"COSE Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MA= ILTO:cose-chairs@ietf.org ORGANIZER;CN=3D"Cisco Webex":MAILTO:messenger@webex.com DTSTART;TZID=3DEurope/Brussels:20200826T180000 DTEND;TZID=3DEurope/Brussels:20200826T190000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm5528e10375ba600e61b913= 3f1f8bcfa7 TRANSP:OPAQUE SEQUENCE:1597158587 UID:51e88c5d-618c-4f70-b8fc-55557f991a70 DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTI= D=3Dm5528e10375ba600e61b9133f1f8bcfa7\nMeeting number (access code): 171 = 745 9639\n\n\nMeeting password: 6YZbzJ9U6d9\n\n\n\nTAP TO JOIN FROM A MOB= ILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1717459639## tel:%2B1-650-4= 79-3208,,*01*1717459639%23%23*01* Call-in toll number (US/Canada)\n\n\nJO= IN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal cal= l-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dma2817d= 3dce48bb0eb88c7fdf0c76d188\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\n= Dial sip:1717459639@ietf.webex.com\nYou can also dial 173.243.2.68 and en= ter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skyp= e for Business\nDial sip:1717459639.ietf@lync.webex.com\n\n\n\nIf you are= a host, click here to view host information:\nhttps://ietf.webex.com/iet= f/j.php?MTID=3Dmc4b2df631d7ba6352e1aa998e22affcd\n\n\n\nCan't join the me= eting? Contact support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTA= NT NOTICE: Please note that this Webex service allows audio and other inf= ormation sent during the session to be recorded, which may be discoverabl= e in a legal matter. You should inform all meeting attendees prior to rec= ording if you intend to record the meeting.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n<= table bgcolor=3D"#FFFFFF" style=3D"padding: 0; margin: 0; border: 0; widt= h: 100%;" align=3D"left">\n  \n \n \n = \n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the Webex m= eeting here.\n
 
\n= Meeting number (a= ccess code): 171 745 9639\n
\n =
Meeting = password:6YZbzJ9U6d9
\n\n \n \n= \n \n \n
 
\n \n \n \n = \n
Join meeting
\n
\n\n \n 
 
\n\n 
Tap to jo= in from a mobile device (attendees only)  
+1-650-479-3208,,1717= 459639## Call-in toll number (US/Canada) 

Join by phone  
1-650-479-3208 Call-in toll number (US/Canada)   <= BR>Global c= all-in numbers 


\n\n
 
\n\nJoin from a video system or application
Dial 1717459639= @ietf.webex.com 
You can also dial 173.243.2.68 and enter your meeting numbe= r.  
 
\n\n
Join using Microsoft = Lync or Microsoft Skype for Business
Dial 1717459639.ietf@lync.webex.com<= /a>
\n\n
 
\n <= /table>\n\n
If you are a host, click here to view host information.
\n \n <= tr>\n \n \n \n
 
Need help? Go to http://help.= webex.com\n
 
\n \n \n\n SUMMARY:Interim Meeting 2020-08-26 PRIORITY:5 CLASS:PUBLIC RRULE:FREQ=3DWEEKLY;WKST=3DSU;COUNT=3D3;INTERVAL=3D2;BYDAY=3DWE BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --------------619ED70B46854F4A068F45A8-- --5nxgZhrMiA0LjQwDASIi5BdpUZdusvtwT-- --hM5JQrpjiIBHxYj263ruHXnu2H3KCgxAd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAl9FUHIACgkQ7PRyThCe Bbtq5Af/Zqq3QCvwicmbf5u5nOyH2U9z+33eMdukYR7WOhSNnMN5deDodROWebNH LzCpFCZCLDk0wLzHRMW0u0TGa8YgRsSLwHpWgTto43qbZhfUsrE1HD9DFXDa2Ckv eR9bZfCEnoqrqm9btmAoq0nJ/sNn5DNf3qCccdqamwiSKAOv1vRyX2Kec3cPtFtw 9k+FexA2kZBewqjTNaj9uoaJkICVC27yA/oKORo8HrPWFx0au+Lr+NJGFDpo+ki5 0WodNOa1XY2kMtwoHsyuQ4QFcntq8KTfwSqfek+iFwp+jUJ8fEPelnvNnh+RjAHZ JRHSWJ6AyGVxapjaEiyy/Us+XUdoBA== =fjgH -----END PGP SIGNATURE----- --hM5JQrpjiIBHxYj263ruHXnu2H3KCgxAd-- From nobody Wed Aug 26 12:58:28 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460EE3A0A66 for ; Wed, 26 Aug 2020 12:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 Oi0M9ev8sN2s for ; Wed, 26 Aug 2020 12:58:25 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 D405C3A0937 for ; Wed, 26 Aug 2020 12:58:24 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id v6so3413460iow.11 for ; Wed, 26 Aug 2020 12:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=YwFQ/D3MJMQZyjVxtpSyV83qDS1ib1YyZpQpQX0ilsM=; b=nNgfwOJe9L+XtpUzACKiqL0KKm3nHuDiPsi6N354fBubN2AWRxIYLW7Q1nxb+qW1bs 9EEbLxOicj2EgAf7tuoXpojVhdHUDPdiNO3Rn0i6dpRkqx59hFS+fOrxoNe8Toffx+fK Y7s14cYmE3scv6lBPTPA3FWlbKdRUwnl38Ucc9Wzd6cQuBuRLTbsoIfkLtufuXJ6M7AN /Wb0kE5OFRzG196jhbgVTHlmrG96PzidKpMAMPFX9h01JIHDNrIhlPemtVENVPBhHNis DrkOi98EVjhLRsaYp8p27be3+D70xywNuIZ5XPajzeSTi98QIFgYmAZpHmnMWUI1VLeV Dk1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=YwFQ/D3MJMQZyjVxtpSyV83qDS1ib1YyZpQpQX0ilsM=; b=eUg4nUFV4lRtoA5QgGXjrnhwS1K8gQE1JBGiMq5DGGafe8JjmaSBK1MZKP1pkcQo4U zKrmi8lPDjxKxi8/P3L53goxujYjxYPLDzObRQuO4EkFRMXh7dVLKm8p3yBCoY4z8b/l 5L8KenVOXCHqvPhWqCbJ3hVwlT/Ixoqg3uwbLV3Hsp9m++hF2e30sLT91PY8ynTj3n6K J0dNjUlLQ4VCfAbIrGYL+6xPd0MSKw9Vu4W4t91uA7Mb/+fEk9pBYtqr5KalMtCs1Eco elgEfa783MJoZf6dzYzn5kGyDsACOc8lNaDjq/CdUOBz8M/zwW8rXASUPXFMSBTAe1RX XFqw== X-Gm-Message-State: AOAM532F4TB1sOtzLIrcj0Ms+H0gMIv99sOKeyY//+ufBfsMCcmTBmPZ GCgzqc2EfDVppx3EwXG865wRz+kidhTsqC+r X-Google-Smtp-Source: ABdhPJz1nFKD6xoeyjwS9X2f3VpqvyQOIr2dpmZiE5HwU9lkC3hpoQSwmBXbfWOm7FgMi+JE6wZ3wg== X-Received: by 2002:a05:6602:15c3:: with SMTP id f3mr14705250iow.25.1598471903237; Wed, 26 Aug 2020 12:58:23 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:2d29:5621:f661:95dd]) by smtp.gmail.com with ESMTPSA id u81sm1915271ilc.52.2020.08.26.12.58.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Aug 2020 12:58:22 -0700 (PDT) To: cose From: "Matthew A. Miller" Autocrypt: addr=linuxwolf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0Lk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD6JAVcE EwEKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQQx11iN7JBpDWvMmODs9HJO EJ4FuwUCXg4OHwUJFTCUpQAKCRDs9HJOEJ4Fu7ReCACpMVqkxDVHW1wCcOFkvJ4yVOnN3qco 48uaJdQ85B1Hwj+tbh50FUnsfmJBKkpelYWJYjzKUpsN+mxnm2Q2GjGiyDhPaht4Ksw1RkzE iTqRqdfRByZViquzF40tUuyfUlIyHs3wqR8YXNs/5OxdjIN+eO3TnNqOVVLUU7B4Qf4Hy3NQ LVuBAJcQNJVFsemXi6w3NRIJ3AW0e54BJ/DdrWIWJSsiHfNyMldnpbhd+Ml6G2iVCSAsM+9i jV1Uu+zNOVSDUTXWUKH6Igpi80QMzfnVu9N0TUSmITLtyKeeSj3kRRm1yGDGrCmu71UhhhOV xkn6R9sfMRTYuRNlYcLqUm4UuQENBFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5t NBeQkwVrvitUjHTKKipjxB2kEkUZoxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmV HgHj7TT8spa6A/qIccdiIRNsFVvlvFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B 4K+vjbgFJAvsoLfzLZ5Bz3kb6dpuxUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4S r8CRkpoMB25rxCPS8R+ByiHxpq+U8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6 +xlJXu5U/fqDAClTj5mfABEBAAGJATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4F uwUCXjPluQUJD45YPwAKCRDs9HJOEJ4Fu2viCADQVO0d7deyyn5UKN50lKKjAS5I8aPf3ssy gG97tBY2+ZnfvREqxW9N8NWVJCi4f2+pXkxaudCCW38YA5VYJE5/49FzzpiB6Xw7VWD5wP6y ObKjM4296hTjxWRV/U4pd+tLr/WXOZpZCXDOe1+Gi0Ze8EhkVz6oe79+erPiZbyxfKwbWey1 OUqwlnqFmbv+zb6lvlDRDjj9sQJTiHeAXmFn5ZKczXEj5IQJA9l78PxpsjptuCJuxH9jubHE IRDv3Rvt41OEJ0hhbS1x53R6TTNtLw+k/rllKcqeYNuyqyBwKVqvTN6OikevKUziyazMXLYf MZhyzqbllQChAATUEQ3x Message-ID: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> Date: Wed, 26 Aug 2020 13:58:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] =?utf-8?q?=F0=9F=94=94_Call_for_Consensus_Confirmation=3A?= =?utf-8?q?_Progressing_rfc8152bis-struct_and_Countersignatures_?= =?utf-8?b?8J+UlA==?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 19:58:26 -0000 Hello COSE WG, The interim meeting today focused on countersignatures, and there was rough consensus on a proposed plan. The chairs are seeking any objections for a proposed breakdown to move forward countersignatures. 1) The working group will have two documents: rfc8152bis-struct for the current state of the art, and a separate (still to be written) document that describes the improved countersignatures (colloquially V2). -rfc8152bis-struct will include an informative reference to this new document in order to progress. Please inform the WG if you object to separating countersignatures into a separate document. 2) The current countersignatures algorithm will be removed from -rfc8152bis-struct, and in its place will be the rationale for deprecating the "v1" countersignatures; readers will be directed to RFC 8152 for information on implementing them. Please inform the WG if you object to dropping "Countersignatures v1" from -rfc8152bis-struct. Please respond to this message with your objection to (1) and/or (2) above. This call expires in approximately one week, on September 2. Please be sure to respond with objections before then. Thank you, - Ivaylo and Matthew COSE WG Chairs From nobody Wed Aug 26 13:55:57 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A173A0112 for ; Wed, 26 Aug 2020 13:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3OMO8uY_ios for ; Wed, 26 Aug 2020 13:55:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9323A0100 for ; Wed, 26 Aug 2020 13:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EE365300B53 for ; Wed, 26 Aug 2020 16:55:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NMeKK3ct5zq6 for ; Wed, 26 Aug 2020 16:55:50 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 552FA30009B; Wed, 26 Aug 2020 16:55:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> Date: Wed, 26 Aug 2020 16:55:51 -0400 Cc: cose Content-Transfer-Encoding: quoted-printable Message-Id: References: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] =?utf-8?q?=F0=9F=94=94_Call_for_Consensus_Confirmation=3A?= =?utf-8?q?_Progressing_rfc8152bis-struct_and_Countersignatures_?= =?utf-8?b?8J+UlA==?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 20:55:56 -0000 I would have preferred one document, but I can live with this approach. Russ > On Aug 26, 2020, at 3:58 PM, Matthew A. Miller = wrote: >=20 > Hello COSE WG, >=20 > The interim meeting today focused on countersignatures, and there was > rough consensus on a proposed plan. The chairs are seeking any > objections for a proposed breakdown to move forward countersignatures. >=20 > 1) The working group will have two documents: rfc8152bis-struct for = the > current state of the art, and a separate (still to be written) = document > that describes the improved countersignatures (colloquially V2). > -rfc8152bis-struct will include an informative reference to this new > document in order to progress. Please inform the WG if you object to > separating countersignatures into a separate document. >=20 > 2) The current countersignatures algorithm will be removed from > -rfc8152bis-struct, and in its place will be the rationale for > deprecating the "v1" countersignatures; readers will be directed to = RFC > 8152 for information on implementing them. Please inform the WG if = you > object to dropping "Countersignatures v1" from -rfc8152bis-struct. >=20 > Please respond to this message with your objection to (1) and/or (2) > above. This call expires in approximately one week, on September 2. > Please be sure to respond with objections before then. >=20 >=20 > Thank you, > - Ivaylo and Matthew > COSE WG Chairs From nobody Wed Aug 26 21:57:57 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B303A0C76 for ; Wed, 26 Aug 2020 21:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH7xp6pXWlWo for ; Wed, 26 Aug 2020 21:57:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544E83A02BC for ; Wed, 26 Aug 2020 21:57:52 -0700 (PDT) Received: from client-0093.vpn.uni-bremen.de (client-0093.vpn.uni-bremen.de [134.102.107.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BcVpk2yBRzysv; Thu, 27 Aug 2020 06:57:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> Date: Thu, 27 Aug 2020 06:57:49 +0200 Cc: cose X-Mao-Original-Outgoing-Id: 620197069.9369529-8a7dcc08cc6d0c95dabb53e3f874efcc Content-Transfer-Encoding: quoted-printable Message-Id: References: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [COSE] =?utf-8?q?=F0=9F=94=94_Call_for_Consensus_Confirmation=3A?= =?utf-8?q?_Progressing_rfc8152bis-struct_and_Countersignatures_?= =?utf-8?b?8J+UlA==?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 04:57:55 -0000 Unfortunately, circumstances made me miss yesterday=E2=80=99s meeting. I fully support the way forward outlined below. (I.e., I don=E2=80=99t have an objection, but wanted to make known that = I=E2=80=99m part of the emerging consensus.) Gr=C3=BC=C3=9Fe, Carsten > On 2020-08-26, at 21:58, Matthew A. Miller = wrote: >=20 > Hello COSE WG, >=20 > The interim meeting today focused on countersignatures, and there was > rough consensus on a proposed plan. The chairs are seeking any > objections for a proposed breakdown to move forward countersignatures. >=20 > 1) The working group will have two documents: rfc8152bis-struct for = the > current state of the art, and a separate (still to be written) = document > that describes the improved countersignatures (colloquially V2). > -rfc8152bis-struct will include an informative reference to this new > document in order to progress. Please inform the WG if you object to > separating countersignatures into a separate document. >=20 > 2) The current countersignatures algorithm will be removed from > -rfc8152bis-struct, and in its place will be the rationale for > deprecating the "v1" countersignatures; readers will be directed to = RFC > 8152 for information on implementing them. Please inform the WG if = you > object to dropping "Countersignatures v1" from -rfc8152bis-struct. >=20 > Please respond to this message with your objection to (1) and/or (2) > above. This call expires in approximately one week, on September 2. > Please be sure to respond with objections before then. >=20 >=20 > Thank you, > - Ivaylo and Matthew > COSE WG Chairs >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Aug 26 22:47:28 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7B3A0D61 for ; Wed, 26 Aug 2020 22:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsVtzP_isQ35 for ; Wed, 26 Aug 2020 22:47:25 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140047.outbound.protection.outlook.com [40.107.14.47]) (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 BC2543A0D5D for ; Wed, 26 Aug 2020 22:47:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n3fJIrF/cdtYTJ8qC0I9EcdU0naKQgDN9WbVEXnujhP9L2bXfp1a4xGBgwaQZdIC98/qb0oXSi4TgkHDDP2kcqM51/XKD3TRv20ofDsMRD5JTskaE66jVlRiN7dFsjOSgdRVZ8IGuF+ESUpKjsjroML3u6uV1pqxArpcYzVba8C9knzyQ7gdTE0dR6mUlyXWDp9TagHi8MZn6NWYSgj3hVNMwd7E0FNhNrl706b8Ka7hw6Kse7tkpQxqGzOmUMUHtwGj09TVdcJO50U/EqK/r5l6J/du6PJXwHbNXKXMiLikhq4oN8q6E3cCqm4jCKmVxLxjPGbv3YfMUITsOLqyxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmO2lzyf+KgvYdLHwyRLLLLFlm2M9SH6jNizX3iBRE0=; b=FemRkupTpUi11QQxUn+Z8gNlTthIpjGy+EawzcIrcVi/aqAkJkbbVGaiwcqCw7/GSk1UUH2zR5/CeRYUvA5mzBMU44GhEFwJtbpxcemKZZOjMMvYhrx+UgAH4r8NS8OAdi0zxRaFnFNtixiwwAK3MFX8rQTICWUcNQ1tvgiOY2ew9F0nfopEShXbh3w++y9mcV8ZdmDwpRHvRvlWHKzAGsNxlj/pwQUQ1H7uh0F0xQ0ZLsfh7mVGPqPjMFI3k2e27WekVLbhxm7iVRRBNNwx9MVw2F/5GX9vacJsEbYScSNw38I++l3Q0kLGYRe6FYoWaTSiXTLbW0kjpP7Bjblmew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmO2lzyf+KgvYdLHwyRLLLLFlm2M9SH6jNizX3iBRE0=; b=Rn6a2LsBZGrEqKv0fQHll6iOHy3OfrcsV00l5wUodI9Hu/usdVd1bvPluGtYYtLHpj1b1HVMXG2gHTd21NOw5//fH4lsK/33i+0UkuMzBO/tj2t3k9Qt1WwphzPwNVpFpwSjGYOp73xUUmLXNkNQI2eXzWaug0sBF1QwqHEIyUo= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0701MB2220.eurprd07.prod.outlook.com (2603:10a6:3:1d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Thu, 27 Aug 2020 05:47:17 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.005; Thu, 27 Aug 2020 05:47:17 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Matthew A. Miller" CC: cose Thread-Topic: =?utf-8?B?W0NPU0VdICDwn5SUIENhbGwgZm9yIENvbnNlbnN1cyBDb25maXJtYXRpb246?= =?utf-8?B?IFByb2dyZXNzaW5nIHJmYzgxNTJiaXMtc3RydWN0IGFuZCBDb3VudGVyc2ln?= =?utf-8?B?bmF0dXJlcyDwn5SU?= Thread-Index: AQHWfC6nvVMIlt9i3k+Xj3vigvPQi6lLlDSA Date: Thu, 27 Aug 2020 05:47:17 +0000 Message-ID: References: <976f0487-5df7-1c52-3d88-e5922e777a58@outer-planes.net> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: outer-planes.net; dkim=none (message not signed) header.d=none;outer-planes.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2912ed80-24e4-4792-8ee5-08d84a4ca880 x-ms-traffictypediagnostic: HE1PR0701MB2220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nx8SMSWNIKBJ2OupATi2gio14WHUr3HPB5gUgtfiEF7pYhqcxRe/uGCudGlDY62NYeAtxsoyABvskkNER1Avo6PD0o4vTUpVx4zilxxaY7wD396PNIwdTZ0pmQimBCMgGPD/sGldA9KGZkWTjjFB8eo26n57z3dTKvt2NZzYGA/WJWZah5awYfY5MtQCQiQlAWd04hEpMAQ7vhmu+Z48ifntWCEhA3S0+NDBNxC7CNzGt0YYdk/P3kL62BgWwR6fwOqRctN21oo9yJokzlZHIxa1doFXQ9fM9So7gpBL5xUEM+DRJSVCsnnCO3qdEGXd1CBSrzZsgJNIDY2K4ZwQ66PgPg5EktzIaGoeG63gYlJ3oO2kTENvIuybYCCPHABc8sNLP+1tieMr7j6j94kKOQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(376002)(396003)(39860400002)(33656002)(2906002)(8936002)(186003)(26005)(6512007)(6486002)(2616005)(85202003)(966005)(86362001)(478600001)(36756003)(4326008)(85182001)(6916009)(66946007)(66476007)(64756008)(66556008)(66446008)(71200400001)(76116006)(66574015)(83380400001)(6506007)(53546011)(316002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Hld7+MWD/95a4wLirdFFxCAgg3BxOA52gBIKokRZ5VNQvjtuYhPsKGGB8blpDAtIdFQe8JazEntNMrA1S9WQHTg2c+rjcO7AYeEHOB2plbhWvPmEDeonbbkDzwjdZoP6S50z8ietwH26c80firs3nuYqvhrCNWt57wS1VP6BKvgX5z2CdmZb0xQCoASxJU4UhpXpCaFuaKktitk0btPiKwyR2sCFEPEibObJW4ec932Rb8Uo/wJhcyhsM1p9sJ4zTwWN561ohZ0j8OYBCyWXHThvMH7OOuwCVL00mP6FaNtK8L+sea35NRD34GrQUjdtEWVXQGq6Isr7ul4+gcITeYeR3pvbDYWICytCuS6H2j+yf7RSumPyogisMnLvfwsfceJneZ5i20PQRzlfo9Iwo6JcaVfvdYUbcXmCYT4VPgyG55Oxyf7FdDxtAClL00PGWpJ8W3rY3xgLbihrg4F0A0aQ0dlh7ngm9JXooQEQBHP2+qr7m6/1sSDM8p13/vkNe4esuyhDAJ4OerDJ2+D0CWGUOXLI9G2noWgpXmvlSxHW/Ov2D6f2NLVR6AnHwLh1FS7IGH/D/YsZPE8aJZwIonjMgjZddiSBhXi9mCRF2Ckm8mttnzZ21QMCrXo1AlyyxyqpN7KywkZsa1+hXvto2Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <61A5BB4BDD713C4CA9B2F41A86FCD87F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2912ed80-24e4-4792-8ee5-08d84a4ca880 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 05:47:17.6823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /86oa0r8SvfYMpCbEBzl3MYSeXUN0W3Dn6I7UJpumRRmjTwss6cc6Y45OHjsKxKyCsM/C3kQBSwUCgkZ+r0ajiU8qwcdMZ0IjK7H6tFRdsE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2220 Archived-At: Subject: Re: [COSE] =?utf-8?q?=F0=9F=94=94_Call_for_Consensus_Confirmation=3A?= =?utf-8?q?_Progressing_rfc8152bis-struct_and_Countersignatures_?= =?utf-8?b?8J+UlA==?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 05:47:27 -0000 KzENCg0KR8O2cmFuDQoNCu+7v09uIDIwMjAtMDgtMjcsIDA2OjU4LCAiQ09TRSBvbiBiZWhhbGYg b2YgQ2Fyc3RlbiBCb3JtYW5uIiA8Y29zZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBj YWJvQHR6aS5vcmc+IHdyb3RlOg0KDQogICAgVW5mb3J0dW5hdGVseSwgY2lyY3Vtc3RhbmNlcyBt YWRlIG1lIG1pc3MgeWVzdGVyZGF54oCZcyBtZWV0aW5nLg0KICAgIEkgZnVsbHkgc3VwcG9ydCB0 aGUgd2F5IGZvcndhcmQgb3V0bGluZWQgYmVsb3cuDQogICAgKEkuZS4sIEkgZG9u4oCZdCBoYXZl IGFuIG9iamVjdGlvbiwgYnV0IHdhbnRlZCB0byBtYWtlIGtub3duIHRoYXQgSeKAmW0gcGFydCBv ZiB0aGUgZW1lcmdpbmcgY29uc2Vuc3VzLikNCg0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCg0KDQog ICAgPiBPbiAyMDIwLTA4LTI2LCBhdCAyMTo1OCwgTWF0dGhldyBBLiBNaWxsZXIgPGxpbnV4d29s ZkBvdXRlci1wbGFuZXMubmV0PiB3cm90ZToNCiAgICA+IA0KICAgID4gSGVsbG8gQ09TRSBXRywN CiAgICA+IA0KICAgID4gVGhlIGludGVyaW0gbWVldGluZyB0b2RheSBmb2N1c2VkIG9uIGNvdW50 ZXJzaWduYXR1cmVzLCBhbmQgdGhlcmUgd2FzDQogICAgPiByb3VnaCBjb25zZW5zdXMgb24gYSBw cm9wb3NlZCBwbGFuLiAgVGhlIGNoYWlycyBhcmUgc2Vla2luZyBhbnkNCiAgICA+IG9iamVjdGlv bnMgZm9yIGEgcHJvcG9zZWQgYnJlYWtkb3duIHRvIG1vdmUgZm9yd2FyZCBjb3VudGVyc2lnbmF0 dXJlcy4NCiAgICA+IA0KICAgID4gMSkgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBoYXZlIHR3byBk b2N1bWVudHM6IHJmYzgxNTJiaXMtc3RydWN0IGZvciB0aGUNCiAgICA+IGN1cnJlbnQgc3RhdGUg b2YgdGhlIGFydCwgYW5kIGEgc2VwYXJhdGUgKHN0aWxsIHRvIGJlIHdyaXR0ZW4pIGRvY3VtZW50 DQogICAgPiB0aGF0IGRlc2NyaWJlcyB0aGUgaW1wcm92ZWQgY291bnRlcnNpZ25hdHVyZXMgKGNv bGxvcXVpYWxseSBWMikuDQogICAgPiAtcmZjODE1MmJpcy1zdHJ1Y3Qgd2lsbCBpbmNsdWRlIGFu IGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGlzIG5ldw0KICAgID4gZG9jdW1lbnQgaW4gb3Jk ZXIgdG8gcHJvZ3Jlc3MuICBQbGVhc2UgaW5mb3JtIHRoZSBXRyBpZiB5b3Ugb2JqZWN0IHRvDQog ICAgPiBzZXBhcmF0aW5nIGNvdW50ZXJzaWduYXR1cmVzIGludG8gYSBzZXBhcmF0ZSBkb2N1bWVu dC4NCiAgICA+IA0KICAgID4gMikgVGhlIGN1cnJlbnQgY291bnRlcnNpZ25hdHVyZXMgYWxnb3Jp dGhtIHdpbGwgYmUgcmVtb3ZlZCBmcm9tDQogICAgPiAtcmZjODE1MmJpcy1zdHJ1Y3QsIGFuZCBp biBpdHMgcGxhY2Ugd2lsbCBiZSB0aGUgcmF0aW9uYWxlIGZvcg0KICAgID4gZGVwcmVjYXRpbmcg dGhlICJ2MSIgY291bnRlcnNpZ25hdHVyZXM7IHJlYWRlcnMgd2lsbCBiZSBkaXJlY3RlZCB0byBS RkMNCiAgICA+IDgxNTIgZm9yIGluZm9ybWF0aW9uIG9uIGltcGxlbWVudGluZyB0aGVtLiAgUGxl YXNlIGluZm9ybSB0aGUgV0cgaWYgeW91DQogICAgPiBvYmplY3QgdG8gZHJvcHBpbmcgIkNvdW50 ZXJzaWduYXR1cmVzIHYxIiBmcm9tIC1yZmM4MTUyYmlzLXN0cnVjdC4NCiAgICA+IA0KICAgID4g UGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBtZXNzYWdlIHdpdGggeW91ciBvYmplY3Rpb24gdG8gKDEp IGFuZC9vciAoMikNCiAgICA+IGFib3ZlLiAgVGhpcyBjYWxsIGV4cGlyZXMgaW4gYXBwcm94aW1h dGVseSBvbmUgd2Vlaywgb24gU2VwdGVtYmVyIDIuDQogICAgPiBQbGVhc2UgYmUgc3VyZSB0byBy ZXNwb25kIHdpdGggb2JqZWN0aW9ucyBiZWZvcmUgdGhlbi4NCiAgICA+IA0KICAgID4gDQogICAg PiBUaGFuayB5b3UsDQogICAgPiAtIEl2YXlsbyBhbmQgTWF0dGhldw0KICAgID4gQ09TRSBXRyBD aGFpcnMNCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+IENPU0UgbWFpbGluZyBsaXN0DQogICAgPiBDT1NFQGlldGYub3Jn DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0KICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgQ09T RSBtYWlsaW5nIGxpc3QNCiAgICBDT1NFQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== From nobody Thu Aug 27 13:06:00 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D363A129A for ; Thu, 27 Aug 2020 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mJoAL3MMoGwr for ; Thu, 27 Aug 2020 13:05:51 -0700 (PDT) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (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 08D163A1299 for ; Thu, 27 Aug 2020 13:05:50 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id BO9dkjp3eFItaBO9dkaITh; Thu, 27 Aug 2020 13:05:50 -0700 X-CMAE-Analysis: v=2.3 cv=aOKOVo1m c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=VrHXGImtAAAA:8 a=K6EGIJCdAAAA:8 a=Eqp6jkYgQ34o3N5TpJAA:9 a=SyrdsgEqa-XJUW_k:21 a=vFFfuvnHeaAGb_Vv:21 a=QEXdDO2ut3YA:10 a=ZZLNv0RtSJYDGVn108QA:9 a=uSGSoO5p8o597y66:21 a=8ZSD_EyMHTX0iJQT:21 a=_FPemj0bJg9INCJ5:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=rjybpTLx1R2UrS7S5igv:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Thu, 27 Aug 2020 13:05:49 -0700 In-Reply-To: <00d201d67333$d8449d30$88cdd790$@augustcellars.com> Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> <00d201d67333$d8449d30$88cdd790$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.15) X-CMAE-Envelope: MS4wfBO+VgS/fmQsDM4Ijhh6yMJYC/vj4NsvK8ckaWYDTx0svJRC7hH5RCDCN4dPDfC9is0UdWsr/t70EPCXrMZld97XLDP20JMwPExLTj6X4lVRMrfdmMaY yQCk1E+DfS93EEyhJN7vhbTSsZVUDIp+KvwZ/+NixfCvdB9DPvYqwajABwXbVUlej9d5cEr4yvk7u/HTt7/lDhz20K9TxVve6WknHa5jxAGEt9tQr3M+r7nq Archived-At: Subject: Re: [COSE] [Ace] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 20:05:55 -0000 --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In a CBOR thread it became clear (to me anyway) that in the context of = CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is = the combination of the identifier and the content. In the CBOR context = when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date tag=E2=80= =9D you mean the major type 6 and the number content. The encoded CBOR = for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00. RFC 8392 uses the terminology incorrectly in section 5 = . It refers to the tag as = a prefix. Maybe errata should be filed on this? Going back to the identification of a CWT and/or COSE, my understanding = is that a =E2=80=9CCWT=E2=80=9D is a protocol message. A =E2=80=9CCWT = Tag=E2=80=9D is a type 6 item value 61 and the CWT protocol message. = The definition of the CWT protocol message stands apart from the = definition of tag 61. (This is not true of a tag 1 epoch date; the = definition of the date is intwined with the definition of tag 1). I believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example. Further, I think nesting of COSE works as follows. It doesn=E2=80=99t = have to be identified with COSE tags. Several levels of COSE can be = required by some top level media type or even by some CBOR tag that is = not a COSE defined tag. For example, I could define = application/very-secure-string as follows. - Start with string of bytes - Encrypt it with COSE_Encrypt (the string of bytes is the payload) = (note that this is not COSE_Encrypt_Tagged) - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this = is not COSE_Sign1_Tagged - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that = this is not COSE_Mac0_Tagged) I could make the payload at some level in this example some newly = defined tag that requires a COSE_Sign1 with EdDSA and indicates = something about its payload format. LL > On Aug 15, 2020, at 11:42 AM, Jim Schaad = wrote: >=20 > =20 > =20 > From: Laurence Lundblade >=20 > Sent: Saturday, August 15, 2020 10:58 AM > To: Jim Schaad > > Cc: cose >; Ace Wg > > Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? > =20 > =20 >=20 >=20 >> On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: >> =20 >> =20 >> =20 >> From: Laurence Lundblade >=20 >> Sent: Friday, August 14, 2020 1:59 PM >> To: Jim Schaad > >> Cc: Ace Wg >; cose > >> Subject: Re: [COSE] Gap in registration of application/cwt? >> =20 >> Here=E2=80=99s a series of scenarios that I think are legal CWT. = These are allowed by RFC 8392, right? >> =20 >> 1) Explicitly tagged, no external type info needed >> - Has CWT tag >> - Has COSE type tag >> [JLS] Yes >> =20 >> 2) CWT identification by label, COSE type tagged >> - The CWT is a CBOR data item with a label. The definition of the = label says the contents of the label are always CWT >> - No CWT tag necessary as it is implied by the label >> - Has a COSE type tag >> [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type > =20 > I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. >=20 >=20 >> =20 >> 3) CWT and COSE by label >> - The CWT is an item with a label. The definition of the label says = the contents of the label are always CWT and of a specific COSE type >> - No tags necessary >> [JLS] Yes that would be fine >> =20 >> 4) Application/CWT identifies content as CWT, tagging for COSE type >> - No CWT tag >> - Has a COSE tag >> [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. > =20 > You mean there could be other media types that also identify the = content as CWT? > [JLS] Yes this could be done in the future. One would normally = expect this to be an application specific profile, but funny things = happen. >> =20 >> 5) Application/CWT identifies content as CWT >> - Has CWT tag even though it is redundant=20 >> - Has a COSE tag >> [JLS] Yes > =20 > Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. > [JLS] For deterministic encoding, but not for general encoding. >> =20 >> 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) >> - No tags are used >> - Identification is completely by the MIME type header >> - (I understand that the cose-type MIME parameter is not defined, but = it could be. 8392 doesn=E2=80=99t forbid it) >> [JLS] Yes you could do that, and as I stated in a previous mail this = is not a good idea for the CoAP world. >> =20 >> 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 >> - No tags are used >> [JLS] yes >> =20 >> 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag >> - No CWT tag >> - Has a COSE tag >> [JLS] yes >> =20 >> The one thing you can=E2=80=99t do is have a CWT tag without a COSE = type tag. 8392 section 6 forbids this. >> =20 >> [JLS] There however is a set of nested cases that you might need to = look at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would = also need to think about the requirements for nested COSE layers. > =20 > All but the most outer COSE type are always identified by a tag, per = 7.1 step 5 and 7.2 step 6, right? > [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. > Jim > =20 > =20 > LL > =20 >=20 >=20 >> =20 >> Jim >> =20 >> =20 >> LL >> =20 >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >>> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = > wrote: >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>>> =20 >>>> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >>>> =20 >>>> [JLS] What is the text that says that this is true. This would be = a surprising statement for me. >>>=20 >>> =20 >>> Here=E2=80=99s three things that lead me to this. >>> =20 >>>> CBORbis >>>> The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >>>> =20 >>>> Typical CDDL >>>> Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >>>> =20 >>>> Email threads >>>> This thread = and this thread = . >>>> =20 >>>> I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >>>> =20 >>> So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >>> =20 >>> However you slice it, I think it is up to the surrounding protocol = to say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >>> =20 >>> Defaulting or explicitly allowing optional tagging means the = receiver has to allow for all the tagging scenarios and makes possible = the error case where the surrounding protocol says the data is of one = type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID). >>> =20 >>> I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >>> =20 >>> It has some disadvantage because it introduces error conditions and = potential confusion. >>> =20 >>> I think there are several scenarios with section 6 and = application/cwt that could be more clear. >>> =20 >>>> Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >>>> =20 >>>> How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >>>> =20 >>>> Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >>> =20 >>> Said another way, my fully general CWT decoder that is called by = some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined. >>> =20 >>> I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >>> =20 >>> LL >>=20 >> =20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace = > =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
In a CBOR thread it became clear (to me anyway) that in the = context of CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or = such. It is the combination of the identifier and the content. In the = CBOR context when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based = date tag=E2=80=9D you mean the major type 6 and the = number content.  The encoded CBOR for a tag 1 with value for Jan 1, = 1970 would be 0xc1 0x00.

RFC 8392 uses the terminology incorrectly in section = 5. It refers to the tag as a prefix. Maybe errata should be filed on = this?


Going back to the identification of a = CWT and/or COSE, my understanding is that a =E2=80=9CCWT=E2=80=9D is a = protocol message. A =E2=80=9CCWT Tag=E2=80=9D is a type 6 item value 61 = and the CWT protocol message.  The definition of = the CWT protocol message stands apart from the definition of tag 61. = (This is not true of a tag 1 epoch date; the definition of the date is = intwined with the definition of tag 1).

I believe the definition of the CWT = protocol message allows the type of COSE used to secure it to be = identified in many ways. You can do it with CBOR tags or you can do with = externally such as my Application/CWT; cose-type=3DCOSE_Sign1 content = type example.

Further, I think nesting of COSE works as follows. It = doesn=E2=80=99t have to be identified with COSE tags. Several levels of = COSE can be required by some top level media type or even by some CBOR = tag that is not a COSE defined tag. For example, I could define = application/very-secure-string as follows.
  - = Start with string of bytes
  - Encrypt it with = COSE_Encrypt (the string of bytes is the payload) (note that this is = not COSE_Encrypt_Tagged)
  - Sign it = COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is = not COSE_Sign1_Tagged
  - Mac it with COSE_Mac0 = (the COSE_Sign1 is the payload) (note that this is = not COSE_Mac0_Tagged)

I could make the payload at some level in this example some = newly defined tag that requires a COSE_Sign1 with EdDSA and = indicates something about its payload format.

LL





On Aug 15, 2020, at 11:42 AM, = Jim Schaad <ietf@augustcellars.com> wrote:

 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?
 
 


On Aug 14, 2020, at = 3:35 PM, Jim Schaad <ietf@augustcellars.com> wrote:
 
 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?
 
Here=E2=80=99s a series of = scenarios that I think are legal CWT. These are allowed by RFC 8392, = right?
 
1) Explicitly tagged, no external type info = needed
- Has CWT tag
- Has COSE type tag
[JLS] = Yes
 
2) CWT identification by label, COSE type = tagged
- The CWT is a CBOR data item with a = label. The definition of the label says the contents of the label are = always CWT
- No CWT tag necessary as it is implied = by the label
- Has a COSE type tag
[JLS] = Yes, the label could be internal to the CBOR object or external such as = an media-type
 
I was being very specific with the term = label, meaning a label/key identifying an item in a CBOR map.


 
3) CWT and COSE by label
- The CWT is an item with a label. The = definition of the label says the contents of the label are always CWT = and of a specific COSE type
- No tags necessary
[JLS] Yes = that would be fine
 
4) Application/CWT identifies content as CWT, = tagging for COSE type
- No CWT tag
- Has a COSE tag
[JLS] = This is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media type.
 
You mean there could be other media = types that also identify the content as CWT?
[JLS] Yes this could be = done in the future.   One would normally expect this to be an = application specific profile, but funny things happen.
 
5) Application/CWT identifies content = as CWT
- Has CWT tag even though it is = redundant 
- Has a COSE tag
[JLS] = Yes
 
Additionally, one might interpret CBORbis 4.2.2 to say the = the CWT tag should not be present.
[JLS] For deterministic encoding, but not =  for general encoding.
 
6) Application/CWT; = cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags are used
- Identification is completely by the MIME type = header
- (I understand that the cose-type MIME = parameter is not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)
[JLS]= Yes you could do that, and as I stated in a previous mail this is not a = good idea for the CoAP world.
 
7) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT with = COSE_Sign1
- No tags are used
[JLS] = yes
 
8) A protocol like FIDO identifies a = protocol element that is an attention type the type of which is CWT; the = COSE type is determined by tag
- No CWT tag
- Has a COSE tag
[JLS] = yes
 
The one thing you can=E2=80=99t do is have a CWT = tag without a COSE type tag. 8392 section 6 forbids this.
 
[JLS] = There however is a set of nested cases that you might need to look = at.  That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))  You = would also need to think about the requirements for nested COSE = layers.
 
All = but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right?
[JLS] Yes I guess that is true.  I think my = code is more generous that this in terms of what is accepted.
Jim
 
 
LL
 


 
Jim
 
 
LL
 
 
 
 



On Aug 11, 2020, at 12:20 PM, Laurence = Lundblade <lgl@island-resort.com> wrote:
 
 



On Aug 10, 2020, at 5:49 PM, Jim Schaad = <ietf@augustcellars.com> = wrote:
 
This is = all based on my understanding that the surrounding protocol for must = specify exactly when CBOR tags are to be used and when they are not to = be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for me.
 
Here=E2=80=99s three things that lead me to = this.
 
CBORbis
The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only = for deterministic encoding.
 
Typical CDDL
Most CDDL that describes tagged data describes = it only as tagged or untagged, not as optionally tagged.  COSE is = one example of this. 
 
Email threads
This thread and this thread.
 
I summarized this behavior = in this email and no where in the rest of the thread was it = indicated differently.
 
So, it is not a hard requirement because 4.2.2 = is only for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR protocol.
 
However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.
 
Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged CoSWID).
 
I don=E2=80=99t think = optional tagging is of any advantage in a protocol design. It doesn=E2=80=99= t enable anything.
 
It has some disadvantage because it introduces = error conditions and potential confusion.
 
I think there are several = scenarios with section 6 and application/cwt that could be more = clear.
 
Can you use tag 61 or not? I think the current = answer is that in application/cwt, tag 61 is optional.
 
How do you know what the = COSE type is? It is somewhat obvious that COSE tags will work, but there = is no requirement to use them. A MIME parameter or other is entirely = allowed here.
 
Section 6 does say that determination that = something is a CWT is application dependent, but doesn=E2=80=99t say = that the COSE type is also application dependent. Section 7 does address = this.
 
Said another way, my fully general CWT decoder = that is called by some application needs an input parameter to indicate = the COSE type because there is no requirement in 8392 that a CWT = indicate which COSE type is in use. Sometimes the caller will be able to = provide the COSE type and sometimes they won=E2=80=99t. Sometimes there = will be an error of conflicting COSE type and sometimes the error will = be that the COSE type can=E2=80=99t be determined.
 
I think it would have been = cleanest if CWT always indicated the COSE type be used and the tagging = optionality didn=E2=80=99t span two protocol layers, but that would be = an incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?
 
LL
 
_______________________________________________
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
= --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE-- From nobody Thu Aug 27 15:19:22 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BF03A13BA; Thu, 27 Aug 2020 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0xICBXrggDd; Thu, 27 Aug 2020 15:19:17 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CF23A13BE; Thu, 27 Aug 2020 15:19:08 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 15:19:00 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Ace Wg' , 'cose' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> <00d201d67333$d8449d30$88cdd790$@augustcellars.com> <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> In-Reply-To: <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> Date: Thu, 27 Aug 2020 15:18:59 -0700 Message-ID: <00c401d67cc0$11b18520$35148f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01D67C85.6555E170" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowAJ+XblxAdxq5xAB1lY1dwLytqwvqlweVpA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] [Ace] Gap in registration of application/cwt? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 22:19:20 -0000 ------=_NextPart_000_00C5_01D67C85.6555E170 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Thursday, August 27, 2020 1:06 PM To: Jim Schaad Cc: Ace Wg ; cose Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 In a CBOR thread it became clear (to me anyway) that in the context of = CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is = the combination of the identifier and the content. In the CBOR context = when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date = tag=E2=80=9D you mean the major type 6 and the number content. The = encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00. =20 RFC 8392 uses the terminology incorrectly in section 5 = . It refers to the tag = as a prefix. Maybe errata should be filed on this? =20 [JLS] I would be fine with you filing an errata to this effect. It = would get marked, probably, as editorial not technical but that should = be fine. =20 Jim =20 =20 =20 Going back to the identification of a CWT and/or COSE, my understanding = is that a =E2=80=9CCWT=E2=80=9D is a protocol message. A =E2=80=9CCWT = Tag=E2=80=9D is a type 6 item value 61 and the CWT protocol message. = The definition of the CWT protocol message stands apart from the = definition of tag 61. (This is not true of a tag 1 epoch date; the = definition of the date is intwined with the definition of tag 1). =20 I believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example. =20 Further, I think nesting of COSE works as follows. It doesn=E2=80=99t = have to be identified with COSE tags. Several levels of COSE can be = required by some top level media type or even by some CBOR tag that is = not a COSE defined tag. For example, I could define = application/very-secure-string as follows. - Start with string of bytes - Encrypt it with COSE_Encrypt (the string of bytes is the payload) = (note that this is not COSE_Encrypt_Tagged) - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this = is not COSE_Sign1_Tagged - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that = this is not COSE_Mac0_Tagged) =20 I could make the payload at some level in this example some newly = defined tag that requires a COSE_Sign1 with EdDSA and indicates = something about its payload format. =20 LL =20 =20 =20 =20 On Aug 15, 2020, at 11:42 AM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Saturday, August 15, 2020 10:58 AM To: Jim Schaad > Cc: cose >; Ace Wg > Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 =20 On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad > Cc: Ace Wg >; cose > Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 You mean there could be other media types that also identify the content = as CWT? [JLS] Yes this could be done in the future. One would normally expect = this to be an application specific profile, but funny things happen. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. [JLS] For deterministic encoding, but not for general encoding. =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. Jim =20 =20 LL =20 =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 _______________________________________________ Ace mailing list Ace@ietf.org = https://www.ietf.org/mailman/listinfo/ace =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_00C5_01D67C85.6555E170 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Thursday, August 27, 2020 = 1:06 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Ace Wg = <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: = [Ace] [COSE] Gap in registration of = application/cwt?

 

In a = CBOR thread it became clear (to me anyway) that in the context of CBOR a = =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is the = combination of the identifier and the content. In the CBOR context when = you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date = tag=E2=80=9D you mean the major type 6 and the number content. =  The encoded CBOR for a tag 1 with value for Jan 1, 1970 would be = 0xc1 0x00.

 

RFC 8392 uses the terminology incorrectly in section 5. It = refers to the tag as a prefix. Maybe errata should be filed on = this?

 

[JLS] I would be fine with you filing an errata to = this effect.=C2=A0 It would get marked, probably, as editorial not = technical but that should be fine.

 

Jim

 

 

 

Going back to the identification of a CWT and/or COSE, = my understanding is that a =E2=80=9CCWT=E2=80=9D is a protocol message. = A =E2=80=9CCWT Tag=E2=80=9D is a type 6 item value 61 and the CWT = protocol message.  The definition of the CWT protocol message = stands apart from the definition of tag 61. (This is not true of a tag 1 = epoch date; the definition of the date is intwined with the definition = of tag 1).

 

I = believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example.

 

Further, I think nesting of COSE works as follows. It = doesn=E2=80=99t have to be identified with COSE tags. Several levels of = COSE can be required by some top level media type or even by some CBOR = tag that is not a COSE defined tag. For example, I could define = application/very-secure-string as follows.

  - Start with string of = bytes

  - Encrypt it = with COSE_Encrypt (the string of bytes is the payload) (note that this = is not COSE_Encrypt_Tagged)

  - Sign it COSE_Sign1 (the COSE_Encrypt is the = payload) (note that this is not COSE_Sign1_Tagged

<= div>

  - Mac = it with COSE_Mac0 (the COSE_Sign1 is the payload) (note = that this is not COSE_Mac0_Tagged)

 

I could make the payload at some level in this example = some newly defined tag that requires a COSE_Sign1 with EdDSA and = indicates something about its payload = format.

 

LL

 

 

 

 



On Aug 15, 2020, at 11:42 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: cose <cose@ietf.org>; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?

 

 




On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 1:59 = PM
To: Jim = Schaad <ietf@augustcellars.com>
= Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of = application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

<= p class=3DMsoNormal>1) Explicitly tagged, no external type info = needed

- Has CWT = tag

- Has COSE type = tag

[JLS] = Yes

 

<= p class=3DMsoNormal>2) CWT identification by label, COSE type = tagged

- The CWT is a CBOR data item with a label. The = definition of the label says the contents of the label are always = CWT

- No CWT tag necessary as it is implied by the = label

- Has a COSE type = tag

[JLS] Yes, = the label could be internal to the CBOR object or external such as an = media-type

<= p class=3DMsoNormal> 

I was being very specific with the term label, meaning = a label/key identifying an item in a CBOR = map.




 

<= p class=3DMsoNormal>3) CWT and COSE by = label

- The CWT is an item with a label. The definition of = the label says the contents of the label are always CWT and of a = specific COSE type

- No tags = necessary

[JLS] = Yes that would be fine

 

<= p class=3DMsoNormal>4) Application/CWT identifies content as CWT, = tagging for COSE type

- No CWT = tag

- Has a COSE = tag

[JLS] This = is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

 

You mean there could be other media types that also = identify the content as CWT?

[JLS] Yes this could be done in the future. =   One would normally expect this to be an application specific = profile, but funny things happen.

 

<= div>

5) Application/CWT identifies content as = CWT

- Has CWT tag even though it is = redundant 

- Has a COSE = tag

[JLS] = Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say = the the CWT tag should not be present.

[JLS] For deterministic encoding, but not  for = general encoding.

 

<= p class=3DMsoNormal>6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 = or =E2=80=A6)

- No tags are = used

- Identification is completely by the MIME type = header

- (I understand that the cose-type MIME parameter is = not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)

[JLS] Yes = you could do that, and as I stated in a previous mail this is not a good = idea for the CoAP = world.

 

<= p class=3DMsoNormal>7) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT with = COSE_Sign1

- No tags are = used

[JLS] = yes

 

<= div>

8) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT; the COSE = type is determined by = tag

- No CWT = tag

- Has a COSE = tag

[JLS] = yes

 

<= p class=3DMsoNormal>The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids = this.

 

[JLS] There however is a set of nested cases that you = might need to look at.  That is 6.CWT ( COSE_Encrypt_Tagged ( = COSE_Sign ))  You would also need to think about the requirements = for nested COSE = layers.

 

All but the most outer COSE type are always identified = by a tag, per 7.1 step 5 and 7.2 step 6, = right?

[JLS] Yes I guess = that is true.  I think my code is more generous that this in terms = of what is accepted.

Jim

 

 

LL

 




 

Jim

 

<= p = class=3DMsoNormal> 

<= p class=3DMsoNormal>LL

 

<= p = class=3DMsoNormal> 

<= p class=3DMsoNormal> 

 





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 





On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting = protocol.

 

<= p class=3DMsoNormal>[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph = in 4.2.2 very clearly states this, though this is only for = deterministic = encoding.

 

<= p class=3DMsoNormal>Typical = CDDL

Most CDDL that describes tagged data describes it only = as tagged or untagged, not as optionally tagged.  COSE is one = example of this. 

 

<= p class=3DMsoNormal>Email = threads

 

<= p class=3DMsoNormal>I summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a = =E2=80=9Cshould" in spirit. It is the preferred way to design a = CBOR protocol.

 

<= p class=3DMsoNormal>However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally = required.

 

<= p class=3DMsoNormal>Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged = CoSWID).

 

<= p class=3DMsoNormal>I don=E2=80=99t think optional tagging is of any = advantage in a protocol design. It doesn=E2=80=99t enable = anything.

 

<= p class=3DMsoNormal>It has some disadvantage because it introduces error = conditions and potential = confusion.

 

<= p class=3DMsoNormal>I think there are several scenarios with section 6 = and application/cwt that could be more = clear.

 

Can you use tag 61 or not? = I think the current answer is that in application/cwt, tag 61 is = optional.

 

<= p class=3DMsoNormal>How do you know what the COSE type is? It is = somewhat obvious that COSE tags will work, but there is no requirement = to use them. A MIME parameter or other is entirely allowed = here.

 

<= p class=3DMsoNormal>Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

<= p class=3DMsoNormal>Said another way, my fully general CWT decoder that = is called by some application needs an input parameter to indicate the = COSE type because there is no requirement in 8392 that a CWT indicate = which COSE type is in use. Sometimes the caller will be able to provide = the COSE type and sometimes they won=E2=80=99t. Sometimes there will be = an error of conflicting COSE type and sometimes the error will be that = the COSE type can=E2=80=99t be = determined.

 

<= p class=3DMsoNormal>I think it would have been cleanest if CWT always = indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE = type?

 

<= p = class=3DMsoNormal>LL

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org=
<= a href=3D"https://www.ietf.org/mailman/listinfo/ace">https://www.= ietf.org/mailman/listinfo/ace

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/m= ailman/listinfo/ace

 

------=_NextPart_000_00C5_01D67C85.6555E170-- From nobody Fri Aug 28 12:33:32 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160F3A097A; Fri, 28 Aug 2020 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChFqSo0ijMxs; Fri, 28 Aug 2020 12:33:29 -0700 (PDT) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (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 5474C3A0978; Fri, 28 Aug 2020 12:33:26 -0700 (PDT) Received: by mail-il1-f170.google.com with SMTP id o16so1657314ilq.0; Fri, 28 Aug 2020 12:33:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=bbie/HFBRfiqktMRT0qVGX9KHozucaMgPykOLu/X6Is=; b=tccfHrruFtK4okdWnj4lB+xJ8swHvSJ4vMJZO6hauLlDcrYJqyWGy86P2GaOD/thL7 peTi2x9S4cFLf1AhhAEgjRoHuwo8pic3n7wPyFshwcw6EWRjbmJHqbXuB5JAKR9tl3Z9 XKFK3hvc+QCUrYCj+kRBAJS+8XSsjdDuLE1WVG2kJr92eBedad4enU+LEytuaGwF8xWa HAqY6/JIFDAT9VmGWd30Cf+LIuoW86rwbYUkzTuT9QMQNLC+bgR5mLt4MUxAFY95aD7+ +VSl73LWEE3weL8EFTg4Sihyv4h/tUoHPf6njJjBgW8egJL9shFS5OSqPSmM/B22vph4 C+oQ== X-Gm-Message-State: AOAM53098lzzKiAo11k5utwz1FlelbyQJojSC9kfS/c0Ah14+C/878ZP GgYklunV+fMix02XdwMzGsw0zag81B3AzKUF6lwr2/ziRAtoHw== X-Google-Smtp-Source: ABdhPJyKlkMjrS78iL7kFrjo1xFWOWlvtqBcSkD9Y61MPYOQNsvmqobKA1eOMa+fIrPOr3CSmiiFiauMCY9B/eK8Aak= X-Received: by 2002:a05:6e02:140f:: with SMTP id n15mr333546ilo.277.1598643205078; Fri, 28 Aug 2020 12:33:25 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 28 Aug 2020 15:33:13 -0400 Message-ID: To: draft-ietf-cose-x509.all@ietf.org Cc: cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [COSE] AD evaluation of draft-ietf-cose-x509-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 19:33:31 -0000 Hi, all. I'm taking this document over at Ben Kaduk's request, so as to get it moving more quickly, given Ben's workload. There are two items in my review below that I think I want to resolve before starting last call: the MTI comment in Section 2, and the question about Table 2 in Section 3. =E2=80=94 Section 1 =E2=80=94 In the process of writing [RFC8152] discussions were held on the question of X.509 certificates [RFC5280] and if there was a needed to provide for them. At the time no use cases were presented that appeared to have a sufficient need for these attributes. Typo: =E2=80=9Cneeded=E2=80=9D -> =E2=80=9Cneed=E2=80=9D. But, really, I w= ould just merge the two sentences: NEW In the process of writing [RFC8152] the working group discussed X.509 certificates [RFC5280] and decided that no use cases were presented that showed a need to support certificates. END =E2=80=94 Section 2 =E2=80=94 It is not necessarily expected that constrained devices themselves will evaluate and process of X.509 certificates Then, this is intended to be used in one direction: constrained devices might have certs built in, but a constrained device will not *receive* a cert from a server, for example=E2=80=A6 right? The examples i= n Section 1 are consistent with that, but it might be good to say it explicitly. For interoperability, applications which use this header parameter MUST support the hash algorithm 'SHA-256', but can use other hash algorithms. I appreciate the need for an MTI alg here, but what does it really mean for me to say that my temperature sensor =E2=80=9Csupports SHA-256=E2= =80=9D, but that everything it sends uses SHA-512? How does that help interoperability? This will normally be the situation when self-signed certificates are used. I wonder whether some readers will misread this as saying that self-signed certs will normally be used here. Maybe, =E2=80=9CSelf-signed certificates are more likely to appear in this parameter than in the others.=E2=80=9D ? * COSE_Signature and COSE_Sign0 objects, in these objects they identify the certificate to be used for validation the signature. * COSE_recipient objects, in this location they identify the certificate for the recipient of the message. Nit: I would use colon or semicolon instead of comma in both of these. And the first should say "validating", rather than "validation". =E2=80=94 Section 3 =E2=80=94 There is no definition for the certificate bag as the same attribute would be used for both the sender and recipient certificates. Nit: there needs to be a comma after =E2=80=9Cbag=E2=80=9D. One thing I=E2=80=99m not sure about here is why there=E2=80=99s no need to= have =E2=80=9Cx5bag=E2=80=9D in Table 2 in order to register the ECDH algorithms= (in Section 4.2). =E2=80=94 Section 4.1 =E2=80=94 IANA is requested to register the new COSE Header parameter in Nit: =E2=80=9Cparameters=E2=80=9D =E2=80=94 Section 5 =E2=80=94 A new self-signed certificate appearing on the client cannot be a trigger to modify the set of trust anchors, instead a well defined trust-establishment process is required. Nit: I had a bit of trouble parsing this, and I think it needs different punctuation, or, better, just a change from =E2=80=9Cinstead=E2= =80=9D to =E2=80=9Cbecause=E2=80=9D. Before using the keys in a certificate, they MUST be checked as described in the COSE algorithms document [I-D.ietf-cose-rfc8152bis-algs]. I think the MUST here makes rfc8152bis-algs normative. I see that the document shepherd also thought that, but I don=E2=80=99t really follow the argument about why not. --=20 Barry