Thanks a lot, Michael
Wrt. the process: As a reviewer, keeping everything in a single file is always
easier
than breaking it up into issues. Especially because the more you revisit a
document, the
more you go back and forth and maybe delete comments or change them.
When i sent this as an attachment, i was under the (mis)interpretation, that
attachments
would give me different file-size limits. I did learn in the meantime this is
not the case,
but in that review (for another WG doc), i ended up having to zip the review so
it could
go through *sigh*.
I think i should have created the tags for each review point that would have
allowed to
auto-create github issues from them. I remember that someone in IESG did
provide such feedback,
but i could not find it again. WOuld be nice to have a very simple way to find
such a
preferred tagging method documented on authors.ietf.org..
Thanks again!
Toerless
On Tue, Dec 19, 2023 at 09:53:29AM -0500, Michael Richardson wrote:
>
> Hi, I have processed the complete review from Toerless.
> (Making it a file attach is a bit hostile to the archives, btw)
>
> I have opened 40 issues at: https://github.com/anima-wg/brski-cloud/issues
>
> A few have text fixes on the branch
> https://github.com/anima-wg/brski-cloud/pull/88
> A few will require some discussion, and I've marked them for Toerless'
> attention. Most can be handled by authors, however, and I'll endeavour to
> get that posted by Jan. 2.
>
> Here is my comments/issues for the comments that Toerless made.
> (In two parts)
> Some comments inline as well.
>
> 1) many typos are at: https://github.com/anima-wg/brski-cloud/pull/88
>
> > 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-05
>
> > 13 Abstract
>
> > 15 This document specifies the behavior of a BRSKI Cloud Registrar, and
> > 16 how a pledge can interact with a BRSKI Cloud Registrar when 17
> > bootstrapping.
>
> > If you can, add an explanation what the core aspects of a Cloud
> > Registrar are for tthe purpose of this document... discovery ?
> > untrusted connection,.... ?
>
> https://github.com/anima-wg/brski-cloud/issues/48
>
> > 95 1. Introduction
>
> > 97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies 98
> > automated bootstrapping of an Autonomic Control Plane. BRSKI
>
> > Suggest to replace after BRSKI with:
>
> > ... BRSKI specifies automated and secure provisioning of nodes (which
> > are called pledges) with cryptographic keying material (trust anchors
> > and certificates) to enable authenticated and confidential
> > communication with other similarily enrolled nodes. This is also called
> > enrolment.
>
> > No need to mention Autonomic Control Plane here IMHO (just sounds like
> > limiting scope of BRSKI Cloud).
>
> > If you really want folks to understand what is happening here, i
> > suggest to include explanations such as the following.
>
> > In BRSKI, the pledge performs enrolment by communicating with a BRSKI
> > Registrar belonging to the domain that provides the cryptopgraphic
> > keying material and usually is or acts upon the owner of the
> > pledge. The pledge does not know who its owner is. Insted, in BRSKI it
> > is assumed that the network to which the pledge connects belongs to the
> > owner of the pledge and therefore network-supported discovery
> > mechanisms can resolve generic, non-owner specific names to the owners
> > Registrar. To support enrolment of pledges without such an owner based
> > access network, the mechanisms of BRSKI Cloud are required which assume
> > that Pledge and Registrar simply connect to the Internet. The Internet
> > ("Cloud") connected Registrar will then determine ownership of the
> > Pledge and redirect the Plege to its owners Registar.
>
> https://github.com/anima-wg/brski-cloud/issues/49
>
> > 99 Section 2.7 describes how a pledge "MAY contact a well-known URI of
> > a 100 cloud registrar if a local registrar cannot be discovered or if
> > the 101 pledge's target use cases do not include a local registrar".
>
> > I would remove parenthesis and lowercase the MAY. No need for this
> > formalism to expose your internal repetition of sentence. This is still
> > introduction, repetition is perfectly fine.
>
> https://github.com/anima-wg/brski-cloud/issues/50
>
> > 131 * Local Domain Registrar: The Registrar discovered on the Local 132
> > Domain. There may not be a Local Domain Registrar in all 133
> > deployment scenarios.
>
> > Isn't one core aspect of interest (which should be discussed in the
> > text), that the pledge does discover a Registar locally, but its not of
> > its owner ?
>
> https://github.com/anima-wg/brski-cloud/issues/51
>
> > 135 1.2. Target Use Cases
>
> > 137 Two high level use cases are documented here. There are more
> > details
>
> > This document specifies and standardizes procedures for two high level
> > use cases.
>
> > (use case documentation is fine, but the beef of standard tracks RFCs
> > is the specification of standardized procedures).
>
> https://github.com/anima-wg/brski-cloud/issues/52
>
> > 152 or vertically (more equipment at one site) scaled. It is also 153
> > entirely possible that all devices sold by through a particular VAR
> > ^^^^^^^^^^ 154 might be preloaded with a configuration that changes the
> > Cloud 155 Registrar URL to point to a VAR. Such an effort would
> > require 156 unboxing each device in a controlled environment, but the
> > 157 provisioning could occur using a regular BRSKI or SZTP [RFC8572]
> > 158 process.
>
> > I think VAR is an unnecessary term and the whole paragraph is somewhat
> > confusing.
>
> > If i understand it correctly, the core argument is like this:
>
> > The procedures specified in this document are an alternative to
> > mechanisms possible with just BRSKI to reduce operational cost.
>
> > Consider pledges are to be enrolled when being connected solely to the
> > Internet, but no owner based network. Likewise, the Registar is assumed
> > to be only connected to the Internet. The challenge in this case is for
> > the pledge to discover a URI for the Oners Registar. In the absence of
> > the procdures described in this doument, BRSKI could be used, but the
> > pledge would need to be pre-staged with that URI. In one instance, the
> > seller of the pledge could attach to the shipment of the pledge a USB
> > stick pre-populated with a file containing that Owner Registar URI, and
> > that USB stick would need to be inserted into the pledge to enavble
> > enrolment. This is but one option, and compared to similar
> > alternatives, it does not require unpacking/configuration/repackaging
> > of the pledge at the sellers site, but only configuration of a USB
> > stick
>
> > Yada yada... i really don't know how to make this shorter without
> > looking readers who do not live & breathe this stuff, so it probably is
> > all better suited to be put later into the document and only put a
> > pointer to such a chapter here into the Introduction.
>
> https://github.com/anima-wg/brski-cloud/issues/53
>
> > 160 1.2.1. Owner Registrar Discovery
>
> ...
>
> > This option can be used to introduce the benefits of BRSKI for an
> > initial period when BRSKI is not available in existing EST-Servers. But
> > it can also be used long-term as an security-equivalent solution in
> > which BRSKI and EST-Server are set up in a modular fashion.
>
> > Would also suggest to add:
>
> > The use of an EST-Server instead of a BRSKI Registrar may mean thatno t
> > all the EST options required by [BRSKI] may be available and hence this
> > option may not support all BRSKI deployment cases. For example,
> > certificates to enroll into an ACP [RFC8994] needs to include an
> > AcpNodeName (see [RFC8994], Section 6.2.2), which non-BRSKI capable
> > EST-Servers ma not support.
>
> > At this point in the doc you need to insert 1.2.3 Summary
>
> https://github.com/anima-wg/brski-cloud/issues/54
>
> > 204 If the cloud registrar issues a voucher itself without redirecting
> > 205 the pledge to an owner registrar, the cloud registrar will inform
> > the 206 pledge what domain to use for accessing EST services in the
> > voucher 207 response.
>
> > These two paragrapsh need to be specifically referring to which of the
> > section 1 mentioned use cases they are. Aka: in case of 1.2.2 ..., In
> > case of 1.2.2...
>
> https://github.com/anima-wg/brski-cloud/issues/55
>
> > 209 Finally, when bootstrapping against an owner registrar, this 210
> > registrar may interact with a backend CA to assist in issuing 211
> > certificates to the pledge. The mechanisms and protocols by which 212
> > the registrar interacts with the CA are transparent to the pledge and
> > 213 are out-of-scope of this document.
>
> > "will interact with a CA" (aka: i don't think we hacve a case where a
> > CA is not involved, but no need to express opinion about where it's
> > located "backend..." superflous).
>
> > More importantly: This paragraph applies to both owner registar and
> > owner EST-Server, rewrite all occurrances within paragraph to cover
> > both cases. (i think...!)
>
> https://github.com/anima-wg/brski-cloud/issues/56
>
> > 219 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2.
> > 220 Cloud Registrar returns VOUCHER pinning Owner Register.
>
> > This paragraph comes totall unexpected without context. Pinning is
> > unexplained. Maybe less ternse explanation here.
>
> https://github.com/anima-wg/brski-cloud/issues/57
>
> > 242 Figure 1: High Level Architecture
>
> https://github.com/anima-wg/brski-cloud/issues/58
>
> > 246 1. OEM - Equipment manufacturer. Operate the MASA.
>
> > The rest of the document does not use the term OEM. Delete
>
> https://github.com/anima-wg/brski-cloud/issues/59
> I think we need this term.
>
> > 248 2. Network operator. Operate the Owner Registrar. Often operated
> > 249 by end owner (company), or by outsourced IT entity.
>
> > This is only used twice below and the second time its not clear its the
> > same operator.
>
> > 251 3. Network integrator. They operate a Cloud Registrar.
>
> https://github.com/anima-wg/brski-cloud/issues/60
>
> > 253 2.2. Network Connectivity
>
> > 255 The assumption is that the pledge already has network connectivity
> > 256 prior to connecting to the cloud registrar. The pledge must have
> > an 257 IP address, must be able to make DNS queries, and must be able
> > to 258 send HTTP requests to the cloud registrar. The pledge operator
> > has
>
> > I would remove the "able to send HTTP requests" as this opens a rathole
> > of questions re. HTTP and mutual authentication, which are just
> > resolved later in the doc.
>
> https://github.com/anima-wg/brski-cloud/issues/61
>
> > 262 2.3. Pledge Certificate Identity Considerations
>
> > 264 BRSKI section 5.9.2 specifies that the pledge MUST send an EST 265
> > [RFC7030] CSR Attributes request to the registrar. The registrar MAY
>
> > which registrar - cloud or owner ?
>
> https://github.com/anima-wg/brski-cloud/issues/62
>
> > 266 use this mechanism to instruct the pledge about the identities it
> > 267 should include in the CSR request it sends as part of enrollment.
> > 268 The registrar may use this mechanism to tell the pledge what
> > Subject 269 or Subject Alternative Name identity information to include
> > in its 270 CSR request. This can be useful if the Subject must have a
> > specific 271 value in order to complete enrollment with the CA.
>
> > So... In case of using an owner EST-Server instead of the Owner BRSKI
> > Registrar, this paragraph seems to hint at the option that the pledge
> > does the CSR Attribute request so that the Cloud registrar provides
> > this information because the EST-Server may not ? That should be said
> > more explicitly.
>
> > For the case of Cloud and Owner Registrar it seems that the CSR attr
> > request could also be sent to the cloud registrar, but also to owner
> > registrar. Should both be sent ?? Be more explicit please.
>
> https://github.com/anima-wg/brski-cloud/issues/63
>
> > 280 For example, the pledge may only be aware of its IDevID Subject
> > which 281 includes a manufacturer serial number, but must include a
> > specific 282 fully qualified domain name in the CSR in order to
> > complete domain 283 ownership proofs required by the CA.
>
> > puuh... interesting, but bring up security challenge if i understand it
> > correctly:
>
> > So the pledge would learn attributes from the cloud registrar via
> > CSRattr request/reply and later on uses them in the cert enrolment step
> > with the EST-Server/Owner-Registrar.
>
> > Yes ?
>
> ... https://github.com/anima-wg/brski-cloud/issues/64
>
> > 294 3.1.1. Cloud Registrar Discovery
>
> > 296 BRSKI defines how a pledge MAY contact a well-known URI of a cloud
> > 297 registrar if a local domain registrar cannot be discovered.
>
> > Actually, it would really be good if some text in the introduction of
> > brski cloud would discus/refer to RFC8995 section 2.7 "Cloud Registar",
> > such as:
>
> https://github.com/anima-wg/brski-cloud/issues/65
>
> > 298 Additionally, certain pledge types may never attempt to discover a
> > 299 local domain registrar and may automatically bootstrap against a
> > 300 cloud registrar.
>
> > 302 The details of the URI are manufacturer specific, with BRSKI giving
> > 303 the example "brski-registrar.manufacturer.example.com".
>
> > Hmm. RFC8995 says:
>
> > performing a DNS lookup using a well-known URI such as
> > "brski-registrar.manufacturer.example.com"
>
> > but i think thats wrong text because "brski-..." is not a URI given how
> > it has no scheme. Sentence should have been "DNS lookup using the host
> > of the well-known URI".
>
> https://github.com/anima-wg/brski-cloud/issues/66
>
> > 313 with pre-loaded trust-anchors that are used to validate the TLS 314
> > connection. This can be using a public Web PKI trust anchors using 315
> > [RFC6125] DNS-ID mechanisms, a pinned certification authority, or 316
> > even a pinned raw public key. This is a local implementation 317
> > decision.
>
> > I am mostly worried of this being mis-read such that it could be
> > appropriate to include the teirrbly long list of WebPKI Trust Anchors
> > and think thats good security. If we sa WebPKI it would certainlt be
> > good to suggest limiting WebPKI Trust anchros to only the ones known to
> > be required for the Cloud Registar.
>
> https://github.com/anima-wg/brski-cloud/issues/67
>
> > 319 The pledge MUST NOT establish a provisional TLS connection (see
> > BRSKI 320 section 5.1) with the cloud registrar.
>
> > Reads confusingly here. Suggest to remove paragraph here and explain
> > after the following paragraph that compared to BRSKI, the TLS
> > connection is immediately mutually authenticated and not first a
> > provisional TLS connection as in BRSKI.
>
> https://github.com/anima-wg/brski-cloud/issues/68
>
> > 322 The cloud registrar MUST validate the identity of the pledge by 323
> > sending a TLS CertificateRequest message to the pledge during TLS 324
> > session establishment. The cloud registrar MAY include a 325
> > certificate_authorities field in the message to specify the set of 326
> > allowed IDevID issuing CAs that pledges may use when establishing 327
> > connections with the cloud registrar.
>
> > 329 The cloud registrar MAY only allow connections from pledges that
> > have 330 an IDevID that is signed by one of a specific set of CAs, e.g.
> > 331 IDevIDs issued by certain manufacturers.
>
> > How about we upgrade this ?
>
> > To protect itself against DoS attacks, the cloud registrar SHOULD
> > reject TLS connections when it can determine during TLS authentication
> > that it can not support the pledge, for example because the plege can
> > not provide an IDevID signed by a CA recognized/supported by the cloud
> > registrar.
>
> https://github.com/anima-wg/brski-cloud/issues/69
>
> > 334 identity certificates or using Raw Public Key [RFC7250]
> > certificates.
>
> > I think you're mention this because you have a good business case, such
> > as reduction in manufacturing cost by doing self enrolment or raw
> > public keys during manufacturing and capturing those into MASA and
> > manufacturing databases - instead of also having to bother about a
> > CA. It might be useful to add a paragraph about this benefit, although
> > it is AFAIK not really BRSKI Cloud specific - but it seems like this
> > could be even a more common case as peldges with non-self-signed certs.
>
> https://github.com/anima-wg/brski-cloud/issues/70
>
> > 339 registrar and has verified the cloud registrar PKI identity, the
>
> > s/and has verified the cloud registrar PKI identity,// ??
>
> https://github.com/anima-wg/brski-cloud/issues/71
> (I disagree)
>
> > 350 * return a suitable 4xx or 5xx error response to the pledge if the
> > 351 registrar is unwilling or unable to handle the voucher request
>
> > call this " * error: " ?
>
> https://github.com/anima-wg/brski-cloud/issues/72
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
