Roman Danyliw via Datatracker <[email protected]> wrote: > (5) Section 1.3.2. Cite the origin of the taxonomy which defines > “class 2+” devices – likely RFC7228
done.
> (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”?
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.
> (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?
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>
> (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?
I guess:
Pledges that have no real-time clocks MAY omit this field.
> (13) Section 5.3. Per “If these validations fail the registrar SHOULD
> respond
> 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.
> ** 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?
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
> “idevid-issuer” field?
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.
> (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 “?
fixed.
I need to go back throuth an renumber the figures (or rather,use anchors).
> (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.
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.
> (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.
I had not seen this second review, thank you.
I will read this on Thursday and post additional changes.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
