Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 09:14:59 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

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

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

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

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 16:46:01 -0400

I will attempt to answer each substantive comment in a separate email,
as I want to show the work in the form of a diff, and it will be too
confusing to do it all at once.  The tinyurl that I posted for
Eric should remain valid as a cumulative diff as I push stuff to github, as
rfcdiff will calculate again each time.

Roman Danyliw via Datatracker <[email-masked]> wrote:
    > 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:

Could you specifically comment on Eric's comment about domainID being
a SHA-1 Hash of the PublicKeyInfo

    > (1) Section 5.7.  The format of a pledge status telemetry message seems

Fair enough.
In the interop testing that has occured online and in-person since November,
we have actually not gotten to this point yet.

    > ** what are all of the fields (e.g., version appears in the example but
    > no the text)

added version and text about how a registrar should behave when it sees a
version larger than it understands.

    > ** what are the field formats (e.g., the format of the status field is
    > inferred from the unlabeled example

    > receiving unexpected JSON attributes?

I have made these changes:
https://github.com/anima-wg/anima-bootstrap/commit/dd17db4f1c39b2332e6f49877a0a0fccd1dd5a6f

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index 610150d..9aa2a2a 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2101,41 +2101,69 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
         status.</t>

         <t>To indicate pledge status regarding the voucher, the pledge
-        MUST post a status message.</t>
+        MUST post a status message to the Registrar.</t>

         <t>The posted data media type: application/json</t>

         <t>The client HTTP POSTs the following to the server at the EST well
-        known URI "/voucher_status". The Status field indicates if the voucher
-        was acceptable. If it was not acceptable the Reason string 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
-        balanced against the operational costs of not recording that an
-        voucher was ignored by a client the registrar expected to continue
-        joining the domain.</t>
+        known URI "/voucher_status".</t>
+
+        <t>
+          The format and semantics described below are for version 1.
+          A version field is included to permit significant changes to this
+          feedback in the future.  A Registrar that receives a status
+          message with a version larger than it knows about SHOULD log the
+          contents and alert a human.
+        </t>
+
+        <t>The Status field indicates if the voucher was acceptable.
+        Boolean values are acceptable.
+        </t>
+
+        <t>
+          If the voucher was not acceptable the Reason string 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
+          balanced against the operational costs of not recording that an
+          voucher was ignored by a client the registrar expected to continue
+          joining the domain.
+        </t>

-        <t><figure>
-            <artwork><![CDATA[{
-  "version":"1",
-  "Status":FALSE /* TRUE=Success, FALSE=Fail"
-  "Reason":"Informative human readable message"
-  "reason-context": { additional JSON }
-}]]></artwork>
-          </figure>The server SHOULD respond with an HTTP 200 but MAY simply
-        fail with an HTTP 404 error. The client ignores any response. Within
-        the server logs the server SHOULD capture this telemetry
-        information.</t>
         <t>
           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.
         </t>
+
+        <t>
+          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.
+        </t>
+        <t>
+          The keys to this JSON hash are case-insensitive.
+        </t>
+
+        <t><figure>
+            <artwork><![CDATA[{
+  "version":"1",
+  "status":FALSE /* TRUE=Success, FALSE=Fail"
+  "reason":"Informative human readable message"
+  "reason-context": { additional JSON }
+}]]></artwork>
+          </figure>
+          The server SHOULD respond with an HTTP 200 but MAY simply
+          fail with an HTTP 404 error. The client ignores any response. Within
+          the server logs the server SHOULD capture this telemetry
+          information.
+        </t>
         <t>
           Additional standard JSON fields in this POST MAY be added, see
-          <xref target="pledgestatustelemetryregistry" />.
+          <xref target="pledgestatustelemetryregistry" />.  A server that
+          sees unknown fields should log them, but otherwise ignore them.
         </t>
       </section>

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 16:51:23 -0400

Roman Danyliw via Datatracker <[email-masked]> wrote:
    > (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?

Yes, it's intended to be normative.
How can we make it clearer without over-engineering this, remembering that
this is a PS, not IS, and the proof will be in the running-code.

Would you prefer to used CDDL or something like that to describe it?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 16:59:34 -0400

> -- Why are normative sections, like Section 11, discussing it?

1) It's non-normative for proper/full operation of the ANIMA ACP

2) We think that some of the mechanisms that 7.2 describes may be needed
   in order for operators to have ways to work around infrastructure
   failures, such as manufacturers going out of business.
   We don't want to standardize
   I see that we use 2119 language in this section, and maybe that
   does not belong.  or maybe the section should be normative, but
   consist of a series of "MAY" statements?

   If vendors are going to provide work arounds ("back-doors")
   it would be best if they did something we can identify and reason about.
   So to use the back-door to the building analogy: we want to define
   fire-exits in the building code rather that doors that are insecure.

A lot of the text in Section 7 was originally sprinkled elsewhere, but that
confused things.  As shown by the long thread from concerned operators,
this move towards a secure-onboarding-by-default scares people who
are used to improvising things in an emergency.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 17:15:17 -0400

Roman Danyliw via Datatracker <[email-masked]> wrote:
    > (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.

Our goal here has been to provided bootstrapping... the beginning of the
lifecycle.  It would be great to be able to provide full lifecycle
specification.

There are quite a number of non-technical issues (i.e. layer 8 and 9)
involved in supporting a second sale process.  Updating the trust anchors
that are used to verify the voucher is, I think, a pretty big deal, and
I just don't see that we can deal with this in a general way for a variety of
product types.  Some vendors would see this as meaning that the TPM has
to be opened up.  Some operators would be concerned that if this was
possible, that they would no longer be able to be certain that a secure
boot process would still be secure.  I would be happy if this work was
chartered a "RATS 2.0", or became part of NETMOD.  I don't see how we
can do justice in this document.

As for operational notions as to how to operator a MASA, and as you say, one
that supports off-line vouchers, I agree that we are not that helpful.

Note that off-line vouchers are ones without nonces and without expiry dates,
transfered to the Registrar by store-and-forward (USB key, scan from
QR code on invoice, etc.).  They are still signed by the primary
manufacturer, and still bind to the primary owner.  They are not bearer
tokens, and they do not require changes to the trust anchors, and they do not
facilitate second sale.

Perhaps there is something I can change in that section to clarify this point.

To use an HTTP 0.9 analogy, it's like asking the http (1.0) WG to comment on
how whether Model-View-Controller vs Presentation-Abstraction-Control is
the right way to build social media sites.

Having said that, I am pretty sure that we need to write an Operational
Considerations document for both MASA and Registrar.  I suspect that the
first draft will mostly be a list of things not to do. ("Doctor it hurts when
I move my harm like this...")

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 20:34:42 -0400

Roman Danyliw via Datatracker <[email-masked]> wrote:
    > (5) Section 1.3.2.  Cite the origin of the taxonomy which defines
    > “class 2+” devices – likely RFC7228

done.

    > status telemetry MUST be returned.”, what is a “voucher artiface”?  is
    > that just a “voucher”?

It's a typo. It should be voucher artifact.
We used "Voucher Artifact" all over RFC8366.

    > (7) Section 2.6.1.  What is a “Network Time Protocols” – specifically
    > why is protocols plural?  Is this something more than NTP?

Yes, NTPv4, but it could also be IEEE PTP, or even GSM.
It doesn't much matter... no network ==> no network time.

    > Link-Local addresses”, if that is the case, why does Figure 3 show IPv4
    > and Appendix A describes an IPv5 approach?

Because some members of the WG continued to complain that IPv6 isn't
ubiquitous, and Appendix A was the compromise.
I would be happy to rip it out, because I think the argument is specious.

    > (9) Section 5.1., Per “The pledge maintains a security paranoia
    > concerning the provisional state …”, what does it mean to “maintain a
    > security paranoia”?

I guess I don't know.
Max?  Seems like useless words.

    > (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?

fixed.
        A pledge that can not maintain as many connections as there are
    -   eligible proxies.  If no connection is making progess after 5 seconds
    -   then the pledge SHOULD drop the oldest connection and go on to a
    -   different proxy: the proxy that has been communicated with least
    -   recently.  If there were no other proxies discovered, the pledge MAY
    -   continue to wait, as long as it is concurrently listening for new
    -   proxy announcements.
    +   eligible proxies will need to rotate among the various choices,
    +   terminating connections that do not appear to be making progress.  If
    +   no connection is making progess after 5 seconds then the pledge
    +   SHOULD drop the oldest connection and go on to a different proxy: the
    +   proxy that has been communicated with least recently.  If there were
    +   no other proxies discovered, the pledge MAY continue to wait, as long
    +   as it is concurrently listening for new proxy announcements.

    > (11) Section 5.2.  created-on.  The value to use in this field of this
    > field is not described here.

-            RECOMMENDED to populate this field. This provides additional
-            information to the MASA.</t>
+            RECOMMENDED to populate this field with the current date and
+            time in yang:date-and-time format. This provides additional
-            information to the MASA.</t>

    > voucher-request”, should this be read as guidance that the fields
    > mentioned above this text are mandatory (i.e., created-on, nonce,

I guess:
            Pledges that have no real-time clocks MAY omit this field.

    > with an appropriate HTTP error code”, a few questions:

Ha, I kept asking for us to be specific about error codes, but I missed this
part.

-          If these validations fail the registrar SHOULD respond with an
-          appropriate HTTP error code.
+          If these validations fail the registrar SHOULD respond with the
+          HTTP 404 error code.  If the voucher-request is in an unknown
+          format, then an HTTP 406 error code is more appropriate.
+          A situation that could be resolved with administrative action
+          (such as adding a vendor to a whitelist) MAY be responded with an
+          403 HTTP error code.

    > ** What specific codes should be used?

I believe that there may be other error codes that would make sense, so
I'm sticking with SHOULD.

    > (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.

aha. It's section 2.8 of this document! Some punctuation is missing.

-          <xref target="obtainmasaurl" /> for <xref target="RFC6125" />
-          authentication of the MASA.
+          <xref target="obtainmasaurl" />. The mechanisms in
+          <xref target="RFC6125" /> SHOULD be used authentication of the
+          MASA.  Some vendors will establish explicit (or private) trust
+          anchors for validating their MASA; this will typically done as
+          part of a sales channel integration.  Registars SHOULD permit
+          trust anchors to be pre-configured on a per-vendor basis.

    > (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.

-        <t hangText="created-on:">Registrars are RECOMMENDED to populate
         this field. This provides additional information to the MASA.</t>
+        <t hangText="created-on:">
+          The Registrars SHOULD populate this field with the current date and
+          time when the Registrar formed this voucher request. This field
+          provides additional information to the MASA.
+        </t>

    > (16) Section 5.5. What is a “statistically unique identity” per the

Max?

I don't think the word statistically is useful here.

The serial-number extracted from the pledge IDevID is unique per IDevID
issuer, so we include that here.  I realize that my implementation does
not include this at all, and I just use the certificate from the
prior-signed-voucher-request.

    > TRUE=Success, FALSE=Fail”” mean – opening with a /* and closing with a “?

fixed.
I need to go back throuth an renumber the figures (or rather,use anchors).

    > 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

             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 <xref target="authzLogRequest" />.
+            issues a voucher, it appends details of the assignment to
+            an internal audit log for that device.
+            The internal audit log is processed when responding to
+            requests for details as described in <xref
+            target="authzLogRequest" />.

Does this work for you?
It is not our intend to specify how the internal audit log works, just
what it must be able to produce.

    > (19) Section 5.9.4.  What happens if the pledge doesn’t re-negotiate an
    > EST TLS session after been successful enrolled?

I'm not sure.
Max?

    > (20) Section 5.9.4.  In what way is a the SubjectKeyIdentifier included
    > in the success telemetry message?

If there is success, I don't think the SubjectKeyIdentifier needs to be
logged.  If there is failure, then the idea was that it would go into the
reason in some textual form.

    > (21) Section 6.  What is “../voucherrequest”?

It's a typo for /requestvoucher!

    > (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?

How about:
        This section is considered non-normative: use of the suggested
        mechanism here MUST be detailed in specific profiles of
        BRSKI.  This is a subject for future work.

I don't understand "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?

In what way to do you mean?
Maybe this paragraph has been mis-understood.
We are trying to say that despite the headers and content being untrusted,
that mature HTTP libraries should not be particularly vulnerable.  Is
that what you understood?

    > (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?

Absolutely.
One reason why we call it the Manufacturer *AUTHORIZED* signing authority,
is that we believe that this is something Manufacturers will outsource,
and buyers will insist that there is an escrow plan.

    > (25) Section D.1.4.  Provide an openssl version and reference that
    > generated this output

Well, it was done with libcrypto 1.1.1c, from (open source ruby) code linked
against it.  I can certainly say that, but I don't know what
"reference" means here.

    > please respond to the last two issues – random number generation and the

I had not seen this second review, thank you.
I will read this on Thursday and post additional changes.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 11 Jul 2019 03:35:54 +0000

inline comments, 

> On Jul 10, 2019, at 6:34 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

The intention is to warn implementers that the HTTP and other data received until the voucher content is verified could be from an attacker since the TLS connection is in a provisional mode. Perhaps this is clearer:  

-            <t>The pledge maintains a security paranoia concerning the
-            provisional state, and all data received, until a voucher is
-            received and verified as specified in <xref
-            target="CompletingAuthenticationBootstrapping"></xref></t>
-
+            <t>The pledge performs input validation of all data received
+               until a voucher is verified as specified in <xref
+               target="CompletingAuthenticationBootstrapping"></xref> and
+               the TLS connection leaves the provisional state. Until these
+               operations are complete the pledge could be communicating
+               with an attacker.</t>

> I don't think the word statistically is useful here.

It is possibly pedantic. The voucher leaf of idevid-issuer (see RFC8366) is the Authority Key Identifier as defined in RFC5280 and I probably have it in my head that this is only statistically unique when its based on the key identifier (where the keys are only statistically unique). 

-        is included to ensure a statistically unique identity.</t>
+        is included to ensure a unique identity.</t>

>> EST TLS session after been successful enrolled?

If the client skips renegotiating the server does not have operational proof that the client can successfully use the certificate as a TLS client certificate. Instead it will only receive the telemetry message where the client claimed everything is ’SUCESS’. 
I didn’t use ‘MUST' because of the keyusage morass where perhaps the cert is to be used for something where TLS isn’t valid. In other enrollment protocol discussions we either make exceptions for “misuse” of a key type during enrollment itself (such as performing a signing operation when the key usage says not to) or accept that the TLS client authentication might be with a different keypair than the one distributed (such as using EST to maintain and re-enroll a cert that isn’t appropriate for TLS). Using "SHOULD” here avoids having BRSKI take a stance on any of those issues. 

- max

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 12 Jul 2019 02:07:41 +0000

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: Wednesday, July 10, 2019 4:51 PM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-anima-bootstrapping-
> [email-masked]; Toerless Eckert <[email-masked]>; anima-
> [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-
> keyinfra-22: (with DISCUSS and COMMENT)
> 
> How can we make it clearer without over-engineering this, remembering
> that this is a PS, not IS, and the proof will be in the running-code.
> 

CDDL would be very nice, but I have a much lower bar.  I would be happy with a full field list (e.g., I noticed that "version" isn't explained anywhere but appears in the examples; what's the format of the date?) and a statement that the log be structured per the JSON example. 

Roman