Subject: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 16 Oct 2019 07:50:07 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS points. Original COMMENT below.

------

I think this document would benefit from two concise lists, with notes about
which items in each list are defined in this document and which ones are not
defined: (1) what is operationally required of a manufacturer to support BRSKI,
and (2) what is operationally required of a domain owner to support BRSKI.

= Section 2.3.1 =

What precisely is meant by "TPM identification"? Could a citation be provided?

= Section 10.1 =

"The domain can maintain some privacy since it has not necessarily been
   authenticated and is not authoritatively bound to the supply chain."

What does this mean? That the domain can expect the manufacturer not to trust
the domainID because it hasn't been authenticated?

= Section 10.2 =

"The above situation is to be distinguished from a residential/
   individual person who registers a device from a manufacturer: that an
   enterprise/ISP purchases routing products is hardly worth mentioning.
   Deviations would, however, be notable."

What does the last sentence mean?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 23:12:37 +0200

> and (2) what is operationally required of a domain owner to support

Please see a diff at: https://tinyurl.com/y5l4xz3z
I will not get to the YANG Doctor review before the IESG call tomorrow,
so I won't post -29 until I do.

I have add a section with this list:

     9.1.  Operational Requirements  . . . . . . . . . . . . . . . .  70
       9.1.1.  MASA Operational Requirements . . . . . . . . . . . .  70
       9.1.2.  Domain Owner Operational Requirements . . . . . . . .  71
       9.1.3.  Device Operational Requirements . . . . . . . . . . .  72

I have placed it under the Applicability statement to ACP, as I think that
other users might need to change things.

    > What precisely is meant by "TPM identification"? Could a citation be

In -28 we don't have the words TPM identification.  We ripped the TPM
identification out a few revisions ago.  It was a point form about a
subjectAltName that might come from the 4108 HardwareModuleName.  The text
was there as a workaround for legacy/deployed TPM modules out there; it turns
out the concerns were ill-founded.

    > the domainID because it hasn't been authenticated?

A domain that didn't want to leave so many traces in the audit-log could
cycle through different key pairs much like we do with IPv6 temporary addresses.

    > What does the last sentence mean?

That text was changed in -28 to:

   The above situation is to be distinguished from a residential/
   individual person who registers a device from a manufacturer.
   Individuals do not tend to have multiple offices, and their registrar
   is likely on the same network as the device.  A manufacturer that
   sells switching/routing products to enterprises should hardly be
   surprised if additional purchases switching/routing products are
   purchased.  Deviations from a historical trend or an establish
   baseline would, however, be notable.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-