Re: [Anima] Iotdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-17

[Michael Richardson <[e-mail]>]

Russ Housley <[e-mail]> wrote:
> Major Concerns:
>
> Section 2.2 says:
>
>    ...  The registrar
>    maintains control over the transport and policy decisions allowing
>    the local security policy of the domain network to be enforced.
>
> I have no idea what this means.  Please clarify.

duplicates issue raised by Jari:
https://github.com/anima-wg/anima-bootstrap/issues/92

> In Section 2.3, it says:
>
>    5.  (Optional) Signing of voucher-request by the pledges IDevID to
>        enable MASA to generate voucher only to a registrar that has a
>        connection to the pledge.
>
> This is an important section to understand BRSKI, but I cannot parse
> this sentence.  Please reword.

https://github.com/anima-wg/anima-bootstrap/issues/93

> Section 2.3.1 talks about pledges being uniquely identified by a
> "serial-number" in voucher and voucher-requests.  Pledges are also
> uniquely identified by their serial number in certificates.
>
> Section 2.3.1 refers to HardwareModuleName, which is defined in
> RFC 4108.  It says that the HardwareModuleName hwSerialNum is base64
> encoded.  RFC 4108 does not require base64 encoding.  Where does that
> requirement come from?

duplicates:
https://github.com/anima-wg/anima-bootstrap/issues/95

> Section 3.1 shows the YANG tree model of the Voucher-Request.  I am far
> from a YANG expert, but I expected a subsequent section to describe the
> semantics of each field.  The examples in Section 3.2 are useful, but
> they are not a replacement.  Some fields (like voucher/expires-on) are
> not described in Section 3.3.  I assume that this is building on another
> module because this one contains "import ietf-voucher", but this does
> not say what RFC contains the imported module to learn the rest of the
> semantics.

I think that the sentence:
  The notation used in this diagram is described in [RFC8366].

should be changed to say:
   The voucher-request builds upon
   the voucher artifact described in <xref target="RFC8366" />.
   The tree diagram is described in <xref target="RFC8340" />.

(we described tree-diagrams in 8366 at one point, because we didn't know if
8340 would get published in time)

> I think that the CDDL in Sections 4.1.1 and 4.3 are supposed to be
> structures.  If that is correct, the structure should look something
> like the following, which includes type information:
>
>    basic-header = [
>      field1: int,
>      field2: text,
>    ]
>
>    advanced-header = [
>      ~basic-header,
>      field3: bytes,
>      field4: ~time,
>    ]

We are filling in the gaps for the definition in GRASP M_FLOOD
mechanism.  We aren't defining a new structure.
I'm not sure if we can do this any other way.

> I have no idea what the boxes in Figure 10 represent.

Hmm. I guess we chopped the boxes off of the flow from section 2.4.
Would a reference back to section 2.4 help?
Maybe we should not repeat the boxes.

> Section 7.2 does not contain enough information to make the needed
> object identifier assignments.

Right we had a note to fix that. It's: SMI Security for PKIX Certificate Extension
  https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.1

> In Section 7.4, the IESG (not the IETF Chair) should be the contact
> for standards-track registrations.

Done.

>
> I think the security considerations ought to describe the consequences
> of compromise of the various private keys in the ecosystem.  Some only
> impact one device, but others have much greater impact.

okay.
I'm expanding issue #80 to include describing this.
    https://github.com/anima-wg/anima-bootstrap/issues/80

> I think the security considerations ought to say something about the
> nonce.  First, it should point to RFC 4086.  Second, it should say
> something about the consequences of a poor random source.  It does not
> need to be a comprehensive as the section dealing with setting time.

I've expanded issue #91:
     https://github.com/anima-wg/anima-bootstrap/issues/91

>
> Minor Concerns:

next email.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-