Re: [Anima] Feedback on constrained-voucher example certificates (in Github / -09 )

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 18 November 2020 14:50 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 380D93A0A2E for <anima@ietfa.amsl.com>; Wed, 18 Nov 2020 06:50:58 -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 vA7X7YuGkZfi for <anima@ietfa.amsl.com>; Wed, 18 Nov 2020 06:50:55 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70139.outbound.protection.outlook.com [40.107.7.139]) (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 4DC053A0A2C for <anima@ietf.org>; Wed, 18 Nov 2020 06:50:54 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pg3xU7K4YKJlgzMrY6VuuwygEEi90mRiaRHOzdz30AMviZ4eDUt9E+FVDI1+2rGnbr3dee5FXD4VtsQsmL9eR/Vhu1Bot1aoNSSs49MsOeGe/sSKm8zRUpGj60ocGtWgnJWIu8f7Fvy98AnLYKGNAytosDmdKysyP6AZuIOomdNk1hgSUvHAfIKWA8p21+LFGY+mQV328a1PGbs5LnMWauv8V99VZ3R2y3msAHep94WgQAtaO0DBNLUmm+5sA8P2dhMjJK41sTI3TCIylayLwZ4mdyzH6/RlSyZTKthy0J3kQJ9GLsu5lGuM/vKLE0C27lnYIITVgdWFLjT0uA4g/Q==
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=cid8/etiNeLb+v2oeboaYY/gtBtXMjHrrjkyU0aNRXQ=; b=baTxt0hvP78lx5sLY6Mx0ScvYptFgOWVhMGKU4cjStEkEfbUyMMkSneNot6wH/LhwoSncs4YTk1oCv31INSHFXQ9YIp8CgPCdo9bfH5KFZ/0v/skv47tCHsZiJ0N0QedXIiJLpvZ/DHb0vWMyXoONeoMHkqC0olpwkQQ6thatEQ64aALzAk9firoR9excF0Y3NFsuUJ2RYMHqCe4aon40RBFgxJGlQIunAmRO7zQJZdj/hXJ8mmlF9UJdCCebupMOOn7zT8UNPyw8ikUh+Cxz2C7KBn2+rWr2OvrJCkulav9aVaWmVVkc1CKooRKv7LlrukzVhu5D988E4vPKRRPKw==
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=cid8/etiNeLb+v2oeboaYY/gtBtXMjHrrjkyU0aNRXQ=; b=LErzQiUo5I20DYGjbd9818KD3L4ttubYjkA5FL7tcvQtw3/vwtPyNAns4s4p2BW111fxjqvRqoQUo88m9Aep4E23TVp1ssbSI2vfqRaJouR0z++3W4EayojxBnJJpA8L4xj47Xq9awkb4KH+Pm23MSZRt9ADQ8sddwGugf63kOw=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1267.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:264::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Wed, 18 Nov 2020 14:50:51 +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.3589.021; Wed, 18 Nov 2020 14:50:51 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "Panos Kampanakis (pkampana" <pkampana@cisco.com>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Feedback on constrained-voucher example certificates (in Github / -09 )
Thread-Index: Ada8yTuRMneYZouPQ2WsDETw+5FtUQA74sQw
Date: Wed, 18 Nov 2020 14:50:50 +0000
Message-ID: <AM8P190MB0979B33C6FA2A3A1AECF4B8DFDE10@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <AM8P190MB0979397BCEE4561869E4CD5DFDE20@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P190MB0979397BCEE4561869E4CD5DFDE20@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:cd7e:25a6:ebbe:2f77]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 197b4980-6a39-4bdd-a362-08d88bd157cb
x-ms-traffictypediagnostic: AM9P190MB1267:
x-microsoft-antispam-prvs: <AM9P190MB1267E048438667FC72B18FCFFDE10@AM9P190MB1267.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: PLhxKKZ6OEjYz/Zz5+Gq/wH4u5U6eONIDP8nBfRJto9AuKw1gChT7SeezrINmTin0r0yuHPdOyZLnM8E+dCvAkluBXMW7kHVPI7vIdpXCk1hXOdu+nrCKYGfrd1FY8aUNjXdtwz667vaEn61oW+O591dXqQvSt3XtWSg4Q58UUki7EGvrUiS9S5WYtaPgFYDKGx0t7AI+W8fwSg3KxmJhAFEhLS4XQhXuTMvRl3qy/YYdmfJ6p4kVdW6XDkWWIqBPGUJJwlouyzY6Juq2HlIc5j11U9Q8x74+HsQ85L2c0dyPsxrIaMEuak3XfYYAZc+AhRXRevbPK4ZhTI51jlfOMlyT9uJQnM2RpC4rlIZ6jQ63a3la+mXyFe8KED5gfMzGCZrJPxgMLab/d24a+rPPQ==
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:(396003)(376002)(346002)(136003)(39830400003)(366004)(7696005)(9686003)(86362001)(52536014)(166002)(71200400001)(186003)(110136005)(33656002)(55016002)(5660300002)(316002)(8676002)(44832011)(966005)(66946007)(66446008)(83380400001)(76116006)(8936002)(66476007)(6506007)(4326008)(53546011)(2906002)(66556008)(64756008)(478600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xWOEq/I5N2Yia17kSw64xCsmH8wOEO65mz9Phy639coXT8D4KWUqo03GQv35SV7o9XxxOyICaEmS3FCqhXg/KQPaCJdX+LktRgboxUD+m548BbBLMA/QXZ6ifd53CUKMd9/QfoCTgLSPL9GoUbiMKXVpL7kgUTX7ANR4jNbMM7h8y5gx16R67S0UMzZhr2O5McmwKbR7Aw7YzP3sbcqnLQeGMe3di2fLQjWNw2WDdiLNyOR1C3nbyRr3nvhD7x+KPlZVpm+YqoNc2wON09cgh+Ofw5s9ZJ5XpDj8eJEVvJG7rEgPOUuaG40O3TADV/2HL5M/LVy9oC/FO72+sbTAQPfNnXP1pPoka9m08YHx9p47zyOpHhFxFb+RiMF1CgUGjk74Uxht7dvYzL4CexjQ/aYd41vYiARQUh5gcK9wCR7jVqSPhsIqhm213qMXe015IEoaE0Z+Jw7xoTBXYZtmugDM1XdRmEU+LGESyFeKyPXyu+78gCpkIigXZiOkp5Vg3zGz5FR2P994TPKdfB7bQ/RGddCOpjPAHaxH2ZUxBbrT7BntBV3uWe8EscNgACl6FbLiYc3FNJu2UY93wLtc+FCIL1boNgBV12yYFSeXLl6Hxu9obOIFNZiMh9CaVfxDD0lX0mWJk32kHP79xN1C4FyayYBJJa6ZHCYjHf/8RKpiRiDO+Yt9fHIUXePmGcDE9/Diqq9vamG+3KGNZOYhmA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979B33C6FA2A3A1AECF4B8DFDE10AM8P190MB0979EURP_"
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: 197b4980-6a39-4bdd-a362-08d88bd157cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 14:50:50.8283 (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: nrsK0fWL2BHuUH4DLswxOlr9XWplACW6gBx0Sh95wi59Pr9FmCW9/fIB5XJnSqP1uZg9OpGz7PbFk5xCiodtldOTwksAjLWkUKCcXMmztaY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1267
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/0WQPGnGuaq7OJi1fppa1C2xiadE>
Subject: Re: [Anima] Feedback on constrained-voucher example certificates (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: Wed, 18 Nov 2020 14:50:58 -0000

PS one more remark on the Registrar certificate:  per BRSKI, the Registrar must have the id-kp-cmcRA extension in its certificate to make it a Registration Authority (RA). As defined in https://tools.ietf.org/html/rfc6402#section-2.10.
I did not see this in the certificate.  In principle, the Pledge could reject the Registrar as not-valid EST server for this reason (per RFC 7030) and the MASA will reject the Registrar (per BRSKI).

Esko

From: Esko Dijk
Sent: Tuesday, November 17, 2020 11:12
To: 'peter van der Stok' <stokcons@xs4all.nl>nl>; Michael Richardson <mcr+ietf@sandelman.ca>ca>; Panos Kampanakis (pkampana <pkampana@cisco.com>
Cc: anima@ietf.org
Subject: Feedback on constrained-voucher example certificates (in Github / -09 )

Hello Peter,

I did my review of the new example certificates in Github. Below my feedback. Because examples are used in the constrained-voucher draft Appendix C, I include all authors in this email.

pledge-cert.txt / pledge-cert.hex (https://github.com/anima-wg/constrained-voucher/blob/master/examples/pledge-cert.txt) :


  *   The X509v3 extension ‘subjectKeyIdentifier’ should not be included according to the 802.1AR-2009 spec section 7.2.6 (for IDevID/LDevID).  Reason is that this value in an EE certificate is never used for chain building; it’s unnecessary bytes effectively.  Only CA certs do need this extension.
  *   The X509v3 extension ‘keyUsage’ is present, and is allowed per the 802.1AR-2009 spec section 7.2.13 , however looking at the 802.1AR text there it basically says restrictions of key usage shouldn’t be necessary for an IDevID – it can be used for any purpose whether defined today or in the future. (Up to the year 9999 at least :-) )
BRSKI-45 also writes “therefore RECOMMENDS that no key usage restrictions be included” for IDevID.

masa-cert.txt / masa-cert.hex (https://github.com/anima-wg/constrained-voucher/blob/master/examples/masa-cert.txt) :

  *   the validity (1 year) seems a little short for a manufacturing root CA.  3, 5, 7, or 10 years I would expect to be more usual for such a CA.
  *   Of course a Pledge stores this root CA cert in its trust store for the entire device lifetime, and will keep using it during this lifetime. Even if that root CA cert expired and the Pledge has a realtime clock so it *could* verify expiry in principle. But it will not do that, because the cert is hardcoded in its trust store. So I’m not sure if the validity of it has any impact in practice; it seems not.
  *   Side note 1: the MASA will need to sign Vouchers with this root CA identity , for many years to come,  and in the meantime the root CA cert may expire and MASA may be given a renewed root CA cert that uses the same public/private keypair.  The latter – using same keypair - ensures that ‘older’ Pledges can still recognize the signer and so accept these newer Vouchers. So the MASA’s root CA cert validity period will impact how often the cert needs to be renewed – all the time using the same pub/private keypair – and that seems to be all.
  *   Side note 2: one can also have a MASA signing the Vouchers using an expired root CA cert/identity.  The Registrar and the Pledges won’t mind.
  *   Side note 3: another easy way out of this is to give the MASA root CA certificate also a very long / infinite lifetime just like the IDevID.

registrar-cert.txt / registrar-cert.hex (https://github.com/anima-wg/constrained-voucher/blob/master/examples/registrar-cert.txt)

  *   (Looks ok)

pledge-to-regis.txt  (https://github.com/anima-wg/constrained-voucher/blob/master/examples/pledge-to-regis.txt)

  *   Looks like this should be a .hex file! Not .txt.
  *   (May consider a filename like ‘pledge-to-regis.cbor.hex’ to indicate it is hex-format CBOR binary)
  *   Similar comment for the other ‘x-to-y’ .txt files.
  *   I will review the contents of these files later on!

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>