Re: [COSE] Key identifier of type bstr / int
Göran Selander <goran.selander@ericsson.com> Mon, 21 March 2022 18:10 UTC
Return-Path: <goran.selander@ericsson.com>
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 3C4CF3A19F9 for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 11:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-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=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 Jlrpym-IY1rv for <cose@ietfa.amsl.com>; Mon, 21 Mar 2022 11:10:23 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::611]) (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 377A53A19D6 for <cose@ietf.org>; Mon, 21 Mar 2022 11:10:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SXH1Gm7hPJp+hVNufNDvmuuPeBVr+tII/ZYD2+9UE4PbByg2wtMRK04faD7HHAQVUCNyPLpelWyh8SFiu+rF9jEhd9mSZvr1m1YfnWjWYohJGjX0F3Osl8hgx8wQueCkIeHRqE5HhPrqO/wYEB8QUEBi2P7bhyo4IMenrU9njrTpod2gxKK5dpUf2KbaZyHq+bqDutZS7ioBUXrVNig4MoP02IRvC5/1Dg6LfhUwBh6q/VqmzEUlr24hMbNnVqaThsxajGMMBK3Vtc6O4YGJdJMgrNigwWMbzHjtivDQ/Z+Y+/P3B2beInWSTD0deb5kVXN01pZj22py0fG3wIthug==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PmHTzWykmFABwlJC+xtKjWZK66AH35Y9o9r52h+xDkA=; b=Ag70e9i4v9lRw3AIToMaj21td204/OKgoxLwJeyLPHjocsTG12leMcF3q/1kCCh32EQ4+ndxq8g3dhZwVeUrAFYQwtbineiS4Px5NNvK4W08PsUXeBE7mVtbDH1ngO7Z/0uCvJw3CvYwQZMRFyc9h0QdYVwXJnuzTV2uZbjePvxAiET9zCuKimX/RCSPVPFWgQKAgw/AemFZBov+4kIO+NMYw6LxoueyQCHrTOV69gLPBe6qDo+cWH06gyut0IbAAlr9UlXLpmqVdezT4sUMZoaZewWVyMB0b1tJnofqN+XOEa3IKU6aCCzVftP/5Tq35SNafDhQzv1iC+4n5LxPFw==
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=PmHTzWykmFABwlJC+xtKjWZK66AH35Y9o9r52h+xDkA=; b=PuOcsc86V4Nl5gdWsaYKkSawyuhSdLZi1dwSxxBHmNZVQaGhLR7jn72rWMCYi2HFbaOcX61vnlnjnfsiH7YoEhPG60m5srNUiCUFrAm/6qtZe4I3pI7/z7nPN7c3VZvlP8pPAyMyl1tSvrQkwaPjUkKEbQD+RfSLF0fP7BmpVjk=
Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR0702MB3633.eurprd07.prod.outlook.com (2603:10a6:208:1b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.7; Mon, 21 Mar 2022 18:10:16 +0000
Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7c54:b32f:e7b0:baff]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7c54:b32f:e7b0:baff%11]) with mapi id 15.20.5102.015; Mon, 21 Mar 2022 18:10:15 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Orie Steele <orie@transmute.industries>, Laurence Lundblade <lgl@island-resort.com>
CC: "cose@ietf.org" <cose@ietf.org>
Thread-Topic: [COSE] Key identifier of type bstr / int
Thread-Index: AQHXhT54TcPpMfWo3E61Id/NsrhJv6triUiAgAEuhQCBXojpgYAAAG63gAAK3oCAADPpUYAAC9gAgAAFLICAAADEgIAAAG5s
Date: Mon, 21 Mar 2022 18:10:15 +0000
Message-ID: <AM4PR0701MB2195D9DE4D4DC40D737996DBF4169@AM4PR0701MB2195.eurprd07.prod.outlook.com>
References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> <EDFDB6E4-2BDE-4E2E-9CF0-D771E2DEF3C6@ericsson.com> <823C00C2-4F6C-4DF5-99B0-87D8524D4A9C@island-resort.com> <C059B669-4C5D-4980-A665-96A39F4457C3@island-resort.com> <AM4PR0701MB21958541C07CEA44DB1B1578F4169@AM4PR0701MB2195.eurprd07.prod.outlook.com> <CAN8C-_+3sWckZKo7KS2fsPU4pBHo+NNGgQpxg7p8LytFX01eEw@mail.gmail.com> <AM4PR0701MB2195D76D8CFCC873C1D05A04F4169@AM4PR0701MB2195.eurprd07.prod.outlook.com> <CAN8C-_K4EfFSar9H_QR+cV_pz+xhXtWA=pKK+rFv241E5DQofQ@mail.gmail.com> <DC1C335A-629D-4E4F-97BD-B4CA3519EDC6@island-resort.com> <CAN8C-_Ks26cf38Y3c1htzhYV4zpos=2fUnCxDaxjtrJbVVytkA@mail.gmail.com>
In-Reply-To: <CAN8C-_Ks26cf38Y3c1htzhYV4zpos=2fUnCxDaxjtrJbVVytkA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b9014d3d-3a73-4942-2843-08da0b660cfd
x-ms-traffictypediagnostic: AM0PR0702MB3633:EE_
x-microsoft-antispam-prvs: <AM0PR0702MB363334D7DFF08AE4EAD02CD7F4169@AM0PR0702MB3633.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eFbI4BHhyd/9IueJJ/c6AQlz2F/FZkXWlTyDY8gx2Poq+09DeTvUjNtUcHy+K34YC3efIiMp7wn6IemDnfg3gSlrrbo91tWM4v+ASGkrSogG5PFElAb1qfgEFPXNtCLpOn6dfAgxbuQsEQJQMnqnqtxn54hwlKHgwJWkwRJV1DHKKaVxqdQ6u6a4dEqew3EkusUuDMT3dFfgSOgEJaNTi4pD7/c0BqSRV24LARutnJrzRqniX3pm+KWWcXsPSm4WkLtK+ijAM5D4Bt6bnjSxoXB9tm5yfo3x2J4PiGXsuxGzN9Kkn88tGcFH/DrjS6esStuE0sfeqHmh1WySWHYjbwPF0movdK/q2TxRwDuSyaWTMbC0q8kN4eb7Fiwc+ljP4F//uqDJMeJvuAMMz7aNf+STdaaRPDFk8QubX0HMraiLRkyUXn4D+bXRk0a2E/n46Qdxhj9mCNaFcBITOO/7zsTcXKx8+sUh57SsSAy6020Sn54yY1ctT2N0dCLN8XTeuA/tYgwhQG0HVUxXQozdJrRx1t/vN0eyhIwCbXw/nPpofkP6sgirMUDMFgM7mpxnQS+Ocl246zvViYVEferv6+rEUIS7D72RVpFWEqEG0jevABBwpxJXL9WJ1JvisQR5pXzrPqpp1eSZiPvqSK1E21OgfRKz3G1TR2/wHlhSgXGeqaC4Fcx37Y1yI6t5+wFZ4g+iRPPRklebf+Qm2Rc7DA4Ib3jlb+xDA205t8RyvpdTrWx1p9qQGrdwfHPy5MZ0P7icsTRJ0YCu/dpUzIyyn6fIzsZiv8OS5oQ6fDP5MPXp1skDVArxrLxtu9FvwfeaJlb89x8M9931aO3XtHwtCA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(64756008)(33656002)(166002)(66556008)(66446008)(66476007)(55016003)(110136005)(26005)(52536014)(66946007)(8676002)(76116006)(6506007)(966005)(4326008)(316002)(7696005)(508600001)(91956017)(9686003)(53546011)(5660300002)(86362001)(66574015)(38100700002)(83380400001)(71200400001)(82960400001)(8936002)(122000001)(2906002)(38070700005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 6L7jz0OhFXJXQ83zf7wDguJ4SX036xSiFNtzIq5qg+sbnEMPI2J2N50bhrgBYH0J1RkDNph94DQW8yIAfExK9OB7QofVlYSDUslilChvg3S4bidZWvDkn/kP6zQmMwXtpcUbr2vMKlxBlxeD944Z99+1IkRZyn4bmKxqT/2FDmyXiuO2HjSzgEM/p38kWq2zBGljP4HG3a3HZyjNNrjr87O+j6/5S0b2eluAUtwaCMlJ8MvBNmQOxNRqawGzUgNO0k/CaZ6xnCTXhbYIDIy/HM7fHw9XErqfv1HzNpKBoABoxl+wcsjDwWaH5TnUMO9lqIb0N4YaU9r8/CLOHCc9SuHbILfkl/StkiLn3rizMkTv38p/OmqGZPWFvKr0dk/JW/J3KFZJP9P2jKCvQMI4rSrQrPqSM5BsP5Wx6nwTRsfRVPcoB667uwamSuoioDCURlLhqnKS3MKgYUQnQ5D9dM9TH2lo8gQut/i95xgVUPgldsm1KH322YZYwoX7c8NcPy4JoMPj0TjHiII+usubS+jxGayHnZtCYCTyWe18r5yduPsaEr4V9nu00Gamxhpvl2qZxUloTt2ZcymWK0ZhQNCzgnu7r/GZ7qVSX3lzVXwdXbiFjMzFwDK8wEKD2Qb7rJ8v+oR7ZZEKgoWAtu6bWf1FDwyWTcN27zEWVhwhYmkZYixftO/FN8NGkxYQSxY+IWz4/OqXzImfsw9AlTrO07lm3nmTVWnoOfuWqrNHJJC6I+RXYtOHBs31j8tCn1vjW4fmzPzbGhc1CRYNnhuyGGNIN7qdgNWllBHseSlsAg624NLTCT6q6nnLLBzmjbm/qlHU8vZoxyIynjnXwl6rlIniDSfP5CYKpjj4Ac7ug3bNpAR0XbqRgXPDzewWJR07UhMvOU2nLeSb5S4K8Jz2i0/al1OI6whEn7uxv7y8MFS4MEbDDf3zuKxDNevmEQCHtsGeKidbPsy3e/B/TML6Y9ExCyqywdLuKz0ebBh3PXSQmhYXqDbRPLgwjihqPmxJn8HsJ+XvRF1RSFKwsm2O69oX465FRL8K+aSBUWPkZn0kIdKMgtFylTb2cus8ZNPR7EwT0H1zL5ba+9VKtpWqOjTFT35hFoN/rrEjbqc4GtHFfIGkWIP4FY69E1bAyVSBX6ZrxnStJtRTvogzrF9zZEjTsSaP6ssckm0ykk7wPYMlb1I/FxS5WXAmPssRA0U72z8ENPy0cjrCsanIDzyikbGCIZIzZjvcTb2ohakAVaIJ+z7f/FJcZl5WdEMSQMK9a8KMeXnfFC6YNU/lUatnpT2IOsPxtH6xxONnlLcH4MURTcFf+KPUQ0aN50BaV+zno8usrU/IdMKsxe199skypIVIA5muxiVvPTOS+SHOXSL4ULY6m176cHNnhEtGDSNRrMMmRDqvxYstRabca3ead9uwiv6+S4/QtR1qxHfz3aZgKagTskyN6OVd417lCxtEZoKyE1R99kUBim0Sq6O2BZWwPrcuggfCCXCG2AA0HIU=
Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB2195D9DE4D4DC40D737996DBF4169AM4PR0701MB2195_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b9014d3d-3a73-4942-2843-08da0b660cfd
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2022 18:10:15.7896 (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: ZIH3UU1t8tO+63w8khdLFk1kjrEoVWxqpCEjjK/rKtFsjDeOc76LVozqdv4dCp+hpD2Fgv5gw+muxgWKe+9HUz8lfpAz1t0Khq79JCPlDY8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3633
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/9egCxyHyIE5huvVHkt_ErIv_WKY>
Subject: Re: [COSE] Key identifier of type bstr / int
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 18:10:31 -0000
Here is the history. The objective is to have 1-byte COSE key identifiers to meet the requirements in the LAKE WG: https://datatracker.ietf.org/doc/draft-ietf-lake-reqs/ Without going into the details, the overhead requirements of certain radio frames when you add sizes of ephemeral public keys and MACs etc. doesn't leave you many bytes for identifiers. The thread in COSE started here: https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/ The conclusion of that thread was there was a preference in the COSE WG for extending the COSE header `kid` to bstr / int. Today the discussion restarted in the COSE WG, and Laurence picked up on that. Göran From: Orie Steele <orie@transmute.industries> Date: Monday, 21 March 2022 at 19:04 To: Laurence Lundblade <lgl@island-resort.com> Cc: Göran Selander <goran.selander@ericsson.com>, cose@ietf.org <cose@ietf.org> Subject: Re: [COSE] Key identifier of type bstr / int Thank you, much clearer. My current position is that I am unconvinced that it's needed, or a good idea :) ... any links or summary for why a new key identifier is needed would be helpful. However, of the names suggested I am mostly a fan of "intkid". OS On Mon, Mar 21, 2022 at 1:01 PM Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote: Let me try to be more clear. The COSE standard now is: kid => bstr If we make this change: kid => int / bstr then we break backwards compatibility for COSE as Mike pointed out today. So we need a separate parameter called kid2, ckid, intkid or such. To not break backwards compatibility we need: intkid = int or: intkid = int / bstr (I don’t remember why an int kid was needed, but do remember I was convinced that it was) LL On Mar 21, 2022, at 6:43 PM, Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> wrote: I think I may have misread your proposal. Why do we need `kid2` is this just so that we can have an integer `kid` ? Seems not worth it to me, since `kid` is already legal in CBOR, my proposal of `ckid` makes no sense. So I am basically just saying I dislike seeing `kid2` and don't understand what its value prop is. OS On Mon, Mar 21, 2022 at 12:16 PM Göran Selander <goran.selander@ericsson.com<mailto:goran.selander@ericsson.com>> wrote: Hi Orie, Thanks for input. I didn't get the proposal though: > If we really need an integer version of `kid` I would suggest following the `jti / cti` convention and calling it `ckid`... keeping it optional (as is the convention), and ensuring it is not part of thumbprint computations. RFC 7517/7519: kid and jti value are case-sensitive strings RFC 8152/8392: kid and cti value are CBOR bstr Is there any difference between a `ckid` which is CBOR int or a `kid2` which is a CBOR int (besides the name)? Thanks Göran From: Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> Date: Monday, 21 March 2022 at 14:55 To: Göran Selander <goran.selander@ericsson.com<mailto:goran.selander@ericsson.com>> Cc: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>, cose@ietf.org<mailto:cose@ietf.org> <cose@ietf.org<mailto:cose@ietf.org>> Subject: Re: [COSE] Key identifier of type bstr / int I am a -1 to changing `kid`, it should remain a string, for compatibility with existing key identifier systems. Including ones that support https://datatracker.ietf.org/doc/html/rfc7638#section-1 See the original definition: https://datatracker.ietf.org/doc/html/rfc7517#section-4.5 > The "kid" value is a case-sensitive string. Many implementations have built hard dependencies on RFC7515. One of the nicest things about JOSE / COSE is being able to "upgrade" from JOSE to COSE. Having a significant difference between `kid` in JOSE and COSE would be harmful. If we really need an integer version of `kid` I would suggest following the `jti / cti` convention and calling it `ckid`... keeping it optional (as is the convention), and ensuring it is not part of thumbprint computations. Regards, OS On Mon, Mar 21, 2022 at 8:35 AM Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote: Hi Laurence, Thanks for copying in the old thread. As noted, you and others preferred `kid` as bstr / int rather than `kid2` as int when we discussed it last time. Would be good to come out with a more solid motivation this time so we can converge on this :-) With `kid2` as int, the fields that uses both bstr and int would be of type `kid` / `kid2` which is fine. There is an algorithm for translation from CBOR bstr / int to byte strings on the wire (back and forth) in draft-ietf-core-oscore-edhoc. Göran From: COSE <cose-bounces@ietf.org<mailto:cose-bounces@ietf.org>> on behalf of Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> Date: Monday, 21 March 2022 at 14:14 To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> Cc: cose@ietf.org<mailto:cose@ietf.org> <cose@ietf.org<mailto:cose@ietf.org>> Subject: Re: [COSE] Key identifier of type bstr / int Thinking about Mike’s comment today in COSE/Vienna about backwards compatibility. Looked at my code around this. That definitely seems like an issue. What about defining “kid2” as just int? “kid” stays as bstr only. Then there’s no backwards compatibility break. Adding support for another integer parameter isn’t difficult. The downside is a little extra code to look at two different parameters. You’d probably want to say that only one of the two kids MUST be present. Another random idea — could you say that it is allowed to translate an integer kid to a bstr kid by assuming network byte order and stripping leading zeros? LL On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote: Understood about the use case. Thx for the background. On Aug 10, 2021, at 3:13 AM, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org<mailto:goran.selander=40ericsson.com@dmarc.ietf.org>> wrote: Assume that we do want to allow key identifiers to be CBOR ints in certain settings, what is the best (least intrusive) way to allow this while still maintain compatibility with 'kid's supporting the type bstr? Another alternative to what has been listed below is to define 'kid2' to only be of type int - is that a better option? I didn’t write actual code to check, but they about the same to me. ‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it does exactly the same thing whether it is an int or a bstr. So my pick is ‘kid’, but ‘kid2’ is OK too. LL _______________________________________________ COSE mailing list COSE@ietf.org<mailto:COSE@ietf.org> https://www.ietf.org/mailman/listinfo/cose -- ORIE STEELE Chief Technical Officer www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=94b1f6ec-570c-49db-b72f-d15cfe926d93&u=http%3A%2F%2Fwww.transmute.industries%2F> [https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=94b1f6ec-570c-49db-b72f-d15cfe926d93&u=https%3A%2F%2Fwww.transmute.industries%2F> -- ORIE STEELE Chief Technical Officer www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F> [https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F> -- ORIE STEELE Chief Technical Officer www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F> [https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F>
- [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Benjamin Kaduk
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Benjamin Kaduk
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Mike Prorock
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Göran Selander
- Re: [COSE] Key identifier of type bstr / int Orie Steele
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade
- Re: [COSE] Key identifier of type bstr / int Christian Amsüss
- [COSE] Attempting to summarize: Key identifier of… Christian Amsüss
- Re: [COSE] Key identifier of type bstr / int Ilari Liusvaara
- Re: [COSE] Key identifier of type bstr / int Tobias Looker
- Re: [COSE] Key identifier of type bstr / int Anders Rundgren
- [COSE] draft-looker-cose-bls-key-representations Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] draft-looker-cose-bls-key-representati… Orie Steele
- Re: [COSE] draft-looker-cose-bls-key-representati… Anders Rundgren
- Re: [COSE] Key identifier of type bstr / int Michael Richardson
- Re: [COSE] Key identifier of type bstr / int Carsten Bormann
- Re: [COSE] Key identifier of type bstr / int Laurence Lundblade