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
