Re: [Gen-art] Genart last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Alissa Cooper <alissa@cooperw.in> Wed, 10 July 2019 20:45 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF42120381; Wed, 10 Jul 2019 13:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=y0HVZG/Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aVoM+iBV
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 QQ6Zt4xwuj0f; Wed, 10 Jul 2019 13:45:03 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E9212037B; Wed, 10 Jul 2019 13:45:00 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3E3BE43B; Wed, 10 Jul 2019 16:44:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 10 Jul 2019 16:44:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=C 30JX6EtYVV4s0tVncwm984gsanhRGCXfRBgLKvNAxY=; b=y0HVZG/YkaEiu4KQ9 FacYpwY+y3MYhJr3G5jY7nnCYKxXcc2jSEckFeUsPCxzrLPXbTY0tKpqx31k1Q4L SS5VoA9XU8OOqwCDxOxMMxksLLvc5zMux5dk62xPfnPpiNZXPY99F8V0aPfiJY9x z2SXKUpTj6oilI2YAyVRrQaDfBe88zU4BYavIhr6gxwZMbSVSSC9ycyE9Ouhd0K8 PmAZG45ytWxDcR2cN0WUnKv98lENr3vDEyxOIi2eIX8QBuhvMI+h0PoZ1YfXdbjf 9cyve2+dat6LGfXVO02cvkMrpXnrJfn7i2nNexD4TkolRqh/xnCDobBWKgWUCdIX 0jW6w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=C30JX6EtYVV4s0tVncwm984gsanhRGCXfRBgLKvNA xY=; b=aVoM+iBV7c3XD6tZUwECyCykBbhzYmX0BSoPV50BhLkVmz9M2Uia/GW8G 6FlClPMTRXsPdKByEEiL7GMbW7OghCiE3CkwFfCG7q1JCXe+/HVYF0KnEWx9dm1F +J0HxFa1cS8Q5KDeBDj33sDI0J46Y8wGadPYnoD18rU6TcDDCigf4Z/hb3DTPF0v ptfDG0H1xq7i4xRqwL5FCf+GIZwR7Uo3rKiATGmFc6KlbZNc4vhnyetbL256Ly1j 7icnuS4lG3nTu0AEZv5l7TQy86DEL9Gm7axcgVeoJE+5KP4GZ4fDSDsVfZ/kpAfZ m3o7np+9MRU/Purx6HTsIAoeSGvPA==
X-ME-Sender: <xms:Sk4mXTTQZtNGHkzWfW7unLPbaHMqtgosTJZkiazIpymh8V9S1Rqa8Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeeigdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrledunecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:Sk4mXZBT6gqIAOHgoneMfGXSa94r-fLPKwY0JFeX2lYXyGQfcHmAvA> <xmx:Sk4mXT3hQ9cXcP2T8GY6Fahand4TI2fjWoJFo1wxydCMHWMBoh--Wg> <xmx:Sk4mXXW-fj2j-thmPIzrLu-1uv9H-cuhVjgqsi_WdDcOsWV2yz-c2Q> <xmx:Sk4mXRQyBzUFI-SGrx65ipGdigAZalblh5b-_6WcaJz6E1_k1vNfbQ>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id DB881380087; Wed, 10 Jul 2019 16:44:57 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <153874289877.989.15433226866680411112@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 16:44:57 -0400
Cc: gen-art@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <791CADFA-EB89-47AE-A808-FEA9D3B93A00@cooperw.in>
References: <153874289877.989.15433226866680411112@ietfa.amsl.com>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/eEdTWNZoSE7HgTtao3U066h6KjQ>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 20:45:13 -0000

Jari, thanks for your review. I reviewed the issues list on Github and it appears that the authors provided responses to all of your points, addressing many of them with text updates. Authors, thanks for that. I entered a DISCUSS ballot with just two outstanding comments.

Alissa

> On Oct 5, 2018, at 8:34 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> 
> Reviewer: Jari Arkko
> Review result: Not Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-anima-bootstrapping-keyinfra-??
> Reviewer: Jari Arkko
> Review Date: 2018-09-27
> IETF LC End Date: 2018-10-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> I have reviewed this document. My intent was to complete this review by the
> original Gen-ART and IETF last call deadline on October 2. Unfortunately,
> it took longer to read the document than expected, for which I apologize.
> Hopefully these comments are still useful.
> 
> I have some overall comments and then a number of more detailed technical
> and editorial comments.
> 
> First up, I agree with Christian Huitema's stellar review that was
> posted earlier on the IETF list. He brought out many of the most
> relevant questions about this specification.
> 
> I won't repeat those questions, but I'll observe that I *do* think it
> is useful to build enrollment and imprinting protocols, for various
> situations. It is beneficial for there to be standards in this space,
> and for those standards to support use cases that fit me and others
> that fit other people's goals. I do agree with Christian and others
> that one has to be careful about doing that though, and be careful
> about, for instance, avoid putting any party in a more controlling
> role than others purely due to how the technology is constructed.
> 
> I did encounter a number of question marks and have several
> suggestions throughout the document. It also wasn't an easy read,
> particularly from the point of view of understanding what its
> implications are.
> 
> My first bigger comment is that I believe the security and privacy
> considerations section should have provided an actual in-depth
> analysis of the characteristics offered by the protocol, perhaps under
> several different situations, as the protocol can be operated in
> different modes.
> 
> My second comment is that the protocol as defined is quite focused on
> manufacturer-controlled situations. As Christian mentioned, there is
> some discussion of other situations in the document (Section 6.4), but
> not much, and there's little information on what happens if one tries
> to use the protocol in this way. It would seem that a better support
> for getting a voucher or vouchers when the device is new and the
> manufacturer still around would alleviate some of the concerns that
> were raised in the IETF list discussion. There's little information
> about the security implications, little explanation of the various
> lifetimes and when infinite lifetimes are OK and when not, etc. All
> of those details would have been useful. But for now, it is difficult
> to even evaluate those aspects, because I don't know if I can use
> the protocol for in a more owner-oriented fashion. And if I can't,
> is that because of a fundamental limit or because we chose to design
> the protocol that way? 
> 
> More detailed technical comments:
> 
> Section 1:
> 
>> It uses a TLS connection and an PKIX (X.509v3)
>> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
>> points 1 and 2.  It uses a new artifact called a "voucher" that the
>> registrar receives from a "Manufacturer Authorized Signing Authority"
>> and passes to the pledge to answer points 3 and 2.
> 
> What is used to answer point 4?
> 
> Section 1.3.3:
> 
>> This document presumes that network access control has either already
>> occurred, is not required, or is integrated by the proxy and
>> registrar in such a way that the device itself does not need to be
>> aware of the details.
> 
> I understand why this limitation is specified, but this does considerably
> reduce the number of cases where BRSKI can be applied.
> 
> Section 2.1:
> 
>> A unique nonce can be
>> included ensuring that any responses can be associated with this
>> particular bootstrapping attempt.
> 
> It seems odd to have such a fundamental request-response matching
> be optional. Also, are these the same nonces as were described early
> for one-time usage limits, or different?
> 
> Section 2.2:
> 
>> Vouchers provide a signed but non-encrypted communication channel
>> among the pledge, the MASA, and the registrar.  The registrar
>> maintains control over the transport and policy decisions allowing
>> the local security policy of the domain network to be enforced.
> 
> Is this a potential privacy vulnerability, as there are serial numbers
> and possibly some other information in the voucher? (One could have,
> for instance, exposed a hash of the relevant information during the
> process onlu reveal the actual data once the encrypted channel is set
> up to avoid this.)
> 
> Section 2.3:
> 
>> 4.  (Optionally) communicating the MUD URL (see Appendix C.
> 
> There's plenty of potentially useful information that could be
> communicated. The linkage to MUDs seems a bit arbitrary. Could
> this perhaps be generalized?
> 
> Section 2.4:
> 
>> P---Voucher Request (include nonce)------>|                    |
> 
> Is this nonce the one inside the voucher or something different?
> 
> Section 3.1:
> 
>>  grouping voucher-request-grouping
>>    +---- voucher
>>       +---- created-on?                      yang:date-and-time
>>         +---- expires-on?                      yang:date-and-time
>>       +---- assertion                        enumeration
>>       +---- serial-number                    string
> 
> I'm not sure it is necessary to base everything on a serial number.
> 
> Section 3.2:
> 
>> "proximity-registrar-cert": "base64encodedvalue=="
> 
> I do not understand the notation that you are using here, nor did my
> grep for the above string find anything from the RFC directory other
> than in RFC 8366. Is "base64encodedvalue==" a value that you are using
> as an example, or some special format that signifies something else?
> 
> Section 4:
> 
>> A proxy MAY assume TLS framing for auditing purposes, but MUST NOT
>> assume any TLS version.
> 
> Is this specification sufficient to understand what this means
> from a actual behaviour point of view? Must pass all bytes unchanged?
> 
> Section 4:
> 
>> In the ANI, the Autonomic Control Plane (ACP) secured instance of
>> GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI
>> registrar ACP addresses and ports by ANI proxies.  The TCP leg of the
>> proxy connection between ANI proxy and ANI registrar therefore also
>> runs across the ACP.
> 
> MUST seems a strong keyword to use here. Perhaps some systems would
> like to use another mechanism, but this MUST prohibits any such
> changes. MUST support maybe...
> 
> Also, a bit later in Section 4.1 it says "The pledge MAY listen
> concurrently for other sources of information" which would seem to
> contradict the MUST.
> 
> Section 4.1:
> 
>> The result of discovery is a logical communication with a registrar,
>> through a proxy.  The proxy is transparent to the pledge but is
>> always assumed to exist.
> 
> Is it really a requirement that it must exist? I could imagine
> small networks where the registrar is on the network...
> 
> Section 4.1:
> 
>> A new temporary
>> address SHOULD be allocated whenever the discovery process is
>> forced to restart due to failures. 
> 
> Why is this necessary? It seems to set a pretty high requirement
> on the integration of the IP stack and the brski functionality.
> Presumably RFC 4941 is used by many applications and there
> should be support in the general facility for sufficiently
> frequent change of addresses.
> 
> Section 5:
> 
>> o  The pledge either attempts concurrent connections, or it times out
>>   quickly and tries connections in series.
> 
> Concurrent connections to where? You mean multiple proxies? Be more
> specific.
> 
> Section 5.2:
> 
>> nonce:  The pledge voucher-request MUST contain a cryptographically
>>    strong random or pseudo-random number nonce.  Doing so ensures
>>    Section 2.6.1 functionality.  The nonce MUST NOT be reused for
>>    multiple bootstrapping attempts.
> 
> But elsewhere in the document you talk about the nonceless case, so
> how can the nonce actually be mandatory? Or are there multiple nonces?
> The document is unclear on this.
> 
> Section 5.4:
> 
>> The registrar SHOULD verify that the serial number
>> field it parsed matches the serial number field the pledge
>> provided in its voucher-request.
> 
> It is surprising that this is only a SHOULD. The pledge will
> be made for a wrong device and/or there is an attack somewhere
> if the two values don't match.
> 
> Section 5.4.7:
> 
>> It MAY perform a simple
>> consistency check: If the registrar voucher-request contains a nonce
>> and the prior-signed-voucher-request exists then the nonce in both
>> MUST be consistent.
> 
> The formulation is odd, because you are specifying something optional
> (MAY) which then has a MUST statement but that statement relates
> to how things are supposed to be, not what the implementations should
> do.
> 
> And again, I think these consistency checks should be mandatory.
> 
> Section 5.5:
> 
>> expires-on:  This is set for nonceless vouchers.  The MASA ensures
>> the voucher lifetime is consistent with any revocation or pinned-
>> domain-cert consistency checks the pledge might perform.  See
>> section Section 2.6.1.  There are three times to consider: (a) a
>> configured voucher lifetime in the MASA, (b) the expiry time for
>> the registrar's certificate, (c) any certificate revocation
>> information (CRL) lifetime.  The expires-on field SHOULD be before
>> the earliest of these three values.  Typically (b) will be some
>> significant time in the future, but (c) will typically be short
>> (on the order of a week or less).  The RECOMMENDED period for (a)
>> is on the order of 20 minutes, so it will typically determine the
>> lifespan of the resulting voucher.
> 
> There are several issues here, the lifetimes of the imprinting with
> the owner/registrar vs. the lifetimes of the imprinting process
> artifacts. Please clarify. I *think* you are talking about the
> process expery times above, not about the expiry of the imprinting.
> And certainly I'd hope 20min is not the duration of the imprinting,
> but rather it needs to be infinite in most cases.
> 
> Section 5.5.2:
> 
>> The pinned-domain-cert MAY be installed as an trust anchor for future
>> operations.
> 
> Could this be used for future imprinting, or only for other things?
> Please clarify.
> 
> Section 5.7.1:
> 
>> 5.7.1.  MASA audit log response
> 
> I found this section not providing enough details to tell what
> the MASA should return. Everything? Only log entries concerning
> the device in question? Log entries for the same domain as in
> the indicated voucher request?
> 
> Section 5.7.2:
> 
>> A "proximity" assertion
>> assures the registrar that the pledge was truly communicating with
>> the prior domain and thus provides assurance that the prior domain
>> really has deployed the pledge.
> 
> I don't think I understand the promixity assurances. Obviously, the
> pledge and the owner's domain are in some kind of communication,
> but not sure how that proves proximity, given that requests from
> a pledge could easily be tunneled from somewhere else.
> 
> Section 6.2:
> 
>> 2.  The pledge MAY support "trust on first use" for physical
>>    interfaces such as a local console port or physical user
>>    interface but MUST NOT support "trust on first use" on network
>>    interfaces.  This is because "trust on first use" permanently
>>    degrades the security for all use cases.
>> 
>> 3.  The pledge MAY have an operational mode where it skips voucher
>>    validation one time.  For example if a physical button is
>>    depressed during the bootstrapping operation.  This can be useful
>>    if the manufacturer service is unavailable.  This behavior SHOULD
>>    be available via local configuration or physical presence methods
>>    (such as use of a serial/craft console) to ensure new entities
>>    can always be deployed even when autonomic methods fail.  This
>>    allows for unsecured imprint.
> 
> I think #2 is actually too conservative; with a "TOFU" button one
> would reasonably be able to pair devices to a local, previously
> untrusted registrar. And #3 is I suppose something along those lines,
> but defined quite imprecisely. One should verify the exchanges and
> signatures and go through the whole process, but NOT require signature
> from the trusted MASA.
> 
> Section 6.4:
> 
>> 6.4.  MASA security reductions
>> ...
>> 1.  Not enforcing that a nonce is in the voucher.  This results in
>>    distribution of a voucher that never expires and in effect makes
>>    the Domain an always trusted entity to the pledge during any
>>    subsequent bootstrapping attempts.
> 
> Depending on your viewpoint this may be a security reduction or
> increase. It is only a reduction if you are the manufacturer. Owners
> and users might wish to protect themselves against the manufacturer,
> however, in which case permanent vouchers are a feature, not a bug.
> 
> Section 8:
> 
>> 8.  Privacy Considerations
> 
> This does not discuss the role of serial numbers and other
> identifying information.
> 
> Section 9:
> 
>> 9.  Security Considerations
> 
> I expected to find a section that would go through the protocol and
> explain the security properties that it has, along with some
> discussion of residual vulnerabilities. What I found was a discussion
> of a handful of specific issues, such as the impacts of trusting the
> manufacturers, or why the nonce design is the way it is in the
> protocol.
> 
> I'd find it useful to have, say, a discussion for each major
> mode of the protocol and what security properties it provides
> and does not provide.
> 
> Nits/editorial comments: 
> 
>> BRSKI provides a solution for secure zero-touch (automated) bootstrap
>> of virgin (untouched) devices that are called pledges in this
> 
> Maybe s/virgin (untouched)/new (unconfigured)/
> 
>> Services that benefit from this:
>> o  Device management.
>> o  Routing authentication.
>> o  Service discovery.
> 
> Are these examples? If so, say so? Otherwise, please specify why these services
> and not others are suitable for BRSKI.
> 
>> the following actions are required and MUST be performed by the
>> pledge:
>> 
>> o  BRSKI: Request Voucher
>> o  EST: CA Certificates Request
>> o  EST: CSR Attributes
>> o  EST: Client Certificate Request
>> o  BRSKI: Enrollment status Telemetry
> 
> Actions? Operations? Steps? (Later you use the term operations.)
> 
> Would be good to clarify if the listed items are sending a message, or
> performing a procedure called <something>, or something else. Wording
> here is quite loose.
> 
>> 1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices
> 
> FWIW, it would have felt more natural to have thee requirements specified in the
> ANI documents, rather than here.
> 
>> The pledge goes through a series of steps, which are outlined here at
>> a high level.
> 
> The Section 2.1 steps in the figure do not match the "actions" from
> Section 1.5.
> 
>> 4.  Imprint on the registrar.  This requires verification of the
>>    manufacturer service provided voucher.  A voucher contains
>>    sufficient information for the pledge to complete authentication
>>    of a registrar.  (The embedded 'pinned-domain-certificate'
>>    enables the pledge to finish authentication of the registrar TLS
>>    server certificate).
> 
> There is a lot going on here. Might have been better to separate the
> steps.
> 
>> After imprint a secure transport exists between pledge and registrar.
> 
> Do you mean there's an open TLS/TCP connection or that there are
> credentials&keys to securely communicate between the two?
> 
>>  The pledge goes through a series of steps, which are outlined here at
>>  a high level.
>> 
>> ...
>> 
>>  |            +------v-------+
>>  |            | (6) Enrolled |
>>  ^------------+              |
>>   Factory     +--------------+
> 
> "Enrolled" is not a step, but rather a state...
> 
>> 2.  Securely authentating the pledges identity via TLS connection to
> 
> typo
> 
>> 2.  Securely authentating the pledges identity via TLS connection to
> 
> s/pledges/pledge's/?
> 
>> registrar.  This provides protection against cloned/fake pledged.
> 
> s/pledged/pledge/?
> 
>> 3.  Secure auto-discovery of the pledges MASA by the registrar via
>>    the MASA URI in IDevID as explained below.
> 
> I can't parse the sentence.
> 
>> 4.  (Optionally) communicating the MUD URL (see Appendix C.
> 
> Missing closing paren.
> 
>> The following newly defined field SHOULD be in the PKIX IDevID
>> certificate:
> 
> I didn't understand the formulation here. Are you defining one
> (seems like it below) or are you referencing a newly elsewhere
> defined field? Suggest a reformulation, e.g., "This document
> defines a new field for PKIX certificates. These fields SHOULD
> appear in the PKIX IDevID certificates when used with BRSKI."
> 
>> Specifically, the IDevID:
>> 
>> 1.  Uniquely identifying the pledge by the Distinguished Name (DN)
>> ...
>> 2.  Securely authentating the pledges identity via TLS connection to
>> ...
>> 3.  Secure auto-discovery of the pledges MASA by the registrar via
>> ...
>> 4.  (Optionally) communicating the MUD URL (see Appendix C.
>> 
>> 5.  (Optional) Signing of voucher-request by the pledges IDevID to
>> ...
>> 6.  Authorizing pledge (via registrar) to receive certificate from
> 
> There's something wrong with the language here. Maybe "Specifically,
> the IDevID enables the following: 1. Unique identification of the ..."
> 
> Section 2.4 protocol flow is very different from the explanation
> in Section 2.1, which does not show the role of the background
> systems (MASA) at all.
> 
>> P                     |       /--->       |                    |
>> P                     |       |      [accept device?]          |
>> P                     |       |      [contact Vendor]          |
>> P                     |       |           |--Pledge ID-------->|
>> P                     |       |           |--Domain ID-------->|
>> P                     |       |           |--optional:nonce--->|
>> P                     |       |           |     [extract DomainID]
>> P                     |    optional:      |     [update audit log]
>> P                     |       |can        |                    |
>> P                     |       |occur      |                    |
>> P                     |       |in         |                    |
>> P                     |       |advance    |                    |
>> P                     |       |if         |                    |
>> P                     |       |nonceless  |                    |
>> P                     |       |           |<- voucher ---------|
>> P                     |       \---->      |                    |
> 
> I had a difficulty in understanding the notation here. Is the
> thing in the middle with the label "optional" a bracket that
> shows a part of the flow can be at a different place? Or is it
> some entity with some messages flowing from it, because it has
> arrows? I think the format, but this is unclear.
> 
>> The registrar uses an Implicit Trust Anchor database for
> 
> Upon the first reference to the term you should include a
> reference to RFC 7030.
> 
>> be-determined mechanism (such as an Intent) to become the local
> 
> Reference needed to "Intent".
> 
>> 4.2.  CoAP connection to Registrar
>> 
>> The use of CoAP to connect from pledge to registrar is out of scope
>> for this document, and may be described in future work.
> 
> I would just have said other mechanisms can be defined in future work.
> 
>> In the nonced case, validation of the registrar MAY be omitted if the
> 
> Nonced?
> 
>> assertion:  The assetion leaf in the voucher and audit log indicates
> 
> Typo
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art