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

Michael Richardson <> Tue, 10 March 2020 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A66C23A0C99 for <>; Tue, 10 Mar 2020 13:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 uj2ePvyfFrhL for <>; Tue, 10 Mar 2020 13:44:48 -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 7559D3A0C86 for <>; Tue, 10 Mar 2020 13:44:48 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 175CA38985; Tue, 10 Mar 2020 16:43:34 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4A510825; Tue, 10 Mar 2020 16:44:46 -0400 (EDT)
From: Michael Richardson <>
To: Toerless Eckert <>
cc: "anima\" <>
In-Reply-To: <>
References: <>
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: Tue, 10 Mar 2020 16:44:46 -0400
Message-ID: <1808.1583873086@localhost>
Archived-At: <>
Subject: Re: [Anima] comments about draft-richardson-anima-masa-considerations
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: Tue, 10 Mar 2020 20:44:52 -0000

Toerless Eckert <> wrote:
    > Very interesting document.

Thank you for your comments.

    > Some alas not very structured comments:

    > 1. tooling: would be great if you had a makefile that automatically
    > updates the .txt when you do a commit in github. .mkd is just 'ok',
    > but not 'great' to read (like .txt is).

I do.  And I regularly commit the .txt file too.
I just don't use the all-singing-all-dancing one, and I don't generate it via travis-ci.

    > 2. "A three-tier PKI infrastructure is appropriate"

    > I was confused by that statement vs. the followig text. When i heard for
    > example "intermedia CA" in other contexts (enterprise PKI
    > architectures), it meant that there was another layer of CA below the
    > intermediate CAs, namely the "assigning CA(s)". And they called that a
    > three-tier PKI infrastructure too.

The point you are making is whether we count End-Entity certificates or not.
I assumed one did, that the leaves were the third tier.
You are making the point that if we count only CAs, then I have described a
two-tier system.
My understanding is that all CAs which are not the root CA are intermediate
CAs, and that seems to be how they are described in most documentation I have

But, I don't operate a commercial CA, so I don't really know, which is why I
want these parts reviewed....

    > The reason for three tiers of CA is when you have multuple functions
    > within an organization that need to run CAs. The root CA is the offline
    > magic you described, so it not really for day to day work. The
    > intermediate CA are run by the enterprise security department which sets
    > policies which department can do what with their CAs. The departments
    > (like manufacturing) run the assigning ("leaf") CA.

I think that, for the purposes of produces and IDevIDs, that the manufacturer
should not mix their internal business CA (which has a "marketing" or
"manufacturing" department) with their product CA.
Except in the smallest of entities, they should not share the same root-CA,
and even in a 30-person operation, I still think that would be a mistake.

I can rewrite this to say it is a two-tier system, and clearly describe it
(probably add a diagram) as having a root, and a minimum of one intermediate
CA.  I have no objection if someone wants to have more levels :-)

    > Related: Whether or not you want a CA in the manufacturing plant also
    > depends on the trust model to your likely outsourced manufacturing plant
    > and the tracking/control you want to exercise on it. Your headqaurter
    > based CA will not sign IDevIDs for the plant cousins grey market plant
    > across the street ;-)

Exactly.  I have been trying to get Cullen to contribute to this document, as
he has direct experience dealing with the "across the street" problem.
Depending on the model of how/where the private key is generated, it could be
that no signing ever needs to occur in the plant.  Or access to the signing
system requires that some VPN be up to HQ.

    > 3. Title etc..

    > Something like "IDevID, MASA and voucher considerations for BRSKI infrastructures"
    > would be better matching the content.

I like that title, and I will use it.
I am concerned that MASA needs to be expanded in the title, though.
Doing so, makes it very long.

    > The text also reads more like design and not operations, maybe consider
    > if where you say "operations" (also in the text) it is really design.

I see your point.
I am laying out considerations on how to design the system based upon
operational concerns.

    > 4. "There are two fundamental ways to generate IDevID certificates ..."

    > But then you have 3 bullet points.

There are 10 kinds of people in the world... fixed.

    > 5.  Key generation process

    > I think the different mechanisms you describe also exist to support
    > other systems than those that we have constrained BRSKI to so far, e.g.:
    > also systems without certificates, but ... hmm, forgot name, the stuff
    > we discussed with ACME ?

Section 2 is about provisioning of secrets into devices, and it is hardly
unique to BRSKI.   The Intel SDO/ARM Pelion system, Rambus has a product that
is apparently widely used... part of the point of this document is to make it
clear that provisioning IDevID is a solved problem.

    > Maybe just note that these systems have additional pro and cons when
    > used outside of the realms of BRSKI with IDevID generation, but that
    > those differences are out of scope of this document. Until they are not,
    > because someone brings that stuff into BRSKI)

I'm not sure I understand what your objection :-)

    > 6.  why should i read this

    > The intro would be helped if it outlined example target readers and what
    > they would get out of reading the document.

Agreed, opened an issue.

    > 7. From where we are to BRSKI

    > I think one mayor reason why to read this are manufacturers that may
    > have have or plan to have one of the described IDevID designs and now
    > want to understand what is needed to add support for MASA to their
    > designs. That could be called out in the introduction, but i think
    > the IDevID section itself could better distinguish between the
    > description/judgement that is independent of MASA and then the
    > new MASA considerations. Maybe structure, put MASA text always at end of
    > options "When adding/using MASA in this option, the following
    > applies...".


]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [