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
