[Anima] My comments about draft-richardson-anima-masa-considerations-02:

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Fri, 28 February 2020 06:40 UTC

Return-Path: <frank.xialiang@huawei.com>
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 236C43A115B for <anima@ietfa.amsl.com>; Thu, 27 Feb 2020 22:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGHz7iy9WqAs for <anima@ietfa.amsl.com>; Thu, 27 Feb 2020 22:40:27 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 359453A1159 for <anima@ietf.org>; Thu, 27 Feb 2020 22:40:27 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 03E23704BB91C498D5D5 for <anima@ietf.org>; Fri, 28 Feb 2020 06:40:25 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 06:40:24 +0000
Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.69]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Fri, 28 Feb 2020 14:40:21 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: My comments about draft-richardson-anima-masa-considerations-02:
Thread-Index: AdXuAaZTd23akt0LRFiEvEAkZcXn1g==
Date: Fri, 28 Feb 2020 06:40:20 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EC88B58@DGGEMM531-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.46]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EC88B58DGGEMM531MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/PSkpYZs0C_RLzUFD2BSMipEggfQ>
Subject: [Anima] My comments about draft-richardson-anima-masa-considerations-02:
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, 28 Feb 2020 06:40:29 -0000

Hi Michael,
This draft is useful for helping guy to get valuable guidance of deploying BRSKI MASA service, please see my current comments as below:


pg 4:

   One way to do the transmission is during a manufacturing during a Bed

   of Nails (see [BedOfNails]) or Boundary Scan.



comment:

   Can the manufacturer internal scep or similar protocols be the other ways?



pg 4:

   has been started the first time.



comment:

   Both in the manufacturing process and in-field provisioning process?



pg 4:

   A serial number for the device can be assigned and placed into a



comment:

   Is it appropriate to assign the serial number to device, since device has

   already had its own SN?



pg 5:

   Ongoing access to the root-CA is important, but not as critical as

   access to the MASA key.



comment:

   MASA key is not relevant with the IDevID three-tier PKI

   infrastructure. So, does this sentence make sense here?



pg 5:

   The IDevID certificates have very long (ideally infinite)

   validity lifetimes for reasons that [ieee802-1AR] explains, but once

   the certificates have been created the intermediate CA has no further

   obligations as neither CRLs nor OCSP are appropriate.



comment:

   Miss some text here for clarifying how the updated intermediate CAs with

   new keypair can still be used to validate the old IDevID which is issued

   with the intermediate CA's old keypair. Can the updated intermediate CA

   still store and use the old keypair?

   And why do you say that the intermediate CA has no further obligations for

   its status update once the IDevIDs have been created?



pg 6:

   A plan to escrow the signing keys SHOULD be detailed, and it is

   likely that customers will want to review it for high-value products.



comment:

   what is the "escrow the signing keys"?



pg 7:

   In order to avoid locking down a single validation key, a PKI infrastructure is

   appropriate.



comment:

   A PKI infrastructure for MASA?



pg 7:

   a new End-Entity (EE) Certificate with an online

   private key, and use that to sign voucher requests. The entity used

   to sign [RFC8366] format vouchers does not need to be a certificate

   authority.



comment:

   Why is it the EE Certificate?


B.R.
Frank

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!