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

Michael Richardson <> Sun, 05 April 2020 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F2123A10BF for <>; Sat, 4 Apr 2020 19:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YkUXA3XLJGlJ for <>; Sat, 4 Apr 2020 19:27:47 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 817E93A097C for <>; Sat, 4 Apr 2020 19:27:46 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 4E9A83897D; Sat, 4 Apr 2020 22:26:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4AF17AA9; Sat, 4 Apr 2020 22:27:43 -0400 (EDT)
From: Michael Richardson <>
To: "Panwei \(William\)" <>
cc: "anima\" <>
In-Reply-To: <>
References: <> <4178.1583770121@localhost> <>
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: Sat, 04 Apr 2020 22:27:43 -0400
Message-ID: <20160.1586053663@localhost>
Archived-At: <>
Subject: Re: [Anima] My comments about draft-richardson-anima-masa-considerations-02:
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Apr 2020 02:27:50 -0000

Panwei (William) <> wrote:
    >> 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.

    > [Wei] I think what needs to be explained is the distinct
    > characteristics of the serial number for the device. Maybe how it is
    > assigned is not important, but other aspects, such as what it is used
    > for, are important. So the readers can match the specific thing in
    > their implementation with the serial number you mean.

I am not sure I know what are the important characteristics.

For BRSKI, what is important is that the serial numbers found in the vouchers
are unique within the scope of the key/PKI that signs the voucher.

(So, different manufacturers can have overlapping serial numbers.
A single manufacturer that has different product lines with different MASA
PKI, such as described in section 3.2, can also overlap serial numbers)

Nothing else matters. The serial numbers don't need to be monotonically increasing,
don't need to dense, and don't even need to be numbers.
I think it's convenient if they are; I think that I would use a counter which
I'd encrypt, or maybe a seeded PRNG as many manufacturers don't want their
serial numbers to show many units they have sold.
Encoding it as base32 would seem like a good thing to me.

BRSKI doesn't care about any of those details though.

    >> > 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).

    > [Wei] Two comments:
    > 1) Why ongoing access to the root CA is important? In the document it
    > is said the root-CA private key should be kept offline, so how to
    > ongoing access to the root-CA?

The root-CA can be offline.
The root-CA is needed in order to resign the intermediate CA(s), but this
does not need to be done online.  It can be done via some kind of key signing
ceremony, depending upon the level security threat.
It's okay if the root-CA is unavailable for a few weeks (maybe even months),
as long as it the intermediate CA validity period does not run out.
This is why one would typically resign or re-generate new intermediate CAs at
their half-lifetime period.
(Consider what one would do if the key signing ceremony needed people from
across the world, and/or the primary HSM was located in Wuhan or Italy..!)

Splitting up the root key via secret splitting means that the rootCA key can
be recovered in a new location should there be a problem.

    > 2) This sentence seems inappropriate in this section. This section and
    > the upper-level section is talking about the device's IDevID. Suddenly
    > mentioning the MASA key doesn't make sense.

I understand.
I guess what I'm trying to do is contrast the differences in requirements.
A single process will not satisfy both sets of requirements.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-