f the goal is to enable interoperability, then this draft needs to be cleaned
up to be clear, concise, and logical. Currently, it appears to be a mishmash
of terminology and loose specifications. I will give some examples below where
I think it is unclear, but I can't claim to be complete in my review:
Section 1, para 4: I'm confused by this statement: 'the Pledge can then use
the resulting anchor to authenticate other actors who are part of the network'.
Is this because other 'actors' hold the private key for the trust anchor? Is
it because other 'actors' have certificates that are signed by the trust
anchor? Does the Pledge hold a key and certificate certified by the trust
anchor?
Section 1, para 7 and 8: These two paragraph does not flow from the previous
paragraphs which are discussing trust anchors, vouchers and pledges. Perhaps a
sub section would help.
Section 1, para 9 and 10: yet another jump. This time, it might make sense to
move these before para 7 and 8. When a specification jumps around from topic
to topic, it is difficult to see how any implementer will be able to follow -
severely impacting interoperability.
Section 2, Bootstrapping and onboarding: If bootstrapping is being deprecated,
merely state that and point to the onboarding definition. One can only hope
that there is a good reason for this terminology shift.
Section 2, Imprinting: This is a lovely idea, but how does it mesh with what
was discussed in Section 1 where the terms Voucher, Pledge, and trust anchors.
Would the term 'Trust Anchor' be more suitable?
Section 2, Join Registrar: How important is the phrase 'perhaps
autonomically'? And if it is referred to as 'just Registrar', then why not
define 'Registrar'?
Section 2, Malicious Registrar: What is the entity seeking to do, presumably
to the Pledge?
Section 2: I'm not sure the terminology could be more confusing. For example:
"Voucher: a Voucher Artifact, not a Voucher Request...", while "Voucher
Request: a signed artifact...." But while a Voucher Request is a signed
artifact (does lower case make it different?), it is not a Voucher. I don't
even know what to suggest.
Section 4, Assertion Basis: what is 'measured boot'? (I know what 'secure
boot' is)
Section 4: It is really unclear exactly how the use of nonces or time limits
blocks a malicious registrar. This is especially true if the nonces are
transmitted in the clear.
Section 5: Where is the list of changes?
Section 5.1: What is the purpose of this section? A clear and concise list of
changes would be more useful.
Section 8, EcDSA: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list
suggests that this should be ECDSA (which is also the only way I've ever seen
it).
Section 9.1: 'manufacturer-private?'. Does this imply the manufacturer's
private key? Surely this isn't sent to anyone.
Section 10.1, para 2: 'Revocation artifact'? Like an OCSP response showing
that the current key/cert pair is still valid? OCSP is specified in RFC 6960.
Section 10.1, para 3: Updating a short-lived certificate requires the same
care as the initial certification. It is more than merely 'updates the
Voucher's validity period'. One needs to ensure that the entity that holds the
private key still possesses it, and hasn't disclosed it.
Section 11.1, para 2: Devices with no understanding of time cannot possibly
verify that the 'expires-on' field has not yet passed.
Section 11.2: Why not MUST? What are the circumstances in which is it ok to
not store that private key in an HSM?
Section 11.4: For sensitive data fields which are distributed, I would expect
these structures to be encrypted as well as signed. Nonces and other private
values should not be distributed in the clear (or merely signed). I would have
preferred to see the carefully constructed paragraph which is normally standard
in Yang specifications.
