Much thanks for Michael Richardson for putting these diffs together. Comments inline,
> On Feb 14, 2018, at 1:09 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41 > > https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-10&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/bill-atwood-comments/dtbootstrap-anima-keyinfra.txt > or: https://goo.gl/pXNghv > > > William Atwood <william.atw...@concordia.ca> wrote: >> 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. > > Added another reference to anima-voucher document at the end of the paragraph. > >> 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? > > No, because anima-voucher is used by the RESTCONF work in the NETCONF WG, and > they have no use for the voucher-request. > >> 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 > > so, I think that understanding something about PKIX (X509) and EST is > unavoidable, and I don't think we should clutter the document explaining > those parts. > >> 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. > > ./well-known is a typo. I've put / in front of every use. > /.well-known refers to rfc5785. > RFC7030 (EST) all lives under /.well-known/est. > I've added a reference to 5785 at the first use of /.well-known. > >> 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. > > Max, I have added a paragraph to explain the legacy situation that the "Cloud > <t> > There are transitional situations where devices may be > deployed into legacy networks that use proprietary > bootstrapping mechanisms based upon the base EST (<xref > target="RFC7030"/>). The same device may also be deployed > into an ANIMA environment. This may be due to incremental > replacement of a legacy situation with ANIMA. > </t> > <t> > There are additionally some greenfield situations involving an > entirely new installation where a device may have some kind of > management uplink that it can use (such as via 3G network for > instance). In such a future situation, the device might use > this management interface to learn that it should > configure itself by to-be-determined mechanism (such as an Intent) > to become the local registrar. > </t> > <t> > In order to support this scenario, the Pledge MAY contact a well > known URI of a cloud Registrar if a A simpler case could be, “There exist operationally open network wherein device gains unauthenticated access to the internet at large. In these use cases the management domain for the device needs to be discovered within the larger internet. These are less likely within the anima scope but may be more important in the future." (I’ve added this comment within github as well in prep for the pull request) > >> 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. > > So the title of the section is "Voucher-Request artifact", and the entire > section is about the YANG module ietf-voucher-request. I have added one > phrase: "defined in this section" > >> 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. > > The nonce, created-on and assertion are carried forward. > I have changed the text to say: > > The 'prior-signed-voucher-request' leaf is populated with the > Pledge's > voucher-request (such as the prior example). The pledge's > voucher-request, if a signed artifact with a CMS format > signature is a binary object. In the JSON encoding used > here it must be base64 encoded. The nonce, created-on and > assertion is carried forward. serial-number is extracted from > the pledge's Client Certificate from the TLS connection. See > <xref target="RequestVoucherFromMASA"/>.</t></list></t> > > >> Section 4.1, para 2, bullet 2, line 3. "may" -> "MAY" (This "may" >> seems to be normative.) > > Yes, thank you. > >> Para 7, line 2. "should" -> "SHOULD" > > done. > >> 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. > > Added. > >> 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:" > > changed. > >> 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. > > Changed to: > <t>The Pledge is also RECOMMENDED to implement the EST automation > extensions described below. They > > Max, I think that this is a “SHOULD" RFC2119 indicates these are equivalent. I bow to your sense of grammar on this. Use of SHOULD is clearer: "The Pledge SHOULD implement…” > >> 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? > > I think that I don't know which paragraph you are referring to. This is the para in question: Although EST allows clients to obtain multiple certificates by sending multiple CSR requests BRSKI mandates use of the CSR Attributes request and mandates that the Registrar validate the CSR against the expected attributes. This implies that client requests will "look the same” … The point here is that if the client does CSR Attributes and the “Registrar validate[s] the CSR against the expected attributes” then it is not possible to leverage this specific connection to request multiple different client certificates (because of the above requirements). As a result a BRSKI initiated EST connection will result in a single client certificate. If the above is followed and expected every request from the client to the server ‘will look the same’ and every certificate issued will look the same. Solutions would include: tearing down the session and starting a new EST session to obtain more complex certs for other, non-anima, purposes. Or expanding on the CSRAttributes and validation logic to allow for multiple certs. None of which are necessary for anima. - max > > >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Distinguished Professor Emeritus fax: +1 (514) 848-2830 > > Onward to your other editorial comments. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
