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

[Michael Richardson <[e-mail]>]

Panwei (William) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-