Hi all, Since the WGLC period is now past let me post my viewpoint: the draft is not yet ready. Some editorial updates are to be done by the WG and the YANG module definition needs fixing. I will provide my comments as Github PRs in the coming days, which should make it easiest to integrate. There I will propose changing "EST Registrar" to "EST server".
Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Esko Dijk Sent: Monday, November 21, 2022 10:41 To: Anima WG <[email protected]>; [email protected] Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022 Hello all, I'm reviewing the draft currently and agree it needs at least one more editing pass. So far no technical issues came up, only editorial ones and YANG-nits. To help write up my review comments I do have these questions to the authors: - should I provide my comments in email, as Github issues, or Github PRs? (any preference) - what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server *could* be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.) - the YANG contains "RFC XXXX: Voucher Profile for Cloud redirected Devices" - it seems the name needs updating and there should be an RFC ednote here saying the reference is "this RFC". Correct? - YANG contains this: description "Base the constrained voucher upon the regular one"; This looks like a copy/paste leftover from constrained-voucher; correct that it should be modified? (Would this also bump the YANG version and date then?) - YANG description for leaf "est-domain" does not explicitly say the word "EST server" which I think it should. So this URI directs to the EST server in the owner's domain. - could YANG support the use case of combining the voucher-constrained format (that extends base voucher) and the voucher-redirected format (from current draft) ? Would that require yet another new YANG module? Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Brian E Carpenter Sent: Sunday, November 20, 2022 22:27 To: Anima WG <[email protected]> Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022 Hi, Summary: ======== This draft is very clear and almost ready, but I think it needs one more editing pass. I have some minor substantive comments followed by some nits. Substantive comments: ===================== > Abstract This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar). > 1. Introduction > > Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies automated > bootstrapping of an Autonomic Control Plane. Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 8994 that bootstraps the ACP. > 2. Architecture > > The high level architecture is illustrated in Figure 1. I find the "??" in the figure confusing. The Cloud Registrar and the MASA could just be shown as adjacent boxes; the explanation in the text is fine. > TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. Cloud > Registrar returns VOUCHER pinning Owner Register. That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A more complete explanation would be good. > 2.1. Interested Parties I find this section too telegraphic. Needs a bit more grammar... > 2.2. Network Connectivity > > The assumption is that the pledge already has network connectivity prior to > connecting to the cloud registrar. The pledge must have an IP address, Should specify that you mean "routeable" IP address, I think. (I suppose it could be a ULA in some deployments?) > 2.3. Pledge Certificate Identity Considerations > ... > EST [RFC7030] is not clear on how the CSR Attributes response should be > structured, and in particular is not clear on how a server can instruct a > client to include specific attribute values in its CSR. > [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can use CSR > Attributes I'm not entirely comfortable with this being an Informative reference. Isn't this essential for interoperable implementations? Nits: ===== > 1.2. Target Use Cases > ... > for many smaller sites (such as teleworkers) no further infrastructure are > expected. s/are/is/ > ... > While a Cloud Registrar will typically handle all the devices of a particular > product line from a particular manufacturer there are no restrictions on how > the Cloud Registrar is horizontally (many sites) or vertically (more > equipment at one site) scaled. That sentence is really hard to decode. Please rewrite using more words! > It is also entirely possible that all devices sold by through a particular > VAR Please define VAR. > 1.2.2. Bootstrapping with no Owner Registrar > ... > In one use case, an organization has an EST service Please define EST. > The pledge is deployed in the organization's domain, but does not discover a > local domain, or owner, registrar. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"? > 3.1.1. Cloud Registrar Discovery > > BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar > if a local domain registrar cannot be discovered. Additionally, certain > pledge types may never attempt to discover a local domain registrar and may > automatically bootstrap against a cloud registrar. The two occurences of lower-case "may" might be clearer as "might". > 3.1.2. Pledge - Cloud Registrar TLS Establishment Details > > The pledge MUST use an Implicit Trust Anchor database (see [EST]) to > authenticate the cloud registrar service. The Pledge can be done with > pre-loaded trust-anchors "The Pledge can be done with" ???? > 3.2.2. Cloud Registrar Redirects to Owner Registrar > > Once the cloud registrar has determined pledge ownership, the cloud registrar > may redirect the pledge "may" or "MAY"? > 3.3.1. Redirect Response > 3.3.2. Voucher Response There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST". > 8. References [EST] and [RFC7030] are duplicates. Regards Brian Carpenter _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
