[Anima] Feedback on constrained-voucher example voucher payloads (in Github / -09)

Esko Dijk <esko.dijk@iotconsultancy.nl> Fri, 04 December 2020 14:34 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785A63A0D86 for <anima@ietfa.amsl.com>; Fri, 4 Dec 2020 06:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=iotconsultancy.nl
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 DXIK6nReh7vN for <anima@ietfa.amsl.com>; Fri, 4 Dec 2020 06:34:00 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70134.outbound.protection.outlook.com [40.107.7.134]) (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 219123A0C4A for <anima@ietf.org>; Fri, 4 Dec 2020 06:33:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZj0ysBIrVWw1KtNd8mgEbmcV63ID4+FdgD6tnnC9KkvtUyDARq4xkqPgWPstI5UUiVVNXmdnhqPbzDQISzC7fn/yPGnFx/WofnIfDfly29EdDpLhv3S3x37g+icg0fgZPJhP1Nu8yKyNC+AZlomETrynZ6T6V1cKzCYbhIKmGyHgIxoGPmLSe3E0XMKpZ4o1JW7ChlB2xvMbgqYuSz9w9Lf+hzglpzzcwhflqfH6XYLlNhF/M+dzmnaJe6FdDvPZjxesDcbEmzEuU+vSOzzqwK62z3wYR26b/FlL5895ha4zXS8IeiOMnJzKQoTGfIEARo7DfoGBxCAhQcbLVo4Tw==
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=A2PBkWg6ZtZDgKirvRapJXXs8kGUL9+YE60bdwloXy8=; b=PVJtEpTS1eVYv9SXASLr1TEfUh9o5VPxhagw0tmIZI0Cr3llsxJ8DnO97ipO9rQgG5Nm5BTymj+iawub0YfdXe0hWRMsKC0JAl1IV87NF4pRb7aEoprfnJC7BJPUwydzUKkNHs+ocvsJndN7Ad4QbjrCdAaZxp0MiWiGST0om+RtJwCIDFKJmZwe0qx/tYXeiSngbsb1/uOcKHVsAuKuu/nUrVmKuvhfc7uSPmP7S+k+ndxJyTPD9HiGg7v8btc4ryZp7mSvXkpufyDR5sl1eXBHhSDlmCdUieL7kEJ6cf4F5v+7H6SrEpxw8L7f+IiepZekudx/+xNzEoKyFfxKoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A2PBkWg6ZtZDgKirvRapJXXs8kGUL9+YE60bdwloXy8=; b=ccShbwmq8NpLhTJ1+QgCsPLhn72cHFz5t4297tUD4+j/Eb5RM09PuBXOXF5O6AOoun70DJqbpspyYC40amSLSw7Bx2X2QNrSRG3nEdKnns4n5gJ7BcD6DFT+BpcLaok5kBFotog2J45OCfgzR3wkwdY22IJGWTreT+iPcwD0ES0=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0676.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:193::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Fri, 4 Dec 2020 14:33:56 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3611.031; Fri, 4 Dec 2020 14:33:55 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Feedback on constrained-voucher example voucher payloads (in Github / -09)
Thread-Index: AdbKPXRMZQMqXjk6Q32PeBIGHYN4ww==
Date: Fri, 4 Dec 2020 14:33:55 +0000
Message-ID: <AM8P190MB097940CB58A10875A656DDB2FDF10@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=iotconsultancy.nl;
x-originating-ip: [2001:1c02:3103:f000:f8dd:426f:cee7:9f0c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d48c76e-056f-46df-54d0-08d89861a166
x-ms-traffictypediagnostic: AM0P190MB0676:
x-microsoft-antispam-prvs: <AM0P190MB06760833034E7522672FE929FDF10@AM0P190MB0676.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OrHsAynEL4Gm+tVc0jaFgoMez/G9CbVKZxx+QVD9TJo5q5epn5InlTG6eDY2mrhZbcbYkv3lGtuZ23QDqzZshiJKmAhW8Swm74oA0Ms/ZKcpDk4BiFwgq5Ky239vBDgJiJLzl2fAkxpt1gTG1IQtEGfaJgTT1DlWJ/jCvaKc8010qODR3JE+jRmS0SE6MY1ffVtmnewiEFYLFo0wizwYVCCs1Ia7+D6fTeG26EGpa28zkGrbYDWYVQe3eUVIYB2Z+li3+v0g9Fu49AqMtHko1c2nMiy0C9IV+m7wTFzO4OMha9vH0iRMvd8zuxKWtH7OHLCRlj0JMuts6Oh42XBRo/GTvY5wttWxLOeHe3Hyq3wU1e54rQkt6sIp4RANEmK7QCFG5PzmkW9tdSAZN+/cVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(39830400003)(366004)(396003)(136003)(2906002)(5660300002)(8676002)(186003)(55016002)(478600001)(52536014)(4326008)(83380400001)(86362001)(966005)(66946007)(66556008)(33656002)(66446008)(66476007)(9686003)(71200400001)(64756008)(76116006)(166002)(316002)(6506007)(44832011)(8936002)(9326002)(6916009)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?R2lOamt0YmJiYjlqWDQvclFRQjBSODRHMkVRTElkeXRSN2JZNjZOS0dKSmZK?= =?utf-8?B?LzlrMEQ2UXZYRWtjdFYzNFBWTGNQYkllcFd5SU44d2NHbjcwTUh6cnFDdGw0?= =?utf-8?B?c3RNam9ScXA1UjRwOWRxamh3N2YzeERkd01yUFVPRU9BL09jbENyNmd4eGlt?= =?utf-8?B?cnB0M1RySXBwQ0VFMmNQMWNMRFZNZXYwa0RDdG9UREduWXhTREwwSkJraDFN?= =?utf-8?B?SUJubW1Kc3ZCZ3ZXcGVKc2szSkpaZ1VKSmZ4Zk0zRWg3VFptUkY4UDVSQnRY?= =?utf-8?B?dGRYSE1MR0k2SlowR1pLNmthK016aWtDWXhuNUhQUkNrS3kyb3luaS8vK0xQ?= =?utf-8?B?KzFteUZOZmpGTGI2YjE3aHdqTWwydndHT1YxOEdvaitRNzBId0FubnI2SXRQ?= =?utf-8?B?TnhLbTB6TFhacnpzVU9RNEJVZ1NCK3BYNnVuSkRnczBDQ0RuYmVZS2dBS2Nu?= =?utf-8?B?bFZJRGJ1WkYxcjhRUzdDNjMzYy84MGdCNktKVEJCUk5WT3VWc2VDa1J3Wjhv?= =?utf-8?B?U1lwTm5CTEVZeEN4SlZNeHNhODhOb0kraVlrb2Voc2JOa3lacjU0U0tlSTFC?= =?utf-8?B?NkdkQUIzaVdwREIxeWZ4dCtCRGFQNDlSVTBmL3VIVXl0ejZwSktlQlJCVEc4?= =?utf-8?B?RFlMam82VjVDbEh4eGlyamtnVWFyL0pUQ3ZscHF1UEU3MmtUVG8xSG1KL0FF?= =?utf-8?B?dGZiT0o2bjVxRjRDZkVpck80Z0dwUXp0c2lQRVp3cVZUbW1kcDYrOG13Sito?= =?utf-8?B?TmlqL2U3ZTl6ak1mSHlGWi82cjFQWDFwc2dtOUJQWHBNNGNtdmVrMXdUeHBp?= =?utf-8?B?cEZVeW5Qa0M2U3NRd1VhM3BvZmxyc3ZWc25rQlhPS2MrT3FGZVBvWVZ5TTNB?= =?utf-8?B?eWdXcU0vTlIzcEpBTUY2RG5qNVhReXgrMU1sN0NlUnVOaHhCRG04cUVJKzJ3?= =?utf-8?B?ZzZHU3lYZ2lJTGI4c1hwSjIxVXpUY1d3VTFOSEE4bS9ZdFNoWEdCQW5yUk1N?= =?utf-8?B?UUhHNmdxWlNnNUF3REluVjFFOU5YTVFmejlMbzVkYmdMNmMzbTcrazJKL3FG?= =?utf-8?B?aG80T1JaaDBMWi9jZEpzNk5BTjFtVmNjMVhwaEVoWU1BeXZZUVAvSmlXZFg0?= =?utf-8?B?UFIwc2VnUnIvYlFGM01PMWpDSTZIc0dlcE9MTE1FWFlCRHYyNDI2ZHBwamo1?= =?utf-8?B?ampxVWdwU3h2Nkh6VkRiaC9YeWt3OUpSQUhTVTBxUzFDR0JoQU44ZXNwNm1n?= =?utf-8?B?b3c3M1NqN0dEZ0kyZ2JRd3NtdjJ0dEp4N21aWUFNZGVZUG1MMk9qNEQ5OUhi?= =?utf-8?B?RXF1dkFyMHFHbUtJZ3R6aGxWbk1VQnFhaFFRVFhwcGZ3bzFRMHJNZUFUVFMz?= =?utf-8?Q?dP64PvJ/o8U7xVKZALytNPL0h+CX0TEE=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM8P190MB097940CB58A10875A656DDB2FDF10AM8P190MB0979EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d48c76e-056f-46df-54d0-08d89861a166
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 14:33:55.8509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KKmUA+B2Sm6jU2eMPg77O+tbOVqKceN/9f4PzigARYQiFVpEzo4ms0xlvw80zODFAAG58pgI4OG6AdHtuE1gmFYWiW7t2T1coRJnkntPD7I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0676
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/OSJUcwqe1KpFGwde1omzNFgJbLI>
Subject: [Anima] Feedback on constrained-voucher example voucher payloads (in Github / -09)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 14:34:04 -0000

Hi Peter,



Here my feedback as result of reviewing the example voucher payloads:



*** pledge-to-regis.txt:



1- there seems to be an error in the delta encoding of the numeric SID keys.  If I decode the CBOR from the COSE payload in pledge-to-regis, I get the following



{2501: {2503: "2020-10-5T13:46:13-00:00", 2505: "2022-10-5T13:46:13-00:00", 2502: 2, 2508: h'29C7BAFB81A2C6160D3357D22911F510', 2514: "pledge.1.2.3.4", 2511: h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}}



while based on https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13#section-4.2.1  I would expect something like

{2501: {2: "2020-10-5T13:46:13-00:00", 4: "2022-10-5T13:46:13-00:00", 1: 2, 7: h'29C7BAFB81A2C6160D3357D22911F510', 13: "pledge.1.2.3.4", 10: h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}}



This uses the delta encoding. In order to use the full SID number (e.g. 2503, 2505, etc.) these have to be prefixed with a CBOR tag. By default, delta encoding is to be used if that tag is not present.



2- for the Registrar certificate embedded in field '10' above, see my previous email about the certificates.



3- The Yang date-and-time format needs the date to be 2 digits always, so e.g.: "2020-10-05T13:46:13-00:00". For a constrained system the following equivalent string is even better: "2020-10-05T13:46:13Z"

4- The ‘created-on’ and ‘expires-on’ fields would typically not be included in the constrained Voucher request, because the Pledge doesn’t have current time e.g. a Real-time clock in typical situations nor access to NTP over the network prior to bootstrap. So I would expect this to be not included typically. If included the expires time should be sufficiently far in the future, i.e. later than the ‘created’ timestamp. That’s currently not the case. Leaving both out is the easiest solution :)  - the nonce is anyway used for freshness verification.


*** regis-to-masa.txt:

The decoded COSE payload looks as follows in CBOR diagnostic:

{2501: {2503: "2020-10-5T13:46:13-00:00", 2505: "2022-10-5T13:46:13-00:00", 2508: h'29C7BAFB81A2C6160D3357D22911F510', 2514: "pledge.1.2.3.4", 2506: h'433D4E4C2C2053543D4E422C204C3D48656C6D6F6E642C204F3D76616E64657273746F6B2C204F553D6D616E75666163747572696E672C20434E3D757569643A706C656467652E312E322E332E342C2073657269616C4E756D6265723D706C656467652E312E322E332E34', 2510: h'D28444A101382EA1045820F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1FD6EE5902ACA11909C5A61909C77818323032302D31302D355431333A34363A31332D30303A30301909C97818323032322D31302D355431333A34363A31332D30303A30301909C6021909CC5029C7BAFB81A2C6160D3357D22911F5101909D26E706C656467652E312E322E332E341909CF59023D30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC7558473045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A172CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE46DD3A7C60F5BB5'}}

1- see above comments on delta encoding and timestamps which shouldn’t be equal.

2- when I take the Issuer from the pledge.hex cert, I get the following bytes:
306F310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31153013060355040B0C0C6D616E7566616374757265723115301306035504030C0C6D6173612E73746F6B2E6E6C
This should be identical to the field  2506 (idevid-issuer) in above COSE payload, however in the decoded example it looks different. My ASN.1 decoder even can’t decode it properly.

3- as already discussed in issue https://github.com/anima-wg/constrained-voucher/issues/59 the COSE signing needs to be updated to include a certificate signing chain of the Registrar. (Can be length 1, 2, 3 or more)  This can only be implemented of course once we resolve this issue.


*** voucher-from-MASA.txt:

Decoded payload:

{2451: {2453: "2020-10-5T13:46:14-00:00", 2455: "2022-10-5T13:46:14-00:00", 2452: 3, 2458: h'29C7BAFB81A2C6160D3357D22911F510', 2462: "pledge.1.2.3.4", 2459: h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75', 2454: 0}}

1- see above on delta encoding and date values

2- the assertion value is 3, which is not defined, it should probably be 2 (proximity) here ?

3- the value of domain-cert-revocation-checks (2454) needs to be a CBOR boolean ‘false’. Currently uses an integer 0. Since YANG Boolean translates to CBOR Boolean.

4- the “expires-on” field is not really needed in the Voucher. See BRSKI section 5.6: the expires-on field is set for nonceless vouchers (since the nonce is used for freshness by the Pledge – not really a need to have an additional expiry time sent.)  See also RFC 8366 for examples, the expires-on field is there only used in nonce-less vouchers. And the  Yang module code for “leaf nonce” also formally defines a “must not” condition on the “expires-on” field so the two cannot really be used together.
But if we want to include this field for some reason (which seems to go against BRSKI and RFC 8366 so needs to be motivated!) then we would also rather set a shorter timespan for Voucher validity. E.g. BRSKI 5.6 recommends something like 20 minutes time as the expected time e.g. to complete the bootstrap process. 2 years seems really too long for this.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>    |   +31 6 2385 8339