As a result of trying to understand (and then to model) the protocol flow for BRSKI, I have made a review of draft-ietf-anima-bootstrapping-keyinfra-09. The following are my technical comments. A separate list of suggested minor editorial changes has been sent to the authors.
Bill Section 1, para 3, lines 4-5. "is a minor extension to the voucher format (see Section 3)." What "voucher format"? I guess that you mean the voucher format defined in draft-ietf-anima-voucher. I suggest some additional precision here. Lines 4-5. Why is this "minor extension" defined here, and not in draft-ietf-anima-voucher? Would it not be better to have all (currently known) voucher formats in one place? Section 2.3, para 2, line 1. "previously defined fields" Where are these defined? Are they previously defined in this document? Are they previously defined in some other document? (If so, give reference.) In general, this paragraph and its two bullets might be understandable by someone who is well familiar with X.509, but they are opaque to someone who is not (i.e., this reviewer). I believe that your message would be much clearer if you first defined (or explained) what is in the X.509 certificate (that you are going to use), and then specified the constraints/extensions that you are going to impose. Here is my (possibly incorrect) understanding: <begin understanding> The X.509 certificate contains a "subject" field, which in turn contains a DN encoding. (What is "DN"? Please define the acronym.) For a voucher, this DN encoding MUST include the "serialNumber" attribute. The X.509 certificate also contains a "subject-alt" field. For a voucher, this field SHOULD contain a "HardwareModuleName". Three possible mappings are given to produce the "serial-number" field in the voucher. A new extension for the X.509 IDevID certificate contains a URI pointing to the MASA. IRIs MUST be mapped to URIs in a specific way. <end understanding> However, I had to struggle to come to this understanding. Hopefully, new text can be introduced to ensure that future readers will come to this understanding more quickly. After all, if our goal is to ensure correct implementations of the spec, it would be helpful if the spec were clear and specific. Section 2.3, para 5, line 4. In this document, the string ".well-known" appears variously as ".well-known", "./well-known", and "/.well-known". If these are in fact intentional, then the differences should be explained. Otherwise, a consistent form should be ensured throughout the document. Given that I do not know what is correct, or if they are intended to be different, I have not signaled these cases in my General Comments. You will have to do a search to discover all the instances. Section 2.6, para 1. I find this entire paragraph puzzling. I believe that more text is required here, in the hope that the use cases will be clearer. Perhaps the use cases need to be stated first, followed by the allowed actions. Section 3, para 1, line 6. What is the meaning of '"proximity-registrar-cert" leaf'? What is the leaf a leaf of? If this refers to some YANG module, please cite the YANG module. Section 3.2, Example (2). Does this example illustrate _a_ Registrar voucher-request, or does it illustrate the Registrar voucher-request that would be used to forward Example (1)? If the former, why is the nonce identical? If the latter, it should be explained that certain other fields are carried forward as well. Section 4.1, para 2, bullet 2, line 3. "may" -> "MAY" (This "may" seems to be normative.) Para 7, line 2. "should" -> "SHOULD" Section 5, para 8, bullet 1. The reference to RFC6125 appears to be normative, and so RFC 6125 should be added to the list of (normative) references. Section 5.4, para 9. This paragraph gives a series of actions that are described in the introductory material as "validation checks". However, the first bullet is describing a renewal action, not a validation check. I suggest that the phrase "The MASA validation checks before issuing a voucher are as follows:" be replaced with "The MASA performs the following actions and validation checks before issuing a voucher:" Section 5.8, para 2, line 1. "the following EST" (I have no idea where these "following" items are. The subsequent subsections are clearly not extensions, so I cannot determine what is being referenced here. Since this is a "recommendation", it is important that it be clear to the reader what is intended. Para 2. This paragraph is quite opaque to me. I cannot follow the logic of the sequence of statements. Does the second sentence imply "one-at-a-time" operation, or something else? In the third sentence, requests will "look the same" as what? Each other, something else? -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atw...@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
