BRSKI Cloud Registrar
License: Other
This repository is https://github.com/anima-wg/brski-cloud
**This is the active repository.
This is the working area for the individual Internet-Draft, "BRSKI Cloud Registrar".
Links which are not yet working:
Formatted text and HTML versions of the draft can be built using make.
$ makeThis requires that you have the necessary software installed. See the instructions.
See the guidelines for contributions.
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.
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,.... ?
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?
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?
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.
different spellings and capitalizations are used.
- References
[EST] and [RFC7030] are duplicates.
(WGLC review comment 2022-11-21 , link)
The 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.
OLD:
The est-domain is a URL to which the Pledge should continue doing enrollment rather than with the Cloud Registrar. The pinned-domain-cert contains a trust-anchor which is to be used to authenticate the server found at this URI.
NEW: (proposed)
The est-domain is a URL of an EST server in the owner's domain on which the Pledge should continue doing enrollment rather than with the Cloud Registrar. The pinned-domain-cert contains a trust-anchor which is to be used to authenticate the server found at this URI.
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.
You never use the term Network integrator in the rest of the document. Delete
Aka: This whole section doesn't make sense unless you add some more explanation
(but likely it can just go).
OLD:
The cloud registrar replies to the voucher request with a suitable HTTP 307 response code, including the owner's local domain in the HTTP Location header.
NEW:
In case of redirection, the cloud registrar replies to the voucher request with a HTTP 307 Temporary Redirect response code, including the owner's local domain in the HTTP Location header.
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.
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 ?
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".
339 registrar and has verified the cloud registrar PKI identity, the
s/and has verified the cloud registrar PKI identity,// ??
(@toerless suggests removing this part)
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).
(WGLC review comment 2022-11-21 , link)
242 Figure 1: High Level Architecture
This picture does not show the EST-Server option. Gap ?!
What is "Services" ??
The end-to-end lines look like explicit connections. This is confiusing.
Maybe the connections can be repainted in two ways:
1. replace lines with just some "Internet" in the middle with some dotted
lines from each box connecting to it.
Then insert some rough lines, e.g.:
<--(1) cloud register--->
between Pledge and Cloud Registar
<--(2) VR-sign(N)--->
<--(3) sign(VR-sign(N))-->
Finally, you should add a paragraph with text explaining what the picture shows.
For example saying that all nodes only need to connect over the Internet, and
that it shows the three high-level stages of communication (1) (2), (3)
just roughly so readers understand it.
See WGLC review on mailing list by Brian Carpenter.
The abstract issue is separately defined here: #37
The other issues can be found in the email, also reproduced below.
- 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.
- 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?
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".
- References
[EST] and [RFC7030] are duplicates.
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).
138 provided in sections Section 4.1 and Section 4.2. While both use
139 cases aid with incremental deployment of BRSKI infrastructure, for
140 many smaller sites (such as teleworkers) no further infrastructure
141 are expected.
Last sentence is not correct english and reads weird. How about:
Common to both uses cases is that they aid with the use of BRSKI
in the presence of many small sites (such as teleworkers) with minimum
expectations against their network infrastructure.
143 The pledge is not expected to know which of these two situations it
144 is in. The pledge determines this based upon signals that it
145 receives from the Cloud Registrar. The Cloud Registrar is expected
rephrase/explain: "determines this" -> determines what ? which of the two cases ?
146 to make the determination based upon the identity presented by the
147 pledge.
rephrase/explain: make determination of what ?
149 While a Cloud Registrar will typically handle all the devices of a
150 particular product line from a particular manufacturer there are no
151 restrictions on how the Cloud Registrar is horizontally (many sites)
152 or vertically (more equipment at one site) scaled. It is also
This is very hard to grasp if you did not know in before what the paragraph
means to confer. I hope i get it right. How about:
A Cloud Registrar will receive BRSKI communications from all devices configured
with its URI. This could (for example) all devices of a particular product line from
a particular manufacturer. When this is a significantly large number, a Cloud
Registrar may need to be scaled with the usual web-service scaling mechansisms.
(btw: This is useful text, i am just not sure if its best positioned here
upfront. I would prefer if this was a detail explained later because i don't
feel its so super important or non-obvious).
Insert new paragraph after sentence because you're starting a completely new
piece of information following.
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.
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.
To replace the wording "below" (which is very vague) with exact section reference.
(WGLC review comment Brian 2022-11-20 link)
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).
(WGLC review comment 2022-11-21 , link)
Interesting to consider that the owner's EST server could be on the same host as a BRSKI Registrar i.e. handing out vouchers to Pledges, 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.
344 3.2. Cloud Registrar Handles Voucher Request
346 The cloud registrar must determine pledge ownership. Once ownership
347 is determined, or if no owner can be determined, then the registrar
348 may:
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: " ?
353 * redirect the pledge to an owner register via 307 response code
^ ra
call this " * redirect to owner registrar:" ?
355 * issue a voucher and return a 200 response code
call this " * redirect to owner EST server" ?? Although i don't see
any redirect... Forgot initial text is there no redirect, pledge should assume
to know where to find EST-Server ?
(WGLC review comment 2022-11-21 , link)
Note: this comment may be superseded by #34 in case the YANG extensions are moved to RFC8366-bis.
The 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?)
246 1. OEM - Equipment manufacturer. Operate the MASA.
The rest of the document does not use the term OEM. Delete
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.
- 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.
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.
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".
I am actually not even sure how a BRSKI URI would look like. E.g.: when the
pledge just has a URI - how does it know that the protocol should be BRSKI - let's say
it does support multiple different enrolment protocols... ???
https://brski-registrar.manufacturer.example.com/.well-known/brski
Is that a correct URI that fully identifies BRSKI ???
(i think it is...)
from upros/brski-cloud#2
There does not appear to be a way for CA to send a CSR-Attributes instructing the client to not include a specific field.
Looking at serialNumber which is:
X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
I assume that a X509 parsing stack would complain / not allow a CSR-Attributes response with a NULL value serialNumber.
However, what is stated "the registrar may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR" should be fine. The CA sends a random string as the serialNumber value.
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.
2.1. Interested Parties
I find this section too telegraphic. Needs a bit more grammar...
** Section 3.2
I can't fully follow the logic in Section 3.2 - it's unclear. Below is a proposal for improvement. There needs to be reference to [BRSKI] defined codes, and a particular code defined for the "owner cannot be determined" case because just using any 4xx/5xx code for that at the whim of the registrar implementer doesn't make sense to me. (The party implementing the cloud registrar may be another party than the one making the pledge code - interoperability plays a role here.)
PROPOSED NEW TEXT:
The cloud registrar must determine pledge ownership. Prior to ownership determination, the registrar checks the request for correctness and if it is unwilling or unable to handle the request, it MUST return a suitable 4xx or 5xx error response to the pledge as defined by [BRSKI] and HTTP.
For example, in case of an unknown pledge a 404 is returned, for a malformed request 400 is returned, or in case of server overload 503.
If the request is correct and the registrar is able to handle it, but unable to determine ownership, then it MUST return a 401 Unauthorized response to the pledge. This signals to the Pledge that there is currently no known owner domain for it, but that retrying later might resolve this situation.
If the cloud registrar successfully determines ownership, then it MUST take one of the following actions:
** Section 3.3
It seems that a section is missing on the Pledge side handling an "error response". For example, it could be just a sentence saying the "usual" HTTP error handling defined by [BRSKI] and HTTP applies.
And that for the case of 401 Unauthorized the Pledge MAY retry at a later time.
** Nits
"They operator the Registrar or EST Server"
"which is addresses in part in"
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:
"RFC8995 2.7 introduces concept of Cloud Registar, but does not define how a Cloud
Registrar should perform BRSKI enrolment for pledges from potentially multiple domain.
This document provides a specification for Cloud Registar in which the Cloud
Registar either only provides a Voucher and then redirects the pledge to its
owners EST server, or where it only redirects the pledge to its owners BRSKI Registar.
This whole scope of this document also makes me wonder if we should amend the title
of the docuemtn to "Redirecting BRSKI Cloud Registar". Because there could still be
perfectly well an "all-in-one" BRSKI Cloud Registar, perfectly well fitting RFC8995
section 2.7 - bit not requiring any of this documents procedures, right ? Aka:
The key identifying property is not that of the Cloud Registrar but the fact that it
is redirecting (i think).
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 ?
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"?
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.
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...!)
OLD:
When the pledge downloads a voucher, it can validate the TLS connection
NEW: (proposed)
After the pledge receives the voucher, it validates the TLS connection
(use of "can validate" conveys some optionality - while I think it's mandatory as defined per standard BRSKI. That aspect is already covered by referring to "per standard BRSKI operation" later in the sentence.)
For other BRSKI drafts we have agreed to move any extensions to the YANG voucher model into RFC8366-bis.
It would make sense to do the same for the YANG extensions required by the BRSKI-cloud draft ? ( @mcr )
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 ?
Because in this case we would just upgradr the trust requirement against the
Cloud Registrar. Without this step, the Cloud Registrar is just a glorified
traffic guide to redirect the pledge to the Owner and deliver a a voucher to
it. But really doesn't have to be well trusted - just good enough to oppress
the worst of DoS attack opportunities. (I hope i get this right).
But with such aditional attributes, the cloud-registar has to be trusted
much more.
I would suggest that for this case, if feasible, the voucher would also vouch
for the cloud registar - that would upgrade all the information received from
the cloud registrar to the same level of trust that the pledge has against the
owner registrar - by virtue of the voucher.
Alternatively, i think we should explicitly call for authenticartion of the
Cloud Registrar only via explicit TA for the purpose of Cloud Registrar
connections, but not general purpose WebPKI TA (which a lot of pledges
may also have...).
```
- 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.
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.
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...
160 1.2.1. Owner Registrar Discovery
See also note in 1.2.2 - i would suggest "Bootstrap via Cloud Registrar and Owner Registrar" as better title
162 A pledge is bootstrapping from a remote location with no local domain
You didn't define remote location.
163 registrar (specifically: with no local infrastructure to provide for
164 automated discovery), and needs to discover its owner registrar. The
165 cloud registrar is used by the pledge to discover the owner
166 registrar. The cloud registrar redirects the pledge to the owner
167 registrar, and the pledge completes bootstrap against the owner
168 registrar.
170 A typical example is an enduser deploying a pledge in a home or small
s/enduser/employee who is/
171 branch office, where the pledge belongs to the enduser's employer.
s/enduser's employer/employer/
172 There is no local domain registrar, and the pledge needs to discover
173 and bootstrap with the employer's registrar which is deployed in
174 headquarters. For example, an enduser is deploying an IP phone in a
175 home office and the phone needs to register to an IP PBX deployed in
...needs the keying material from BRSKI to register..
176 their employer's office.
178 1.2.2. Bootstrapping with no Owner Registrar
How about Bootstrapping from via "Cloud Registrar and Owner EST-Server"
180 A pledge is bootstrapping where the owner organization does not yet
^^^
181 have an owner registrar deployed. The cloud registrar issues a
^
... but it has an [RFC7030] EST-Server for enrolment of pledges.
(aka: pull up this sentence here, because later in the paagraph it reads weird.
182 voucher, and the pledge completes trust bootstrap using the cloud
183 registrar. The voucher issued by the cloud includes domain
184 information for the owner's [EST] service the pledge should use for
185 certificate enrollment.
I should have tried to understand this earlier ;-), but i really like this
case. WOuld love to see the following type of explanation here:
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 that
not 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
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.
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?)
OLD:
The pledge MUST process any error messages as defined in [BRSKI], and MUST restart the process from it's provisioned cloud registry anchor.
NEW: (proposed)
The pledge MUST process any error messages as defined in [BRSKI], and in case of error MUST restart the process from it's provisioned cloud registry anchor.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.