Henk Birkholz via Datatracker <[email protected]> wrote: > Reviewer: Henk Birkholz
Thank you for this review!
> (0) Title
> The title implies that this document defines a message or document called
> 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The
first
> sentence contradicts this by saying 'This document defines a protocol'.
This
> "IETF'ler Human" also suspects that "Voucher Artifacts" are kind of
redundant,
> but that was okay in RFC8366 so that seems to be okay here.
https://github.com/anima-wg/constrained-voucher/issues/132
The title reflects a history that thought we'd write two documents.
> (1) Abstract
> The abstract requires more (concise!) context and outline of the general
> problem so that context-specific terms used can be easily understood,
e.g.,
> 'Pledge' or its relationship to 'owner'. Imagine the abstract being the
only
> thing visible in a document indexing and management system and phrase it
as
> such. The "new" CoAP protocol defined seems to be a complement to an HTTPS
> protocol, which the reader has to guess is defined either by RFC8366 or
BRSKI
> (this is cleared up early in the Intro). Why is it not CoAPS, if its
complement
> is HTTPS? Ultimately, you shall not use references in an abstract and
that is
> the root cause for this need for guessing here, I think.
https://github.com/anima-wg/constrained-voucher/issues/133
> (2) Introduction
> OSCORE and EDHOC are suddenly used and not introduced.
> Terms, such as 'Pledge' or 'Registrar' could be better introduced or it
should
> be very clearly stated that this memo cannot be used without a clear
> understanding of other documents (and which documents that exactly are and
> why). It is not very clear to the reader why YANG and SID are suddenly
> appearing here (which again becomes pretty obvious when you read other
> documents). In general, the Intro requires more context.
I've tacked this onto the issue:
https://github.com/anima-wg/constrained-voucher/issues/124
> (3) Overview of Protocol
> It is not immediately clear what 'proximity' means here (the term is not
listed
> in the Terminology section). A quick recap of roles and interactions
would not
> hurt, I think, but that can also be addressed by adding more contextual
text to
> the Intro. "Most Pledges using these constrained": maybe just remove the
> "these" - it made me read it as a back-reference to time-based vouchers.
The
> term "pinned" used here could benefit a from a tad bit more expositional
text -
> it is a term relevant to a lot of security aspects in this memo and
deserves a
> proper introduction.
https://github.com/anima-wg/constrained-voucher/issues/134
> (4) Discovery, URIs and Content Formats
> Maybe an example of EST and BRSKI URIs helps the reader to see the
> difference/optimization more easily? The terms URI and URL or both used
in this
> section. Are they used dedicatedly with their distinct meanings or are
they
> used interchangeably? Sometimes the term 'end point' is also spelled
> 'end-point'. Why is there a fall-back (as MAY) to Content-Format 50 for
the
> shorter URLs?
https://github.com/anima-wg/constrained-voucher/issues/135
> (5) Extensions to BRSKI
> 'CoRE Link Format parsing' is suddenly used and it is not clear here in
the
> context why avoiding that is useful. I am not sure that 'reconnect' is the
> appropriate term to use when writing about resources available via a
single UDP
> port.
https://github.com/anima-wg/constrained-voucher/issues/136
Reconnect because DTLS might get renegotiated, because we might go from COAP
to COAPS, and it's just extra round trips.
> (6) Extensions to EST-coaps
> The example '/sen' for simple enrollment is used here, but not really
> introduced in the document. Is that intentionally so?
Yes, because it's in draft-ietf-ace-est-coaps.
https://github.com/anima-wg/constrained-voucher/issues/137
> (7) Pledge Extensions
> '/att' is introduced here and it might not be obvious to a reader where
that
> comes from and what it exactly represents. Maybe a small example for "it
MUST
> use the Subject Distinguished Name fields from its IDevID unmodified."
would
> help here? Is '/crts' the short-name for '/cacerts'? So - in general,
maybe
> there should be a complete list of short-names used or are these
intentionally
> just used as examples?
https://github.com/anima-wg/constrained-voucher/issues/138
> (8) Registrar Extensions
> "for operational or security reasons" - that could be a topic for the TBD
in
> the Security Considerations.
Agreed.
> (9) BRSKI-MASA Protocol
> Some of the consideration about "CoAPS for the BRSKI MASA is deemed
> unrealistic" can probably also fuel the Security Considerations.
https://github.com/anima-wg/constrained-voucher/issues/139
> (10) Registrar Identity Selection and Encoding
> 'which participate' -> 'that participate'
fixed in my copy.
> (11) MASA Pinning Policy
> Maybe explicitly highlight that in the case of the nonce-less vouchers,
the
> makeup of the x5bag provides the knobs and dials to exactly influence
which
> certificate will be pinned. That is only expressed implicitly, I think,
or I
> did not get the meaning of the text properly.
https://github.com/anima-wg/constrained-voucher/issues/140
> (12) Pinning of Raw Public Keys
> "However, if the Pledge is known to also support RPK pinning and the MASA
> intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin
the
> RPK (RPK3 in Figure 2) of the Registrar instead of the Registrar's
End-Entity
> certificate to save space in the voucher.": why is that not a MUST? What
are
> the consequences, if that is not done as highlighted?
https://github.com/anima-wg/constrained-voucher/issues/141
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
