Russ Housley <housley@xxxxxxxxxxxx> 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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works -= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature
