[Anima] Genart early review of draft-ietf-anima-constrained-voucher-10

[Russ Housley via Datatracker <[e-mail]>]

Reviewer: Russ Housley
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-anima-constrained-voucher-10
Reviewer: Russ Housley
Review Date: 2021-05-13
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Not Ready


Note:  I did not review Section 9 or the Appendices.


Major Concerns:

Section 4 says:
   "... sign using its IDevID X.509 certificate, or if an IDevID is not
   available its manufacturer-installed raw public key (RPK)."

This is not accurate.  Signatures are created with a private key, and
then they are validated with the public key in a certificate.  A sign
operation cannot use an RPK; a signnature validation operation might.

Section 6.2 says: "... and MUST NOT distinguish between them."  There
are many different contexts that one might "distinguish" that are fine.
I think you mean that the implementation MUST respond to the two in the
same manner.

Section 6.4.1 is confusing to me.  The section says that a "constrained
Pledge MAY use the following optimized EST-coaps procedure", however,
there are MUST statements in the numbered paragraphs that follow.


Minor Concerns:

Section 1 says:
   "...  As the tooling to
   convert YANG documents into a list of SID keys is still in its
   infancy, the table of SID values presented here should be considered
   normative rather than the output of the pyang tool."

It is unclear to me what this means to an implementer.  When does
this situation change?  This seems to be begging for a MUST or SHOULD.

Section 5 says: "Saving header space is important...".  Okay.  It is not
just the headers.  Maybe something like: "To keep the protocol messages
small..."

Section 5 ends with: "For example, the following more complete response
is possible."  Nothing follows.  Not sure what is meant.

Section 6 and Section 6.1 say the same thing.  Drop one.

The last paragraph of Section 6.4.1 and the only paragraph in
Section 6.4.2 say the same thing.  Drop one.

Section 8.1 ends with:

   When the Registrar is using a COSE-signed constrained format voucher
   request towards MASA, instead of a regular CMS-signed voucher
   request, the COSE_Sign1 object contains a protected and an
   unprotected header, and according to [I-D.ietf-cose-x509], would
   carry all the certificates of the chain in an "x5bag" attribute
   placed in the unprotected header.

I think there should be a MUST statement in this paragraph.  Maybe:

   When the Registrar is using a COSE-signed voucher instead of a
   CMS-signed voucher, the COSE_Sign1 object contains a protected
   header and an unprotected header.  The Registrar MUST place all
   all the certificates for the chain in an "x5bag" attribute in
   the unprotected header [I-D.ietf-cose-x509].

Section 8.2 says: "... reduce on average the duration ...".  I cannot
figure out what is actually being reduced.  Please add more explanation
or drop the bulk of the sentence.  Rationale that comes later in the
section does not say anything about duration being reduced, but it does
talk about avoiding retransmission of the same certificates.


Nits:

Abstract: Please remove the references.  The RFC Editor Guidlines for
Abstracts include: "An Abstract should be complete in itself; it should
not contain citations unless they are completely defined within the
Abstract."

Section 1, paragraph 1:
  s/such as [I-D.ietf-anima-bootstrapping-keyinfra]/
   /such as BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]/

Section 1, paragraph 3:
  s/either OSCORE+EDHOC, or/either OSCORE+EDHOC or/

Section 4, paragraph 7:
   s/section Section 8./Section 8./

Section 6.4.1, last paragraph:
   s/needs to use at least multiple CAs/needs to use multiple CAs/

Section 6.4.2, only paragraph:
   s/needs to use at least multiple CAs/needs to use multiple CAs/

Section 8, only paragraph: The first sentence is very awkward.  I
suggest something like: "The voucher is a statement by the MASA for
use by the Pledge that provide the identity of the Pledge's owner."

Section 8.2, paragraph 1:
   s/pin in the voucher in case there are multiple available/pin/
   
Section 8.3, Figure 2:  Please find fome other way to represent [RPK3].
This looks like a reference, and that is not the intent.

Section 8.3, first paragraph after Figure 2:
   s/certificate-less enrollment/enrollment without certificates/