Bootstrapping Remote Secure Key Infrastructure (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-45

Received changes through RFC Editor sync (created alias RFC 8995, changed title to 'Bootstrapping Remote Secure Key Infrastructure (BRSKI)', changed abstract to 'This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.  Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks.  Support for deployment models with less stringent security requirements is included.  Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.', changed pages to 116, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-05-21, changed IESG state to RFC Published)

[Ballot comment]
Thanks for putting in all the work to get this over the finish line!
I did a final read-through before entering my YES, which produced some
non-blocking comments.

Section 5.1

  The signatures in the certificate MUST be validated even if a signing

nit: just "signature" singular?

Section 5.2

  assertion:  The pledge indicates support for the mechanism described
      in this document, by putting the value "proximity" in the voucher-
      request, and MUST include the "proximity-registrar-cert" field
      (below).

Sorry if I asked this already, but is the "MUST include" only when the
"proximity" assertion is used?  The current text could be read that it
applies always.

Section 5.4

It's too bad we can't mention SCRAM in addition to Basic and Digest, but I
guess that ship has sailed.

Section 5.5

  The voucher media type "application/voucher-cms+json" is defined in
  [RFC8366] and is also used for the registrar voucher-request.  It is
  a JSON document that has been signed using a CMS structure.  The
  registrar MUST sign the registrar voucher-request.
  [...]
  [...]
  [...]
  MASA impementations SHOULD anticipate future media types but of
  course will simply fail the request if those types are not yet known.

I think these two paragraphs were originally next to each other but with the
large amount of intervening text it seems like the transition could be
improved.

Section 5.5.2

  A certificate chain is extracted from the Registrar's signed CMS
  container.  This chain may be as short as a single End-Entity

(I guess technically the CMS structure is an unordered set of certificates,
not a chain, but we're using it as a chain so I don't mind this usage.)

  The MASA MAY use the highest certificate from the certificate chain
  that it received from the Registrar, as determined by MASA policy.  A

"highest certificate" is not a particularly common usage; "farthest in the
chain from the end entity" might be more conventional.

Section 5.5.3

  As described in Section 5.5.2, the MASA has extracted Registrar's
  domain CA.  This is used to validate the CMS signature ([RFC5652]) on
  the voucher-request.

  Normal PKIX revocation checking is assumed during voucher-request
  signature validation.  This CA certificate MAY have Certificate
  Revocation List distribution points, or Online Certificate Status
  Protocol (OCSP) information ([RFC6960]).  If they are present, the

We could maybe wordsmith this a bit to only cover the case when the
pinned-domain-cert is a CA cert (vs. end entity).

Section 5.5.4

This section mentions that checking for the presence of id-kp-cmcRA in the
registrar's cert protects the domain in some cases, but that protection is
probably weakend in cases when the pinned-domain-cert is not the domain's
root CA.  That said, the failure mode is not catastrophic, since the
registrar still has to authenticate to the MASA somehow, and the MASA logic
can account for the different cases.

Section 5.6

  correct registrar, the pledge MUST NOT follow more than one
  redirection (3xx code) to another web origins.  EST supports

s/web origins/web origin/

Section 5.6.1

missing close parenthesis for "(according to local policy[...]"

Section 5.8.2

  The domainID is determined from the certificate chain associated with
  the pinned-domain-cert and is used to update the audit-log.

Is it determined from the "chain associated with" or just the
"pinned-domain-cert" itself?

Section 7.1

  Join Proxy:  Provides proxy functionalities but is not involved in
      security considerations.

The Join Proxy is not involved in crypto, as noted here, but could drop or
delay traffic.

Section 7.3

      X.509 IDevID factory installed credential.  New Entities without
      an X.509 IDevID credential MAY form the Section 5.2 request using
      the Section 5.5 format to ensure the pledge's serial number
      information is provided to the registrar (this includes the
      IDevID AuthorityKeyIdentifier value, which would be statically
      configured on the pledge.)  The pledge MAY refuse to provide a

It's not entirely clear to me why "(this includes the IDevID
AuthorityKeyIdentifier value" holds (it's not in the idevid-issuer, I
think), but if it's clear to others that's fine.

Section 9.1.1

  full sales channel integration where Domain Owners need to be
  positively identified by TLS Client Certicate pinned, or HTTP

I'm not sure if this was intended to be "by a pinned TLS Client Certificate" or
"by the pinned-domain-cert".

Section 10.3

It looks like the second paragraph may be an editing remnant (copy of text
being modified in the first paragraph).

Section 11.6.2.1

I guess the vouchers created by an attacker with access to the MASA signing
key would not necessarily be in the audit log, which is probably worth
mentioning.

Appendix B

  Discovery of registrar MAY also be performed with DNS-based service
  discovery by searching for the service "_brski-
  registrar._tcp.".  In this case the domain "example.com" is
  discovered as described in [RFC6763] section 11 (Appendix A.2
  suggests the use of DHCP parameters).

Is there a mismatch between "" and "example.com"?

[Ballot discuss]
Thanks for the updates leading to the -39; I believe we're almost there!

Unfortunately, it seems that the "pinned-domain-cert" in the issued voucher
is the registrar's cert, not the CA cert.  (Given that the documented workflow is
to extract this CA cert from the registrar-voucher-request CMS object, and the
registrar-voucher-request in our examples does include both the registrar cert
and the CA cert, I wonder if this reflects a bug in the code itself used to generate
the examples, in that it picks the wrong cert?)  My understanding is that the
protocol requires this field to be populated by a CA cert, and the registrar's
cert is not a CA cert.

I am very hopeful that we can just regenerate the voucher without having to
redo the rest of the examples, since we have all the keys and certificate enshrined
in the document already, and my apologies for not noticing whether this issue was
present in previous revisions as well.

[Ballot comment]
I would make this a Discuss point but I think I already had my chance at the text and
missed it: Section C.1.5 says that "The public key is used by the registrar to find the MASA",
but it's really the certificate (via the "MASA URL" extension) and not the public key that
is so used.

I would suggest noting in C.2 that the asn1parse output is truncated at $number
columns, and specifically calling out that this makes it hard to differentiate between
organizationally related name components, specifically "highway-test.example.com CA"
and "highway-test.example.com MASA".  (The full asn1parse output from the live openssl
CLI is much clearer about the distinction.)

[Ballot discuss]
Thanks for the updated examples using the allocated MASA URL extension OID!

Unfortunately, I think there are still some inconsistencies in the examples to resolve:

The MASA cert/key is identical to the "manufacturer key pair for IDevID
signatures" (C.1.1 and C.1.2).  (It shows the MASA Subject CN, so maybe
just the included file was typo'd?)  The example IDevID cert shows an
issuer name that doesn't match the cert given.
(Also the MASA cert doesn't have a randomized serial number but the
registrar one does.)

The registrar-to-MASA voucher request in C.2.2 seems to have a CMS
SignedData with the SignerIdentifier identifying the "Unstrung Fountain
Root" (i.e,. the root CA used for these examples) instead of the
expected "fountain-test.example.com".  Am I misreading the ASN.1 dump?
(We do seem to send both certificates.)

The voucher response from MASA to Registrar seems to be signed by the
"highway-test.example.com CA" (which would be the "manufacturer key pair
for IDevID signatures" that we don't have in the -35 since the MASA
certificate is repeated), not the MASA's cert from C.1.1.

[Ballot comment]
Thanks for addressing Tom Petch's comments about the YANG.

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?

[Ballot discuss]
I think we're down to just:

Email exchange with mcr notes:
>    > An RFC Editor note about the RFC 8366 assignment of OID
>    > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
>    > properly use that assigned OID now?
>
> We got a MASA URL Extension OID for:
>    1.3.6.1.5.5.7.1.32
>
> the examples date from before that, and do not use it yet.

We need to fix the examples before publication.

[Ballot comment]
[COMMENT unchanged from -31 and probably all stale]

A few new comments on the -30 and -31 to start.  I think some of my comments
on the -29 are still valid, and will try to remove ones that have been addressed.
To reiterate: to the best of my knowledge, all the comments in this ballot position
are actionable and have not been overtaken by events.

In Section 5.9.4:

  In the case of a FAIL, the same TLS connection MUST be used.  The
  Reason string indicates why the most recent enrollment failed.

I'd suggest something more like "In the case of a failed enrollment, the
client MUST send the telemetry information over the same TLS connection
that was used for the enrollment attempt, with a Reason string indicating
why the most recent enrollment failed.  (For failed attempts, the TLS
connection is the most reliable way to correlate server-side information
with what the client provides.)"
(Also, why is "FAIL" capitalized?)

Thanks for the text in Section 11.2 about second-preimage-resistance of
DomainID calculation; the grammar needs a tweak or two, though.  My
suggestion would be to either drop "The consequences of" or add "be to" to
make "would be to allow" (but not both).

Section 11.3 has gone back to just "Devices which are reset to factory default
in order to perform a second bootstrap with a new owner MUST NOT use idential
seeds", but I think it's important to be clear about what the scope of uniqueness is.
The text in Section 5.2 is pretty good in this regard, with respect to the nonces
(which are generally derived from the seed); I wonder if we might want to
restructure this text to be more like "The random seed used by a device at boot
MUST be unique across all devices and all bootstraps.  Resetting a device to
factory default state does not obviate this requirement."  (FWIW, I think the
text in the -29 was that way because of my request.)

[A few comments on the -29, some of which I think might be repeats of
ones I made on a WIP interim draft; sorry if I say something again that was
already debunked.  The comment section from the -28 is preserved later.]

In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both
base64 and base64url, so a section reference is usually appropriate (and
in Section 5 we do give a section reference into RFC 4648).

Section 9.1

  Other use cases likely have similar, but MAY different requirements.

nit: ", but MAY have different, requirements"

Section 9.1.1

  Authentication process.  The MASA creates signed voucher artifacts
  according to a it's internally defined policies.

nit: s/a it's/its/

Section 9.1.3

(Do we need to say "DULL" specifically again here for Join Proxy discovery?
Maybe not...)

[All new comments for the -28]

Please respond to the secdir re-review.

Section 2.6.1

  A pledge with a real time clock in which it has confidence in, MUST
  check the above time fields in all certificates and signatures that
  it processes.

nit: s/in// from "in which it has confidence in" (your
choice which one).


Section 4

  This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

  [...] The use of
  GRASP mechanism part of the ACP.  Other users of BRSKI will need

nit: missing "is", "the"


Section 5.7

  The Status field indicates if the voucher was acceptable.  Boolean
  values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

Section 10.6

  Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

  existing products.  Said products might be previous deployed and need
  to be re-initialized, purchased used, or just kept in a warehouse as
  long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

  In particular implementations should pay attention to the advance in
  [RFC4086] section 3, particulary section 3.4.  Devices which are
  reset to factory default in order to perform a second bootstrap with
  a new owner MUST NOT seed their random number generators in the same
  way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.
[ed. I also can't remember if we had discussion about this comment]

=======================================================================

I trimmed all the "Additional comments since posted ballot position on -28"
that were in my previous ballot position, as they are likely stale by now.

[Ballot discuss]
Thanks for providing a clear specification of the /enrollstatus EST endpoint
in the -30.  The following two points still seem unaddressed, though.

The -29 reworks the definition of the 'nonce' field to be:

      strong random or pseudo-random number nonce (see [RFC4086] section
      6.2).  As the nonce is usually generated very early in the boot
      sequence there is a concern that the same nonce might generated
      across multiple boots, or after a factory reset.  Difference
      nonces MUST NOT generated for each bootstrapping attempt, whether
      in series or concurrently.  The freshness of this nonce mitigates
      against the lack of real-time clock as explained in Section 2.6.1.

This needs to either be "Different nonces MUST be generated" or
"the same nonce MUST NOT be reused"; this mashup is no good.

Email exchange with mcr notes:
>    > An RFC Editor note about the RFC 8366 assignment of OID
>    > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
>    > properly use that assigned OID now?
>
> We got a MASA URL Extension OID for:
>    1.3.6.1.5.5.7.1.32
>
> the examples date from before that, and do not use it yet.

We need to fix the examples before publication.

[Ballot comment]
A few new comments on the -30 and -31 to start.  I think some of my comments
on the -29 are still valid, and will try to remove ones that have been addressed.
To reiterate: to the best of my knowledge, all the comments in this ballot position
are actionable and have not been overtaken by events.

In Section 5.9.4:

  In the case of a FAIL, the same TLS connection MUST be used.  The
  Reason string indicates why the most recent enrollment failed.

I'd suggest something more like "In the case of a failed enrollment, the
client MUST send the telemetry information over the same TLS connection
that was used for the enrollment attempt, with a Reason string indicating
why the most recent enrollment failed.  (For failed attempts, the TLS
connection is the most reliable way to correlate server-side information
with what the client provides.)"
(Also, why is "FAIL" capitalized?)

Thanks for the text in Section 11.2 about second-preimage-resistance of
DomainID calculation; the grammar needs a tweak or two, though.  My
suggestion would be to either drop "The consequences of" or add "be to" to
make "would be to allow" (but not both).

Section 11.3 has gone back to just "Devices which are reset to factory default
in order to perform a second bootstrap with a new owner MUST NOT use idential
seeds", but I think it's important to be clear about what the scope of uniqueness is.
The text in Section 5.2 is pretty good in this regard, with respect to the nonces
(which are generally derived from the seed); I wonder if we might want to
restructure this text to be more like "The random seed used by a device at boot
MUST be unique across all devices and all bootstraps.  Resetting a device to
factory default state does not obviate this requirement."  (FWIW, I think the
text in the -29 was that way because of my request.)

[A few comments on the -29, some of which I think might be repeats of
ones I made on a WIP interim draft; sorry if I say something again that was
already debunked.  The comment section from the -28 is preserved later.]

In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both
base64 and base64url, so a section reference is usually appropriate (and
in Section 5 we do give a section reference into RFC 4648).

Section 9.1

  Other use cases likely have similar, but MAY different requirements.

nit: ", but MAY have different, requirements"

Section 9.1.1

  Authentication process.  The MASA creates signed voucher artifacts
  according to a it's internally defined policies.

nit: s/a it's/its/

Section 9.1.3

(Do we need to say "DULL" specifically again here for Join Proxy discovery?
Maybe not...)

[All new comments for the -28]

Please respond to the secdir re-review.

Section 2.6.1

  A pledge with a real time clock in which it has confidence in, MUST
  check the above time fields in all certificates and signatures that
  it processes.

nit: s/in// from "in which it has confidence in" (your
choice which one).


Section 4

  This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

  [...] The use of
  GRASP mechanism part of the ACP.  Other users of BRSKI will need

nit: missing "is", "the"


Section 5.7

  The Status field indicates if the voucher was acceptable.  Boolean
  values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

Section 10.6

  Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

  existing products.  Said products might be previous deployed and need
  to be re-initialized, purchased used, or just kept in a warehouse as
  long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

  In particular implementations should pay attention to the advance in
  [RFC4086] section 3, particulary section 3.4.  Devices which are
  reset to factory default in order to perform a second bootstrap with
  a new owner MUST NOT seed their random number generators in the same
  way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.
[ed. I also can't remember if we had discussion about this comment]

=======================================================================

I trimmed all the "Additional comments since posted ballot position on -28"
that were in my previous ballot position, as they are likely stale by now.

[Ballot comment]
Thank you for addressing my previous DISCUSS and COMMENTS.

I remain concerned that the current text continues to only normatively specify the behavior in the first part of the lifecycle that BRSKI-enabled equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  I appreciate that this scope is the consensus of the WG.  Therefore, thank you for all of the efforts made in recent version of the draft to more substantively document (if not fully specify) these later lifecycle activities. 

** Abstract.  Per “Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged.”, the rational for the lower security models as described in Section 7 do not appear to be “legacy”.

** Section 1.5  Per “Upon successfully validating a voucher artifact, a status telemetry MUST be returned.  See Section 5.7.”  Is a “voucher artifact” the same as a “voucher”?

** Section 5.9.4. Per “In the case of a SUCCESS the Reason string is omitted.  The SubjectKeyIdentifier is included so that the server can record the successful certificate distribution.”.  Given the single example in Figure 18, it isn’t clear how to represent the SubjectKeyIdentifier in JSON.

** Section 10.3.  Per “[t]he so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals. ([livingwithIoT] and [IoTstrangeThings] for a small sample).”

-- Thanks for including this text about the “call-home” mechanism.  However the references don’t seem like a fit.  Both references appear to focus on the regular “call home” activity of these device rather than the narrow, on-time one-time onboarding process.  The nature of the “call-home” isn’t just about privacy (as these articles imply), but also lock-in.

-- It isn't appropriate to characterize concerns about the BRISKI-MASA link as “sinister mechanisms ...”.

** Section 10.7.  Per “It is anticipated that specialist service providers will come to exist that deal with the creation of vouchers in much the same way that many companies have outsourced email, advertising and janitorial services.”, I don’t think this is a fair analogy.  Delegating the voucher process to an entity would take active cooperation of the manufacturer.  If the manufacture is out of business, there is not guarantee this would have been put in place (or those assets were acquired in the liquidation)

** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue a firmware update to all devices that had that key as a trust anchor”.  This suggests a required capability to update trust anchors.  However, Section 7.4.3 discusses a similar (albeit more flexible) practice but this is non-normative and deemed reduced security.  Why the dissidence?

** Please respond to Christian Huitema’s new SECDIR review items (thank you again, Christian!) on clarifying the TLS version negotiation and certificates for MASA authentication.

** Editorial Nits:

Section 3.4.  Typo. s/occurence/occurrence/

Section 4.  These sentences didn’t parse for me – “This section applies is normative for uses with an ANIMA ACP.  The use of GRASP mechanism part of the ACP.”

Section 4.  Reference expansion issue?.  s/{{RFC8446}}/[RFC8446]/

Section 5.1.  Typo.  s/progess/progress/

Section 5.2.  Editorial. Per “The media type is the same as defined in [RFC8366].  and is also …”, the start of the second sentence shouldn’t be “and is …”

Section 5.2. Editorial.  s/then there a On-Path Attacker (MITM)/then there is an On-Path Attacker (MITM)/

Section 4.1.  Recommend clarity on the non-normative behavior.  s/While the GRASP M_FLOOD mechanism is passive for the pledge, the optional other methods (mDNS, and IPv4 methods) are active./While the GRASP M_FLOOD mechanism is passive for the pledge, the non-normative, optional methods (mDNS, and IPv4 methods) described in Appendix A are active./

Section 5.7.  Editorial
s/The client HTTP POSTs the following to the server at the URI ".well-known URI "/voucher_status"./
The client sends an HTTP POSTs to the server at the URI ".well-known URI "/voucher_status".

Section 7.2.  Typo.  s/dependant/dependent/

Section 7.4.1. Typo.  s/A MASA has the option of not including a nonce is in the voucher/A MASA has the option of not including a nonce in the voucher/

Section 7.4.2.  Typo.  s/ nuissance/nuisance/

Section 7.4.3.  Typo. s/overwitten/overwritten/

Section 7.4.3.  Typo.  s/responsability/responsibility/

Section 10.2.  Duplicate word. s/the the/the/

Section 10.2. Typo. s/ arbitrary/ arbitrary/

Section 10.2 Typo. s/coorelate/correlate/

Section 10.3.  Typo. s/the the/the/

Section 10.4.  Typo. s/absense/absence/

Section 10.6.  Typo. s/gratuitiously/gratuitously/

Section 10.6.  Duplicate Word. s/Section Section/Section/

Section 10.6.  Duplicate Word. s/an an/an/

Section 11.2. Typo. s/particulary/particularly/

Section 11.3.  Typo.  s/occurence/occurrence/

Section 11.5.  Typo. s/proceedures/procedures/

Section 11.5. Sometime is amiss with reference expansions – s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/

Section 11.5.2.1.  Typo. s/opportunies/opportunities/

==[ summary of old DISCUSS ]==
(1) Section 5.7.  The format of a pledge status telemetry message seems underspecified.

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is the JSON snippet presented here normative to describe the MASA audit log response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4.  It helpfully lays justifies the current design approach.  I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed. 

My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension.  This is a substantial amount of work, and may be an area for future standardization work”.  Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging.

[Ballot discuss]
% (5.1) the new /enrollstatus EST endpoint seems under-specified.

Shame on me, I reused (5) for two points and have renumbered this to
(5.1) so we don't miss it again.  We don't anywhere give a formal
description of the contents of the POST body; there's just an example
JSON object.

The -29 reworks the definition of the 'nonce' field to be:

      strong random or pseudo-random number nonce (see [RFC4086] section
      6.2).  As the nonce is usually generated very early in the boot
      sequence there is a concern that the same nonce might generated
      across multiple boots, or after a factory reset.  Difference
      nonces MUST NOT generated for each bootstrapping attempt, whether
      in series or concurrently.  The freshness of this nonce mitigates
      against the lack of real-time clock as explained in Section 2.6.1.

This needs to either be "Different nonces MUST be generated" or
"the same nonce MUST NOT be reused"; this mashup is no good.

Email exchange with mcr notes:
>    > An RFC Editor note about the RFC 8366 assignment of OID
>    > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
>    > properly use that assigned OID now?
>
> We got a MASA URL Extension OID for:
>    1.3.6.1.5.5.7.1.32
>
> the examples date from before that, and do not use it yet.

We need to fix the examples before publication.

[Ballot comment]
[A few comments on the -29, some of which I think might be repeats of
ones I made on a WIP interim draft; sorry if I say something again that was
already debunked.  The comment section from the -28 is preserved later.]

Thanks for sorting the definitions; I didn't verify that the text remained
the same in the reordering

In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both
base64 and base64url, so a section reference is usually appropriate (and
in Section 5 we do give a section reference into RFC 4648).

s/accesptable/acceptable

figure 17 seems to no longer be an "abstract example" but rather a concrete
one.

Section 9.1

  Other use cases likely have similar, but MAY different requirements.

nit: ", but MAY have different, requirements"

Section 9.1.1

  Authentication process.  The MASA creates signed voucher artifacts
  according to a it's internally defined policies.

nit: s/a it's/its/

Section 9.1.3

(Do we need to say "DULL" specifically again here for Join Proxy discovery?
Maybe not...)

[All new comments for the -28]

Please respond to the secdir re-review.

Abstract

nit: hyphenate "manufacturer-installed"

  or on limited/disconnected networks.  Support for lower security
  models, including devices with minimal identity, is described for

nit: maybe "deployment models with less-stringent security requirements"?

Section 1

  [I-D.ietf-anima-autonomic-control-plane].  This bootstrap process
  satisfies the [RFC7575] section 3.3 of making all operations secure
  by default.  Other users of the BRSKI protocol will need to provide

nit: missing "requirement"

  between manufacturer and owner: in it's default modes it provides a
  cryptographic transfer of control to the initial owner.  In it's
  strongest modes, it leverages sales channel information to identify

nit: s/it's/its/

Section 1.2

  domainID:  The domain IDentity is a unique hash based upon the
      Registrar CA's certificate.  Section 5.8.2 specifies how it is
      calculated.

nit: the grammar here is weird; I'd suggest s/hash based upon/value
derived from/

  MASA Audit-Log:  A list of previous owners maintained by the MASA on
      a per device (per pledge) basis.  Described in Section 5.8.1.

nit: maybe "anonymized list" since the MASA doesn't really track owners
directly?

  Ownership Tracker:  An Ownership Tracker service on the global
      Internet.  The Ownership Tracker uses business processes to
      accurately track ownership of all devices shipped against domains
      that have purchased them.  Although optional, this component
      allows vendors to provide additional value in cases where their
      sales and distribution channels allow for accurately tracking of
      such ownership.  Ownership tracking information is indicated in

nit: either "accurate tracking of" or "accurately tracking"

  ANI:  The Autonomic Network Infrastructure as defined by
      [I-D.ietf-anima-reference-model].  This document details specific
      requirements for pledges, proxies and registrars when they are
      part of an ANI.

Maybe refer to section 9 specifically?

Section 2.3.1

  The serialNumber fields is defined in [RFC5280], and is a SHOULD
  field in [IDevID].  IDevID certificates for use with this protocol

nit: s/fields/field/

Section 2.5.1

  The pledge is the device that is attempting to join.  The pledge can
  talk to the Join Proxy using link-local network connectivity.  In
  most cases, the pledge has no other connectivity until the pledge
  completes the enrollment process and receives some kind of network
  credential.

I'd consider s/can talk to/is assumed to talk to/.

Section 2.5.3

  The registrar uses an Implicit Trust Anchor database for
  authenticating the BRSKI-MASA TLS connection MASA certificate.  The
  registrar uses a different Implicit Trust Anchor database for
  authenticating the BRSKI-EST TLS connection pledge client
  certificate.  Configuration or distribution of these trust anchor
  databases is out-of-scope of this specification.

  Configuration or distribution of this trust anchor databases is out-
  of-scope of this specification.  Note that the trust anchors in/
  excluded from the database will affect which manufacturers' devices
  are acceptable to the registrar as pledges, and can also be used to
  limit the set of MASAs that are trusted for enrollment.

We seem to duplicate the "out-of-scope" text at the end/start of the two
paragraphs (and the second paragraph uses the definite article "the" as
if it was only talking about one of the two trust anchor databases).

Section 2.6.1

  A pledge with a real time clock in which it has confidence in, MUST
  check the above time fields in all certificates and signatures that
  ir processes.

nits: s/ir/it/, and s/in// from "in which it has confidence in" (your
choice which one).

Section 2.6.2

  year certificate lifetimes.  Registrars SHOULD be configurable on a
  per-manufacturer basis to ignore pledge lifetimes when they did not
  follow the RFC5280 recommendations.

nit: we want "they" to be the manufacturer, not the registrar, so we
can't use this pronoun.

Section 2.7

  be more important in the future.  In the ANIMA ACP scope, new devices
  will be quarantined behind a Join Proxy.

I can't decide whether the reader would benefit from being hit with a
hammer of "and as such will only have link-local connectivity, to the
Join Proxy".  The use of "quarantined" makes me lean towards "not"...

Section 3

In my previous comment, I said:

%    The "proximity-registrar-cert" leaf is used in the pledge voucher-
%    requests.  This provides a method for the pledge to assert the
%    registrar's proximity.
%
% "proximity" in what sense?  How much verification/confidence needs to be
% done?  (Also, I would have expected the assertion to go the other way;
% that the registrar asserts the pledge's proximity -- how does the pledge
% have a way to know that the registrar is nearby when the proxy is
% transparent?)

We talked about this some, but I think we're still making an unstated
assumption that there is a link-local or pre-ACP connection involved.
Making that an explicit assumption would be helpful.

Section 3.3

  Example (2)  The following example illustrates a registrar voucher-
                request.  The 'prior-signed-voucher-request' leaf is
                populated with the pledge's voucher-request (such as the
                prior example).  The pledge's voucher-request is a
                binary CMS signed object.  In the JSON encoding used
                here it must be base64 encoded.  The nonce and assertion
                MAY be carried forward from the pledge request to the
                registrar request.  The serial-number is extracted from
                the pledge's Client Certificate from the TLS connection.
                See Section 5.5.

Since this is an example, the "MAY be carried forward" feels out of
place -- while it's true in the general case, this is not the place to
say it; we can just describe what the example does, here.

Also, we should probably give a reference for base64 (not necessarily
here), such as Section 4 of RFC 4648.

Section 4

  This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

  use of GRASP mechanism part of the ACP.  Other users of BRSKI will

nit: missing "is"

Section 4

  Registrar itself.  In this scenario the pledge is unaware that there
  is no proxing occurring.  This is useful for Registrars which are

nit: s/proxing/proxying/

Section 4.3

  The M_FLOOD message MUST be sent periodically.  The default SHOULD be
  60 seconds, the value SHOULD be operator configurable but SHOULD be
  not smaller than 60 seconds.  The frequency of sending MUST be such

nits: "default period" (or similar); s/be not/NOT be/

Section 5

  While EST section 3.2 does not insist upon use of HTTP persistent
  connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use

nit: comma after parenthetical, not before.

Section 5.1

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

How painful would it be to require 1.3 at this point?  RFC 8446 has been
out for more than a year, and the TLS WG is leaning on me to tighten up
on this...

  IDevID certificate is out-of-scope of this specification.  Note that
  the trust anchors in/excluded from the database will affect which
  manufacturers' devices are acceptable to the registrar as pledges,
  and can also be used to limit the set of MASAs that are trusted for
  enrollment.

I can't tell if we want to bring the division into two distinct trust
anchor databases into this discussion as well.

  A self-signed certificate for the Registrar is acceptable as the
  voucher will validate it.

nit: "will" applies only when everything works, so maybe "can" or "will
validate it in the case of successful enrollment".

  A pledge that can connect to multiple registries concurrently SHOULD

nit: s/registries/Regitstrars/

Section 5.3

  on the authenticated identity presented.  For different networks,
  examples of Automated acceptance may include:

nit: s/A/a/

Section 5.4

  Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
  authentication of the MASA.  Some vendors will establish explicit (or

nit: s/used/used for/
Also, we tend to require that people using 6125 specify what name type
in the cert to verify (e.g., DNS-ID) against what expected name.  It
would be pretty easy to convince me that we don't need to do that here,
though.

Section 5.4

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

As above, how painful would requiring 1.3 be?

  client certificate.  Registrars SHOULD also permit an HTTP Basic and
  Digest authentication to be configured.

nit: s/an//

Section 5.4.1

  be uniquely identified.  This can be done by any stateless method
  that HTTPS supports: such as with HTTP Basic or Digest authentication

nit: this colon is not appropriate usage.

  Stateful methods involving API tokens, or HTTP Cookies are not
  recommended.

nit: zero commas or two, around "or HTTP Cookies", but one is right out.

  This document does not make a specific recommendation as there is
  likely different tradeoffs in different environments and product

nit: s/is/are/

Section 5.5

  idevid-issuer:  The Issuer value from the pledge IDevID certificate
      is included to ensure a uniqueness of the serial-number.  In the
      case of nonceless (offline) voucher-request, then an appropriate
      value needs to be configured from the same out-of-band source as
      the serial-number.

nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you
don't take that, the "a" is superfluous in the current formulation).

  prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  The entire
      CMS signed structure is to be included, base64 encoded for
      transport in the JSON structure.

I think we need a ref for (which) base64.

  The MASA verifies that the registrar voucher-request is internally
  consistent but does not necessarily authenticate the registrar
  certificate since the registrar MAY not be known to the MASA in
  advance.  The MASA performs the actions and validation checks

I suggest s/MAY not be known/MAY be unknown/.

Section 5.5.2

  The registrar's certificate chain is extracted from the signature
  method.  The entire registrar certificate chain was included in the
  CMS structure, as specified in Section 5.5.  This CA certificate will
  be used to populate the "pinned-domain-cert" of the voucher being
  issued.

By saying "this CA certificate", are we excluding use cases where the
pinned-domain-cert is not the global root CA of the organization (or is
the implication just that you don't send the rest of the chain)?

Section 5.5.5

  voucher-request MUST include a 'proximity-registrar-cert' that is
  consistent with to the certificate used to sign the registrar

nit: s/to// (first one)

Section 5.5.6

  The MASA populates the audit-log with the nonce that was verified.
  If a nonceless voucher is issued, then the audit-log is to be
  populated with the JSON value "null".

The quotes around "null" are perhaps anti-helpful.

Section 5.6.1

  The pledge MUST verify that the voucher nonce field is accurate and
  matches the nonce the pledge submitted to this registrar, or that the
  voucher is nonceless (see Section 7.2).

In my previous Discuss position I had asked:
% Is the pledge supposed to accept a nonceless voucher in response to a
% nonce-ful voucher request?
and we had some discussion that helped clarify the intent.  I just have
a suggested rewording, that I *think* is entirely editorial and might
reduce the potential for confusion:
NEW
  The pledge MUST verify the nonce information in the voucher.  If
  present, the nonce in the voucher must match the nonce the pledge
  submitted to the registrar; vouchers with no nonce can also be
  accepted (according to local policy).

Section 5.7

  The Status field indicates if the voucher was acceptable.  Boolean
  values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

  The version, and status fields MUST be present.  The Reason field
  SHOULD be present whenever the status field is negative.  The Reason-
  Context field is optional.

nit: no comma after "version".
nit: s/negative/false/

  The keys to this JSON hash are case-insensitive.  Figure 15 shows an
  example JSON.

This (case-insensitivity) seems to be a drastic divergence from the RFC
8259 standard behavior and as such would require some justification.
nit: s/hash/object/

Section 5.8.1

It's hard to call Figure 17 an "example" when it doesn't conform to the
CDDL schema...

  The domainID is a binary value calculated SubjectKeyIdentifier
  according to Section 5.8.2.  It is encoded once in base64 in order to
  be transported in this JSON container.

nit: I suggest "binary SubjectKeyIdentifier value calculated"

Section 5.8.2

  used as the domainID.  If not, then it is the SPKI Fingerprint as
  described in [RFC7469] section 2.4 is to be used.  This value needs

nit: drop "is to be used" or "then it is".

Section 5.8.3

  A relatively simple policy is to white list known (internal or
  external) domainIDs.  To require all vouchers to have a nonce.

nit: sentence fragment.

  Alternatively to require that all nonceless vouchers be from a subset

nit: comma after "alternatively".  (Hmm, this is also a sentence
fragment.)

Section 5.9.4

  In order to communicate this indicator, the client HTTP POSTs the
  following to the server at the new EST endpoint at "/.well-known/est/
  enrollstatus".

"The following" is just more text, not a formal description of a
protocol element.

    "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

Section 6

  When used within BRSKI, the original RFC7030 EST endpoints remain
  Base64 encoded, but the new BRSKI end points which send and receive
  binary artifacts (specifically, /requestvoucher) are binary.  That

The other two occurrences spell this "/.well-known/est/requestvoucher".

Section 7.2

  The following are a list of alternatives behaviours that the pledge
  can be programmed to implement.  These behaviours are not mutually
  exclusive, nor are they dependant upon other.  Some of these methods

nits: singular/plural mismatch "are"/"list"; "upon each other"

Section 7.3

  A registrar can choose to accept devices using less secure methods.
  These methods are acceptable when low security models are needed, as
  the security decisions are being made by the local administrator, but
  they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

Section 7.4.1

  A MASA has the option of not including a nonce is in the voucher,

nit: s/is//

  and/or not requiring one to be present in the voucher-request.  This
  results in distribution of a voucher that never expires and in effect

"expires-on" is distinct from the nonce-ful freshness check, so I think
some additional wordsmithing is in order.

  This is useful to support use cases where registrars might not be
  online during actual device deployment.

nit: there's enough intervening text that we should probably replace
"this is" with "nonceless vouchers are".

  authorized to provide this functionality to this customer.  The MASA
  is RECOMMENDED to use this functionality only in concert with an
  enhanced level of ownership tracking (out-of-scope.)

I suggest s/out-of-scope/the details of which are out of scope for this
document/.

Section 7.4.2

  functionality.  This provides a proof-of-proximity check that reduces
  the need for ownership verification.

I suggest reiterating the assumption that pledge and JP are on a
link-local connection; whether or not to reiterate that JP and registrar
have a trust relationship (with respect to not falsifying proximity
information) is less clear to me.

Section 7.4.3

We might benefit from some introductory text here to suggest that
updating/extending trust anchors would be desirable in the case of a
vanished or uncooperative manufacturer.

  This weaker factor reset might leave valuable credentials on the
  device and this may be unacceptable to some owners.

nit: s/factor/factory/

Section 9

  Provider organizations.  Equivalent enterprises that has significant
  layer-3 router connectivity also will find significant benefit,

nit: s/has/have/

  In the ACP, the Join Proxy is found to be proximal because
  communication between the pledge and the join proxy is exclusively on

nit(?) My dictionary doesn't list anything for "proximal" that is a good
match for "with proximity"; might be worth double-checking.

  asssertion is satisfied.  Other uses of BRSKI will need make similar
  analysis if they use proximity.

nit: maybe "proximity information" or "proximity assertions".

Section 10.3

  While the contents of the signed part of the pledge voucher request
  can not be changed, they are not encrypted at the registrar.  The
  ability to audit the messages by the owner of the network a mechanism
  to defend against exfiltration of data by a nefarious pledge.  Both

nit: missing verb ("is a mechanism", "provides a mechanism", etc.)

  The manufacturer knows the IP address of the Registrar, but it can
  not see the IP address of the device itself.  The manufacturer can
  not track the device to a detailed physical or network location, only
  to the the location of the Registrar itself.  That is likely to be at

nit: we probably don't need the last "itself".

  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

nit: we probably only need one of "purchases" and "purchased".

Section 10.6

  Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

  existing products.  Said products might be previous deployed and need
  to be re-initialized, purchased used, or just kept in a warehouse as
  long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

  In particular implementations should pay attention to the advance in
  [RFC4086] section 3, particulary section 3.4.  Devices which are
  reset to factory default in order to perform a second bootstrap with
  a new owner MUST NOT seed their random number generators in the same
  way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.

Section 11.5

  This next section examines the risk due to a compromised MASA key.
  This is followed by examination of the risk of a compromised
  manufacturer IDevID signing key.  The third section sections below

nit: I think these appear in the other order.

Section 13.1

[cabforumaudit] and [dnssecroot] probably would be fine as just
informative references.

Appendix D.2

An RFC Editor note about the RFC 8366 assignment of OID
1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
properly use that assigned OID now?

=======================================================================
Additional comments since posted ballot position on -28

Section 2

Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of
bidirectional?

  3.  Request to join the discovered registrar.  A unique nonce is
      included ensuring that any responses can be associated with this
      particular bootstrapping attempt.

This still seems to assume nonce-ful operation, which IIUC remains
required for pledge voucher-requests; only registrar-voucher-requests
have the option of being nonceless.  So, this seems okay as-is, right?

  4.  Imprint on the registrar.  This requires verification of the
      manufacturer service provided voucher.  A voucher contains

nit: hyphenate "manufacturer-service-provided"

Section 2.3.1

  The serialNumber fields is defined in [RFC5280], and is a SHOULD
  field in [IDevID].  IDevID certificates for use with this protocol
  MUST include the "serialNumber" attribute with the device's unique
  serial number (from [IDevID] section 7.2.8, and [RFC5280] section
  4.1.2.4's list of standard attributes).

This is 4.1.2.2 (or just 4.1.2) from RFC 5280.

Section 2.4

I note that both Figure 2 and Figure 4 have a step labeled "Identity",
but the description accompanying Figure 2 describes the step as
"Identify itself"; perhaps the 'f' form is more appropriate everywhere?

Section 2.8

  Note that the registrar can only select the configured MASA URL based
  on the trust anchor -- so manufacturers can only leverage this
  approach if they ensure a single MASA URL works for all pledge's
  associated with each trust anchor.

nit: s/pledge's/pledges/

Section 3

  Voucher-requests are how vouchers are requested.  The semantics of
  the vouchers are described below, in the YANG model.

nit: semantics of vouchers, or voucher requests?

Section 3.3

        Figure 6: JSON representation of example Voucher-Request

I suggest adding "(unsigned)" or "prior to CMS wrapping".

Section 3.4

      refine "voucher/assertion" {
        mandatory false;
        description "Any assertion included in voucher
              requests SHOULD be ignored by the MASA.";

If this is true, why do we propagate the assertion from pledge
voucher-request to registrar voucher-request?

Section 4.1

  Each possible proxy offer SHOULD be attempted up to the point where a
  voucher is received: while there are many ways in which the attempt
  may fail, it does not succeed until the voucher has been validated.

nit: I suggest "valid voucher is received".

Section 5

  o  The pledge requests and validates a voucher using the new REST
      calls described below.

nit: I think the validation is local and does not use the REST call.

  o  The registrar forwards the voucher to the pledge when requested.

I suggest "validates and forwards" to cover the case where the registrar
applies policy.

Section 5.2

  nonce:  The pledge voucher-request MUST contain a cryptographically
      strong random or pseudo-random number nonce. (see [RFC4086]) Doing
      so ensures Section 2.6.1 functionality.  The nonce MUST NOT be

This section reference reads kind of strangely.  (Also, full stop after
parenthetical, not before.)

  proximity-registrar-cert:  In a pledge voucher-request this is the
      first certificate in the TLS server 'certificate_list' sequence
      (see [RFC5246]) presented by the registrar to the pledge.  That
      is, it is the end-entity certificate.  This MUST be populated in a
      pledge voucher-request if the "proximity" assertion is populated.

nit: there is no "proximity" field to be populated; it's the "assertion"
field that's populated with the value "proximity".

Section 5.5

  serial-number:  The serial number of the pledge the registrar would
      like a voucher for.  The registrar determines this value by
      parsing the authenticated pledge IDevID certificate.  See
      Section 2.3.  The registrar MUST verify that the serial number
      field it parsed matches the serial number field the pledge
      provided in its voucher-request.  This provides a sanity check
      useful for detecting error conditions and logging.  The registrar
      MUST NOT simply copy the serial number field from a pledge voucher
      request as that field is claimed but not certified.

(Just to be clear, the serial-number field is optional in the pledge's
voucher-request.)

Section 5.6.2

  intervals according to the backoff timer described earlier.  Attempts
  SHOULD be repeated as failure may be the result of a temporary
  inconsistently (an inconsistently rolled registrar key, or some other
  mis-configuration).  The inconsistently could also be the result an
  active MITM attack on the EST connection.

nit: only one of these "inconsistently"s is correct; the others should
be "inconsistency".

Section 5.8

  although it results in additional network traffic.  The relying MASA
  implementation MAY leverage internal state to associate this request
  with the original, and by now already validated, voucher-request so
  as to avoid an extra crypto validation.

It seems that doing so would turn the voucher-request into a bearer
token for retrieving audit-log information (if the MASA accepts
unauthenticated clients).

Section 5.8.2

  If the "pinned-domain-cert" certificate includes the
  SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
  used as the domainID.  If not, then it is the SPKI Fingerprint as
  described in [RFC7469] section 2.4 is to be used.  This value needs
  to be calculated by both MASA (to populate the audit-log), and by the
  Registrar (to recognize itself).

nit: maybe "to recognize itself in the audit log"?

Section 5.9

  The pledge SHOULD follow the BRSKI operations with EST enrollment
  operations including "CA Certificates Request", "CSR Attributes" and
  "Client Certificate Request" or "Server-Side Key Generation", etc.
  This is a relatively seamless integration since BRSKI REST calls

(I think we decided to not call this REST.)

Section 7.3

  4.  A registrar MAY ignore unrecognized nonceless log entries.  This
      could occur when used equipment is purchased with a valid history
      being deployed in air gap networks that required permanent
      vouchers.

"nonceless" and "permanent" are related but subtly different concepts,
given the potential for an expiration date in a nonceless voucher.

Section 7.4.3

  As a third option, the manufacturer's trust anchors could be entirely
  overwitten with local trust anchors.  A factory default would never
  restore those anchors.  This option comes with a lot of power, but
  also a lot of responsability: if the new anchors are lost the
  manufacturer may be unable to help.

nit: perhaps we refer to the private key portions of the anchors.

Section 11

I am somewhat embarassed that I did not previously note that the
mechanism used to generate the domainID needs to be
second-preimage-resistant or an attacker can claim to be a registrar for
a domain that already exists.

Section 11.2

  Although the nonce used by the Pledge in the voucher-request does not
  require a strong cryptographic randomness, the use of TLS in all of
  the protocols in this document does.

We discuss the need for strong randomness in the nonce in Section 11.3,
so it's not clear this is actually true.

[Ballot discuss]
Thanks for the time and attention to detail put into addressing my previous
Discuss and Comment points.  I have one new Discuss-level point and one
that I think may have been missed (probably because I inadvertently numbered
two points with the same number).

(16) The audit log response (Section 5.8.1) describes the nonce as a JSON
string, but the RFC 8366 nonce is a binary value.  I think we need to
describe some mapping procedure (such as always base64-encoding as is
done for domainID, even if the original nonce is itself base64-encoded
random data) in order to be fully functional.

% (5.1) the new /enrollstatus EST endpoint seems under-specified.

Shame on me, I reused (5) for two points and have renumbered this to
(5.1) so we don't miss it again.  We don't anywhere give a formal
description of the contents of the POST body; there's just an example
JSON object.


Email exchange with mcr notes:
>    > An RFC Editor note about the RFC 8366 assignment of OID
>    > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
>    > properly use that assigned OID now?
>
> We got a MASA URL Extension OID for:
>    1.3.6.1.5.5.7.1.32
>
> the examples date from before that, and do not use it yet.

We need to fix the examples before publication.

[Ballot discuss]
Thanks for the time and attention to detail put into addressing my previous
Discuss and Comment points.  I have one new Discuss-level point and one
that I think may have been missed (probably because I inadvertently numbered
two points with the same number).

(16) The audit log response (Section 5.8.1) describes the nonce as a JSON
string, but the RFC 8366 nonce is a binary value.  I think we need to
describe some mapping procedure (such as always base64-encoding as is
done for domainID, even if the original nonce is itself base64-encoded
random data) in order to be fully functional.

% (5.1) the new /enrollstatus EST endpoint seems under-specified.

Shame on me, I reused (5) for two points and have renumbered this to
(5.1) so we don't miss it again.  We don't anywhere give a formal
description of the contents of the POST body; there's just an example
JSON object.

[Ballot comment]
[All new comments for the -28]

Please respond to the secdir re-review.

Abstract

nit: hyphenate "manufacturer-installed"

  or on limited/disconnected networks.  Support for lower security
  models, including devices with minimal identity, is described for

nit: maybe "deployment models with less-stringent security requirements"?

Section 1

  [I-D.ietf-anima-autonomic-control-plane].  This bootstrap process
  satisfies the [RFC7575] section 3.3 of making all operations secure
  by default.  Other users of the BRSKI protocol will need to provide

nit: missing "requirement"

  between manufacturer and owner: in it's default modes it provides a
  cryptographic transfer of control to the initial owner.  In it's
  strongest modes, it leverages sales channel information to identify

nit: s/it's/its/

Section 1.2

  domainID:  The domain IDentity is a unique hash based upon the
      Registrar CA's certificate.  Section 5.8.2 specifies how it is
      calculated.

nit: the grammar here is weird; I'd suggest s/hash based upon/value
derived from/

  MASA Audit-Log:  A list of previous owners maintained by the MASA on
      a per device (per pledge) basis.  Described in Section 5.8.1.

nit: maybe "anonymized list" since the MASA doesn't really track owners
directly?

  Ownership Tracker:  An Ownership Tracker service on the global
      Internet.  The Ownership Tracker uses business processes to
      accurately track ownership of all devices shipped against domains
      that have purchased them.  Although optional, this component
      allows vendors to provide additional value in cases where their
      sales and distribution channels allow for accurately tracking of
      such ownership.  Ownership tracking information is indicated in

nit: either "accurate tracking of" or "accurately tracking"

  ANI:  The Autonomic Network Infrastructure as defined by
      [I-D.ietf-anima-reference-model].  This document details specific
      requirements for pledges, proxies and registrars when they are
      part of an ANI.

Maybe refer to section 9 specifically?

Section 2.3.1

  The serialNumber fields is defined in [RFC5280], and is a SHOULD
  field in [IDevID].  IDevID certificates for use with this protocol

nit: s/fields/field/

Section 2.5.1

  The pledge is the device that is attempting to join.  The pledge can
  talk to the Join Proxy using link-local network connectivity.  In
  most cases, the pledge has no other connectivity until the pledge
  completes the enrollment process and receives some kind of network
  credential.

I'd consider s/can talk to/is assumed to talk to/.

Section 2.5.3

  The registrar uses an Implicit Trust Anchor database for
  authenticating the BRSKI-MASA TLS connection MASA certificate.  The
  registrar uses a different Implicit Trust Anchor database for
  authenticating the BRSKI-EST TLS connection pledge client
  certificate.  Configuration or distribution of these trust anchor
  databases is out-of-scope of this specification.

  Configuration or distribution of this trust anchor databases is out-
  of-scope of this specification.  Note that the trust anchors in/
  excluded from the database will affect which manufacturers' devices
  are acceptable to the registrar as pledges, and can also be used to
  limit the set of MASAs that are trusted for enrollment.

We seem to duplicate the "out-of-scope" text at the end/start of the two
paragraphs (and the second paragraph uses the definite article "the" as
if it was only talking about one of the two trust anchor databases).

Section 2.6.1

  A pledge with a real time clock in which it has confidence in, MUST
  check the above time fields in all certificates and signatures that
  ir processes.

nits: s/ir/it/, and s/in// from "in which it has confidence in" (your
choice which one).

Section 2.6.2

  year certificate lifetimes.  Registrars SHOULD be configurable on a
  per-manufacturer basis to ignore pledge lifetimes when they did not
  follow the RFC5280 recommendations.

nit: we want "they" to be the manufacturer, not the registrar, so we
can't use this pronoun.

Section 2.7

  be more important in the future.  In the ANIMA ACP scope, new devices
  will be quarantined behind a Join Proxy.

I can't decide whether the reader would benefit from being hit with a
hammer of "and as such will only have link-local connectivity, to the
Join Proxy".  The use of "quarantined" makes me lean towards "not"...

Section 3

In my previous comment, I said:

%    The "proximity-registrar-cert" leaf is used in the pledge voucher-
%    requests.  This provides a method for the pledge to assert the
%    registrar's proximity.
%
% "proximity" in what sense?  How much verification/confidence needs to be
% done?  (Also, I would have expected the assertion to go the other way;
% that the registrar asserts the pledge's proximity -- how does the pledge
% have a way to know that the registrar is nearby when the proxy is
% transparent?)

We talked about this some, but I think we're still making an unstated
assumption that there is a link-local or pre-ACP connection involved.
Making that an explicit assumption would be helpful.

Section 3.3

  Example (2)  The following example illustrates a registrar voucher-
                request.  The 'prior-signed-voucher-request' leaf is
                populated with the pledge's voucher-request (such as the
                prior example).  The pledge's voucher-request is a
                binary CMS signed object.  In the JSON encoding used
                here it must be base64 encoded.  The nonce and assertion
                MAY be carried forward from the pledge request to the
                registrar request.  The serial-number is extracted from
                the pledge's Client Certificate from the TLS connection.
                See Section 5.5.

Since this is an example, the "MAY be carried forward" feels out of
place -- while it's true in the general case, this is not the place to
say it; we can just describe what the example does, here.

Also, we should probably give a reference for base64 (not necessarily
here), such as Section 4 of RFC 4648.

Section 4

  This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

  use of GRASP mechanism part of the ACP.  Other users of BRSKI will

nit: missing "is"

Section 4

  Registrar itself.  In this scenario the pledge is unaware that there
  is no proxing occurring.  This is useful for Registrars which are

nit: s/proxing/proxying/

Section 4.3

  The M_FLOOD message MUST be sent periodically.  The default SHOULD be
  60 seconds, the value SHOULD be operator configurable but SHOULD be
  not smaller than 60 seconds.  The frequency of sending MUST be such

nits: "default period" (or similar); s/be not/NOT be/

Section 5

  While EST section 3.2 does not insist upon use of HTTP persistent
  connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use

nit: comma after parenthetical, not before.

Section 5.1

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

How painful would it be to require 1.3 at this point?  RFC 8446 has been
out for more than a year, and the TLS WG is leaning on me to tighten up
on this...

  IDevID certificate is out-of-scope of this specification.  Note that
  the trust anchors in/excluded from the database will affect which
  manufacturers' devices are acceptable to the registrar as pledges,
  and can also be used to limit the set of MASAs that are trusted for
  enrollment.

I can't tell if we want to bring the division into two distinct trust
anchor databases into this discussion as well.

  A self-signed certificate for the Registrar is acceptable as the
  voucher will validate it.

nit: "will" applies only when everything works, so maybe "can" or "will
validate it in the case of successful enrollment".

  A pledge that can connect to multiple registries concurrently SHOULD

nit: s/registries/Regitstrars/

Section 5.3

  on the authenticated identity presented.  For different networks,
  examples of Automated acceptance may include:

nit: s/A/a/

Section 5.4

  Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
  authentication of the MASA.  Some vendors will establish explicit (or

nit: s/used/used for/
Also, we tend to require that people using 6125 specify what name type
in the cert to verify (e.g., DNS-ID) against what expected name.  It
would be pretty easy to convince me that we don't need to do that here,
though.

Section 5.4

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

As above, how painful would requiring 1.3 be?

  client certificate.  Registrars SHOULD also permit an HTTP Basic and
  Digest authentication to be configured.

nit: s/an//

Section 5.4.1

  be uniquely identified.  This can be done by any stateless method
  that HTTPS supports: such as with HTTP Basic or Digest authentication

nit: this colon is not appropriate usage.

  Stateful methods involving API tokens, or HTTP Cookies are not
  recommended.

nit: zero commas or two, around "or HTTP Cookies", but one is right out.

  This document does not make a specific recommendation as there is
  likely different tradeoffs in different environments and product

nit: s/is/are/

Section 5.5

  idevid-issuer:  The Issuer value from the pledge IDevID certificate
      is included to ensure a uniqueness of the serial-number.  In the
      case of nonceless (offline) voucher-request, then an appropriate
      value needs to be configured from the same out-of-band source as
      the serial-number.

nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you
don't take that, the "a" is superfluous in the current formulation).

  prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  The entire
      CMS signed structure is to be included, base64 encoded for
      transport in the JSON structure.

I think we need a ref for (which) base64.

  The MASA verifies that the registrar voucher-request is internally
  consistent but does not necessarily authenticate the registrar
  certificate since the registrar MAY not be known to the MASA in
  advance.  The MASA performs the actions and validation checks

I suggest s/MAY not be known/MAY be unknown/.

Section 5.5.2

  The registrar's certificate chain is extracted from the signature
  method.  The entire registrar certificate chain was included in the
  CMS structure, as specified in Section 5.5.  This CA certificate will
  be used to populate the "pinned-domain-cert" of the voucher being
  issued.

By saying "this CA certificate", are we excluding use cases where the
pinned-domain-cert is not the global root CA of the organization (or is
the implication just that you don't send the rest of the chain)?

Section 5.5.5

  voucher-request MUST include a 'proximity-registrar-cert' that is
  consistent with to the certificate used to sign the registrar

nit: s/to// (first one)

Section 5.5.6

  The MASA populates the audit-log with the nonce that was verified.
  If a nonceless voucher is issued, then the audit-log is to be
  populated with the JSON value "null".

The quotes around "null" are perhaps anti-helpful.

Section 5.6.1

  The pledge MUST verify that the voucher nonce field is accurate and
  matches the nonce the pledge submitted to this registrar, or that the
  voucher is nonceless (see Section 7.2).

In my previous Discuss position I had asked:
% Is the pledge supposed to accept a nonceless voucher in response to a
% nonce-ful voucher request?
and we had some discussion that helped clarify the intent.  I just have
a suggested rewording, that I *think* is entirely editorial and might
reduce the potential for confusion:
NEW
  The pledge MUST verify the nonce information in the voucher.  If
  present, the nonce in the voucher must match the nonce the pledge
  submitted to the registrar; vouchers with no nonce can also be
  accepted (according to local policy).

Section 5.7

  The Status field indicates if the voucher was acceptable.  Boolean
  values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

  The version, and status fields MUST be present.  The Reason field
  SHOULD be present whenever the status field is negative.  The Reason-
  Context field is optional.

nit: no comma after "version".
nit: s/negative/false/

  The keys to this JSON hash are case-insensitive.  Figure 15 shows an
  example JSON.

This (case-insensitivity) seems to be a drastic divergence from the RFC
8259 standard behavior and as such would require some justification.
nit: s/hash/object/

Section 5.8.1

It's hard to call Figure 17 an "example" when it doesn't conform to the
CDDL schema...

  The domainID is a binary value calculated SubjectKeyIdentifier
  according to Section 5.8.2.  It is encoded once in base64 in order to
  be transported in this JSON container.

nit: I suggest "binary SubjectKeyIdentifier value calculated"

Section 5.8.2

  used as the domainID.  If not, then it is the SPKI Fingerprint as
  described in [RFC7469] section 2.4 is to be used.  This value needs

nit: drop "is to be used" or "then it is".

Section 5.8.3

  A relatively simple policy is to white list known (internal or
  external) domainIDs.  To require all vouchers to have a nonce.

nit: sentence fragment.

  Alternatively to require that all nonceless vouchers be from a subset

nit: comma after "alternatively".  (Hmm, this is also a sentence
fragment.)

Section 5.9.4

  In order to communicate this indicator, the client HTTP POSTs the
  following to the server at the new EST endpoint at "/.well-known/est/
  enrollstatus".

"The following" is just more text, not a formal description of a
protocol element.

    "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

Section 6

  When used within BRSKI, the original RFC7030 EST endpoints remain
  Base64 encoded, but the new BRSKI end points which send and receive
  binary artifacts (specifically, /requestvoucher) are binary.  That

The other two occurrences spell this "/.well-known/est/requestvoucher".

Section 7.2

  The following are a list of alternatives behaviours that the pledge
  can be programmed to implement.  These behaviours are not mutually
  exclusive, nor are they dependant upon other.  Some of these methods

nits: singular/plural mismatch "are"/"list"; "upon each other"

Section 7.3

  A registrar can choose to accept devices using less secure methods.
  These methods are acceptable when low security models are needed, as
  the security decisions are being made by the local administrator, but
  they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

Section 7.4.1

  A MASA has the option of not including a nonce is in the voucher,

nit: s/is//

  and/or not requiring one to be present in the voucher-request.  This
  results in distribution of a voucher that never expires and in effect

"expires-on" is distinct from the nonce-ful freshness check, so I think
some additional wordsmithing is in order.

  This is useful to support use cases where registrars might not be
  online during actual device deployment.

nit: there's enough intervening text that we should probably replace
"this is" with "nonceless vouchers are".

  authorized to provide this functionality to this customer.  The MASA
  is RECOMMENDED to use this functionality only in concert with an
  enhanced level of ownership tracking (out-of-scope.)

I suggest s/out-of-scope/the details of which are out of scope for this
document/.

Section 7.4.2

  functionality.  This provides a proof-of-proximity check that reduces
  the need for ownership verification.

I suggest reiterating the assumption that pledge and JP are on a
link-local connection; whether or not to reiterate that JP and registrar
have a trust relationship (with respect to not falsifying proximity
information) is less clear to me.

Section 7.4.3

We might benefit from some introductory text here to suggest that
updating/extending trust anchors would be desirable in the case of a
vanished or uncooperative manufacturer.

  This weaker factor reset might leave valuable credentials on the
  device and this may be unacceptable to some owners.

nit: s/factor/factory/

Section 9

  Provider organizations.  Equivalent enterprises that has significant
  layer-3 router connectivity also will find significant benefit,

nit: s/has/have/

  In the ACP, the Join Proxy is found to be proximal because
  communication between the pledge and the join proxy is exclusively on

nit(?) My dictionary doesn't list anything for "proximal" that is a good
match for "with proximity"; might be worth double-checking.

  asssertion is satisfied.  Other uses of BRSKI will need make similar
  analysis if they use proximity.

nit: maybe "proximity information" or "proximity assertions".

Section 10.3

  While the contents of the signed part of the pledge voucher request
  can not be changed, they are not encrypted at the registrar.  The
  ability to audit the messages by the owner of the network a mechanism
  to defend against exfiltration of data by a nefarious pledge.  Both

nit: missing verb ("is a mechanism", "provides a mechanism", etc.)

  The manufacturer knows the IP address of the Registrar, but it can
  not see the IP address of the device itself.  The manufacturer can
  not track the device to a detailed physical or network location, only
  to the the location of the Registrar itself.  That is likely to be at

nit: we probably don't need the last "itself".

  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

nit: we probably only need one of "purchases" and "purchased".

Section 10.6

  Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

  existing products.  Said products might be previous deployed and need
  to be re-initialized, purchased used, or just kept in a warehouse as
  long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

  In particular implementations should pay attention to the advance in
  [RFC4086] section 3, particulary section 3.4.  Devices which are
  reset to factory default in order to perform a second bootstrap with
  a new owner MUST NOT seed their random number generators in the same
  way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.

Section 11.5

  This next section examines the risk due to a compromised MASA key.
  This is followed by examination of the risk of a compromised
  manufacturer IDevID signing key.  The third section sections below

nit: I think these appear in the other order.

Section 13.1

[cabforumaudit] and [dnssecroot] probably would be fine as just
informative references.

Appendix D.2

An RFC Editor note about the RFC 8366 assignment of OID
1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
properly use that assigned OID now?

=======================================================================
Additional comments since posted ballot position on -28

Section 2

Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of
bidirectional?

  3.  Request to join the discovered registrar.  A unique nonce is
      included ensuring that any responses can be associated with this
      particular bootstrapping attempt.

This still seems to assume nonce-ful operation, which IIUC remains
required for pledge voucher-requests; only registrar-voucher-requests
have the option of being nonceless.  So, this seems okay as-is, right?

  4.  Imprint on the registrar.  This requires verification of the
      manufacturer service provided voucher.  A voucher contains

nit: hyphenate "manufacturer-service-provided"

Section 2.3.1

  The serialNumber fields is defined in [RFC5280], and is a SHOULD
  field in [IDevID].  IDevID certificates for use with this protocol
  MUST include the "serialNumber" attribute with the device's unique
  serial number (from [IDevID] section 7.2.8, and [RFC5280] section
  4.1.2.4's list of standard attributes).

This is 4.1.2.2 (or just 4.1.2) from RFC 5280.

Section 2.4

I note that both Figure 2 and Figure 4 have a step labeled "Identity",
but the description accompanying Figure 2 describes the step as
"Identify itself"; perhaps the 'f' form is more appropriate everywhere?

Section 2.8

  Note that the registrar can only select the configured MASA URL based
  on the trust anchor -- so manufacturers can only leverage this
  approach if they ensure a single MASA URL works for all pledge's
  associated with each trust anchor.

nit: s/pledge's/pledges/

Section 3

  Voucher-requests are how vouchers are requested.  The semantics of
  the vouchers are described below, in the YANG model.

nit: semantics of vouchers, or voucher requests?

Section 3.3

        Figure 6: JSON representation of example Voucher-Request

I suggest adding "(unsigned)" or "prior to CMS wrapping".

Section 3.4

      refine "voucher/assertion" {
        mandatory false;
        description "Any assertion included in voucher
              requests SHOULD be ignored by the MASA.";

If this is true, why do we propagate the assertion from pledge
voucher-request to registrar voucher-request?

Section 4.1

  Each possible proxy offer SHOULD be attempted up to the point where a
  voucher is received: while there are many ways in which the attempt
  may fail, it does not succeed until the voucher has been validated.

nit: I suggest "valid voucher is received".

Section 5

  o  The pledge requests and validates a voucher using the new REST
      calls described below.

nit: I think the validation is local and does not use the REST call.

  o  The registrar forwards the voucher to the pledge when requested.

I suggest "validates and forwards" to cover the case where the registrar
applies policy.

Section 5.2

  nonce:  The pledge voucher-request MUST contain a cryptographically
      strong random or pseudo-random number nonce. (see [RFC4086]) Doing
      so ensures Section 2.6.1 functionality.  The nonce MUST NOT be

This section reference reads kind of strangely.  (Also, full stop after
parenthetical, not before.)

  proximity-registrar-cert:  In a pledge voucher-request this is the
      first certificate in the TLS server 'certificate_list' sequence
      (see [RFC5246]) presented by the registrar to the pledge.  That
      is, it is the end-entity certificate.  This MUST be populated in a
      pledge voucher-request if the "proximity" assertion is populated.

nit: there is no "proximity" field to be populated; it's the "assertion"
field that's populated with the value "proximity".

Section 5.5

  serial-number:  The serial number of the pledge the registrar would
      like a voucher for.  The registrar determines this value by
      parsing the authenticated pledge IDevID certificate.  See
      Section 2.3.  The registrar MUST verify that the serial number
      field it parsed matches the serial number field the pledge
      provided in its voucher-request.  This provides a sanity check
      useful for detecting error conditions and logging.  The registrar
      MUST NOT simply copy the serial number field from a pledge voucher
      request as that field is claimed but not certified.

(Just to be clear, the serial-number field is optional in the pledge's
voucher-request.)

Section 5.6.2

  intervals according to the backoff timer described earlier.  Attempts
  SHOULD be repeated as failure may be the result of a temporary
  inconsistently (an inconsistently rolled registrar key, or some other
  mis-configuration).  The inconsistently could also be the result an
  active MITM attack on the EST connection.

nit: only one of these "inconsistently"s is correct; the others should
be "inconsistency".

Section 5.8

  although it results in additional network traffic.  The relying MASA
  implementation MAY leverage internal state to associate this request
  with the original, and by now already validated, voucher-request so
  as to avoid an extra crypto validation.

It seems that doing so would turn the voucher-request into a bearer
token for retrieving audit-log information (if the MASA accepts
unauthenticated clients).

Section 5.8.2

  If the "pinned-domain-cert" certificate includes the
  SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
  used as the domainID.  If not, then it is the SPKI Fingerprint as
  described in [RFC7469] section 2.4 is to be used.  This value needs
  to be calculated by both MASA (to populate the audit-log), and by the
  Registrar (to recognize itself).

nit: maybe "to recognize itself in the audit log"?

Section 5.9

  The pledge SHOULD follow the BRSKI operations with EST enrollment
  operations including "CA Certificates Request", "CSR Attributes" and
  "Client Certificate Request" or "Server-Side Key Generation", etc.
  This is a relatively seamless integration since BRSKI REST calls

(I think we decided to not call this REST.)

Section 7.3

  4.  A registrar MAY ignore unrecognized nonceless log entries.  This
      could occur when used equipment is purchased with a valid history
      being deployed in air gap networks that required permanent
      vouchers.

"nonceless" and "permanent" are related but subtly different concepts,
given the potential for an expiration date in a nonceless voucher.

Section 7.4.3

  As a third option, the manufacturer's trust anchors could be entirely
  overwitten with local trust anchors.  A factory default would never
  restore those anchors.  This option comes with a lot of power, but
  also a lot of responsability: if the new anchors are lost the
  manufacturer may be unable to help.

nit: perhaps we refer to the private key portions of the anchors.

Section 11

I am somewhat embarassed that I did not previously note that the
mechanism used to generate the domainID needs to be
second-preimage-resistant or an attacker can claim to be a registrar for
a domain that already exists.

Section 11.2

  Although the nonce used by the Pledge in the voucher-request does not
  require a strong cryptographic randomness, the use of TLS in all of
  the protocols in this document does.

We discuss the need for strong randomness in the nonce in Section 11.3,
so it's not clear this is actually true.

[Ballot discuss]
Thanks for the time and attention to detail put into addressing my previous
Discuss and Comment points.  I have one new Discuss-level point and one
that I think may have been missed (probably because I inadvertently numbered
two points with the same number).

(16) The audit log response (Section 5.8.1) describes the nonce as a JSON
string, but the RFC 8366 nonce is a binary value.  I think we need to
describe some mapping procedure (such as always base64-encoding as is
done for domainID, even if the original nonce is itself base64-encoded
random data) in order to be fully functional.

% (1) The text of the document suffers from lack of clarity throughout about
% whether the nonce-ful operation is mandatory or not, with several
% figures and discussions making declarative statements about nonce usage
% and others saying that nonce usage is optional. (See COMMENT.)

[keep in mind when reading]

% (5.1) the new /enrollstatus EST endpoint seems under-specified.

Shame on me, I reused (5) for two points and have renumbered this to
(5.1) so we don't miss it again.  We don't anywhere give a formal
description of the contents of the POST body; there's just an example
JSON object.

[Ballot comment]
[All new comments for the -28]

Please respond to the secdir re-review.

Abstract

nit: hyphenate "manufacturer-installed"

  or on limited/disconnected networks.  Support for lower security
  models, including devices with minimal identity, is described for

nit: maybe "deployment models with less-stringent security requirements"?

Section 1

  [I-D.ietf-anima-autonomic-control-plane].  This bootstrap process
  satisfies the [RFC7575] section 3.3 of making all operations secure
  by default.  Other users of the BRSKI protocol will need to provide

nit: missing "requirement"

  between manufacturer and owner: in it's default modes it provides a
  cryptographic transfer of control to the initial owner.  In it's
  strongest modes, it leverages sales channel information to identify

nit: s/it's/its/

Section 1.2

  domainID:  The domain IDentity is a unique hash based upon the
      Registrar CA's certificate.  Section 5.8.2 specifies how it is
      calculated.

nit: the grammar here is weird; I'd suggest s/hash based upon/value
derived from/

  MASA Audit-Log:  A list of previous owners maintained by the MASA on
      a per device (per pledge) basis.  Described in Section 5.8.1.

nit: maybe "anonymized list" since the MASA doesn't really track owners
directly?

  Ownership Tracker:  An Ownership Tracker service on the global
      Internet.  The Ownership Tracker uses business processes to
      accurately track ownership of all devices shipped against domains
      that have purchased them.  Although optional, this component
      allows vendors to provide additional value in cases where their
      sales and distribution channels allow for accurately tracking of
      such ownership.  Ownership tracking information is indicated in

nit: either "accurate tracking of" or "accurately tracking"

  ANI:  The Autonomic Network Infrastructure as defined by
      [I-D.ietf-anima-reference-model].  This document details specific
      requirements for pledges, proxies and registrars when they are
      part of an ANI.

Maybe refer to section 9 specifically?

Section 2.3.1

  The serialNumber fields is defined in [RFC5280], and is a SHOULD
  field in [IDevID].  IDevID certificates for use with this protocol

nit: s/fields/field/

Section 2.5.1

  The pledge is the device that is attempting to join.  The pledge can
  talk to the Join Proxy using link-local network connectivity.  In
  most cases, the pledge has no other connectivity until the pledge
  completes the enrollment process and receives some kind of network
  credential.

I'd consider s/can talk to/is assumed to talk to/.

Section 2.5.3

  The registrar uses an Implicit Trust Anchor database for
  authenticating the BRSKI-MASA TLS connection MASA certificate.  The
  registrar uses a different Implicit Trust Anchor database for
  authenticating the BRSKI-EST TLS connection pledge client
  certificate.  Configuration or distribution of these trust anchor
  databases is out-of-scope of this specification.

  Configuration or distribution of this trust anchor databases is out-
  of-scope of this specification.  Note that the trust anchors in/
  excluded from the database will affect which manufacturers' devices
  are acceptable to the registrar as pledges, and can also be used to
  limit the set of MASAs that are trusted for enrollment.

We seem to duplicate the "out-of-scope" text at the end/start of the two
paragraphs (and the second paragraph uses the definite article "the" as
if it was only talking about one of the two trust anchor databases).

Section 2.6.1

  A pledge with a real time clock in which it has confidence in, MUST
  check the above time fields in all certificates and signatures that
  ir processes.

nits: s/ir/it/, and s/in// from "in which it has confidence in" (your
choice which one).

Section 2.6.2

  year certificate lifetimes.  Registrars SHOULD be configurable on a
  per-manufacturer basis to ignore pledge lifetimes when they did not
  follow the RFC5280 recommendations.

nit: we want "they" to be the manufacturer, not the registrar, so we
can't use this pronoun.

Section 2.7

  be more important in the future.  In the ANIMA ACP scope, new devices
  will be quarantined behind a Join Proxy.

I can't decide whether the reader would benefit from being hit with a
hammer of "and as such will only have link-local connectivity, to the
Join Proxy".  The use of "quarantined" makes me lean towards "not"...

Section 3

In my previous comment, I said:

%    The "proximity-registrar-cert" leaf is used in the pledge voucher-
%    requests.  This provides a method for the pledge to assert the
%    registrar's proximity.
%
% "proximity" in what sense?  How much verification/confidence needs to be
% done?  (Also, I would have expected the assertion to go the other way;
% that the registrar asserts the pledge's proximity -- how does the pledge
% have a way to know that the registrar is nearby when the proxy is
% transparent?)

We talked about this some, but I think we're still making an unstated
assumption that there is a link-local or pre-ACP connection involved.
Making that an explicit assumption would be helpful.

Section 3.3

  Example (2)  The following example illustrates a registrar voucher-
                request.  The 'prior-signed-voucher-request' leaf is
                populated with the pledge's voucher-request (such as the
                prior example).  The pledge's voucher-request is a
                binary CMS signed object.  In the JSON encoding used
                here it must be base64 encoded.  The nonce and assertion
                MAY be carried forward from the pledge request to the
                registrar request.  The serial-number is extracted from
                the pledge's Client Certificate from the TLS connection.
                See Section 5.5.

Since this is an example, the "MAY be carried forward" feels out of
place -- while it's true in the general case, this is not the place to
say it; we can just describe what the example does, here.

Also, we should probably give a reference for base64 (not necessarily
here), such as Section 4 of RFC 4648.

Section 4

  This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

  use of GRASP mechanism part of the ACP.  Other users of BRSKI will

nit: missing "is"

Section 4

  Registrar itself.  In this scenario the pledge is unaware that there
  is no proxing occurring.  This is useful for Registrars which are

nit: s/proxing/proxying/

Section 4.3

  The M_FLOOD message MUST be sent periodically.  The default SHOULD be
  60 seconds, the value SHOULD be operator configurable but SHOULD be
  not smaller than 60 seconds.  The frequency of sending MUST be such

nits: "default period" (or similar); s/be not/NOT be/

Section 5

  While EST section 3.2 does not insist upon use of HTTP persistent
  connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use

nit: comma after parenthetical, not before.

Section 5.1

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

How painful would it be to require 1.3 at this point?  RFC 8446 has been
out for more than a year, and the TLS WG is leaning on me to tighten up
on this...

  IDevID certificate is out-of-scope of this specification.  Note that
  the trust anchors in/excluded from the database will affect which
  manufacturers' devices are acceptable to the registrar as pledges,
  and can also be used to limit the set of MASAs that are trusted for
  enrollment.

I can't tell if we want to bring the division into two distinct trust
anchor databases into this discussion as well.

  A self-signed certificate for the Registrar is acceptable as the
  voucher will validate it.

nit: "will" applies only when everything works, so maybe "can" or "will
validate it in the case of successful enrollment".

  A pledge that can connect to multiple registries concurrently SHOULD

nit: s/registries/Regitstrars/

Section 5.3

  on the authenticated identity presented.  For different networks,
  examples of Automated acceptance may include:

nit: s/A/a/

Section 5.4

  Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
  authentication of the MASA.  Some vendors will establish explicit (or

nit: s/used/used for/
Also, we tend to require that people using 6125 specify what name type
in the cert to verify (e.g., DNS-ID) against what expected name.  It
would be pretty easy to convince me that we don't need to do that here,
though.

Section 5.4

  Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
  REQUIRED.

As above, how painful would requiring 1.3 be?

  client certificate.  Registrars SHOULD also permit an HTTP Basic and
  Digest authentication to be configured.

nit: s/an//

Section 5.4.1

  be uniquely identified.  This can be done by any stateless method
  that HTTPS supports: such as with HTTP Basic or Digest authentication

nit: this colon is not appropriate usage.

  Stateful methods involving API tokens, or HTTP Cookies are not
  recommended.

nit: zero commas or two, around "or HTTP Cookies", but one is right out.

  This document does not make a specific recommendation as there is
  likely different tradeoffs in different environments and product

nit: s/is/are/

Section 5.5

  idevid-issuer:  The Issuer value from the pledge IDevID certificate
      is included to ensure a uniqueness of the serial-number.  In the
      case of nonceless (offline) voucher-request, then an appropriate
      value needs to be configured from the same out-of-band source as
      the serial-number.

nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you
don't take that, the "a" is superfluous in the current formulation).

  prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  The entire
      CMS signed structure is to be included, base64 encoded for
      transport in the JSON structure.

I think we need a ref for (which) base64.

  The MASA verifies that the registrar voucher-request is internally
  consistent but does not necessarily authenticate the registrar
  certificate since the registrar MAY not be known to the MASA in
  advance.  The MASA performs the actions and validation checks

I suggest s/MAY not be known/MAY be unknown/.

Section 5.5.2

  The registrar's certificate chain is extracted from the signature
  method.  The entire registrar certificate chain was included in the
  CMS structure, as specified in Section 5.5.  This CA certificate will
  be used to populate the "pinned-domain-cert" of the voucher being
  issued.

By saying "this CA certificate", are we excluding use cases where the
pinned-domain-cert is not the global root CA of the organization (or is
the implication just that you don't send the rest of the chain)?

Section 5.5.5

  voucher-request MUST include a 'proximity-registrar-cert' that is
  consistent with to the certificate used to sign the registrar

nit: s/to// (first one)

Section 5.5.6

  The MASA populates the audit-log with the nonce that was verified.
  If a nonceless voucher is issued, then the audit-log is to be
  populated with the JSON value "null".

The quotes around "null" are perhaps anti-helpful.

Section 5.6.1

  The pledge MUST verify that the voucher nonce field is accurate and
  matches the nonce the pledge submitted to this registrar, or that the
  voucher is nonceless (see Section 7.2).

In my previous Discuss position I had asked:
% Is the pledge supposed to accept a nonceless voucher in response to a
% nonce-ful voucher request?
and we had some discussion that helped clarify the intent.  I just have
a suggested rewording, that I *think* is entirely editorial and might
reduce the potential for confusion:
NEW
  The pledge MUST verify the nonce information in the voucher.  If
  present, the nonce in the voucher must match the nonce the pledge
  submitted to the registrar; vouchers with no nonce can also be
  accepted (according to local policy).

Section 5.7

  The Status field indicates if the voucher was acceptable.  Boolean
  values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

  The version, and status fields MUST be present.  The Reason field
  SHOULD be present whenever the status field is negative.  The Reason-
  Context field is optional.

nit: no comma after "version".
nit: s/negative/false/

  The keys to this JSON hash are case-insensitive.  Figure 15 shows an
  example JSON.

This (case-insensitivity) seems to be a drastic divergence from the RFC
8259 standard behavior and as such would require some justification.
nit: s/hash/object/

Section 5.8.1

It's hard to call Figure 17 an "example" when it doesn't conform to the
CDDL schema...

  The domainID is a binary value calculated SubjectKeyIdentifier
  according to Section 5.8.2.  It is encoded once in base64 in order to
  be transported in this JSON container.

nit: I suggest "binary SubjectKeyIdentifier value calculated"

Section 5.8.2

  used as the domainID.  If not, then it is the SPKI Fingerprint as
  described in [RFC7469] section 2.4 is to be used.  This value needs

nit: drop "is to be used" or "then it is".

Section 5.8.3

  A relatively simple policy is to white list known (internal or
  external) domainIDs.  To require all vouchers to have a nonce.

nit: sentence fragment.

  Alternatively to require that all nonceless vouchers be from a subset

nit: comma after "alternatively".  (Hmm, this is also a sentence
fragment.)

Section 5.9.4

  In order to communicate this indicator, the client HTTP POSTs the
  following to the server at the new EST endpoint at "/.well-known/est/
  enrollstatus".

"The following" is just more text, not a formal description of a
protocol element.

    "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

Section 6

  When used within BRSKI, the original RFC7030 EST endpoints remain
  Base64 encoded, but the new BRSKI end points which send and receive
  binary artifacts (specifically, /requestvoucher) are binary.  That

The other two occurrences spell this "/.well-known/est/requestvoucher".

Section 7.2

  The following are a list of alternatives behaviours that the pledge
  can be programmed to implement.  These behaviours are not mutually
  exclusive, nor are they dependant upon other.  Some of these methods

nits: singular/plural mismatch "are"/"list"; "upon each other"

Section 7.3

  A registrar can choose to accept devices using less secure methods.
  These methods are acceptable when low security models are needed, as
  the security decisions are being made by the local administrator, but
  they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

Section 7.4.1

  A MASA has the option of not including a nonce is in the voucher,

nit: s/is//

  and/or not requiring one to be present in the voucher-request.  This
  results in distribution of a voucher that never expires and in effect

"expires-on" is distinct from the nonce-ful freshness check, so I think
some additional wordsmithing is in order.

  This is useful to support use cases where registrars might not be
  online during actual device deployment.

nit: there's enough intervening text that we should probably replace
"this is" with "nonceless vouchers are".

  authorized to provide this functionality to this customer.  The MASA
  is RECOMMENDED to use this functionality only in concert with an
  enhanced level of ownership tracking (out-of-scope.)

I suggest s/out-of-scope/the details of which are out of scope for this
document/.

Section 7.4.2

  functionality.  This provides a proof-of-proximity check that reduces
  the need for ownership verification.

I suggest reiterating the assumption that pledge and JP are on a
link-local connection; whether or not to reiterate that JP and registrar
have a trust relationship (with respect to not falsifying proximity
information) is less clear to me.

Section 7.4.3

We might benefit from some introductory text here to suggest that
updating/extending trust anchors would be desirable in the case of a
vanished or uncooperative manufacturer.

  This weaker factor reset might leave valuable credentials on the
  device and this may be unacceptable to some owners.

nit: s/factor/factory/

Section 9

  Provider organizations.  Equivalent enterprises that has significant
  layer-3 router connectivity also will find significant benefit,

nit: s/has/have/

  In the ACP, the Join Proxy is found to be proximal because
  communication between the pledge and the join proxy is exclusively on

nit(?) My dictionary doesn't list anything for "proximal" that is a good
match for "with proximity"; might be worth double-checking.

  asssertion is satisfied.  Other uses of BRSKI will need make similar
  analysis if they use proximity.

nit: maybe "proximity information" or "proximity assertions".

Section 10.3

  While the contents of the signed part of the pledge voucher request
  can not be changed, they are not encrypted at the registrar.  The
  ability to audit the messages by the owner of the network a mechanism
  to defend against exfiltration of data by a nefarious pledge.  Both

nit: missing verb ("is a mechanism", "provides a mechanism", etc.)

  The manufacturer knows the IP address of the Registrar, but it can
  not see the IP address of the device itself.  The manufacturer can
  not track the device to a detailed physical or network location, only
  to the the location of the Registrar itself.  That is likely to be at

nit: we probably don't need the last "itself".

  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

nit: we probably only need one of "purchases" and "purchased".

Section 10.6

  Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

  existing products.  Said products might be previous deployed and need
  to be re-initialized, purchased used, or just kept in a warehouse as
  long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

  In particular implementations should pay attention to the advance in
  [RFC4086] section 3, particulary section 3.4.  Devices which are
  reset to factory default in order to perform a second bootstrap with
  a new owner MUST NOT seed their random number generators in the same
  way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.

Section 11.5

  This next section examines the risk due to a compromised MASA key.
  This is followed by examination of the risk of a compromised
  manufacturer IDevID signing key.  The third section sections below

nit: I think these appear in the other order.

Section 13.1

[cabforumaudit] and [dnssecroot] probably would be fine as just
informative references.

Appendix D.2

An RFC Editor note about the RFC 8366 assignment of OID
1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
properly use that assigned OID now?

[Ballot discuss]
One remaining item of clarity in the Section 7 from my previous DISCUSS position:

** Section 7.  Per “This section is considered non-normative in the generality of the protocol.  Use of the suggested mechanism here MUST be detailed in specific profiles of BRSKI, such as in Section 9.”

-- Can you please clarify “non-normative in the generality of the protocol”?  If I take the perspective of an implementer, it seems like a black-and-white issue – either this section is normative or not (I either have to conform or not). 

-- what this MUST is requiring isn’t clear.  Practically, why would using any of these mechanisms in this section require further elaboration?

I’d offer an alternative introduction to this section to address these ambiguities:

OLD
  A common requirement of bootstrapping is to support less secure
  operational modes for support specific use cases.  The following
  sections detail specific ways that the pledge, registrar and MASA can
  be configured to run in a less secure mode for the indicated reasons.

  This section is considered non-normative in the generality of the
  protocol.  Use of the suggested mechanism here MUST be detailed in
  specific profiles of BRSKI, such as in Section 9.

NEW
A common requirement of bootstrapping is to support less secure operational modes for support specific use cases.  This section suggests a range of mechanisms that would alter the security assurance of BRSKI to accommodate alternative deployment architectures and mitigate lifecycle management issues identified in Section 10.4 – 10.7.  They are presented here as informative (non-normative) design guidance for future standardization activities.  It would be expected that subsets of these mechanisms could be profiled with an accompanying applicability statements similar to the one described in Section 9.

[Ballot comment]
Thank you for addressing my previous COMMENTS.

I remain concerned that the current text continues to only normatively specify the behavior in the first part of the lifecycle that BRSKI-enabled equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  I appreciate that this scope is the consensus of the WG.  Therefore, thank you for all of the efforts made in recent version of the draft to more substantively document (if not fully specify) these later lifecycle activities. 

** Abstract.  Per “Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged.”, the rational for the lower security models as described in Section 7 do not appear to be “legacy”.

** Section 1.5  Per “Upon successfully validating a voucher artifact, a status telemetry MUST be returned.  See Section 5.7.”  Is a “voucher artifact” the same as a “voucher”?

** Section 5.9.4. Per “In the case of a SUCCESS the Reason string is omitted.  The SubjectKeyIdentifier is included so that the server can record the successful certificate distribution.”.  Given the single example in Figure 18, it isn’t clear how to represent the SubjectKeyIdentifier in JSON.

** Section 10.3.  Per “[t]he so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals. ([livingwithIoT] and [IoTstrangeThings] for a small sample).”

-- Thanks for including this text about the “call-home” mechanism.  However the references don’t seem like a fit.  Both references appear to focus on the regular “call home” activity of these device rather than the narrow, on-time one-time onboarding process.  The nature of the “call-home” isn’t just about privacy (as these articles imply), but also lock-in.

-- It isn't appropriate to characterize concerns about the BRISKI-MASA link as “sinister mechanisms ...”.

** Section 10.7.  Per “It is anticipated that specialist service providers will come to exist that deal with the creation of vouchers in much the same way that many companies have outsourced email, advertising and janitorial services.”, I don’t think this is a fair analogy.  Delegating the voucher process to an entity would take active cooperation of the manufacturer.  If the manufacture is out of business, there is not guarantee this would have been put in place (or those assets were acquired in the liquidation)

** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue a firmware update to all devices that had that key as a trust anchor”.  This suggests a required capability to update trust anchors.  However, Section 7.4.3 discusses a similar (albeit more flexible) practice but this is non-normative and deemed reduced security.  Why the dissidence?

** Please respond to Christian Huitema’s new SECDIR review items (thank you again, Christian!) on clarifying the TLS version negotiation and certificates for MASA authentication.

** Editorial Nits:

Section 3.4.  Typo. s/occurence/occurrence/

Section 4.  These sentences didn’t parse for me – “This section applies is normative for uses with an ANIMA ACP.  The use of GRASP mechanism part of the ACP.”

Section 4.  Reference expansion issue?.  s/{{RFC8446}}/[RFC8446]/

Section 5.1.  Typo.  s/progess/progress/

Section 5.2.  Editorial. Per “The media type is the same as defined in [RFC8366].  and is also …”, the start of the second sentence shouldn’t be “and is …”

Section 5.2. Editorial.  s/then there a On-Path Attacker (MITM)/then there is an On-Path Attacker (MITM)/

Section 4.1.  Recommend clarity on the non-normative behavior.  s/While the GRASP M_FLOOD mechanism is passive for the pledge, the optional other methods (mDNS, and IPv4 methods) are active./While the GRASP M_FLOOD mechanism is passive for the pledge, the non-normative, optional methods (mDNS, and IPv4 methods) described in Appendix A are active./

Section 5.7.  Editorial
s/The client HTTP POSTs the following to the server at the URI ".well-known URI "/voucher_status"./
The client sends an HTTP POSTs to the server at the URI ".well-known URI "/voucher_status".

Section 7.2.  Typo.  s/dependant/dependent/

Section 7.4.1. Typo.  s/A MASA has the option of not including a nonce is in the voucher/A MASA has the option of not including a nonce in the voucher/

Section 7.4.2.  Typo.  s/ nuissance/nuisance/

Section 7.4.3.  Typo. s/overwitten/overwritten/

Section 7.4.3.  Typo.  s/responsability/responsibility/

Section 10.2.  Duplicate word. s/the the/the/

Section 10.2. Typo. s/ arbitrary/ arbitrary/

Section 10.2 Typo. s/coorelate/correlate/

Section 10.3.  Typo. s/the the/the/

Section 10.4.  Typo. s/absense/absence/

Section 10.6.  Typo. s/gratuitiously/gratuitously/

Section 10.6.  Duplicate Word. s/Section Section/Section/

Section 10.6.  Duplicate Word. s/an an/an/

Section 11.2. Typo. s/particulary/particularly/

Section 11.3.  Typo.  s/occurence/occurrence/

Section 11.5.  Typo. s/proceedures/procedures/

Section 11.5. Sometime is amiss with reference expansions – s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/

Section 11.5.2.1.  Typo. s/opportunies/opportunities/

==[ summary of old DISCUSS ]==
(1) Section 5.7.  The format of a pledge status telemetry message seems underspecified.

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is the JSON snippet presented here normative to describe the MASA audit log response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4.  It helpfully lays justifies the current design approach.  I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed. 

My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension.  This is a substantial amount of work, and may be an area for future standardization work”.  Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging.

[Ballot comment]
(1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use this solution."  The use of Normative language seems out of place: if this document is not applicable to constrained environments, then there's no way to enforce (SHOULD NOT)...  s/SHOULD NOT/should not

(2) §2.1: In Figure 2, should the "rejected" action be a result of step 3 (instead of 2)?

  |                  |
  |            +------v-------+
  |            | (2) Identity |
  ^------------+              |
  | rejected  +------+-------+
  |                  |
  |            +------v-------+
  |            | (3) Request  |
  |            |    Join    |
  |            +------+-------+
  |                  |


(3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended field in [IDevID].  Note that SHOULD is not used properly here because it does not have a Normative quality (as it refers to the other document).  I'm assuming that the replacement is "recommended" (per rfc2119), but it may be "required".


(4) [nits]

s/Bootstrapping to is complete/Bootstrapping is complete

§1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default."  Satisfies the what?  Requirement, maybe?

s/explains the details applicability/explains the detailed applicability

s/out-of-band" information"/out-of-band" information

s/This section applies is normative for uses with an ANIMA ACP./This section is normative for uses with an ANIMA ACP.

s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer Usage Description Specification

s/might be previous deployed/might be previously deployed

s/were receives by/were received from

s/{{...}}/[...]

[Ballot discuss]
Apologies for the multiple emails, I failed to realize there was a new Gen-ART review for this document. The follow-up from the Gen-ART review seems to indicate that a YANG doctor review of this document is needed and/or that the YANG issues raised by Tom Petch need fixing. Is there a plan to get either of those done?

[Ballot comment]
Thanks for addressing my original DISCUSS points.

Please respond to the full Gen-ART review.

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?

[Ballot 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?

[Ballot comment]
Thank you for addressing my DISCUSS points.

Some comments below were still applicable to -27, but some might be out of date.

In 2.3.2:

  As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
  this extension, including the scheme, iauthority, and ipath.  As a
  consideration to constrained systems, this MAY be reduced to only the
  iauthority, in which case a scheme of "https://" and ipath of
  "/.well-known/est" is to be assumed, as explained in section
  Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
b) are wildcards allowed in any of these?

[Ballot comment]
I initially balloted Recuse as I'm the author of a similar document "Secure Device Install" (draft-ietf-opsawg-sdi) - after discussions and consideration I'm changing my position to No Objection; my document addresses a small slice of the problem space.

My initial Recuse also contained a bit of a soapbox rant about the ability of users to buy and use old equipment (avoiding having network gear become a "subscription" service). I'm still somewhat twitchy about this, but am balloting NoObj anyway.

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) Resolved

2) Resolved

3) Resolved

4) In 5.8.1:

Format of different fields is not defined in enough details, so this is not interoperable. Are numeric fields always represented as JSON numbers?

5) Resolved

[Ballot comment]
Some comments below are still applicable to -27, but some might be out of date.

In 2.3.2:

  As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
  this extension, including the scheme, iauthority, and ipath.  As a
  consideration to constrained systems, this MAY be reduced to only the
  iauthority, in which case a scheme of "https://" and ipath of
  "/.well-known/est" is to be assumed, as explained in section
  Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
b) are wildcards allowed in any of these?

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) Resolved

2) Resolved

3) Resolved

4) In 5.8.1:

Format of different fields is not defined in enough details, so this is not interoperable. Please specify what format is used for dates and nonces.

5) Resolved

[Ballot comment]
Some comments below are still applicable to -26, but some might be out of date.

The first mention of HTTP 1.1 needs a Normative reference.


In 2.3.2:

  As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
  this extension, including the scheme, iauthority, and ipath.  As a
  consideration to constrained systems, this MAY be reduced to only the
  iauthority, in which case a scheme of "https://" and ipath of
  "/.well-known/est" is to be assumed, as explained in section
  Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
b) are wildcards allowed in any of these?

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) Resolved

2) In 5.6:

  assertion:  The method used to verify assertion.  See Section 5.5.5.

Section 5.5.5 doesn't define syntax of this field in enough details to implement.
Can it contain one of the allowed values (like C enum)?

— I couldn’t quite figure out what was changed from wdiff. I don’t think this was addressed.

3) Resolved

4) In 5.8.1:

Format of different fields is not defined in enough details, so this is not interoperable. Please specify what format is used for dates and nonces.

5) Resolved

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) In Section 5:

  o  In the language of [RFC6125] this provides for a SERIALNUM-ID
      category of identifier that can be included in a certificate and
      therefore that can also be used for matching purposes.  The
      SERIALNUM-ID whitelist is collated according to manufacturer trust
      anchor since serial numbers are not globally unique.

I think now you are just inventing things. Please define what exactly SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

2) In 5.6:

  assertion:  The method used to verify assertion.  See Section 5.5.5.

Section 5.5.5 doesn't define syntax of this field in enough details to implement.
Can it contain one of the allowed values (like C enum)?

3) Resolved

4) In 5.8.1:

Format of different fields is not defined, so this is not interoperable.

5) In 8.1:

  This document extends the definitions of "est" (so far defined via
  RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
  well-known-uris.xhtml" registry as follows:

  o  add /.well-known/est/requestvoucher (see Section 5.5 )

  o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known URIs IANA registry doesn't list anything below the first level (i.e. "est" in your case).
So I think you really want to have 2 IANA actions here:

a) Add the reference to this document as another reference for "est".
-- This was addressed.

b) create a new registry of "est" URIs and add your 2 URIs above to it and also populate other entries from the original EST RFC.

[Ballot comment]
The first mention of HTTP 1.1 needs a Normative reference.


In 2.3.2:

  As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
  this extension, including the scheme, iauthority, and ipath.  As a
  consideration to constrained systems, this MAY be reduced to only the
  iauthority, in which case a scheme of "https://" and ipath of
  "/.well-known/est" is to be assumed, as explained in section
  Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
b) are wildcards allowed in any of these?

[Ballot discuss]
Hi,

A. This is really a discuss discuss. With to little time to dig into the details it appears that this protocol is making i hack of its interface towards the its transport. It appears to attempt to use an HTTP rest interface, but then it is also have a lot of talking about requirement for the TLS connection underlying the HTTP. So to illustrate the issue I see here is what happens if one like to use QUIC as the underlying transport for the rest interface rather than TCP/TLS? So can this document achieve a clearer interface to the lower layers so that it will be simpler to move the protocol to another underlying version of the HTTP "transport"?

B. Section 5.6:

The server MUST answer with a suitable 4xx
  or 5xx HTTP [RFC2616] error code when a problem occurs.

Referencing RFC 2616 that has been obsolete by RFC 7230 and companions. I do note that there are no normative reference for that part in this document.

[Ballot comment]
I agree with Alissa's discuss that the conclusion of section 10(.3) should be to recommend a manual configuration mode. Also with respect to section 10.2: if ownership is "enforced" by the manufacturer, there should also probably be a way for the buyer to check if ownership was transferred by the saler during the re-sale process.

Two other small comments on more load related points:

1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid head of queue
  problems wherein an attacker running a fake proxy or registrar could
  perform protocol actions intentionally slowly.  The pledge SHOULD
  continue to listen to for additional GRASP M_FLOOD messages during
  the connection attempts."
One minor comment: Maybe also say explicitly, while running in parallel, one should not send all initial messages at exactly the same time but pace  them out (e.g. one every 3 secs) to avoid network overload when initial connectivity is very constraint.

2) sec 4.3: " It must
  be sufficiently low that the aggregate amount of periodic M_FLOODs
  from all EST servers causes negligible traffic across the ACP."
I know this is a little bit a blurry requirement but I would still like to see a MUST here. Or maybe give an upper bound for the maximum frequency, e.g. MUST NOT send more than once per minute...? Not sure it there is a reasonable value here.

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) In Section 5:

  o  In the language of [RFC6125] this provides for a SERIALNUM-ID
      category of identifier that can be included in a certificate and
      therefore that can also be used for matching purposes.  The
      SERIALNUM-ID whitelist is collated according to manufacturer trust
      anchor since serial numbers are not globally unique.

I think now you are just inventing things. Please define what exactly SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

2) In 5.6:

  assertion:  The method used to verify assertion.  See Section 5.5.5.

Section 5.5.5 doesn't define syntax of this field in enough details to implement.
Can it contain one of the allowed values (like C enum)?

3) In 5.8

  This is done with an HTTP GET using the operation path value of
  "/.well-known/est/requestauditlog".

Here you say to use HTTP GET.

  The registrar SHOULD HTTP POST the same registrar voucher-request as

But you only define how to use POST. I think the first "GET" is supposed to be "POST".

4) In 5.8.1:

Format of different fields is not defined, so this is not interoperable.

5) In 8.1:

  This document extends the definitions of "est" (so far defined via
  RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
  well-known-uris.xhtml" registry as follows:

  o  add /.well-known/est/requestvoucher (see Section 5.5 )

  o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known URIs IANA registry doesn't list anything below the first level (i.e. "est" in your case).
So I think you really want to have 2 IANA actions here:

a) Add the reference to this document as another reference for "est".

b) create a new registry of "est" URIs and add your 2 URIs above to it and also populate other entries from the original EST RFC.

[Ballot discuss]
Thank you for this document. Despite comments/DISCUSSes raised, this was a good read.

1) In Section 5:

  o  In the language of [RFC6125] this provides for a SERIALNUM-ID
      category of identifier that can be included in a certificate and
      therefore that can also be used for matching purposes.  The
      SERIALNUM-ID whitelist is collated according to manufacturer trust
      anchor since serial numbers are not globally unique.

I think now you are just inventing things. Please define what exactly SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

2) In 5.6:

  assertion:  The method used to verify assertion.  See Section 5.5.5.

Section 5.5.5 doesn't define syntax of this field in enough details to implement.
Can it contain one of the allowed values (like C enum)?

3) In 5.8

  This is done with an HTTP GET using the operation path value of
  "/.well-known/est/requestauditlog".

Here you say to use HTTP GET.

  The registrar SHOULD HTTP POST the same registrar voucher-request as

But you only define how to use POST. I think the first "GET" is supposed to be "POST".

4) In 5.8.1:

Format of different fields is not defined, so this is not interoperable.

5) In 8.1:

  This document extends the definitions of "est" (so far defined via
  RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
  well-known-uris.xhtml" registry as follows:

  o  add /.well-known/est/requestvoucher (see Section 5.5 )

  o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known URIs IANA registry doesn't list anything below the first level (i.e. "est" in your case).
So I think you really want to have 2 IANA actions here:

a) Add the reference to this document as another reference for "est".

b) create a new registry of "est" URIs and add your 2 URIs above to it and also populate other entries from the original EST RFC.

[Ballot comment]
The first mention of HTTP 1.1 needs a Normative reference.


1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices

  Upon successfully validating a voucher artiface, a status telemetry
  MUST be returned.  See Section 5.7.

"artiface" is an unfortunate typo. I think you meant "artifact" here.

In 2.3.2:

  As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
  this extension, including the scheme, iauthority, and ipath.  As a
  consideration to constrained systems, this MAY be reduced to only the
  iauthority, in which case a scheme of "https://" and ipath of
  "/.well-known/est" is to be assumed, as explained in section
  Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
b) are wildcards allowed in any of these?


4.  Proxying details (Pledge - Proxy - Registrar)

  In order to permit the proxy functionality to be implemented on the
  maximum variety of devices the chosen mechanism SHOULD use the
  minimum amount of state on the proxy device.

What does this mean? How can compliance with this SHOULD be evaluated? I think you want to use lower case "should" here.


In 5.7 (and a similar issue elsewhere):

  {
    "version":"1",
    "Status":FALSE /* TRUE=Success, FALSE=Fail"

This is not valid JSON, this is not even valid pseudo-JSON. Please move the comment:

TRUE=Success, FALSE=Fail

After this block to avoid confusion. Please add missing "," after each attribute value


    "Reason":"Informative human readable message"
    "reason-context": { additional JSON }
  }

[Ballot comment]
sec 4.1: "Connection attempts SHOULD be run in parallel to avoid head of queue
  problems wherein an attacker running a fake proxy or registrar could
  perform protocol actions intentionally slowly.  The pledge SHOULD
  continue to listen to for additional GRASP M_FLOOD messages during
  the connection attempts."
One minor comment: Maybe also say explicitly, while running in parallel, one should not send all initial messages at exactly the same time but pace  them out (e.g. one every 3 secs) to avoid network overload when initial connectivity is very constraint.

sec 4.3: " It must
  be sufficiently low that the aggregate amount of periodic M_FLOODs
  from all EST servers causes negligible traffic across the ACP."
I know this is a little bit a blurry requirement but I would still like to see a MUST here. Or maybe give an upper bound for the maximum frequency, e.g. MUST NOT send more than once per minute...? Not sure it there is a reasonable value here.

[Ballot discuss]
Thanks to everyone who invested time in developing this mechanism.
I have two blocking comments that should be quite easy to resolve.

---------------------------------------------------------------------------

§5:

>  MASA URI is "https://" iauthority "/.well-known/est".

This doesn't make sense: iauthority is a component of IRIs, not of URIs. In
URIs this is simply an "authority." It's not simply a terminology distinction:
converting from an iauthority to an authority requires idna encoding. Please
consult with an IRI expert (which I do not consider myself to be) to work out
the proper terminology and procedures here.  If you need help finding an
expert, please let me know and I'll track someone down for you.

---------------------------------------------------------------------------

§5.8:

>  Rather than returning the audit log as a response to the POST (with a
>  return code 200), the MASA MAY instead return a 201 ("Created")
>  RESTful response ([RFC7231] section 7.1) containing a URL to the
>  prepared (and easily cachable) audit response.

The DISCUSS portion of my comment on this text is that it is unclear about how
the URL is to be returned. It can just as easily be interpreted as returning
it in a "Location" header field as it could as returning it in the response
body -- or maybe somewhere else entirely (e.g., a link relation).  This
ambiguity will cause an interop issue. Please be explicit about precisely how
the value is conveyed.

While not part of the DISCUSS, I also have a fairly serious comment on the
phrasing and citation of  "return a 201 ("Created") RESTful response
([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion of
Control Data header fields, rather than any general discussion of RESTful
responses.  It's worth noting that the term "RESTful" never appears in RFC
7231, so it's really unclear what section this was attempting to target.
Perhaps 6.3.2?

[Ballot comment]
I share Warren's discomfort with the models described in this document,
especially in the context of device viability after companies disappear or
change focus.  It's not clear that this an unintended side effect of the
model: much of the text around "legal ownership" seems aimed at subverting the
doctrine of first sale/rule of exhaustion, and congruent laws around the world.

While I sincerely appreciate the treatment of this issue in section 10.3, I
think the document really needs *normative* behaviors defined that address the
two issues of resale and device utility in a world where the device
manufacturer (as that term is defined in section 1.2) is no longer available,
rather than the high-level non-normative sketches currently provided for
future study.

In short, beyond the user-hostile effects of these two issues, I have
ethical issues with the IETF publishing a protocol that promotes the
unnecessary creation of e-waste; and, unless handled properly, that will
be the inevitable result of the two factors I cite above.

While this isn't part of my DISCUSS, I can't in good conscience ballot "No
Objection" to a document that doesn't normatively address those issues.  I
urge the authors and working group to add text that does so.  I do, however,
recognize that the prospect of this happening at this stage of the process is
vanishingly small. In the absence of such admittedly unlikely action, I plan
to Abstain after my DISCUSS issue has been addressed.

---------------------------------------------------------------------------

§2.1

>  |            +------v-------+
>  |            | (5) Enroll  |<---+ (non-error HTTP codes  )
>  ^------------+              |\___/ (e.g. 201 'Retry-After')
>  | Enroll    +------+-------+
>  | Failure          |

I can't work out what a "Retry-After" would mean in a "201 Created" response.
As noted above, section 5.6 of this document does indicate the use of a
"Retry-After" header field with a 202 response, so I presume this diagram
should say 202?

---------------------------------------------------------------------------

§5:

>  BRSKI uses existing CMS message formats for existing EST operations.
>  BRSKI uses JSON [RFC7159] for all new operations defined here, and
>  voucher formats.

RFC 7159 has been obsoleted by RFC 8259.

---------------------------------------------------------------------------

§5.2

>  The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
>  indicating the acceptable media type for the voucher response.  The

Nit: ..."Accept" header field indicating...

---------------------------------------------------------------------------

§5.5

>  The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
>  header indicating the response media types that are acceptable.  This

Nit: ..."Accept" header field indicating...

>  field and appropriate 'Accept header' field values from the physical

Nit: ...'Accept header field' values...

---------------------------------------------------------------------------

§5.6

>  pledge would keep track of the appropriate Retry-After header values

Nit: "...Retry-After header field values..."

>  desired type or using the desired algorithms (as indicated by the
>  Accept: headers, and algorithms used in the signature) cannot be

Nit: "...Accept: header fields, ..."

>  The voucher response format is as indicated in the submitted accept
>  header or based on the MASA's prior understanding of proper format

Nit: "...Accept header field..."

---------------------------------------------------------------------------

§5.6

>  {
>    "ietf-voucher:voucher": {
>      "nonce": "62a2e7693d82fcda2624de58fb6722e5",
>      "assertion": "logging"
>      "pinned-domain-cert": "base64encodedvalue=="
>      "serial-number": "JADA123456789"
>    }
>  }

This JSON is syntactically invalid. Please run this example and all other
instances of JSON in this document through a validation tool.

With a reasonably modern version of nodejs, validation can be as simple as
something like:

node -e 'console.log(JSON.stringify(JSON.parse(`
  {
    "ietf-voucher:voucher": {
      "nonce": "62a2e7693d82fcda2624de58fb6722e5",
      "assertion": "logging"
      "pinned-domain-cert": "base64encodedvalue=="
      "serial-number": "JADA123456789"
    }
  }
`)));'

If the JSON is valid, you'll get no errors.

---------------------------------------------------------------------------

§5.7:

>  {
>    "version":"1",
>    "Status":FALSE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": { additional JSON }
>  }

Please see https://tools.ietf.org/html/rfc8259#section-3 --

  A JSON value MUST be an object, array, number, or string, or one of
  the following three literal names:

      false
      null
      true

  The literal names MUST be lowercase.  No other literal names are
  allowed.

There are also a number of other syntax errors in this JSON example, even
setting aside the "additional JSON" indication.

---------------------------------------------------------------------------

§5.8:

>  A MASA that returns a code 200 MAY also include a Location: header
>  for future reference by the registrar.

Nit: "Location: header field"

Also, it's not 100% clear what the registrar would use this URI for. Please
explain in the document.

---------------------------------------------------------------------------

§5.8.1:

>  {
>    "version":"1",
>    "events":[
>      {
>      "date":"",
>      "domainID":"",
>      "nonce":""
>      "assertion":""
>      "truncated":""
>      },
>      {
>      "date":"",
>      "domainID":"",
>      "nonce":""
>      "assertion":""
>      }
>    ],
>    "truncation": {
>      "nonced duplicates": "",
>      "nonceless duplicates": "",
>      "arbitrary": ""
>      }
>  }

This JSON is syntactically invalid. Please validate.

---------------------------------------------------------------------------

§5.8.1:

>  Distribution of a large log is less than ideal.  This structure can
>  be optimized as follows: Nonced or Nonceless entries for the same
>  domainID MAY be truncated from the log leaving only the single most

Nit: "truncate" means to shorten something by removing only the beginning or
only the end. I believe that you mean "omitted" (here and elsewhere in this
section).

---------------------------------------------------------------------------

§5.9.4:

>  {
>    "version":"1",
>    "Status":TRUE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": "Additional information"
>  }

This JSON is syntactically invalid. Please validate.


---------------------------------------------------------------------------

§6:

>  In the BRSKI context, the EST "Content-Transfer-Encoding" header if
>  present, SHOULD be ignored.  This header does not need to included.

Nit: "...header field, if present..."

Nit: "This header field does not..."

---------------------------------------------------------------------------

§8.1:

>  This document extends the definitions of "est" (so far defined via
>  RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
>  well-known-uris.xhtml" registry as follows:
>
>  o  add /.well-known/est/requestvoucher (see Section 5.5 )
>
>  o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known registry does not contain sub-paths under the path
element that appears after ".well-known". I note that "est" has already
been registered by RFC 7030. There are a bunch of ways this can be
handled, the easiest of which would be a request for the IANA to add
this RFC alongside RFC 7030 to the entry for "est."

More complex solutions would be selecting a different path than
"est", or establishing a separate sub-registry for paths under
the "est" well-known path.

---------------------------------------------------------------------------

§8.4:

>  Service Name: _brski-proxy
...
>  Service Name: _brski-registrar

You almost certainly don't want the service name to contain a leading
underscore. That is added as part of the DNS-SD resolution process, but
not part of the service name itself.

---------------------------------------------------------------------------

Appendix B:

>  For example, if the first
>  Multicast DNS _bootstrapks._tcp.local response doesn't work then the
>  second and third responses are tried.

I got a little lost here. Where is the "bootstrapks" service defined?
I don't see it defined in this document or registered at
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=bootstrapks

[Ballot discuss]
(1) The text of the document suffers from lack of clarity throughout about
whether the nonce-ful operation is mandatory or not, with several
figures and discussions making declarative statements about nonce usage
and others saying that nonce usage is optional. (See COMMENT.)

(2) There also seems to be internal inconsistency about the proximity
assertion process (and, any sort of assertion in a voucher-request at
all, it seems).  I've tried to note some locations in the Comment
section.

(3) There are other internal inconsistencies as well, including about
section references for when various behaviors occur (see COMMENT).

(4) In Section 5.6.1

  The pledge MUST verify that the voucher nonce field is accurate and
  matches the nonce the pledge submitted to this registrar, or that the
  voucher is nonceless (see Section 7.2).

Is the pledge supposed to accept a nonceless voucher in response to a
nonce-ful voucher request?

(5) RFC7951 is cited for the audit log response, but I cannot find the
underlying YANG module that is JSON-encoded using the RFC 7951
procedures.
Furthermore, I don't think the "nonce" handling (with explicit "NULL"
string where base64-encoded binary data might be expected) would be
consistent with the 7951 rules.

(5) the new /enrollstatus EST endpoint seems under-specified.

(6) In Section 7.2:

  The pledge can choose to accept vouchers using less secure methods.
  These methods enable offline and emergency (touch based) deployment
  use cases:

  1.  The pledge MUST accept nonceless vouchers.  This allows for a use

It's very unclear to me what this "MUST" means, especially so given that
the entire section 7 is declared to be non-normative.  Is it that the
client "can choose" whether it "MUST accept nonceless vouchers"?
That would seem to make the MUST basically ineffective.

More broadly, if the entire Section 6 is non-normative, why is there any
normative language in it?

(7) the new /enrollstatus and /voucher_status well-known EST endpoints
are not registered in Section 8.1

(7.1) I think we also need to register the
"urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"  XML namespace.

(8) The versioning mechanism for Pledge BRSKI Status Telemetry is
underspecified, including the interaction with new registered values.

(9) The versioning mechainsm for the MASA audit log response is
underspecified, including whether a registry of field names is
appropriate.

(10) The term PKIX seems to be incorrectly used a few times; it refers
to the Internet PKI, and so things like a private PKI internal to a
manufacturer would probably not be best described as such.  Such private
PKIs can of course still reuse the protocols and mechanisms developed
for PKIX, and it's accurate to describe them as such.

(11) In a few places we describe the voucher-request in terms of its
YANG structure but do not say that it has to be wrapped in a signed CMS
object as is done for the RFC 8366 voucher.

(12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the
domainID calculation?

(13) In Section 5.5.1:

  As described in [RFC8366] vouchers are normally short lived to avoid
  revocation issues.  If the request is for a previous (expired)
  voucher using the same registrar then the request for a renewed
  voucher SHOULD be automatically authorized.  The MASA has sufficient

I don't understand what "for a previous (expired) voucher" means.
Is it something like "containing the same content as a previous voucher
request for which a voucher was issued", with the presumption that the
voucher expired before the pledge could successfully imprint, so it
needs to try again?  Or does this extend to longer timescales, like a
device that gets deployed for a couple years and is  then reset to
factory settings and has to rebootstrap but is still by the same
registrar?


(14) In Section 5.6:

                            The server MUST answer with a suitable 4xx
  or 5xx HTTP [RFC2616] error code when a problem occurs.  In this
  case, the response data from the MASA MUST be a plaintext human-
  readable (ASCII, English) error message containing explanatory
  information describing why the request was rejected.

It seems hard to support this stance on internationalization in 2019.


(15) In Section 5.9.4:

  To indicate successful enrollment the client SHOULD re-negotiate the
  EST TLS session using the newly obtained credentials.  This occurs by
  the client initiating a new TLS ClientHello message on the existing
  TLS connection.  The client MAY simply close the old TLS session and
  start a new one.  The server MUST support either model.

Is this supposed to be sending a new TLS ClientHello in the application
data channel or as a new handshake message (aka "renegotiation")?  The
latter is not possible in TLS 1.3 and is generally disrecommended
anyways even in TLS 1.2.  I would strongly suggest to remove the
"renegotiation" option and just leave "close the connection and start a
new connection/handshake".

[Ballot comment]
[disclaimer: some of these comments get pretty blunt at the end; it's a
long document and I'm tired.  Please try not to get too annoyed if I'm
failing to see something that's right in front of me.]

I concur with the directorate reviewers that expected a
high-level security analysis of what information flows where, and what
policy choices can be made that affect it.  At a *very* high level
(skipping over a lot of things that I would expect to see), this would
be structured like:

On initial bootstrap, a new device uses local service autodiscovery to
locate a (proxy to a) local registrar.  Having found a candidate
registrar, the fledgling pledge sends a fair bit of information about
itself to the registrar, including its serial number and device identity
(IDevID) along with a voucher request.  The registrar can determine
whether it expected such a device to appear, and locate a MASA, probably
from an extension in the IDevID.  Having determined that the MASA is
suitable, the entire information from the initial voucher request
(including device serial number) is transmitted over the internet in a
TLS protected channel to the manufacturer, along with information about
the registrar/owner.  The manufacturer can then apply policy based onthe
provided information and other sources of information, deciding whether
to approve the claim  by the registrar to own the device; if the claim
is accepted, a voucher is issued that directs the device to accept its
new owner.  The voucher is returned to the registrar, but not
necessarily to the device -- the registrar has an opportunity to examine
the voucher, the MASA's audit logs, and other sources of information to
determine whether the device has been tampered with, whether the
bootstrap should be accepted, etc.  No filtering of information is
possible in the signed voucher, so this is a binary accept-or-not
decision.  If the registrar accepts the voucher as a proper one for its
device, the voucher is returned to the pledge for imprinting.
The voucher also includes a trust anchor that the pledge should use as
representing the owner, successfully bootstrapping from an environment
where only the manufacturer has some (limited) level of trust by the
device into an environment where an owner has a PKI footprint on the
device.  When BRSKI is followed with EST this single footprint is
further leveraged into the full owner's PKI and a LDevID for the device.
Subsequent reporting steps provide flows of  information to indicate
success/failure of the process.

I also concur with the directorate reviewer that wanted to see more
discussion about the tradeoff in the applicability statement between
manufacturer control and ease/automation of bootstrap

Abstract

(side note?) Is there a quick explanation of why bootstrapping can
complete with just installation of the PKI (trust anchor?) and
provisioning a locally issued certificate is not mandatory?

Section 1

  This document describes how pledges discover (or be discovered by) an
  element of the network domain to which the pledge belongs to perform
  the bootstrap.  [...]

nit: s/be/are/, IIUC.
I think there's also something funky with the wording of "to perform the
bootstrap"; we may be looking for an element "that will perform the
bootstrap".

  4.  Pledge authorizing the registrar: "Should I join it?"

nit: what is "it"?  Surely not the registrar, and presumably the
"network domain" in question?

  This document details protocols and messages to answer the above
  questions.  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

I'm kind of confused by "[IDevID] LDevID", since my understanding was
that the LDevID is issued only after all four steps are complete.
Also, following the IDevID link lands me at a page that claims to be for
a standard of status "superseded".
nit: one can use X.509v3 without being PKIX, and it's not entirely clear
that the IDevIDs will chain up to the Internet PKI.

Section 1.2

RFC 8174 has an updated version of the BCP 14 boilerplate.

I'd suggest adding "MASA Audit Log" as a defined term to give advance
warning that this is an explicit protocol feature.

  domainID:  The domain IDentity is the 160-bit SHA-1 hash of the BIT
      STRING of the subjectPublicKey of the pinned-domain-cert leaf,
      i.e. the Registrars' certificate.  This is consistent with the
      subject key identifier (Section 4.2.1.2 [RFC5280]).

What would it take to move away from SHA-1 for this purpose?  It's
unclear how long it will be before finding a second preimage of the SPKI
hash is feasible and thus using it as an identifier no longer serves to
uniquely identify something.

  enrollment:  The process where a device presents key material to a
      network and acquires a network specific identity.  For example

nit: hyphenate "network-specific".

Section 1.4

  As a result of the protocol described herein, the bootstrapped
  devices have the Domain CA trust anchor in common.  An end entity
  certificate has optionally been issued from the Domain CA.  [...]

This end-entity certificate is supposed "to authenticate each
bootstrapped device to other parties in the domain", right?

  The major beneficiary is that it possible to use the credentials
  deployed by this protocol to secure the Autonomic Control Plane (ACP)
  ([I-D.ietf-anima-autonomic-control-plane]).

I might humbly suggest "major intended beneficiary", as there seem to be
many possibilities involving BRSKI.

Section 1.5

  The pledge must perform discovery of the proxy as described in
  Section 4.1 using GRASP M_FLOOD announcements.

Is this DULL GRASP or full-on ACP GRASP flooding?

  Upon successfully validating a voucher artiface, a status telemetry
  MUST be returned.  See Section 5.7.

nit: artifact (right?)

  The ANI Join Registrar ASA MUST support all the BRSKI and above
  listed EST operations.

nit: probably need to expand ASA the first time.

Section 2

The text following Figure 1 suggests that the Domain Registrar is not
always (also) a PKI RA, but the parentheticals in the figure itself are
easy to read as a clarification and not an optional thing, especially
since parentheticals are used in a different manner for the Key
Infrastructure box.

Section 2.1

  3.  Request to join the discovered registrar.  A unique nonce is
      included ensuring that any responses can be associated with this
      particular bootstrapping attempt.

But the nonce is not always present!

  5.  Enroll.  After imprint an authenticated TLS (HTTPS) connection
      exists between pledge and registrar.  Enrollment over Secure
      Transport (EST) [RFC7030] is then used to obtain a domain
      certificate from a registrar.

Isn't this step optional?

Section 2.2

  A voucher is a cryptographically protected artifact (a digital
  signature) to the pledge device authorizing a zero-touch imprint on
  the registrar domain.

nit: "using a digital signature"

  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.

nit: is there supposed to be a comma after "policy decisions" (in that
both the transport and policy decisions allow for policy enforcement)?

Section 2.3

  Pledge authentication and pledge voucher-request signing is via a
  PKIX certificate installed during the manufacturing process.  This is

(As noted elsewhere, "PKIX" may not be the best term here.)

  1.  Uniquely identifying the pledge by the Distinguished Name (DN)
      and subjectAltName (SAN) parameters in the IDevID.  The unique
      identification of a pledge in the voucher objects are derived
      from those parameters as described below.

These unique identifiers can (by design) be used for tracking, so let's
be sure that we talk about any privacy considerations with them, later.
I see a mention in passing in Section 10.2, at least...

  3.  Secure auto-discovery of the pledge's MASA by the registrar (see
      Section 2.8).

I don't think this is an ironclad property, since the crypto chain is
slightly limited and you are in effect trusting the pledge to hand you
something that says "use this issuer" but without as much crypto to back
that up as we might want.  We have to know that the given manufacturer
that signed the IDevID actually is associated with the device we're
trying to bootstrap, which can probably be arranged but I don't remember
being called out explicitly.

  Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
  extensions in the IDevID certificate.  Any restrictions included

I only got my hands on the 2018 rev of [IDevID], but that one does not
actually talk about extendedKeyUsage.

Section 2.3.1

  In the context of BRSKI, pledges are uniquely identified by a
  "serial-number".  This serial-number is used both in the "serial-
  number" field of voucher or voucher-requests (see Section 3) and in
  local policies on registrar or MASA (see Section 5).

(editorial) if the IDevID is supposed to be a unique identifier, why do
we need another one?

  o  The subject field's DN encoding MUST include the "serialNumber"
      attribute with the device's unique serial number.  (from [IDevID]
      section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
      attributes)

side note: I had to think a  bit to convince myself that DN is the right
thing here; when we use dnsNames it's preferred to put them in
subjectAltName to avoid having to pick a preferred/privileged one, but
the serial number does seem to be in a privileged position for
distinguishing the subject.

  o  The subject-alt field's encoding MAY include a non-critical
      version of the RFC4108 defined HardwareModuleName.  (from [IDevID]
      section 7.2.9) If the IDevID is stored in a Trusted Platform
      Module (TPM), then this field MAY contain the TPM identification
      rather than the device's serial number.  If both fields are
      present, then the subject field takes precedence.

"if both fields are present", but the subject field MUST be present, so
this field can never take precedence.

  1.  [RFC4519] section 2.31 provides an example ("WI-3005") of the
      Distinguished Name "serialNumber" attribute.  [RFC4514] indicates
      this is a printable string so no encoding is necessary.

I don't understand why these references were chosen.  Why are LDAP specs
authoritative about what the encoding format for the serialNumber DN
attribute is?  E.g., one could look at RFC 5280 to see that
X520SerialNumber is a PrintableString.

  2.  The HardwareModuleName hwSerialNum OCTET STRING.  This value is
      base64 encoded to convert it to a printable string format.

Please cite Section 4 of RFC 4648 (unless you mean base64url, in which
case use Section 5).
Also, it might be nice to somehow (maybe enumerate the first list in the same
way) tie these two items to the respective subject ND/subjectAltName
fields, to clarify why these are the only two choices.

  As explained in Section 5.5 the Registrar MUST extract the serial-
  number again itself from the pledge's TLS certificate.  [...]

To be clear, this is still the device's IDevID certificate, that just
happens to be getting used as a TLS client certificate.

Section 2.3.2

nit: maybe put a blank line after the IMPORTS are over?

Section 2.4

In Figure 3, I had to think a bit to figure out whether the text that
did not fit mid-arrow was supposed to apply to the arrow above or below
the text (e.g., "optional: mDNS query RFC6763/RFC6762").

[Hmm, so we send our TLS client cert on the provisional connection,
meaning that we have to trust the proxy and registrar to be doing the
right thing w.r.t. broadcasting our identity to the world]

Section 2.5.1

  The pledge is the device that is attempting to join.  Until the
  pledge completes the enrollment process, it has link-local network
  connectivity only to the proxy.

nit(?): I think there is a subtle difference in  meaning between "only
has link-local network connectivity to the proxy" and this text, and I'm
not sure which is intended.

Section 2.5.3

This may just be my personal preference (so feel free to ignore), but
talking about a "trust store used to authenticate the MASA" and "trust
store used to authenticate the pledge" would feel more readable than
"trust anchor database for authenticating the [thing] TLS connection
[thing] certificate".

It may be worth some comment about how this requirement for out-of-band
distribution of implicit trust anchors is something that BRSKI is
designed to avoid, but that distributing to just the registrar is a much
more manageable task than distributing them to all devices/pledges.

Section 2.5.5

  The Public Key Infrastructure (PKI) administers certificates for the
  domain of concerns, providing the trust anchor(s) for it and allowing

nit: "domain of concern" singular

  The voucher provides a method for the distribution of a single PKI
  trust anchor (as the "pinned-domain-cert").  A distribution of the

Earlier we talked about the "pinned-domain-cert leaf" in  the domainID
definition.  Was that supposed to be "leaf"  in the YANG sense and not
in the PKIX "leaf certificate"/"end-entity certificate" sense?

  The expectations of the PKI are unchanged from EST [[RFC7030]].  This

Which parts of RFC 7030 talk about its expectations of the PKI?

Section 2.6.1

  Many devices when bootstrapping do not have knowledge of the current
  time.  Mechanisms such as Network Time Protocols cannot be secured
  until bootstrapping is complete.  Therefore bootstrapping is defined
  in a method that does not require knowledge of the current time.  A

nit: I'd suggest maybe "framework", "scenario", or "environment" rather
than "method".

Section 2.6.2

  [RFC5280] explains that long lived pledge certificates "SHOULD be
  assigned the GeneralizedTime value of 99991231235959Z".  Registrars

This misses the important "for the notAfter field" part.

Why is 3 years the relevant cutoff here?

Section 2.7

  There exist operationally open network wherein devices gain

nit: "networks"  plural

  unauthenticated access to the internet at large.  In these use cases
  the management domain for the device needs to be discovered within
  the larger internet.  These are less likely within the anima scope
  but may be more important in the future.

nit: less likely than what?

  There are additionally some greenfield situations involving an
  entirely new installation where a device may have some kind of
  management uplink that it can use (such as via 3G network for
  instance).  In such a future situation, the device might use this
  management interface to learn that it should configure itself to
  become the local registrar.

  In order to support these scenarios, the pledge MAY contact a well
  known URI of a cloud registrar if a local registrar cannot be
  discovered or if the pledge's target use cases do not include a local
  registrar.

I don't see the connection between "configure itself to become the local
registrar" and "contact a well-known URI of a cloud registrar".

  If the pledge uses a well known URI for contacting a cloud registrar
  an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
  authenticate service as described in [RFC6125].  This is consistent

Would this be more likely to be installed by the manufacturer or device
owner?
nit: "service" needs an article.

Section 2.8

  approach if they ensure a single MASA URL works for all pledge's
  associated with each trust anchor.

nit: "pledges" non-possessive

Section 3

  A pledge forms the "pledge voucher-request" and submits it to the
  registrar.

It would be helpful (at least to me) to know that the request is signed
by the IDevID cert, here.

  The "proximity-registrar-cert" leaf is used in the pledge voucher-
  requests.  This provides a method for the pledge to assert the
  registrar's proximity.

"proximity" in what sense?  How much verification/confidence needs to be
done?  (Also, I would have expected the assertion to go the other way;
that the registrar asserts the pledge's proximity -- how does the pledge
have a way to know that the registrar is nearby when the proxy is
transparent?)

Section 3.3

  Example (1)  The following example illustrates a pledge voucher-
                request.  The assertion leaf is indicated as 'proximity'
                and the registrar's TLS server certificate is included
                in the 'proximity-registrar-cert' leaf.  See
                Section 5.2.

  {
      "ietf-voucher-request:voucher": {
          "nonce": "62a2e7693d82fcda2624de58fb6722e5",
          "created-on": "2017-01-01T00:00:00.000Z",
          "proximity-registrar-cert": "base64encodedvalue=="
      }
  }

I do not see an 'assertion' leaf populated.

  Example (2)  The following example illustrates a registrar voucher-
                request.  The 'prior-signed-voucher-request' leaf is
                populated with the pledge's voucher-request (such as the
                prior example).  The pledge's voucher-request is a
                binary object.  In the JSON encoding used here it must

Why is it a binary object?  We just saw a previous example with a JSON
(non-binary) encoding.  (Hint: CMS-signed,but we didn't say that.)

                be base64 encoded.  The nonce, created-on and assertion
                is carried forward.  The serial-number is extracted from

There is (again) no assertion, and the created-on does not match
exactly.

Section 3.4

The RFC 8174 version of the BCP 14 boilerplate could be used in the
module, too.
Also, is the 2017 copyright still correct, especially given that it is a
2018-02-14 revision?

            For example, a pledge might sign a voucher request
            with a proximity-registrar-cert, and the registrar
            then includes it in the prior-signed-voucher-request field.

nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)?

            This is a simple mechanism for a chain of trusted
            parties to change a voucher request, while
            maintaining the prior signature information.

"chain" seems to admit the possibility of more than one
modification/resigning event, but the architecture as described seems to
only have the registrar doing this.

            registrar agree on proximity assertions. The MASA SHOULD
            remove all prior-signed-voucher-request information when
            signing a voucher for imprinting so as to minimize the
            final voucher size.";

(side note?) This removal would open up some minor exotic attacks in
cases where a pledge reuses an existing nonce (potentially from a
different device), but is probably an okay tradeoff to make.

            The first certificate in the Registrar TLS server
            certificate_list sequence  (see [RFC5246]) presented by
            the Registrar to the Pledge. This MUST be populated in a
            Pledge's voucher request if a proximity assertion is
            requested.";

5246 is replaced by 8446.
It might be simplest to just say the "end-entity TLS certificate", at
least for TLS practitioners.  (Maybe nof for a different audience,
though.)
How do I know that a proximity assertion is requested?

Section 4

  The role of the proxy is to facilitate communications.  The proxy
  forwards packets between the pledge and a registrar that has been
  provisioned to the proxy via GRASP discovery.

[same DULL question as above]

  The proxy does not terminate the TLS handshake: it passes streams of
  bytes onward without examination.  A proxy MUST NOT assume any
  specific TLS version.

Passing bytes without examination is by definition not assuming any
version of TLS.  So while I  think it would make the most  sense to just
remove that sentence, if it's going to say it  might be worth also
noting the TLS invariants discussed in
https://tools.ietf.org/html/rfc8446#section-9.3 .

Section 4.1

  through a proxy.  The proxy is transparent to the pledge.  The
  communication between the pledge is over IPv6 Link-Local addresses.

nit: between the pledge and what?

  M_FLOOD.  The active methods SHOULD exponentially back-off to a
  maximum of one hour to avoid overloading the network with discovery
  attempts.  Detection of change of physical link status (ethernet
  carrier for instance) SHOULD reset the exponential back off.

Mathematically, "exponential" requires to specify the base of the
exponent (or just say "by doubling").  (Also later in the section.)

  Once all discovered services are attempted (assuming that none
  succeeded) the device MUST return to listening for GRASP M_FLOOD.  It
  SHOULD periodically retry the manufacturer specific mechanisms.  The
  pledge MAY prioritize selection order as appropriate for the
  anticipated environment.

nit: "manufacturer-specific" takes a hyphen
not-nit: what are "the manufacturer-specific mechanisms"?  (I don't
remember such discussion yet.)

  Once all discovered services are attempted (assuming that none
  succeeded) the device MUST return to listening for GRASP M_FLOOD.  It
  SHOULD periodically retry the manufacturer specific mechanisms.  The
  pledge MAY prioritize selection order as appropriate for the
  anticipated environment.

nit: "manufacturer-specific" takes a hyphen
not-nit: what are "the manufacturer-specific mechanisms"?  (I don't
remember such discussion yet.)

Section 4.1.1

Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or
some other notation?
Also, I'm not sure that picking an arbitrary (representative) session-id
value, LL address, and port is helpful when describing the formatting of
the message.  Maybe some different introductory text would change
things.

Section 4.3

If we're only defining an EST-TLS objective, how will proxies know that
the registrar supports BRSKI?

It's a little weird to put the reference for GRASP but not ACP.  Either
none or both would feel more natural (given that we've seen both already
a couple times).

Section 5

  MASA URI is "https://" iauthority "/.well-known/est".

nit: "The MASA URI".
Is this always the case, with no opportunity for modification, even as
included in an IDevID certificate extension?

  BRSKI uses JSON [RFC7159] for all new operations defined here, and

RFC 7159 is obsoleted by RFC 8259.

  While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
  connections, BRSKI-EST connections SHOULD use persistent connections.
  The intention of this guidance is to ensure the provisional TLS state
  occurs only once, and that the subsequent resolution of the provision
  state is not subject to a MITM attack during a critical phase.

I think we probably want a requirement that if persistent connections
are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST
check that the exact same certificate is used to authenticate the
registrar for all transactions.  If the signature in the handshake is
valid but you can only chain the certificate up to your trust anchor
once you finish imprinting, you still know that the entire session's
data has been talking to the now-authenticated party (as opposed to the
TLS case where you try to add a new certificate mid-connection, where
that boundary is unclear), but things are much easier to reason about if
you are sure that each EST transaction is talking to the same peer.

  o  In the language of [RFC6125] this provides for a SERIALNUM-ID
      category of identifier that can be included in a certificate and
      therefore that can also be used for matching purposes.  The
      SERIALNUM-ID whitelist is collated according to manufacturer trust
      anchor since serial numbers are not globally unique.

RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
the model of RFC 6125" or "provides a new SERIAL-ID category" or
similar.

  o  The registrar performs log verifications in addition to local
      authorization checks before accepting optional pledge device
      enrollment requests.

Maybe give us a section reference to what the "log validations" are?

Section 5.1

  Establishment of the BRSKI-EST TLS connection is as specified in EST
  [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
  [RFC7030] wherein the client is authenticated with the IDevID
  certificate, and the EST server (the registrar) is provisionally
  authenticated with an unverified server certificate.

I'd consider noting that the signature (or other operation) made by the
certificate must be validated, and that the received certificate and
chain must be retained for later validation.

  The pledge maintains a security paranoia concerning the provisional
  state, and all data received, until a voucher is received and
  verified as specified in Section 5.6.1

Since section 5.6.1 just talks about the voucher verification process, I
think we need to say more about what "security paranoia" entails:
acknowledging that all data transmitted is sent to an unauthenticated
peer, with corresponding privacy considerations, and that all received
data is not authenticated by the TLS connection and must be
self-authenticating or otherwise considered untrusted.

  A pledge that can not maintain as many connections as there are
  eligible proxies.  If no connection is making process after 5 seconds

nit: that's not a complete sentence.

Section 5.2

  application/voucher-cms+json  The request is a "YANG-defined JSON
      document that has been signed using a CMS structure" as described
      in Section 3 using the JSON encoding described in [RFC7951].  This

Section 3 does not describe any "sign[ing] using a CMS structure"
operation.

      voucher media type is defined in [RFC8366] and is also used for
      the pledge voucher-request.  The pledge SHOULD sign the request
      using the Section 2.3 credential.

To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
credential) to sign?

  constrained voucher formats are expected in the future.  Registrar's
  and MASA's are expected to be flexible in what they accept.

nits: no apostrophes for plurals.

  proximity-registrar-cert:  In a pledge voucher-request this is the
      first certificate in the TLS server 'certificate_list' sequence
      (see [RFC5246]) presented by the registrar to the pledge.  This
      MUST be populated in a pledge voucher-request if the "proximity"
      assertion is populated.

[same comment as above about "end-entity certificate"]

  The registrar validates the client identity as described in EST
  [RFC7030] section 3.3.2.  The registrar confirms that the 'proximity'
  assertion and associated 'proximity-registrar-cert' are correct.

what 'proximity' assertion?
Does verifying proximity-registrar-cert just mean checking that it's the
same leaf certificate that the registrar presented?  What happens if the
validation fails?

Section 5.3

  A Registrar accepts or declines a request to join the domain, based
  on the authenticated identity presented.  Automated acceptance
  criteria include:

I suggest "for different networks, examples of automated acceptance
criteria may include".

  If these validations fail the registrar SHOULD respond with an
  appropriate HTTP error code.

Similarly, "If validation fails".

Section 5.4

  The BRSKI-MASA TLS connection is a 'normal' TLS connection
  appropriate for HTTPS REST interfaces.  The registrar initiates the
  connection and uses the MASA URL obtained as described in Section 2.8
  for [RFC6125] authentication of the MASA.

I'd consider mentioning  the implicit trust anchor database as well as
the MASA URL.

  The MASA and the registrars SHOULD be prepared to support TLS client
  certificate authentication and/or HTTP Basic or Digest authentication
  as described in [RFC7030] for EST clients.  This connection MAY also
  have no client authentication at all (Section 7.4)

I don't see discussion of skipping client authentication in Section 7.4.
It would be great to have some, there!

  The authentication of the BRSKI-MASA connection does not affect the
  voucher-request process, as voucher-requests are already signed by
  the registrar.  Instead, this authentication provides access control
  to the audit log.

I don't understand what "access control to the audit log" means.  Is the
idea that the TLS client identity in the BSRKI-MASA connection is only
used when processing requests to the requestauditlog endpoint and that
some clients might be denied access?

Section 5.5

  created-on:  Registrars are RECOMMENDED to populate this field.  This
      provides additional information to the MASA.

Earlier we said that this field would be propagated from the pledge
voucher-request; we should probably say something like "populate this
field; if it was present in the pledge voucher-request it is copied
unchanged to the registrar voucher-request; otherwise the current time
is used".

  nonce:  This is the value from the pledge voucher-request.  The
      registrar voucher-request MAY omit the nonce as per Section 3.1)

I'd suggest "value from the pledge voucher-request, if present" and
changing the second sentence to refer to the pledge voucher-request.

  idevid-issuer:  The idevid-issuer value from the pledge certificate
      is included to ensure a statistically unique identity.

There is no "idevid-issuer" field in the pledge certificate; I assume
this is supposed to be the Issuer Name of the IDevID certificate.

  prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  (NOTE: what
      is included is the complete pledge voucher-request, inclusive of
      the 'assertion', 'proximity-registrar-cert', etc wrapped by the
      pledge's original signature).  If a signed voucher-request was not
      recieved from the pledge then this leaf is omitted from the
      registrar voucher request.

This is a good example of text that implies the signed voucher is
binary.  (And as such would be a good place to talk about the base64
encoding.)

  All other fields MAY be omitted in the registrar voucher-request.

Should the proximity-registrar-cert field *not* be present?

Section 5.5.2

  The MASA MUST verify that the registrar voucher-request is signed by
  a registrar.  This is confirmed by verifying that the id-kp-cmcRA
  extended key usage extension field (as detailed in EST RFC7030
  section 3.6.1) exists in the certificate of the entity that signed
  the registrar voucher-request.  This verification is only a
  consistency check that the unauthenticated domain CA intended the
  voucher-request signer to be a registrar.  Performing this check
  provides value to the domain PKI by assuring the domain administrator
  that the MASA service will only respect claims from authorized
  Registration Authorities of the domain.

If the MASA has no prior knowledge of the domain (certificate), this is
susceptible to anyone spinning up something that claims to be a domain
CA and issuing registrar certs with that extension.  We need to document
somewhere what other part of the system prevents that from causing an
unauthorized voucher to be used.  (Perhaps preventing one from being
issued is not feasible, but acceptable if the pledge will not accept
it, though there remains risk of DoS on the MASA.)

Section 5.5.3

  If a nonceless voucher-request is submitted the MASA MUST
  authenticate the registrar as described in either EST [RFC7030]
  section 3.2, section 3.3, or by validating the registrar's

Subsubsection references might be more helpful.

  In the nonced case, validation of the registrar MAY be omitted if the
  device policy is to accept audit-only vouchers.

I don't see any (SHOULD?) guidance about validating the registrar in the
nonced case when other policy is used.  Even the previous section does
not really say much to indicate there is value in authenticating the
signature on the voucher request.

Section 5.5.4

  authentication or voucher-request signature validation.  Similarly,
  as noted in Section 5.5.2, the MASA performs normal PKIX revocation
  checking during signature consistency checks (a signature by a
  registrar certificate that has been revoked is an inconsistency).

I think this needs to be noted more clearly in Section 5.5.2.

Section 5.5.5

  The MASA MAY verify that the registrar voucher-request includes the
  'prior-signed-voucher-request' field.  If so the prior-signed-
  voucher-request MUST include a 'proximity-registrar-cert' that is
  consistent with the certificate used to sign the registrar voucher-
  request.  Additionally the voucher-request serial-number leaf MUST

This seems kind of tautological ("if the MASA is checking X, X MUST have
happened").  Also, what does "consistent with"  mean?

  match the pledge serial-number that the MASA extracts from the
  signing certificate of the prior-signed-voucher-request.  The MASA is
  aware of which pledges support signing of their voucher requests and
  can use this information to confirm proximity of the pledge with the
  registrar, thus ensuring that the BRSKI-EST TLS connection has no
  man-in-the-middle.

To be clear, this MITM detection is only for the case of pledges that
sign their voucher requests, right?  And it seems to only hold if
pledges that support signing actually do sign, every time.

Section 5.5.6

  The registrar's certificate chain is extracted from the signature
  method.  The chain includes the domain CA certificate as specified in
  Section 5.5.  This certificate is used to populate the "pinned-

I don't think Section 5.5 is the right reference for "includes the
domain CA certificate" (both here and in 5.5.2).

  domain-cert" of the voucher being issued.  The domainID (e.g., hash
  of the root public key) is determined from the pinned-domain-cert and
  is used to update the audit log.

If the pinning takes the whole cert (per RFC 8366), then what do we need
the domainID for?  Just the audit log?  Surely in that case SHA-1 is
not a hard requirement...

Section 5.5.7

  The MASA MUST use the nonce from the registrar voucher-request for
  the resulting voucher and audit log.  The prior-signed-voucher-
  request nonce is ignored during this operation.

I don't understand this requirement.  They could only be different if
the MUST from the previous paragraph is ignored.

Section 5.6

  The MASA voucher response to the registrar is forwarded without
  changes to the pledge; therefore this section applies to both the
  MASA and the registrar.  The HTTP signaling described applies to both
  the MASA and registrar responses.  A registrar either caches prior
  MASA responses or dynamically requests a new voucher based on local
  policy (it does not generate or sign a voucher).  [...]

Do we need to say how this local caching policy interacts with HTTP
cache control headers?
I got confused by "or dynamically requests a new voucher" the first
couple times I read it; I landed on something like "when a voucher
request arrives at the registrar, if it has a cached response from the
MASA for the corresponding registrar voucher-request, that cached
response can be used according to local policy; otherwise the registrar
constructs a new registrar voucher-request and sends it to the MASA".

  type.  The registrar SHOULD use this response if it determines the
  pledge is unacceptable due to inventory control, MASA audit logs, or
  any other reason.

What does "unacceptable due to inventory control" mean?

  A 415 (Unsupported Media Type) response is approriate for a request
  that has a voucher-request or accept encoding that is not understood.

Isn't "Accept-Encoding:" a more typical spelling?

  vouchers are described in detail in [RFC8366].  For example, the
  voucher consists of:

  {
    "ietf-voucher:voucher": {
      "nonce": "62a2e7693d82fcda2624de58fb6722e5",
      "assertion": "logging"
      "pinned-domain-cert": "base64encodedvalue=="
      "serial-number": "JADA123456789"
    }
  }

nit: I think "might consist of" is better than "consists of".

  assertion:  The method used to verify assertion.  See Section 5.5.5.

The method used to verify itself?

  The pledge MUST be prepared to parse and fail gracefully from a
  voucher response that does not contain a 'pinned-domain-cert' field.

What would such a graceful failure look like?  Reverting back to the
discovery stage, since without a manufacturer-validated indication of
the trust anchor for the domain, the pledge cannot  consider itself to
be a part of a domain?

Section 5.6.2

  found.  It SHOULD return to the same proxy again after attempting
  with other proxies.  Attempts should be attempted in the exponential

But only if those other proxies failed to produce a valid voucher?

  The pledge's PKIX path validation of a registrar certificate's
  validity period information is as described in Section 2.6.1.  Once
  the PKIX path validation is successful the TLS connection is no
  longer provisional.

Section 2.6.1 doesn't actually say that the pledge has to check the five
listed timestamps in the case that it does have a realtime clock.

Section 5.7

  To indicate pledge status regarding the voucher, the pledge MUST post
  a status message.

I think we've had other text that implies that providing telemetry is
optional; perhaps just "the pledge POSTs a status message"?

  The client HTTP POSTs the following to the server at the EST well
  known URI "/voucher_status".  The Status field indicates if the

I think it's probably more clear to write out
".well-known/est/voucher_status"; there's not a separate registry of EST
well-known URIs.


We don't actually have anything in  this section that declares "this is
the structure of the JSON object used as the POST body"; it's only
implicitly provided.

  indicates why.  In the failure case this message may be sent to an
  unauthenticated, potentially malicious registrar and therefore the
  Reason string SHOULD NOT provide information beneficial to an
  attacker.  The operational benefit of this telemetry information is

What sort of information might a pledge consider including that would be
beneficial to an attacker?

  {
    "version":"1",
    "Status":FALSE /* TRUE=Success, FALSE=Fail"

I guess you should probably close the comment, not that this is a
formal comment syntax for JSON...

  The reason-context attribute is an arbitrary JSON object (literal
  value or hash of values) which provides additional information
  specific to this pledge.  The contents of this field are not subject
  to standardization.

This still have some privacy considerations, though.

Section 5.8

  is posted to the /requestauditlog URI instead.  The "idevid-issuer"
  and "serial-number" informs the MASA which log is requested so the
  appropriate log can be prepared for the response.  Using the same

Is the implicit point that the other fields are ignored?

  A registrar MAY request logs at future times.  If the registrar
  generates a new request then the MASA is forced to perform the
  additional cryptographic operations to verify the new request.

Is this statement just supposed to be further justification for using
the original voucher-request as the POST body, or describing new
behavior?

  A MASA that receives a request for a device that does not exist, or
  for which the requesting owner was never an owner returns an HTTP 404
  ("Not found") code.

What is a "requesting owner"?  I thought devices were owned by the
domain, not the specific registrar.

  In order to avoid enumeration of device audit logs, MASA that return
  URLs SHOULD take care to make the returned URL unguessable.  For
  instance, rather than returning URLs containing a database number
  such as https://example.com/auditlog/1234 or the EUI of the device
  such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
  return a randomly generated value (a "slug" in web parlance).  The
  value is used to find the relevant database entry.

https://www.w3.org/TR/capability-urls/ may also be a useful reference.

Section 5.8.1

  A log data file is returned consisting of all log entries associated
  with the the device selected by the IDevID presented in the request.
  The audit log may be truncated of old or repeated values as explained
  below.  The returned data is in JSON format ([RFC7951]), and the
  Content-Type SHOULD be "application/json".  For example:

If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data".

  This document specifies a simple log format as provided by the MASA
  service to the registrar.  This format could be improved by
  distributed consensus technologies that integrate vouchers with
  technologies such as block-chain or hash trees or optimized logging
  approaches.  Doing so is out of the scope of this document but is an
  anticipated improvement for future work.  As such, the registrar
  client SHOULD anticipate new kinds of responses, and SHOULD provide
  operator controls to indicate how to process unknown responses.

This would be a great place to talk about the "version" field that's
otherwise ignored.

  anticipated improvement for future work.  As such, the registrar
  client SHOULD anticipate new kinds of responses, and SHOULD provide
  operator controls to indicate how to process unknown responses.

Is "registrar client" intended to be both words or just one?

  A registrar SHOULD use the log information to make an informed
  decision regarding the continued bootstrapping of the pledge.  The

I may be confused, but I thought the registrar was asking for the log
after the voucher had already been issued.  Are these check supposed to
keep the registrar from forwarding the voucher to the  pledge, or just
as a check for future renewal operations?

  A relatively simple policy is to white list known (internal or
  external) domainIDs and to require all vouchers to have a nonce and/
  or require that all nonceless vouchers be from a subset (e.g. only
  internal) domainIDs.  A simple action is to revoke any locally issued

nit: missing "of"

  credentials for the pledge in question or to refuse to forward the
  voucher.  A registrar MAY be configured to ignore the history of the

"simple action" in the case that the registrar doesn't like the audit
log results?

  device but it is RECOMMENDED that this only be configured if hardware
  assisted NEA [RFC5209] is supported.

Probably need to expand NEA.

Section 5.9

  Although EST allows clients to obtain multiple certificates by
  sending multiple CSR requests BRSKI mandates use of the CSR
  Attributes request and mandates that the registrar validate the CSR
  against the expected attributes.  This implies that client requests

Where is this requirement stated normatively?

Section 5.9.1

  This ensures that the pledge has the complete set of current CA
  certificates beyond the pinned-domain-cert (see Section 5.6.1 for a
  discussion of the limitations inherent in having a single certificate
  instead of a full CA Certificates response.)  Although these

I don't see such a discussion in the indicated section.

Section 5.9.2

  To alleviate these operational difficulties, the pledge MUST request
  the EST "CSR Attributes" from the EST server and the EST server needs
  to be able to reply with the attributes necessary for use of the
  certificate in its intended protocols/services.  This approach allows

"intended" implies that the EST server has some knowledge of what the
pledge is expected to be doing in the network, right?

  To alleviate these operational difficulties, the pledge MUST request
  the EST "CSR Attributes" from the EST server and the EST server needs
  to be able to reply with the attributes necessary for use of the
  certificate in its intended protocols/services.  This approach allows
  for minimal CA integrations and instead the local infrastructure (EST
  server) informs the pledge of the proper fields to include in the
  generated CSR.  This approach is beneficial to automated boostrapping
  in the widest number of environments.

This is convenient, but has some security considerations in that it
implies that the validation policy on the CA is somewhat  lax, since the
EST server is expected to be doing most of the policy controls.  Thus, a
compromised pledge/device could send a CSR with unauthorized fields and
it is likely to be signed, allowing for some level of privilege
escalation.  When the registrar acts as a proxy to the CA as well as its
EST role, as described later, this risk is diminished.

  In networks using the BRSKI enrolled certificate to authenticate the
  ACP (Autonomic Control Plane), the EST attributes MUST include the
  "ACP information" field.  See
  [I-D.ietf-anima-autonomic-control-plane] for more details.

This MUST seems like it belongs in the ACP spec and need not be repeated
here using normative language.

Section 5.9.4

  administrators concerning device lifecycle status.  This might
  include information concerning attempted bootstrapping messages seen
  by the client, MASA provides logs and status of credential
  enrollment.  [RFC7030] assumes an end user and therefore does not

This looks like a comma splice.

  In the case of a FAIL, the Reason string indicates why the most
  recent enrollment failed.  The SubjectKeyIdentifier field MUST be
  included if the enrollment attempt was for a keypair that is locally

We haven't talked about POSTing to a new status-report endpoing yet, so
this comes out of the blue.  It would probably be worth adding above
"SHOULD [start a new TLS handshake] and POST a enrollment status
message".

    "Status":TRUE /* TRUE=Success, FALSE=Fail"

[same note about JSON comments]

    "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

  This allows for clients that wish to minimize their crypto operations
  to simply POST this response without renegotiating the TLS session -
  at the cost of the server not being able to accurately verify that
  enrollment was truly successful.

I'd prefer to not have this sort of option available, but I can't
disprove the claim of its utility, so I will not object if it stays.

Section 5.9.5

Is the idea that the initial BRSKI-EST-issued certificate would
authenticate the client for the subsequent EST requests?

Section 7

If this is non-normative and will need to be fleshed out in a separate
document, would an Appendix be more appropriate?

Section 7.1

  Pledge:  The pledge could be compromised and providing an attack
      vector for malware.  The entity is trusted to only imprint using
      secure methods described in this document.  Additional endpoint

How do "could be compromised" and "is trusted to only [...]" go
together?

  Vendor Service, MASA:  This form of manufacturer service is trusted
      to accurately log all claim attempts and to provide authoritative
      log information to registrars.  The MASA does not know which
      devices are associated with which domains.  These claims could be

I think this is maybe more of a "does not enforce" than "does not know",
since the domainID ends up in the audit logs that the MASA holds.

      Current text provides only for a trusted manufacturer.

nit: not a complete sentence.

Section 7.3

  A registrar can choose to accept devices using less secure methods.
  These methods are acceptable when low security models are needed, as
  the security decisions are being made by the local administrator, but
  they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

  Lower security modes chosen by the MASA service affect all device
  deployments unless bound to the specific device identities.  In which

Is this "unless the lower-security behavior is tied to specific device
identities"?

  case these modes can be provided as additional features for specific
  customers.  The MASA service can choose to run in less secure modes

nit: This middle sentence is not a complete sentence.

  1.  Not enforcing that a nonce is in the voucher.  This results in
      distribution of a voucher that never expires and in effect makes

A nonceless voucher can still include an expiration time ... it is just
in practice possible for it to never expire, if the target pledge does
not have an accurate clock.

      subsequent bootstrapping attempts.  That this occurred is
      captured in the log information so that the registrar can make
      appropriate security decisions when a pledge joins the Domain.
      This is useful to support use cases where registrars might not be
      online during actual device deployment.  Because this results in

nit: I think that grammatically the "This" at the start of this sentence
refers to the behavior described in the previous sentence  (the
availability of the log information) rather than the issuance of the
nonceless voucher.

Section 9

  The autonomic control plane that this document provides bootstrap for
  is typically a medium to large Internet Service Provider
  organization, or an equivalent Enterprise that has signficant layer-3
  router connectivity.  (A network consistenting of primarily layer-2

nit: "is used in" -- the ACP is not the entire organization!

Section 10.1

  The MASA audit log includes a hash of the domainID for each Registrar
  a voucher has been issued to.  This information is closely related to
  the actual domain identity, especially when paired with the anti-DDoS
  authentication information the MASA might collect.  This could

I thought I remembered some discussion of collecting this information
and thus what sort of information might be collected, but searching for
"DDoS" in the document didn't find it.

  There are a number of design choices that mitigate this risk.  The
  domain can maintain some privacy since it has not necessarily been
  authenticated and is not authoritatively bound to the supply chain.

Is this really "privacy" or just "semi-plausible deniability"?

  Additionally the domainID captures only the unauthenticated subject
  key identifier of the domain.  A privacy sensitive domain could

It's interesting to see "unauthenticated" used here, since the domainID
is deterministically generated from the pinned-domain-cert that is
included in the voucher and inserted into the pledge's trust store.  So
in a sense it is a committal by "the domain" to tie that domain cert to
that device or have the device otherwise be unusable.  The subsequent
text here seems to be suggesting that instead of having a single root CA
cert used by all devices in the domain, distinct certs would be used for
each device, thus attempting to remove an ability to associate devices
with each other via joint domain membership.  One might imagine doing
this by entering intermediate CAs (or even leafs?) into the
pinned-domain-cert field, but if those certs ever become visible (e.g.,
via certificate transparency), then the domainIDs can be independently
computed and associated to the MASA audit log, and the issuer chain used
to recorrelate the devices by domainID.  So to fully protect privacy,
the per-device pinned-domain-certs would need to be "root"s (i.e.,
self-issued), which greatly increases the manageability complexity and
is in effect counter to the goals of ANIMA and BRSKI.

Section 10.2

  While the contents of the signed part of the pledge voucher request
  can not be changed, they are not encrypted at the registrar.  The
  ability to audit the messages by the owner of the network prevents
  exfiltration of data by a nefarious pledge.  The contents of an

I think "prevents" is too strong -- steganography and concealed channels
are really hard to completely defend against.  "Gives a mechanism to
defend against" would be more accurate, in my opinion.

  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.

Deviations in what sense?

Section 10.3

  4.  There is a fourth case, if the manufacturer is providing
      protection against stolen devices.  The manufacturer then has a
      responsability to protect the legitimate owner against fraudulent
      claims that the the equipment was stolen.  Such a claim would
      cause the manufacturer to refuse to issue a new voucher.  Should
      the device go through a deep factory reset (for instance,
      replacement of a damaged main board component, the device would
      not bootstrap.

I'm  not sure I understand this scenario -- is it talking about where a
third party makes a false theft report in the hopes that the real owner
will have to do a deep reset and then have the device fail to bootstrap
because of the reported theft?

Section 11

  To facilitate logging and administrative oversight, in addition to
  triggering Registration verification of MASA logs, the pledge reports

I'm not sure if "Registration verification" is a typo or not.

  registrar.  This is mandated anyway because of the operational
  benefits of an informed administrator in cases where the failure is
  indicative of a problem.  The registrar is RECOMMENDED to verify MASA

I'd also expect some comment about the limited value of the additional
information to an attacker in the context where the attacker already
would know [other information].

  To facilitate truely limited clients EST RFC7030 section 3.3.2
  requirements that the client MUST support a client authentication
  model have been reduced in Section 7 to a statement that the
  registrar "MAY" choose to accept devices that fail cryptographic
  authentication.  This reflects current (poor) practices in shipping

But section 7 is non-normative!

  devices without a cryptographic identity that are NOT RECOMMENDED.

I guess if we really wanted to disrecommend this practice we could split
it out into a separate document that profiles core BRSKI for such usage.

Section 11.1

  this might be an issue during disaster recovery.  This risk can be
  mitigated by Registrars that request and maintain long term copies of
  "nonceless" vouchers.  In that way they are guaranteed to be able to
  bootstrap their devices.

This, of course, comes with a different risk of what is something like a
long-term credential existing that needs to be protected and stored.

  The issuance of nonceless vouchers themselves creates a security
  concern.  If the Registrar of a previous domain can intercept
  protocol communications then it can use a previously issued nonceless
  voucher to establish management control of a pledge device even after
  having sold it.  This risk is mitigated by recording the issuance of
  such vouchers in the MASA audit log that is verified by the
  subsequent Registrar and by Pledges only bootstrapping when in a
  factory default state.  This reflects a balance between enabling MASA
  independence during future bootstrapping and the security of
  bootstrapping itself.  Registrar control over requesting and auditing
  nonceless vouchers allows device owners to choose an appropriate
  balance.

I would expect some discussion here about nonceless vouchers
with/without expiration times.

I also wonder whether the owner or registrar should expect to be doing
soem periodic MASA audit log checking, akin to a CT auditor or monitor.

  of specific pledge devices, helps to mitigate this.  Pledge
  signatures on the pledge voucher-request, as forwarded by the
  registrar in the prior-signed-voucher-request field of the registrar
  voucher-request, significantly reduce this risk by ensuring the MASA
  can confirm proximity between the pledge and the registrar making the
  request.  This mechanism is optional to allow for constrained
  devices.  Supply chain integration ("know your customer") is an

And so the protection is only available when all devices served by the
MASA are known to produce signed voucher-requests.

  additional step that MASA providers and device vendors can explore.

In terms of adding some more crypto to the BRSKI-MASA flow that would
prevent unauthenticated DoS?

Section 11.2

I appreciate having this discussion present; thanks!

  The fake registrar (Rm) can obtain a voucher signed by the MASA
  either directly or through arbitrary intermediaries.  Assuming that

I'm not sure what sort of intermediary this is thinking about.

  This pledge voucher-request would be 'stale' in that it has a nonce
  that no longer matches the internal state of the pledge.  In order to
  successfully use any resulting voucher the Rm would need to remove
  the stale nonce or anticipate the pledge's future nonce state.
  Reducing the possibility of this is why the pledge is mandated to
  generate a strong random or pseudo-random number nonce.

This gets a bit more complicated to reason about when we assume that a
pledge will have multiple voucher requests out in parallel, instead of
doing them in sequence and timing out (so that there is literally only
one valid nonce at a given time)...

  Additionally, in order to successfully use the resulting voucher the
  Rm would have to attack the pledge and return it to a bootstrapping
  enabled state.  This would require wiping the pledge of current

... and I think there is a different attack if the Rm is in a position
to delay or drop network traffic between the  pledge and the intended
registrar, to cause Rm's voucher to be delivered first even though it is
generated after the intended registrar's authorization process.  The
intended registrar would need to require reports on voucher processing
status (or investigate their absence) in order to detect such a case.

  o  Retreival and examination of MASA log information upon the
      occurance of any such unexpected events.  Rm will be listed in the
      logs along with nonce information for analysis.

How strongly guaranteed is it that a given device will only have a single
specific MASA that it trusts to issue vouchers (and thus limit the scope
of monitoring needed by the owner)?

Section 11.3

  o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
      upon seeing a manufacturer's trust anchor for the first time, and
      then the trust anchor would be installed to the trusted store.
      There are risks with this; even if the key to name is validated
      using something like the WebPKI, there remains the possibility

nit: is this "key to name mapping"?

Section 11.4

It is not entirely clear to me whether device manufacturers are set up
with incentives to maintain a well-run secure CA with strong hardware
protections on the offline signing key for the root CA, cycling through
various levels of intermediates, etc., that CAs in the Web PKI do today.
If the manufacturer uses a less stringent process, that would leave the
manufacturer's key as a more tempting attack surface, and it may be
worth some discussion here about what damage could be done with a
compromised MASA signing key.  E.g., would an attack require restoring
devices to factory defaults or otherwise waiting for natural
bootstrapping events to occur?  Would the attacker need to be on-path?
Etc.

Section 13.2

I think CDDL needs to be a normative reference, as does RFC 7231.
RFC 2473 is listed but not referenced in the text, as are RFC 2663,
RFC 7217, and RFC 7575.

Appendix B

  Discovery of registrar MAY also be performed with DNS-based service
  discovery by searching for the service "_brski-
  registrar._tcp.example.com".  In this case the domain "example.com"
  is discovered as described in [RFC6763] section 11 (Appendix A.2
  suggests the use of DHCP parameters).

I'd suggest using "" per 6763 rather than "example.com".

  If no local proxy or registrar service is located using the GRASP
  mechanisms or the above mentioned DNS-based Service Discovery methods
  the pledge MAY contact a well known manufacturer provided
  bootstrapping server by performing a DNS lookup using a well known
  URI such as "brski-registrar.manufacturer.example.com".  The details
  of the URI are manufacturer specific.  Manufacturers that leverage
  this method on the pledge are responsible for providing the registrar
  service.  Also see Section 2.7.

It seems like there are some security considerations for device owners
that may wish to prevent such registrars from being used.  Do we need to
direct them to run a firewall or similar?

Appendix C

I don't know how important
file "ietf-mud-extension@2018-02-14.yang"
is, but it seems a tad generic.

Appendix D

[Just checking that Michael wants sandelman.ca embedded in the final
RFC]

[Ballot comment]
I support the comments that Warren makes in his ballot, and related comments in Alissa’s DISCUSS.  While simple device provisioning and onboarding is critical, especially in IoT scenarios, I, too, have serious concerns about how such setups can allow too much control by vendors of the use that legitimate buyers can make of the products they bought.

That said, I am balloting “no objection”, because I don’t think that my opinion on that overrides the consensus of the working group and the IETF community, and we and other SDOs are working on alternative mechanisms to do similar things.

[Ballot discuss]
I apologize if I'm misunderstanding how this works, but I didn't see much discussion in the document about the implications of the manufacturer going out of business. Specifically, it seems like if a device ships with BRSKI as its only available mechanism for bootstrapping and the manufacturer goes out of business before the device is enrolled, the ability for the device to function securely on the network may be significantly impaired if not impossible. It seems like this document needs to make clear to manufacturers that a fallback manual enrollment mechanism of some sort needs to be implemented along with BRSKI in order to avoid this situation.

= Section 1.3.1 =

"But this solution is not exclusive to large equipment: it is intended
  to scale to thousands of devices located in hostile environments,
  such as ISP provided CPE devices which are drop-shipped to the end
  user."

I don't quite understand how this squares with the scope limitation described in Section 1 and Section 9. If the whole network is professionally managed by the ISP, what part would be the "hostile environment"?

[Ballot comment]
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?

[Ballot discuss]
I support Eric’s Discuss position. Also a big thanks to Christian Huitema’s thorough SECDIR reviews and the associated improvements made as a result.  I have a few more items:

(1) Section 5.7.  The format of a pledge status telemetry message seems underspecified.

** what are all of the fields (e.g., version appears in the example but no the text)

** what are the field formats (e.g., the format of the status field is inferred from the unlabeled example

** which fields are mandatory?

** Per the JSON snippet, is that normative is some way in describing the format?

** Also, how does a server receiving the telemetry messages behave when receiving unexpected JSON attributes?

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is the JSON snippet presented here normative to describe the MASA audit log response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative?

-- How should implementers take this language?
-- Why are normative sections, like Section 11, discussing it?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4.  It helpfully lays justifies the current design approach.  I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed. 

My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension.  This is a substantial amount of work, and may be an area for future standardization work”.  Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging.

[Ballot discuss]
I support Eric’s Discuss position. Also a big thanks to Christian Huitema’s thorough SECDIR reviews and the associated improvements made as a result.  I have a few more items:

(1) Section 5.7.  The format of a pledge status telemetry message seems underspecified.

** what are all of the fields (e.g., version appears in the example but no the text)
** what are the field formats (e.g., the format of the status field is inferred from the unlabeled example
** which fields are mandatory?
** Per the JSON snippet, is that normative is some way in describing the format?
** Also, how does a server receiving the telemetry messages behave when receiving unexpected JSON attributes?

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is the JSON snippet presented here normative to describe the MASA audit log response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative?

-- How should implementers take this language?
-- Why are normative sections, like Section 11, discussing it?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4.  It helpfully lays justifies the current design approach.  I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed. 

My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension.  This is a substantial amount of work, and may be an area for future standardization work”.  Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging.

[Ballot comment]
(5) Section 1.3.2.  Cite the origin of the taxonomy which defines “class 2+” devices – likely RFC7228

(6) Section 1.5.  Per “Upon successfully validating a voucher artiface, a status telemetry MUST be returned.”, what is a “voucher artiface”?  is that just a “voucher”?

(7) Section 2.6.1.  What is a “Network Time Protocols” – specifically why is protocols plural?  Is this something more than NTP?

(8) Section 4.1.  Per “The communication between the pledge is over IPv6 Link-Local addresses”, if that is the case, why does Figure 3 show IPv4 and Appendix A describes an IPv5 approach?

(9) Section 5.1., Per “The pledge maintains a security paranoia concerning the provisional state …”, what does it mean to “maintain a security paranoia”?

(10) Section 5.1.  Per “A pledge that can not maintain as many connections as there are eligible proxies.”, this is an unfinished sentence.  What should the pledge do?

(11) Section 5.2.  created-on.  The value to use in this field of this field is not described here.

(12) Section 5.2.  Per “All other fields MAY be omitted in the pledge voucher-request”, should this be read as guidance that the fields mentioned above this text are mandatory (i.e., created-on, nonce, proximity-registrar-cert). If so, what value should pledges without clocks use?

(13) Section 5.3.  Per “If these validations fail the registrar SHOULD respond with an appropriate HTTP error code”, a few questions:

** Is this text suggesting that silent failure?  Given the text says SHOULD, validation could fail and the registrar would not share this failure?

** What specific codes should be used?

(14) Section 5.4.  Per “The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8 for [RFC6125] authentication of the MASA.”, RFC6125 doesn’t have a Section 2.8.  Please clarify how this connection is made.

(15) Section 5.5.  What is the relationship between the value of the created-on field passed by the pledge per Section 5.2, and described in Section 5.5 as being populated by the registrar.

(16) Section 5.5. What is a “statistically unique identity” per the “idevid-issuer” field?

(17) Section 5.7.  Per the JSON snippet:

** It isn’t labeled as a figure or example; and isn’t referenced in the text.

** This isn’t valid JSON: no commas between items.  What does the notation “/* TRUE=Success, FALSE=Fail”” mean – opening with a /* and closing with a “?

(18) Section 5.8.2.  Per “Each time the Manufacturer Authorized Signing Authority (MASA) issues a voucher, it places it into the audit log for that device.  The details are described in Section 5.8.”, this reference to Section 5.8 on how the MASA logs doesn’t seem correct.  Section 5.8 describes how a registrar asks a MASA about its logs.

(19) Section 5.9.4.  What happens if the pledge doesn’t re-negotiate an EST TLS session after been successful enrolled?

(20) Section 5.9.4.  In what way is a the SubjectKeyIdentifier included in the success telemetry message?

(21) Section 6.  What is “../voucherrequest”?

(22) Section 7.  Per “This section is considered non-normative: use suggested methods MUST be detailed in specific profiles of BRSKI” -- the clause after the colon doesn’t parse.  What is the guidance relative to profiles?

(23) Section 11.0.  The caution about untrusted data and HTTP libraries seems warranted.  Wouldn’t this also apply to the application code too?

(24) Section 11.1.  Per the list of examples where a MASA is unavailable or uncooperative, wouldn’t a manufacturing going out of business also be a concern?

(25) Section D.1.4.  Provide an openssl version and reference that generated this output

(26) Per Christian Huitema’s Last Call SecDir Review (https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra-20-secdir-lc-huitema-2019-06-04/), please respond to the last two issues – random number generation and the missing assertion leaf.

(27) Editorial

Section 1.  Duplicate Word.  s/Section Section/Section/

Section 1.  Editorial. /(or be discovered by)/(or are discovered by)/

Section 1.1.  Typo.  s/transfered/transferred/

Section 1.1. Typo. s/serveral/several/

Section 1.2.  The term “drop ship” is initial stated with a space, but is later used with a hyphen in the definition.  Consistency is recommended.

Section 1.3.1.  Typo.  s/aquire/acquire/

Section 1.3.3.  Typo.  s/consistant/consistent/

Section 1.3.4.  Typo. s/transfered/transferred

Section 2.3.2.  Typo. s/docucment/document/

Section 2.3.2.  Typo.  s/registrary/registrar/

Section 2.5.4.  Typo.  s/seperate/separate/

Section 2.6.1. Typo.  s/certificiate/certificate/

Section 3.4. Missing letter.  s/conn ection/connection/

Section 3.4.  Typo.  s/occurance/occurrence/

Section 4.  Typo.  s/refered/referred/

Section 4.  Typo.  s/occuring/occurring/

Section 5.  Typo.  s/boostrap/bootstrap/

Section 5.1.  Typo.  s/atttempts/attempts/

Section 5.1.  Typo.  s/making process/making progress/

Section 5.2.  Typo.  s/impementations/implementations/

Section 5.5.  Typo.  s/impementations/implementations/

Section 5.5. Typo.  s/recieved/received/

Section 5.5.7. Typo. s/is exist/exists/

Section 5.6.  Typo.  s/approriate/appropriate/

Section 5.6. Duplicate word.  s/section Section/Section/

Section 5.6.  Typo.  s/sufficent/sufficient/

Section 5.6.1.  Typo.  s/manufacter/manufacturer/

Section 5.8.1.  Duplicate word. s/the the/the/

Section 5.8.2.  Typo.  s/dicussion/discussion/

Section 5.8.2.  Typo.  s/evens/events/

Section 5.8.2.  Typo.  s/anomoly/anomaly/

Section 5.9.2.  Typo.  s/boostrapping/bootstrapping/

Section 5.9.4.  Typo.  s/adminstrative/administrative/

Section 5.9.6.  Typo.  s/defintion/definition/

Section 7.2.  Typo. s/innappropriate/inappropriate/

Section 9.  Typo. s/signficant/significant/

Section 9.  Typo. s/consistenting/consisting/

Section 9.  Duplicate Word.  s/like like/like/

Section 9.  Editorial.  The sentence “Such an operator also is …” does not parse without the parenthetical.  Perhaps it should read like “Such an operator is also capable of performing bootstrapping of a device using a serial-console.”

Section 9.  Typo. s/signficiant/significant/

Section 9.  Duplicate word.  s/still still/still/

Section 10.2.  Typo.  s/targetted/targeted/

Section 10.2.  Typo.  s/comissioning/commissioning/

Section 10.2.  Typo.  s/constrast/contrast/

Section 10.2.  Typo.  s/redesigs/re-designs/

Section 10.2.  Typo.  s/seperate/separate/

Section 10.3.  Typo.  s/responsability/ responsibility/

Section 10.3.  Duplicate Word.  s/the the/the/

Section 10.3.  Typo.  s/occurrance/occurrence/

Section 10.4.  Typo.  s/informatin/information/

Section 10.5.  Typo.  s/gratutiously/gratuitously/

Section 10.5.  Duplicate word.  s/these these/these/

Section 10.5.  Typo.  s/facilitiates/facilitates/

Section 10.5.  Typo.  s/operatonal/operational/

Section 10.5.  Typo.  s/warantee/warrantee/

Section 10.5.  Typo. s/requiments/requirements/

Section 11.0.  Typo. s/truely/truly/

Section 11.2.  Typo.  s/Retreival/Retrieval/

Section 11.2.  Typo.  s/occurance/occurrence/

Section 11.4. Typo.  s/Maintainance/Maintenance/

Section 11.4.  Typo.  s/environements/environments/