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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 09 March 2020 16:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 85E573A134E for <anima@ietfa.amsl.com>; Mon, 9 Mar 2020 09:08:47 -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, 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 tRK_U9FzdxSq for <anima@ietfa.amsl.com>; Mon, 9 Mar 2020 09:08:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7473A1358 for <anima@ietf.org>; Mon, 9 Mar 2020 09:08:42 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 812823818F; Mon, 9 Mar 2020 12:07:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9990F9F9; Mon, 9 Mar 2020 12:08:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13EC88B58@DGGEMM531-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13EC88B58@DGGEMM531-MBS.china.huawei.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 09 Mar 2020 12:08:41 -0400
Message-ID: <4178.1583770121@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/sjafBSOspTyfqXGwovBI3UFDxig>
Subject: Re: [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: Mon, 09 Mar 2020 16:08:54 -0000

I will post -03 today, after a few other review comments.

"Xialiang (Frank, Network Standard & Patent Dept)" wrote:
    > This draft is useful for helping guy to get valuable guidance of
    > deploying BRSKI MASA service, please see my current comments as below:

Thank you for your comments.

    > 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?

SCEP is the Simple Certificate Enrollment Protocol.
It variously described as a Verisign/Cisco originated protocol described in
draft-gutmann-scep-XX.txt and in draft-nourse-scep-XX before that,
going back to 2000.  Never published, I think because of the problems that it
has, and because RFC7030 solves those problems.
In particular, any device/person posessing a valid password can typically
request any certificate contents.

Having said that, SCEP could be used in a controlled manufacturing
environment to do initial enrollment.  My understanding is that the issues
that make it a problem (and which I think has prevented the IETF from
publishing it, preferring EST/RFC7030) would not apply in a controlled
environment like a manufacturer.

I have added a section matching Laurence's slide 32.

    > pg 4:

    > has been started the first time.

    > comment:
    > Both in the manufacturing process and in-field provisioning process?

For on-device private key generation, the device needs to be started at least
once in the factory, when it is attached to the factory provisioning system.
After that, some flag needs to be set to prevent any further generation.
This could be as serious as a blowing a fuse!

I have clarified this section:
https://github.com/mcr/masa-operational-considerations/commit/10a12fb406d254dc1172ae5cb2be2f2cc920f709

    > 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?

This is device has a single serial number.
The point is that a device may not yet have a serial number, and it is
possible to assign the serial number during this process.  Or perhaps more to
the point, the manufacturer step that a serial number is assigned,  is the
right time to deploy the private key.


    > 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?

This comment is about relative levels of access to the private keys.
The key that the MASA uses to sign vouchers *needs* to be online.
The root-CA for the IDevID PKI can be offline, locked in a vault (and guarded
by Godzilla if you like).


    > 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?

I have changed the text to clarify that the private key is not needed online
after the CA has been retired, but that the intermediate CA certificate
should have infinite/indefinite lifetime.
  https://github.com/mcr/masa-operational-considerations/commit/07b551d2cad9584f6fbe984cd2ba854461ee7fb3


    > 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"?

It means to keep a (secure) copy with a lawyer in case the company goes under.
https://en.wikipedia.org/wiki/Source_code_escrow
        Source code escrow is the deposit of the source code of software with
        a third-party escrow agent. Escrow is typically requested by a party
        licensing software (the licensee), to ensure maintenance of the software
        instead of abandonment or orphaning. The software's source code is released
        to the licensee if the licensor files for bankruptcy or otherwise fails to
        maintain and update the software as promised in the software license
        agreement.

I have changed the text to speak about business continuity planning instead.

    > pg 7:

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



    > comment:

    > A PKI infrastructure for MASA?

Yes, for the voucher signing key.
Good cryptographic hygiene would replace the voucher signing key
periodically.  The PKI infrastructure means that the vouchers could still be
validated.

    > 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?

End-Entity certificates are certificates which are not Certificate
Authorities (whether root or intermediate).  The voucher does not need to be
signed by a certificate authority, as the voucher is not a certifiate.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-