Dear authors
Thank you so much for the document. really nice
I have i think almost exclusively NITs for textual quality and hopefully useful
additional
text suggestion to clarify what ultimately is (at least to me) quite a complex
technology.
Maybe i am not the only one who would benefit from the best diligence in making
this
text as easy understood by non-security experts wanting/needing to
implement/operate
BRSKI-(AE).
Due to time constraint, i failed to run in parallel a github pull for the text i
suggested, so hopefully the inline review here will suffice.
Cheers
Toerless
2 ANIMA WG D. von Oheimb, Ed.
3 Internet-Draft S. Fries
4 Intended status: Standards Track H. Brockhaus
5 Expires: 5 December 2022 Siemens
6 E. Lear
7 Cisco Systems
8 3 June 2022
10 BRSKI-AE: Alternative Enrollment Protocols in BRSKI
11 draft-ietf-anima-brski-ae-02
13 Abstract
15 This document enhances Bootstrapping Remote Secure Key Infrastructure
16 (BRSKI, RFC 8995) to allow employing alternative enrollment
17 protocols, such as CMP.
19 Using self-contained signed objects, the origin of enrollment
20 requests and responses can be authenticated independently of message
21 transfer. This supports end-to-end security and asynchronous
22 operation of certificate enrollment and provides flexibility where to
23 authenticate and authorize certification requests.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on 5 December 2022.
42 Copyright Notice
44 Copyright (c) 2022 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents (https://trustee.ietf.org/
49 license-info) in effect on the date of publication of this document.
50 Please review these documents carefully, as they describe your rights
51 and restrictions with respect to this document. Code Components
52 extracted from this document must include Revised BSD License text as
53 described in Section 4.e of the Trust Legal Provisions and are
54 provided without warranty as described in the Revised BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.2. Supported Environment . . . . . . . . . . . . . . . . . . 5
61 1.3. List of Application Examples . . . . . . . . . . . . . . 6
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 3. Requirements and Mapping to Solutions . . . . . . . . . . . . 7
64 3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 7
65 3.2. Solution Options for Proof-of-possession . . . . . . . . 8
66 3.3. Solution Options for Proof-of-identity . . . . . . . . . 9
67 4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 10
68 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 10
69 4.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 13
70 4.3. Enhancements to Addressing Scheme . . . . . . . . . . . . 16
71 4.4. Domain Registrar Support of Alternative Enrollment
72 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 16
73 5. Instantiation to Existing Enrollment Protocols . . . . . . . 17
74 5.1. BRSKI-EST-fullCMC: Instantiation to EST (informative) . . 17
75 5.2. BRSKI-CMP: Instantiation to CMP (normative if CMP is
76 chosen) . . . . . . . . . . . . . . . . . . . . . . . . . 18
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
81 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
82 9.2. Informative References . . . . . . . . . . . . . . . . . 21
83 Appendix A. Using EST for Certificate Enrollment . . . . . . . . 22
84 Appendix B. Application Examples . . . . . . . . . . . . . . . . 23
85 B.1. Rolling Stock . . . . . . . . . . . . . . . . . . . . . . 23
86 B.2. Building Automation . . . . . . . . . . . . . . . . . . . 24
87 B.3. Substation Automation . . . . . . . . . . . . . . . . . . 24
88 B.4. Electric Vehicle Charging Infrastructure . . . . . . . . 25
89 B.5. Infrastructure Isolation Policy . . . . . . . . . . . . . 25
90 B.6. Sites with Insufficient Level of Operational Security . . 25
91 Appendix C. History of Changes TBD RFC Editor: please delete . . 26
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
94 1. Introduction
96 1.1. Motivation
98 BRSKI, as defined in [RFC8995], specifies a solution for secure
99 automated zero-touch bootstrapping of new devices, so-called pledges.
100 This includes the discovery of the registrar in the target domain,
101 time synchronization, and the exchange of security information
^^^^^^^^^^^^^^^^^^^^
NIT: better: "time validation"
102 necessary to establish mutual trust between pledges and the target
103 domain.
105 A pledge gains trust in the target domain via the domain registrar as
106 follows. It obtains security information about the domain,
107 specifically a domain certificate to be trusted, by requesting a
108 voucher object defined in [RFC8366]. Such a voucher is a self-
109 contained signed object originating from a Manufacturer Authorized
110 Signing Authority (MASA).
NIT: Always difficult to summarize BRSKI operations. How about the following
rewrite:
Initially, a pledge has a trust anchor for its Manufacturer. To trust the
registrar
of a target domain for automatic enrollment of the pledge with trust anchor and
domain certificate of the target domain, BRSKI uses voucher objects defined in
[RFC8366].
A voucher is a cryptographic object signed with the Manufacturer trust anchor
by a Manufacturer Authorized Signing Authority (MASA) so the pledge can trust
the voucher. The voucher indicates to the pledge identified through (a hash of)
its IDevID in the voucher that it can trust the domain as identified by a (hash
of a)
trust Anchor for the domain.
110 Therefore, the voucher may be provided in
111 online mode (synchronously) or offline mode (asynchronously).
NIT: I think it would be good to explain this with a bit more detail:
While RFC8995 only specifies a single, online set of protocol option to
communicate the voucher between MASA, registar and pledge (BRSKI-EST and
BRSKI-MASA,
see RFC8995, Section 2), it also desribes the architecture for how the voucher
may be provided in online mode (synchronously) or offline mode (asynchronously).
111 The 112 pledge can authenticate the voucher because it is
shipped with a
113 trust anchor of its manufacturer such that it can validate signatures
114 (including related certificates) by the MASA.
NIT: with my above suggested text, this 111-114 text is redundant.
116 Trust by the target domain in a pledge is established by providing
NIT: s/providing/enrolling/
(i think...)
117 the pledge with a domain-specific LDevID certificate. The
118 certification request of the pledge is signed using its IDevID secret
119 and can be validated by the target domain using the trust anchor of
^^^
NIT: which
120 the pledge manufacturer, which needs to pre-installed in the domain.
122 For enrolling devices with LDevID certificates, BRSKI typically
123 utilizes Enrollment over Secure Transport (EST) [RFC7030]. EST has
NIT: /typically utilizes/specifies how ... can be used/
124 its specific characteristics, detailed in Appendix A. In particular,
125 it requires online or on-site availability of the RA for performing
NIT: expand RA before first use
126 the data origin authentication and final authorization decision on
127 the certification request. This type of enrollment can be called
128 'synchronous enrollment'. For various reasons, it may be preferable
NIT: "for various resons" is hand waiving. If you have explanations in the doc
later, put pointers in here, otherwise consider rewriting to improve quality.
129 to use alternative enrollment protocols such as the Certificate
130 Management Protocol (CMP) [RFC4210] profiled in
131 [I-D.ietf-lamps-lightweight-cmp-profile] or Certificate Management
132 over CMS (CMC) [RFC5272]. that are more flexible and independent of
133 the transfer mechanism because they represent certification request
134 messages as authenticated self-contained objects.
NIT: WOuld be good to make the point more explicit, e.g:
EST (RFC7030), BRSKI-EST and BRSKI-MASA are tied to one specific transport, TLS
and
therefore need to be modified when deployments require different transport. See
[constrained-voucher], [EST-CoAP]. Likewise EST does not support offline
enrolment.
I remember you had other reasons, such as pre-existance of CMP in SDK of many
devices whereas EST does not necessarily exist.
136 Depending on the application scenario, the required PKI-RA/CA
components
NI: Expand CA before first use.
137 may not be part of the registrar. They even may not be available on-
138 site but rather be provided by remote backend systems. The registrar
139 or its deployment site may not have an online connection with them or
NIT: s/them/the PKI-RA/CA/
140 the connectivity may be intermittent. This may be due to security
141 requirements for operating the backend systems or due to site
142 deployments where on-site or always-online operation may be not
143 feasible or too costly. In such scenarios, the authentication and
144 authorization of certification requests will not or can not be
145 performed on-site at enrollment time. In this document, enrollment
NIT: Would rewrite to avoid use of "enrollment time" as its a new yet undefined
(and hopefully unnecessary) term. I think just delete "at enrollment time".
146 that is not performed in a (time-wise) consistent way is called
147 'asynchronous enrollment'.
I think i'd have a hard time judging what is and what is not a time-wise
consistent way,
so i think this is not a good definition.
How about this:
secure asynchronous enrollment are methods where the security between
the communicating parties for enrollment can not be provided by an
authenticated (and
often confidential) end-to-end communications channel such as TLS used in
EST/BRSKI-EST/BRSKI-MASA, but where messages may need to be forwarded through
offline methods (e.g. Sneakernet/USB-sticks) and/or at any point in time only
part
of the communication path is available and messages need to be stored in front
of
an unavailabele segment for potentially long (days) amount of times.
In any case, the definition is an important aspect for future reuse in other
documents,
so make it explicit, not en-passant, e.g.: at least a separate paragraph.
147 Asynchronous enrollment requires a store-
148 and-forward transfer of certification requests along with the
149 information needed for authenticating the requester. This allows
150 offline processing the request.
Maybe my suggested text before is a good replacement for 147-150.
152 Application scenarios may also involve network segmentation, which is
NIT: Add reference to appendix B.5.
153 utilized in industrial systems to separate domains with different
154 security needs. Such scenarios lead to similar requirements if the
155 TLS connection carrying the requester authentication is terminated
156 and thus request messages need to be forwarded on further channels
157 before the registrar/RA can authorize the certification request. In
158 order to preserve the requester authentication, authentication
159 information needs to be retained and ideally bound directly to the
160 certification request.
Nice.
NIT: It might be a better flow to move this paragraph forther below, because
in line 166 you start to explain effectively what an RA is, and that is the
original network segmentation solution. So it would be easier to understand
that the same type of segmentation may need to happen before a place where an
RA can be placed.
But just food for thought..
162 There are basically two approaches for forwarding certification
163 requests along with requester authentication information:
MINOR: What do we call "certification" ? IMHO, we are really talking about two
phases:
part 1 "BRSKI proper": Communications to make the pledge trust the domain it
should be enrolled into. Aka: roughly up to the point that the pledge receives
the
voucher / trust anchor for the domain. Aka: What BRSKI primarily contributed.
part 2 "Certificate enrolment": Aka: What BRSKI takes from EST and just slightly
enhances/modifies.
Certification to me sounds like only part 2. Do we only want to talk about part
2 ?
If yes, then why not also about part 1 (to be asynchronuous...).
165 * A trusted component (e.g., a local RA) in the target domain is
^^^^^^^^^^^^^^^^^^^
NIT: A component trusted both by the pledge and the CA (or the next trusted
component in a chain)
166 needed that forwards the certification request combined with the
167 validated identity of the requester (e,g., its IDevID certificate)
168 and an indication of successful verification of the proof-of-
169 possession (of the corresponding private key) in a way preventing
170 changes to the combined information.
170 When connectivity is
171 available, the trusted component forwards the certification
172 request together with the requester information (authentication
173 and proof-of-possession) for further processing. This approach
174 offers only hop-by-hop security. The backend PKI must rely on the
NIT: The "only hop-by-hop security" reads a bit like a side-node. E.g.: why is
it bad ?
To me the "bad" part is the need to introduce another trusted party if you'd
rather
not want to do so. That also better matches what you write later about the
alternative
approach.
175 local pledge authentication result provided by the local RA when
176 performing the authorization of the certification request. In
177 BRSKI, the EST server is such a trusted component, being co-
178 located with the registrar in the target domain.
NIT: This is all correct, but very dense. I imagine, it could be more
illustrative to
maybe start explaining the original purpose of an RA, which was to have an
entity responsible
for the identification of the pledge, and in result it was necessary then for
the
RA to be trusted separately by the CA. And then continue to note that once you
have this segmentation of security like in an RA, you can also desynchronize the
communications across the two segments from each other - and generalize the
concept beyond an RA to solve cases where just an RA may not sit in the right
place.
180 * Involved components use authenticated self-contained objects for
181 the enrollment, directly binding the certification request and the
182 requester authentication in a cryptographic way. This approach
183 supports end-to-end security, without the need to trust in
184 intermediate domain components. Manipulation of the request and
185 the requester identity information can be detected during the
186 validation of the self-contained signed object.
NIT: It may be useful to amend here an argument that this approach does then not
allow you to decouple the way you can identify the pledge from whatever the CA
would
like to see as identification, which means its not a generic replacement for
RA, but when you do want to rely on proof of posession of an IDevID then its
maybe an even more attactive and simple mechanism than the RA mechanism...
188 Focus of this document is the support of alternative enrollment
189 protocols that allow using authenticated self-contained objects for
^
NIT "the second option, e.g.: "
190 device credential bootstrapping. This enhancement of BRSKI is named
191 BRSKI-AE, where AE stands for alternative enrollment protocols and
192 for asynchronous enrollment. This specification carries over the
193 main characteristics of BRSKI, namely that the pledge obtains trust
194 anchor information for authenticating the domain registrar and other
195 target domain components as well as a domain-specific X.509 device
196 certificate (the LDevID certificate) along with the corresponding
197 private key (the LDevID secret) and certificate chain.
199 The goals are to enhance BRSKI to
201 * support alternative enrollment protocols,
203 * support end-to-end security for enrollment, and
NIT: Reader may ask "how is it that BRSKI does not support this now", aka:
insert
somewhere (earlier ?) a reminder how BRSKI does not specify enrolment at all,
but
relies primarily on a model where BRSKI-EST is used with the registrar doubling
as RA (that half-clear from text above, but not said explicitl).
205 * make it applicable to scenarios involving asynchronous enrollment.
207 This is achieved by
209 * extending the well-known URI approach with an additional path
^
NIT: "of BRSKI and EST message"
210 element indicating the enrollment protocol being used, and
212 * defining a certificate waiting indication and handling, for the
213 case that the certifying component is (temporarily) not available.
215 This specification can be applied to both synchronous and
216 asynchronous enrollment.
218 In contrast to BRSKI, this specification supports offering multiple
^^^^^^^^
NI: As an improvment over BRSKI... ?
219 enrollment protocols on the infrastructure side, which enables
220 pledges and their developers to pick the preferred one.
222 1.2. Supported Environment
224 BRSKI-AE is intended to be used in domains that may have limited
225 support of on-site PKI services and comprises application scenarios
226 like the following.
NIT: Just getting out of AUTH48 i decided to turn all bullet lists into numbered
lists so it is easier in discussions to refer to points of lists ... recommend
to do
the same for this doc (just personal preference.).
228 * There are requirements or implementation restrictions that do not
229 allow using EST for enrolling an LDevID certificate.
NIT: Reference example always welcome (if you have one below, inser reference).
Also not a sufficient example IMHO, because
you would today be able to use RFC8995 together with e.g.: SCEP or some other
"RA" based
enrolment protocol. Aka: An example that would be possible with the RA-model of
BRSKI would
be very helpful here.
231 * Pledges and/or the target domain already have an established
232 certificate management approach different from EST that shall be
233 reused (e.g., in brownfield installations).
NIT: Are there any easily described preprequisites for pre-existing brownfields
to
make BRSKI-AE applicable or not ? If so, would be good to know/add.
235 * There is no registration authority available on site in the target
236 domain. Connectivity to an off-site RA is intermittent or
237 entirely offline. A store-and-forward mechanism is used for
238 communicating with the off-site services.
240 * Authoritative actions of a local RA are limited and may not be
241 sufficient for authorizing certification requests by pledges.
242 Final authorization is done by an RA residing in the operator
243 domain.
NIT: across the above text you use "local" and "site" and didn't introduce a
picture
or other reference as to what it means
Maybe something like:
pledge .... local/site .... edge/sneakernet
.....remote...certification-entity
245 1.3. List of Application Examples
247 Bootstrapping can be handled in various ways, depending on the
248 application domains. The informative Appendix B provides
249 illustrative examples from various industrial control system
250 environments and operational setups. They motivate the support of
251 alternative enrollment protocols, based on the following examples of
252 operational environments:
254 * Rolling stock
256 * Building automation
258 * Electrical substation automation
260 * Electric vehicle charging infrastructures
262 * Infrastructure isolation policy
264 * Sites with insufficient level of operational security
266 2. Terminology
268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
270 "OPTIONAL" in this document are to be interpreted as described in
271 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
272 capitals, as shown here.
274 This document relies on the terminology defined in [RFC8995] and
275 [IEEE.802.1AR_2009].The following terms are defined in addition:
NIT: Afterthought, aka. this nit is written after a lot of other NITs are
written,
so consider this to superceed other competing NITs:
Compared to BRSKI, this document starts to distingish between BRSKI Registrar
and PKI-RA
as two separate entities (or at least its a lot more important for this
document to
make the distinction clear than IMHO it was for BRSKI), but this document
abbreviates
BRSKI Bregistrar as RA and not always abbreviates the PKI Registrar as PKI-RA.
Maybe it
would therefore be better to consistently choose new abbreviations such as BRA
for
BRSKI RegistrAr vz PRA for PKI Registation Authority. Just an idea, but i
really do not
want to see the abbreviation "RA" without any distinguisher in this document.
277 EE: End entity, in the BRSKI context called pledge. It is the
278 entity that is bootstrapped to the target domain. It holds a
^^ into ?
279 public-private key pair, for which it requests a public-key
280 certificate. An identifier for the EE is given as the subject
NIT: maybe "the name of an identifier" instead of "identifier"
Aka: The IDevID is also called an identifier, and the subject-name of it is
what you would copy into the LDevID, so it is a name of the identifier.
281 name of the certificate.
283 RA: Registration authority, an optional system component to which a
284 CA delegates certificate management functions such as
285 authenticating requesters and performing authorization checks on
286 certification requests.
288 CA: Certification authority, issues certificates and provides
289 certificate status information.
291 target domain: The set of entities that share a common local trust
292 anchor, independent of where the entities are deployed.
294 site: Describes the locality where an entity, e.g., pledge,
295 registrar, RA, CA, is deployed. Different sites can belong to the
296 same target domain.
298 on-site: Describes a component or service or functionality available
299 in the target deployment site.
301 off-site: Describes a component or service or functionality
302 available in an operator site different from the target deployment
303 site. This may be a central site or a cloud service, to which
304 only a temporary connection is available.
306 asynchronous communication: Describes a time-wise interrupted
307 communication between a pledge (EE) and a registrar or PKI
308 component.
310 synchronous communication: Describes a time-wise uninterrupted
311 communication between a pledge (EE) and a registrar or PKI
312 component.
314 authenticated self-contained object: Describes in this context an
315 object that is cryptographically bound to the IDevID certificate
316 of a pledge. The binding is assumed to be provided through a
317 digital signature of the actual object using the IDevID secret.
NIT: How about adding the following definition:
BRSKI-AE: a variation of BRSKI (RFC8995), in which BRSKI-EST, the protocol
between
Pledge, Proxy and Registrar is modified to use new URI scheme messages, as
specified
in this document to perform the certificate enrolment step (replacing EST URI
messages).
BRSKI-AE enables the use of different enrolment protocols between Registar and
PKI RA/CA including asynchronous enrolment.
This may sound somewhat repeptitive, but it would be very helpful if we had
such a
strict specification for what we mean when we talk about BRSKI-EST, so that
there is
no ambiguity when future documents refer to these terms.
319 3. Requirements and Mapping to Solutions
321 3.1. Basic Requirements
323 There were two main drivers for the definition of BRSKI-AE:
NIT: /were/are/
325 * The solution architecture may already use or require a certificate
326 management protocol other than EST. Therefore, this other
327 protocol should be usable for requesting LDevID certificates.
NIT: /requesting/enrolling/ ?
329 * The domain registrar may not be the (final) point that
330 authenticates and authorizes certification requests and the pledge
331 may not have a direct connection to it. Therefore, certification
332 requests should be self-contained signed objects.
334 Based on the intended target environment described in Section 1.2 and
335 the application examples described in Appendix B, the following
336 requirements are derived to support authenticated self-contained
337 objects as containers carrying certification requests.
339 At least the following properties are required:
341 * proof-of-possession: demonstrates access to the private key
342 corresponding to the public key contained in a certification
343 request. This is typically achieved by a self-signature using the
344 corresponding private key.
346 * proof-of-identity: provides data origin authentication of the
347 certification request. This typically is achieved by a signature
348 using the IDevID secret of the pledge.
NIT: I am somewhat worried about the the term and/or what you imply.
For example, proof of identity could mean that a protocol includes in the signed
message only a hash of the certificate - but not the full certificate itself. In
this case there needs to be another channel by which the receiving side has to
learn
the actual certificate from. This is seen as sufficient in some contexts (such
as VPN),
but if i am not mistaken, we did not feel this to be acceptable for BRSKI
because
we would not want to be dependent on additional side-channels. But ultimately,
it is
AFAIK not an issue in BRSKI because TLS always includes the full certificate in
a
certificate authentication (But we even went so far that the TLS profile for
BSKI should
contain the trust anchor of the client certificate in the TLS request even
though that
one of course needs to be known/trusted by the recipient upfront anyhow, but it
is
helpful for diagnostics. But in ACP secure channels for example, where IKEv2
offers a
range of options for proof-of-identity, some of them do not carry the full
certificate,
so rfc8994 is explicitly specifying that ACP use of IKEv MUST use the option
that includes
the full certificate.
So: I think the document should be explicit about this. For example, the text
could
also introduce a term "authenticated-show-of-identity" in addition to
"proof-of-identity"
and and then acordingly say that BRSKI-AE mechanisms SHOULD (IMHO ideally MUST)
use
a proof-of-identity that includes authenticated-show-of-identity so that no
additional
side channels are for the authenticating entity to learn the IDevID secret of
the pledge.
This doesn't necessarily have to all go here, but where you feel is most
appropriate
in the docuement (for expediency, i will not try to make that judgment call
now).
350 The rest of this section gives an incomplete list of solution
351 examples, based on existing technology described in IETF documents:
353 3.2. Solution Options for Proof-of-possession
355 Certification request objects: Certification requests are data
356 structures protecting only the integrity of the contained data and
357 providing proof-of-possession for a (locally generated) private key.
358 Examples for certification request data structures are:
360 * PKCS#10 [RFC2986]. This certification request structure is self-
361 signed to protect its integrity and prove possession of the
362 private key that corresponds to the public key included in the
363 request.
365 * CRMF [RFC4211]. Also this certificate request message format
366 supports integrity protection and proof-of-possession, typically
367 by a self-signature generated over (part of) the structure with
368 the private key corresponding to the included public key. CRMF
369 also supports further proof-of-possession methods for types of
370 keys that do not support any signature algorithm.
372 The integrity protection of certification request fields includes the
373 public key because it is part of the data signed by the corresponding
374 private key. Yet note that for the above examples this is not
375 sufficient to provide data origin authentication, i.e., proof-of-
376 identity. This extra property can be achieved by an additional
377 binding to the IDevID of the pledge. This binding to source
378 authentication supports the authorization decision for the
379 certification request. The binding of data origin authentication to
380 the certification request may be delegated to the protocol used for
381 certificate management.
383 3.3. Solution Options for Proof-of-identity
385 The certification request should be bound to an existing
386 authenticated credential (here, the IDevID certificate) to enable a
387 proof of identity and, based on it, an authorization of the
388 certification request. The binding may be achieved through security
389 options in an underlying transport protocol such as TLS if the
390 authorization of the certification request is (completely) done at
391 the next communication hop. This binding can also be done in a
392 transport-independent way by wrapping the certification request with
393 signature employing an existing IDevID. the BRSKI context, this will
394 be the IDevID. This requirement is addressed by existing enrollment
395 protocols in various ways, such as:
397 * EST [RFC7030] utilizes PKCS#10 to encode the certification
398 request. The Certificate Signing Request (CSR) optionally
399 provides a binding to the underlying TLS session by including the
400 tls-unique value in the self-signed PKCS#10 structure. The tls-
401 unique value results from the TLS handshake. Since the TLS
402 handshake includes client authentication and the pledge utilizes
NIT: "client certificate authentication"
Aka: in WebPKI, clients usually do not authenticate with certificate, so
this may be confusing to read with that express statement.
403 its IDevID for it, the proof-of-identity is provided by such a
404 binding to the TLS session. This can be supported using the EST
405 /simpleenroll endpoint. Note that the binding of the TLS
406 handshake to the CSR is optional in EST. As an alternative to
407 binding to the underlying TLS authentication in the transport
408 layer, [RFC7030] sketches wrapping the CSR with a Full PKI Request
409 message using an existing certificate.
411 * SCEP [RFC8894] supports using a shared secret (passphrase) or an
412 existing certificate to protect CSRs based on SCEP Secure Message
413 Objects using CMS wrapping ([RFC5652]). Note that the wrapping
414 using an existing IDevID in SCEP is referred to as renewal. Thus
415 SCEP does not rely on the security of the underlying transfer.
NIT: maybe put "underlying transfer" into terminology and define. I guess
"transport" would
then be a subset of transfer that allows online communications... ?
417 * CMP [RFC4210] supports using a shared secret (passphrase) or an
418 existing certificate, which may be an IDevID credential, to
419 authenticate certification requests via the PKIProtection
420 structure in a PKIMessage. The certification request is typically
421 encoded utilizing CRMF, while PKCS#10 is supported as an
422 alternative. Thus CMP does not rely on the security of the
423 underlying transfer protocol.
425 * CMC [RFC5272] also supports utilizing a shared secret (passphrase)
426 or an existing certificate to protect certification requests,
427 which can be either in CRMF or PKCS#10 structure. The proof-of-
428 identity can be provided as part of a FullCMCRequest, based on CMS
429 [RFC5652] and signed with an existing IDevID secret. Thus CMC
430 does not rely on the security of the underlying transfer protocol.
432 4. Adaptations to BRSKI
434 In order to support alternative enrollment protocols, asynchronous
435 enrollment, and more general system architectures, BRSKI-AE lifts
436 some restrictions of BRSKI [RFC8995]. This way, authenticated self-
NIT: "lift restrictions" sound like the wrong term. Unless you actually have
text
in BRSKI that are restrictions. "Extensions the functionality" ??
437 contained objects such as those described in Section 3 above can be
438 used for certificate enrollment.
440 The enhancements needed are kept to a minimum in order to ensure
441 reuse of already defined architecture elements and interactions. In
442 general, the communication follows the BRSKI model and utilizes the
443 existing BRSKI architecture elements. In particular, the pledge
444 initiates communication with the domain registrar and interacts with
445 the MASA as usual.
447 4.1. Architecture
449 The key element of BRSKI-AE is that the authorization of a
450 certification request MUST be performed based on an authenticated
451 self-contained object. The certification request is bound in a self-
452 contained way to a proof-of-origin based on the IDevID.
MINOR: Need to define proof-of-origin. First time it is used is here.
453 Consequently, the authentication and authorization of the
454 certification request MAY be done by the domain registrar and/or by
455 other domain components. These components may be offline or reside
456 in some central backend of the domain operator (off-site) as
457 described in Section 1.2. The registrar and other on-site domain
458 components may have no or only temporary (intermittent) connectivity
459 to them. The certification request MAY also be piggybacked on
460 another protocol.
462 This leads to generalizations in the placement and enhancements of
463 the logical elements as shown in Figure 1.
465 +------------------------+
466 +--------------Drop-Ship--------------->| Vendor Service |
467 | +------------------------+
468 | | M anufacturer| |
469 | | A uthorized |Ownership|
470 | | S igning |Tracker |
471 | | A uthority | |
472 | +--------------+---------+
473 | ^
474 | |
475 V |
476 +--------+ ......................................... |
477 | | . . | BRSKI-
478 | | . +------------+ +--------------+ . | MASA
479 | Pledge | . | Join | | Domain <-----+
480 | | . | Proxy | | Registrar w/ | .
481 | <-------->............<-----> Enrollment | .
482 | | . | BRSKI-AE | Proxy/LRA/RA | .
483 | IDevID | . | | +--------^-----+ .
484 | | . +------------+ | .
485 | | . | .
486 +--------+ ...............................|.........
487 on-site "domain" components |
488 | e.g., RFC 4210,
489 | RFC 7030, ...
490 .............................................|.....................
491 . +---------------------------+ +--------v------------------+ .
492 . | Public-Key Infrastructure <-----+ Registration Authority | .
493 . | PKI CA +-----> PKI RA | .
494 . +---------------------------+ +---------------------------+ .
495 ...................................................................
496 off-site or central "domain" components
498 Figure 1: Architecture Overview Using Off-site PKI Components
NIT: What do we call what runs between Pledge and Join Proxy ? Put a name
into the picture. If its potentially a differrent set of options from BRSKI-AE
then what is run between join-proxy and Registar, then call it maybe BRSKI-AE(1)
vs BRSKI-AE(2).
500 The architecture overview in Figure 1 has the same logical elements
501 as BRSKI, but with more flexible placement of the authentication and
502 authorization checks on certification requests. Depending on the
503 application scenario, the registrar MAY still do all of these checks
504 (as is the case in BRSKI), or part of them, or none of them.
506 The following list describes the on-site components in the target
507 domain of the pledge shown in Figure 1.
509 * Join Proxy: same functionality as described in BRSKI [RFC8995].
511 * Domain Registrar including RA, LRA, or Enrollment Proxy: in BRSKI-
512 AE, the domain registrar has mostly the same functionality as in
513 BRSKI, namely to facilitate the communication of the pledge with
514 the MASA and the PKI. Yet there are two generalizations.
NIT: LRA first used here without definition. Expand, if necessary explain,
maybe add to glossary.
516 The registrar MAY offer different enrollment protocols. For
517 supporting this, the URI scheme for addressing the domain
518 registrar is generalized (see Section 4.3).
NIT: Put "Enrollment protocol" in the picture, e.g.: above RFC4210, so
that it is clear which part of the picture the text refers to, add
"such as in picture RFC4210/RFC7030". And then something like
"BRSKI-AE enables the use of asynchronous enrolment protocols because it
allows the Pledge to include proof-of-posession (including
authenticated-show-of-posession),
such that the Enrolment protocol does not need to rely on an authenticated
transport connection for its exchange.
MAYOR: The text makes it read as if RFC8995 did not allow the use of different
enrollment protocols. I think this is wrong. For example, i am pretty sure that
it should be possible to build with BRSKI a system that uses SCEP in the
backend.
Without requiring BRSKI-AE.
How about text like this (or similar):
BRSKI-AE extends the URI scheme of BRSKI messages between Pledge, Proxy and
Registrar
so that messages for various suitable enrolment protocols can be encapsulated as
BRKI messages, such as CMP (RFC4280) in Figure 1. The BRSKI encapsulated
messages
are called BRSKI-AE in Figure 1. The Registrar decapsulates these messages and
passes
them to the PKI RA and encapsulates return messages from the PKI RA to send
them towards
Proxy and Pledge as BRSKI encapsulated. Enrollment protocols are suitable, when
this
simple forwarding with encapsulation/decapsulation (tunneling) across the BRSKI
connection
can be supported by the enrolment protocol.
Note that BRSKI already supported (implicity) suitable enrolment protocols, but
only by co-locating Registrar and PKI RA, such that the (IDevID) authentication
of
the Pledge could be known by the PKI RA from the BRSKI TLS connection.
Effectively,
one of the results of BRSKI-AE is that it allows to decouple Registrar and PKI
RA.
520 The registrar MAY also delegate (part of) its certificate
521 enrollment support to a separate system. That is, alternatively
522 to having full RA functionality, the registrar may act as a local
523 registration authority (LRA) or just as an enrollment proxy. In
524 such cases, the domain registrar may forward the certification
525 request to some off-site RA component that performs part of the
526 enrollment authorization. This also covers the case that the
527 registrar has only intermittent connection and forwards
528 certification requests to the RA upon re-established connectivity.
529 Still all certificate enrollment traffic goes via the registrar,
530 such that from the pledge perspective there is no difference in
531 connectivity and the registrar is involved in all steps, including
532 enrollment status telemetry.
534 The following list describes the components provided by the vendor or
535 manufacturer outside the target domain.
537 * MASA: general functionality as described in BRSKI [RFC8995]. The
538 voucher exchange with the MASA via the domain registrar is
539 performed as described in BRSKI.
541 Note: The interaction with the MASA may be synchronous (voucher
542 request with nonce) or asynchronous (voucher request without
543 nonce).
NIT: "Note: BRSKI-MASA, the interaction..."
NIT: should write whether BRSKI-AE extends BRSKI-MASA and if so how. I guess
there
is no extension whatsoever, then rephrase that this synchronous/asynchronous is
already
a property of BRSKI-MASA specified in RFC8995 (a reference to a specific
section would
be lovely here).
545 * Ownership tracker: as defined in BRSKI.
547 The following list describes the target domain components that can
548 optionally be operated in the off-site backend of the target domain.
550 * PKI RA: Performs certificate management functions for the domain
551 as a centralized public-key infrastructure for the domain
552 operator. As far as not already done by the domain registrar, it
553 performs the final validation and authorization of certification
554 requests.
NIT: Is it actually mandatory that the Registrar in this picture connects to the
PKI RA ? Aka: the way you write it, if there is a deployment case where
authentication
and authorization of certificate requests is handled by the Registrar it could
directly
connect to the CA - but it would still be a new BRSKI-AE deployment not
possible
with just RFC8995 in before (aka: enabled trough new BRSKI-AE URIs). Right ?
If this is a correct assesment, this should be written, and the lines in the
picture be
shown with that option.
556 * PKI CA: Performs certificate generation by signing the certificate
557 structure requested in already authenticated and authorized
558 certification requests.
560 Based on the diagram in Section 2.1 of BRSKI [RFC8995] and the
561 architectural changes, the original protocol flow is divided into
562 three phases showing commonalities and differences to the original
563 approach as follows.
565 * Discovery phase: same as in BRSKI steps (1) and (2)
567 * Voucher exchange phase: same as in BRSKI steps (3) and (4).
569 * Enrollment phase: step (5) is changed to employing an alternative
570 enrollment protocol that uses authenticated self-contained
571 objects.
573 4.2. Message Exchange
575 The behavior of a pledge described in Section 2.1 of BRSKI [RFC8995]
576 is kept with one exception. After finishing the Imprint step (4),
577 the Enroll step (5) MUST be performed with an enrollment protocol
578 utilizing authenticated self-contained objects. Section 5 discusses
579 selected suitable enrollment protocols and options applicable.
581 [
582 Cannot render SVG graphics - please view
583 https://raw.githubusercontent.com/anima-wg/anima-brski-ae/main/o.png
584 ]
NIT: Remind me: what is the final verdict re. this SVG graphics. I am pretty
sure
we will not get this document to RFC if we do not have a renderable SVG
graphics.
Is it a matter of converting to greyscale ?
586 Figure 2: BRSKI-AE Abstract Protocol Overview
588 *Pledge - registrar discovery and voucher exchange*
590 The discovery phase and voucher exchange are applied as specified in
591 [RFC8995].
593 *Registrar - MASA voucher exchange*
595 This voucher exchange is performed as specified in [RFC8995].
597 *Pledge - registrar - RA/CA certificate enrollment*
NIT: create a sub-section 4.2.1 for the following text for the certificate
enrolment
and pull up the encrolment status telemetry here, so that the whole description
of Figure 2
is finished here. Right now one gets really confused about the trailing
telemetry text at line 684 that goes back to Figure 2 after all the prior text
that was referring to figure 3 (too muchs stack for human readers).
599 As stated in Section 3, the enrollment MUST be performed using an
600 authenticated self-contained object providing not only proof-of-
601 possession but also proof-of-identity (source authentication).
603 +--------+ +------------+ +------------+
604 | Pledge | | Domain | | Operator |
605 | | | Registrar | | RA/CA |
606 | | | (JRC) | | (PKI) |
607 +--------+ +------------+ +------------+
608 /--> | |
609 [Optional request of CA certificates] | |
610 |---------- CA Certs Request ------------>| |
611 | [if connection to operator domain is available] |
612 | |-- CA Certs Request -->|
613 | |<- CA Certs Response --|
614 |<--------- CA Certs Response ------------| |
615 /--> | |
616 [Optional request of attributes to include in Certificate Request] |
617 |---------- Attribute Request ----------->| |
618 | [if connection to operator domain is available] |
619 | |- Attribute Request -->|
620 | |<- Attribute Response -|
621 |<--------- Attribute Response -----------| |
622 /--> | |
623 [Mandatory certificate request] | |
624 |---------- Certificate Request --------->| |
625 | [if connection to operator domain is available] |
626 | |-Certificate Request ->|
627 | |<- Certificate Resp. --|
628 |<--------- Certificate Response ---------| |
629 /--> | |
630 [Optional certificate confirmation] | |
631 |---------- Certificate Confirm --------->| |
632 | [if connection to operator domain is available] |
633 | |-Certificate Confirm ->|
634 | |<---- PKI Confirm -----|
635 |<--------- PKI/Registrar Confirm --------| |
637 Figure 3: Certificate Enrollment
639 The following list provides an abstract description of the flow
640 depicted in Figure 3.
NIT: There is the repeated notion of "if connection to operator..." which is
not repeated below, so if someone (like i did) try to find an explanation for
this, a simple search won't suffice - and i think there actually is no text
that further details this below.
I would suggest to replace text with MANDATORY Cert request/reply and OPTIONAL
for the others - and add explanations as follow:
For the mandatory certifiate request/reply the explanation should explain
that these messages are send WHEN the connection between the
domain registar/PKI RA/CA is available, and/or through appropriate offline
message transfer (USBnet, sneaker net ?!).
MAYOR: for the optional messages, i would suggest the following text:
Steps described as OPTIONAL in Figure 3 are not necessarily optional
to successfully use BSRKI-AE in any specific deployment for specific Pledges.
For example Registrars supporting [RFC8994] Pledges MUST support CA Certs
Request/Response
as well as Attribute Request/Response and Certificate Confirm. However,
depending on
the target deployment, these functions if they need to be supported by a
Registrar
have different options outside the scope of this specification to be
implemented in a
BRSKI-AE context, such as:
* They may solely be implemented by the Registrar without the PKI backend
involved. For CA Certs Request/Response this would require for example explicit
provisioning of the Certs into the Registrars.
* They may be retrieved from the PKI backend through appropriate means, for
example when a network connection is available - and then cached on the
Registrar.
... I hope this is a correct interpretation on my side. If not, i'd like to
understand
what of this might not work.
Maybe better put this MANDATORY/OPTIONAL text below the following bullet list...
642 * CA Certs Request: The pledge optionally requests the latest
643 relevant CA certificates. This ensures that the pledge has the
644 complete set of current CA certificates beyond the pinned-domain-
645 cert (which is contained in the voucher and may be just the domain
646 registrar certificate).
648 * CA Certs Response: It MUST contain the current root CA
649 certificate, which typically is the LDevID trust anchor, and any
650 additional certificates that the pledge may need to validate
651 certificates.
653 * Attribute Request: Typically, the automated bootstrapping occurs
654 without local administrative configuration of the pledge.
655 Nevertheless, there are cases in which the pledge may also include
656 additional attributes specific to the target domain into the
657 certification request. To get these attributes in advance, the
NIT: Would be lovely if you could add:
For example, see [RFC8994], Section 6.11.7.2 which specifies how the attribute
request
is used to signal to the Pledge the acp-node-name field required for enrolment
into
an ACP domain.
658 attribute request can be used.
660 * Attribute Response: It MUST contain the attributes to be included
661 in the subsequent certification request.
663 * Certificate Request: This certification request MUST contain the
664 authenticated self-contained object ensuring both proof-of-
665 possession of the corresponding private key and proof-of-identity
666 of the requester.
668 * Certificate Response: The certification response message MUST
669 contain on success the requested certificate and MAY include
670 further information, like certificates of intermediate CAs.
672 * Certificate Confirm: An optional confirmation sent after the
673 requested certificate has been received and validated. It
674 contains a positive or negative confirmation by the pledge whether
675 the certificate was successfully enrolled and fits its needs.
677 * PKI/Registrar Confirm: An acknowledgment by the PKI or registrar
678 that MUST be sent on reception of the Cert Confirm.
680 The generic messages described above may be implemented using various
681 enrollment protocols supporting authenticated self-contained objects,
682 as described in Section 3. Examples are available in Section 5.
684 *Pledge - registrar - enrollment status telemetry*
686 The enrollment status telemetry is performed as specified in
687 [RFC8995]. In BRSKI this is described as part of the enrollment
688 phase, but due to the generalization on the enrollment protocol
689 described in this document it fits better as a separate step here.
691 4.3. Enhancements to Addressing Scheme
NIT: "URI Addressing Scheme" ? (i am always thinking of IP address when there
is no further clarification ;-). Also accordingly in the following text.
Especially
because i am not even sure whether "addressing scheme" is correct/preferred, or
just "URI scheme".
693 BRSKI-AE provides generalizations to the addressing scheme defined in
694 BRSKI [RFC8995] to accommodate alternative enrollment protocols that
^
NIT: Please add section you think is authoritative in BRSKI for this statement
695 use authenticated self-contained objects for certification requests.
696 As this is supported by various existing enrollment protocols, they
697 can be directly employed (see also Section 5).
^^^^^^^^
NIT: "employed without modifications to existing PKI RA/CA supporting the
respective
enrolment protocol" ?
...what else could "directly" imply ? write it when there is more.
699 The addressing scheme in BRSKI for certification requests and the
700 related CA certificates and CSR attributes retrieval functions uses
701 the definition from EST [RFC7030], here on the example of simple
702 enrollment: "/.well-known/est/simpleenroll". This approach is
703 generalized to the following notation: "/.well-known/<enrollment-
704 protocol>/<request>" in which <enrollment-protocol> refers to a
705 certificate enrollment protocol. Note that enrollment is considered
706 here a message sequence that contains at least a certification
707 request and a certification response. The following conventions are
708 used in order to provide maximal compatibility to BRSKI:
710 * <enrollment-protocol>: MUST reference the protocol being used,
711 which MAY be CMP, CMC, SCEP, EST [RFC7030] as in BRSKI, or a newly
712 defined approach.
MAYOR: remove the RFC2119 langauge or else we'll have to do the IANA
registration for
the missing protocols CMC and SCEP, which would be hard without having
specifying text.
See https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
e.g.maybe: MUST reference the protocol being used. Existing values inlude EST
[RFC7030]
as in BRSKI and Section 5.1 below and CMP as in
[I-D.ietf-lamps-lightweight-cmp-profile] and
Section 5.2 below. New values for existing protocols such as CMC or SCP or CMC
as
well as newly defined protocols require their own specification for their URI
use
<request> and are outside the scope of this document.
714 Note: additional endpoints (well-known URIs) at the registrar may
715 need to be defined by the enrollment protocol being used.
717 * <request>: if present, this path component MUST describe,
718 depending on the enrollment protocol being used, the operation
719 requested. Enrollment protocols are expected to define their
720 request endpoints, as done by existing protocols (see also
721 Section 5).
723 4.4. Domain Registrar Support of Alternative Enrollment Protocols
725 Well-known URIs for various endpoints on the domain registrar are
726 already defined as part of the base BRSKI specification or indirectly
727 by EST. In addition, alternative enrollment endpoints MAY be
728 supported at the registrar. The pledge will recognize whether its
729 preferred enrollment option is supported by the domain registrar by
730 sending a request to its preferred enrollment endpoint and evaluating
731 the HTTP response status code.
733 The following list of endpoints provides an illustrative example for
734 a domain registrar supporting several options for EST as well as for
735 CMP to be used in BRSKI-AE. The listing contains the supported
736 endpoints to which the pledge may connect for bootstrapping. This
737 includes the voucher handling as well as the enrollment endpoints.
NIT: If this list is something that can be learned by the pledge through some
form
of HTTP based discovery, then it would vbe nice to mention this with a
reference.
Or else some sentence of who/how one would be able to generate this list
738 The CMP-related enrollment endpoints are defined as well-known URIs
739 in CMP Updates [I-D.ietf-lamps-cmp-updates] and the Lightweight CMP
740 profile [I-D.ietf-lamps-lightweight-cmp-profile].
742 </brski/voucherrequest>,ct=voucher-cms+json
743 </brski/voucher_status>,ct=json
744 </brski/enrollstatus>,ct=json
745 </est/cacerts>;ct=pkcs7-mime
746 </est/fullcmc>;ct=pkcs7-mime
747 </est/csrattrs>;ct=pkcs7-mime
748 </cmp/initialization>;ct=pkixcmp
749 </cmp/p10>;ct=pkixcmp
750 </cmp/getcacerts>;ct=pkixcmp
751 </cmp/getcertreqtemplate>;ct=pkixcmp
753 5. Instantiation to Existing Enrollment Protocols
755 This section maps the requirements to support proof-of-possession and
756 proof-of-identity to selected existing enrollment protocols handles
757 provides further aspects of instantiating them in BRSKI-AE.
759 5.1. BRSKI-EST-fullCMC: Instantiation to EST (informative)
MINOR: why is this informative instead of normative ? Some "should" could be
changed
to rfc2119 language ? No strong opinion. If there is a good reason for
informative it
would be great to write it down.
761 When using EST [RFC7030], the following aspects and constraints need
762 to be considered and the given extra requirements need to be
763 fulfilled, which adapt Section 5.9.3 of BRSKI [RFC8995]:
765 * proof-of-possession is provided typically by using the specified
766 PKCS#10 structure in the request. Together with Full PKI
767 requests, also CRMF can be used.
769 * proof-of-identity needs to be achieved by signing the
770 certification request object using the Full PKI Request option
771 (including the /fullcmc endpoint). This provides sufficient
772 information for the RA to authenticate the pledge as the origin of
773 the request and to make an authorization decision on the received
774 certification request. Note: EST references CMC [RFC5272] for the
775 definition of the Full PKI Request. For proof-of-identity, the
776 signature of the SignedData of the Full PKI Request is performed
777 using the IDevID secret of the pledge.
MINOR/Q: And is the full certificate (IDevID) also included ?
779 Note: In this case the binding to the underlying TLS connection is
780 not necessary.
782 * When the RA is temporarily not available, as per Section 4.2.3 of
783 [RFC7030], an HTTP status code 202 should be returned by the
784 registrar, and the pledge will repeat the initial Full PKI Request
^
NIT: ... later ?
786 5.2. BRSKI-CMP: Instantiation to CMP (normative if CMP is chosen)
NIT: s/if CMP is chosen//
Given how this is normative, i was raising the question why the EST section 5.1
is not.
788 Note: Instead of referring to CMP as specified in [RFC4210] and
789 [I-D.ietf-lamps-cmp-updates], this document refers to the Lightweight
790 CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] because the
791 subset of CMP defined there is sufficient for the functionality
792 needed here.
794 When using CMP, the following specific implementation requirements
795 apply (cf. Figure 3).
797 * CA Certs Request
799 - Requesting CA certificates over CMP is OPTIONAL.
800 If supported, it SHALL be implemented as specified in
801 Section 4.3.1 of [I-D.ietf-lamps-lightweight-cmp-profile].
803 * Attribute Request
805 - Requesting certificate request attributes over CMP is OPTIONAL.
806 If supported, it SHALL be implemented as specified in
807 Section 4.3.3 of [I-D.ietf-lamps-lightweight-cmp-profile].
808 Note that alternatively the registrar MAY modify the contents
809 of requested certificate contents as specified in
810 Section 5.2.3.2 of [I-D.ietf-lamps-lightweight-cmp-profile].
812 * Certificate Request
814 - Proof-of-possession SHALL be provided as defined in
815 Section 4.1.1 (based on CRMF) or Section 4.1.4 (based on
816 PKCS#10) of the Lightweight CMP Profile
817 [I-D.ietf-lamps-lightweight-cmp-profile].
818 The caPubs field of certificate response messages SHOULD NOT be
819 used.
821 - Proof-of-identity SHALL be provided by using signature-based
822 protection of the certification request message as outlined in
823 Section 3.2. of [I-D.ietf-lamps-lightweight-cmp-profile] using
824 the IDevID secret.
826 * Certificate Confirm
827 - Explicit confirmation of new certificates to the RA MAY be used
828 as specified in Section 4.1.1 of the Lightweight CMP Profile
829 [I-D.ietf-lamps-lightweight-cmp-profile].
830 Note that independently of certificate confirmation within CMP,
831 enrollment status telemetry with the registrar will be
832 performed as described in Section 5.9.4 of BRSKI [RFC8995].
834 * If delayed delivery of responses (for instance, to support
835 asynchronous enrollment) within CMP is needed, it SHALL be
836 performed as specified in Sections 4.4 and 5.1.2 of
837 [I-D.ietf-lamps-lightweight-cmp-profile].
839 BRSKI-AE with CMP can also be combined with Constrained BRSKI
840 [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
841 message transport as described by CoAP Transport for CMPV2
842 [I-D.msahni-ace-cmpv2-coap-transport]. In this scenario, of course
843 the EST-specific parts of [I-D.ietf-anima-constrained-voucher] do not
844 apply.
846 6. IANA Considerations
848 This document does not require IANA actions.
850 7. Security Considerations
852 The security considerations as laid out in BRSKI [RFC8995] apply for
853 the discovery and voucher exchange as well as for the status exchange
854 information.
856 The security considerations as laid out in the Lightweight CMP
857 Profile [I-D.ietf-lamps-lightweight-cmp-profile] apply as far as CMP
858 is used.
860 8. Acknowledgments
862 We would like to thank Brian E. Carpenter, Michael Richardson, and
863 Giorgio Romanenghi for their input and discussion on use cases and
864 call flows.
866 9. References
868 9.1. Normative References
870 [I-D.ietf-anima-constrained-voucher]
871 Richardson, M., Stok, P. V. D., Kampanakis, P., and E.
872 Dijk, "Constrained Bootstrapping Remote Secure Key
873 Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
874 draft-ietf-anima-constrained-voucher-17, 7 April 2022,
875 <https://www.ietf.org/archive/id/draft-ietf-anima-
876 constrained-voucher-17.txt>.
878 [I-D.ietf-lamps-cmp-updates]
879 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
880 Management Protocol (CMP) Updates", Work in Progress,
881 Internet-Draft, draft-ietf-lamps-cmp-updates-20, 31 May
882 2022, <https://www.ietf.org/archive/id/draft-ietf-lamps-
883 cmp-updates-20.txt>.
885 [I-D.ietf-lamps-lightweight-cmp-profile]
886 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight
887 Certificate Management Protocol (CMP) Profile", Work in
888 Progress, Internet-Draft, draft-ietf-lamps-lightweight-
889 cmp-profile-12, 13 May 2022,
890 <https://www.ietf.org/archive/id/draft-ietf-lamps-
891 lightweight-cmp-profile-12.txt>.
893 [I-D.msahni-ace-cmpv2-coap-transport]
894 Sahni, M. and S. Tripathi, "CoAP Transport for CMPV2",
895 Work in Progress, Internet-Draft, draft-msahni-ace-cmpv2-
896 coap-transport-01, 5 October 2020,
897 <https://www.ietf.org/archive/id/draft-msahni-ace-cmpv2-
898 coap-transport-01.txt>.
900 [IEEE.802.1AR_2009]
901 IEEE, "IEEE Standard for Local and metropolitan area
902 networks - Secure Device Identity", IEEE 802.1AR-2009,
903 DOI 10.1109/ieeestd.2009.5367679, 28 December 2009,
904 <http://ieeexplore.ieee.org/servlet/
905 opac?punumber=5367676>.
907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
908 Requirement Levels", BCP 14, RFC 2119,
909 DOI 10.17487/RFC2119, March 1997,
910 <https://www.rfc-editor.org/info/rfc2119>.
912 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
913 "Internet X.509 Public Key Infrastructure Certificate
914 Management Protocol (CMP)", RFC 4210,
915 DOI 10.17487/RFC4210, September 2005,
916 <https://www.rfc-editor.org/info/rfc4210>.
918 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
919 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
920 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
922 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
923 "A Voucher Artifact for Bootstrapping Protocols",
924 RFC 8366, DOI 10.17487/RFC8366, May 2018,
925 <https://www.rfc-editor.org/info/rfc8366>.
927 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
928 and K. Watsen, "Bootstrapping Remote Secure Key
929 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
930 May 2021, <https://www.rfc-editor.org/info/rfc8995>.
932 9.2. Informative References
934 [IEC-62351-9]
935 International Electrotechnical Commission, "IEC 62351 -
936 Power systems management and associated information
937 exchange - Data and communications security - Part 9:
938 Cyber security key management for power system equipment",
939 IEC 62351-9, May 2017.
941 [ISO-IEC-15118-2]
942 International Standardization Organization / International
943 Electrotechnical Commission, "ISO/IEC 15118-2 Road
944 vehicles - Vehicle-to-Grid Communication Interface - Part
945 2: Network and application protocol requirements", ISO/
946 IEC 15118-2, April 2014.
948 [NERC-CIP-005-5]
949 North American Reliability Council, "Cyber Security -
950 Electronic Security Perimeter", CIP 005-5, December 2013.
952 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1
953 (Draft)", December 2019.
955 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
956 Request Syntax Specification Version 1.7", RFC 2986,
957 DOI 10.17487/RFC2986, November 2000,
958 <https://www.rfc-editor.org/info/rfc2986>.
960 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
961 Certificate Request Message Format (CRMF)", RFC 4211,
962 DOI 10.17487/RFC4211, September 2005,
963 <https://www.rfc-editor.org/info/rfc4211>.
965 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
966 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
967 <https://www.rfc-editor.org/info/rfc5272>.
969 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
970 RFC 5652, DOI 10.17487/RFC5652, September 2009,
971 <https://www.rfc-editor.org/info/rfc5652>.
973 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
974 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
975 <https://www.rfc-editor.org/info/rfc5929>.
977 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
978 "Enrollment over Secure Transport", RFC 7030,
979 DOI 10.17487/RFC7030, October 2013,
980 <https://www.rfc-editor.org/info/rfc7030>.
982 [RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol",
983 RFC 8894, DOI 10.17487/RFC8894, September 2020,
984 <https://www.rfc-editor.org/info/rfc8894>.
986 [UNISIG-Subset-137]
987 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
988 FFFIS; V1.0.0", December 2015,
989 <https://www.era.europa.eu/sites/default/files/filesystem/
990 ertms/ccs_tsi_annex_a_-_mandatory_specifications/
991 set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
992 _subset-137_v100.pdf>.
993 http://www.kmc-subset137.eu/index.php/download/
995 Appendix A. Using EST for Certificate Enrollment
997 When using EST with BRSKI, pledges interact via TLS with the domain
998 registrar, which acts both as EST server and as registration
999 authority (RA). The TLS connection is mutually authenticated, where
NIT: Suggest for consistency to use longer term "PKI registration authority"
throughout document (not only here), but pls. check all places.
1000 the pledge uses its IDevID certificate issued by its manufacturer.
1002 In order to provide a strong proof-of-origin of the certification
1003 request, EST has the option to include in the certification request
1004 the so-called tls-unique value [RFC5929] of the underlying TLS
1005 channel. This binding of the proof-of-identity of the TLS client,
1006 which is supposed to be the certificate requester, to the proof-of-
1007 possession for the private key is conceptually non-trivial and
1008 requires specific support by TLS implementations.
NIT: What benefit does this tls-unique value have anyhow in the case of BRSKI ?
I was reading rfc7030 3.5 and could not figure it out. In BRSKI, the Pledge
authenticates the TLS connection with its IDevID, and the CSR will have the
same public key as the TLS client certificate. Thats already linkage of TLS
proof-of-posession and the identity used for the CSR, right ?
NIT: If the whole porpose of the text here is to just complain about
implementation
complexities of the option, even when it may not only be unclear to me (but also
to the authors), if/why this option would be needed, then maybe just make tht
point stronger, e.g.: Relying on TLS authentication in support such
authenticating
the CSR can have implementation chalenges. For example, in order to provide
... rest of paragraph.
1010 The registrar terminates the security association with the pledge at
1011 TLS level and thus the binding between the certification request and
1012 the authentication of the pledge. The EST server uses the
1013 authenticated pledge identity provided by the IDevID for checking the
1014 authorization of the pledge for the given certification request
1015 before issuing to the pledge a domain-specific certificate (LDevID
1016 certificate). This approach typically requires online or on-site
NIT: I think this text is not precise, and it only describes one possible
option.
It is not entierly clear to me why the text picks this one option, would be
good to
know why so that the text could maybe motivate this explanation better by
writing why.
Let me guess and suggest text here:
The registrar terminates the security association with the pledge at
TLS level and thus the binding between the certification request and
the authentication of the pledge. In RFC8995 BRSKI, the registrar would
typically double as the PKI-RA and also authenticate the CSR, filtering/denying
requests from non-authorized pledges. In BRSKI-AE the Registrar would
typically not employ this level of policy operation, because it is intended
to be an unmanaged device. Instead, it connects to the PKI-RA, which will
perform the authorization, and which then passes on the CSR to the PKI CA
thast will issue the domain-specific certificate (LDevID).
1016 certificate). This approach typically requires online or on-site
1017 availability of the RA for performing the final authorization
1018 decision for the certification request.
NIT: I don't think this is true and also a bit vague (no explicit restating
where
exactly EST is used). How about:
Because in this setup, the protocol between the on-site Registrar and the
remote PKI-RA
is EST, this approach requires online or at least intermittent connectivity
between Registrar
and PKI-RA.
1020 Using EST for BRSKI has the advantage that the mutually authenticated
^^^^^^^^^^^^^^^^^^^
NIT: "Using EST for BRSKI between Pledge, Proxy and Register".
1021 TLS connection established between the pledge and the registrar can
1022 be reused for protecting the message exchange needed for enrolling
1023 the LDevID certificate. This strongly simplifies the implementation
1024 of the enrollment message exchange.
NIT: This paragraph seems to open a new point separate from the prior text which
was more i think about the Registrar/PKI-RA connection. This one is about the
Pledge/Proxy/Registrar TLS connection.
a) Maybe reorder and move this upfront.
b) Maybe create a bullet or numbered list for these different points that this
section
makes to better separate them (or any other form of better separation).
1026 Yet the use of TLS has the limitation that this cannot provide
1027 auditability nor end-to-end security for the certificate enrollment
NIT: s/end-to-end security/Pledge to PKI-RA/CA authentication/
NIT: would like to see some example/explanation of "auditability". E.g.: When
CMP is being used (as an alternative), is a good amount of the CSR payload just
authenticated (via signatures), but not encrypted ? Then one way to refine
would be:
Comparing EST and CMP, the latter could more easily be audited because logs
of CSR can easily be third-party authenticated, whereas TLS connections can not.
(but maybe there are other similar, but better explanations/examples).
1028 request because the TLS session is transient and terminates at the
1029 registrar. This is a problem in particular if the enrollment is done
1030 via multiple hops, part of which may not even be network-based.
NIT: Suggest to add the IMHO strongest point:
Furthermore, the BRSKI Registrars in each site have to be hardened so that they
can be trusted to be the TLS initiator of the EST connection to the PKI-RA/CA,
and in result, their keying material needs to be managed with more security
care than that of
other Pledges because of that trusted requirement, for example they need to
have the id-kp-cmcRA extended key usage attribute according to [RFC7030], see
[RFC6402].
Impairment to a BRSKI Registrar can result in arbtrary many fake certificate
registrations.
1032 A further limitation of using EST as the certificate enrollment
1033 protocol is that due to using PKCS#10 structures in enrollment
1034 requests, the only possible proof-of-possession method is a self-
1035 signature, which excludes requesting certificates for key types that
1036 do not support signing.
NIT: Would be good to give an example (or point to an example) of what
alternative
option enabled by BRSKI-AE would solve this, i guess CMP, but with what type of
Pledge
credential ?
1038 Appendix B. Application Examples
1040 This informative annex provides some detail to the application
1041 examples listed in Section 1.3.
1043 B.1. Rolling Stock
1045 Rolling stock or railroad cars contain a variety of sensors,
1046 actuators, and controllers, which communicate within the railroad car
1047 but also exchange information between railroad cars building a train,
1048 with track-side equipment, and/or possibly with backend systems.
1049 These devices are typically unaware of backend system connectivity.
1050 Managing certificates may be done during maintenance cycles of the
1051 railroad car, but can already be prepared during operation.
1052 Preparation will include generating certification requests, which are
1053 collected and later forwarded for processing, once the railroad car
1054 is connected to the operator backend. The authorization of the
1055 certification request is then done based on the operator's asset/
1056 inventory information in the backend.
1058 UNISIG has included a CMP profile for enrollment of TLS certificates
NIT: What is a TLS certificate ? RFC5820 certificate ? Aka: pls add reference.
1059 of on-board and track-side components in the Subset-137 specifying
1060 the ETRAM/ETCS on-line key management for train control systems
1061 [UNISIG-Subset-137].
1063 B.2. Building Automation
1065 In building automation scenarios, a detached building or the basement
1066 of a building may be equipped with sensors, actuators, and
1067 controllers that are connected with each other in a local network but
1068 with only limited or no connectivity to a central building management
1069 system. This problem may occur during installation time but also
1070 during operation. In such a situation a service technician collects
1071 the necessary data and transfers it between the local network and the
1072 central building management system, e.g., using a laptop or a mobile
1073 phone. This data may comprise parameters and settings required in
1074 the operational phase of the sensors/actuators, like a component
1075 certificate issued by the operator to authenticate against other
1076 components and services.
1078 The collected data may be provided by a domain registrar already
1079 existing in the local network. In this case connectivity to the
1080 backend PKI may be facilitated by the service technician's laptop.
1081 Alternatively, the data can also be collected from the pledges
1082 directly and provided to a domain registrar deployed in a different
1083 network as preparation for the operational phase. In this case,
1084 connectivity to the domain registrar may also be facilitated by the
1085 service technician's laptop.
1087 B.3. Substation Automation
1089 In electrical substation automation scenarios, a control center
1090 typically hosts PKI services to issue certificates for Intelligent
1091 Electronic Devices (IEDs) operated in a substation. Communication
1092 between the substation and control center is performed through a
1093 proxy/gateway/DMZ, which terminates protocol flows. Note that
1094 [NERC-CIP-005-5] requires inspection of protocols at the boundary of
1095 a security perimeter (the substation in this case). In addition,
1096 security management in substation automation assumes central support
1097 of several enrollment protocols in order to support the various
1098 capabilities of IEDs from different vendors. The IEC standard
NIT: If you just google "wiki IED" you get "Improvised Explosive Devices"
(which was also my first thought). Suggest to expand term.
Also, general note:
https://www.rfc-editor.org/materials/abbrev.expansion.txt
Check all abbreviations used how they are covered in that document:
-> if your abbreviation exissts but with different expansion than you want,
only use the abbreviation if its pre-established or you feel strongly that
you want to introduce a new semantic for such an existing abbreviation.
add note to RFFC eitor to add this abbreviation semantic to the document.
-> if they have a (*) in the doc, you can choose not to expand on first use.
otherwise always expand abbreviation on first use.
1099 IEC62351-9 [IEC-62351-9] specifies mandatory support of two
1100 enrollment protocols: SCEP [RFC8894] and EST [RFC7030] for the
1101 infrastructure side, while the IED must only support one of the two.
1103 B.4. Electric Vehicle Charging Infrastructure
1105 For electric vehicle charging infrastructure, protocols have been
1106 defined for the interaction between the electric vehicle and the
1107 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
1108 between the charging point and the charging point operator (e.g.
1109 OCPP [OCPP]). Depending on the authentication model, unilateral or
1110 mutual authentication is required. In both cases the charging point
1111 uses an X.509 certificate to authenticate itself in TLS connections
1112 between the electric vehicle and the charging point. The management
1113 of this certificate depends, among others, on the selected backend
1114 connectivity protocol. In the case of OCPP, this protocol is meant
1115 to be the only communication protocol between the charging point and
1116 the backend, carrying all information to control the charging
1117 operations and maintain the charging point itself. This means that
1118 the certificate management needs to be handled in-band of OCPP. This
1119 requires the ability to encapsulate the certificate management
1120 messages in a transport-independent way. Authenticated self-
1121 containment will support this by allowing the transport without a
1122 separate enrollment protocol, binding the messages to the identity of
1123 the communicating endpoints.
1125 B.5. Infrastructure Isolation Policy
1127 This refers to any case in which network infrastructure is normally
1128 isolated from the Internet as a matter of policy, most likely for
1129 security reasons. In such a case, limited access to external PKI
1130 services will be allowed in carefully controlled short periods of
1131 time, for example when a batch of new devices is deployed, and
1132 forbidden or prevented at other times.
1134 B.6. Sites with Insufficient Level of Operational Security
1136 The registration authority performing (at least part of) the
1137 authorization of a certification request is a critical PKI component
1138 and therefore requires higher operational security than components
1139 utilizing the issued certificates for their security features. CAs
1140 may also demand higher security in the registration procedures.
NIT: unclear what this means. "From the Registrar ?" , or on the CA itself ?
1141 Especially the CA/Browser forum currently increases the security
1142 requirements in the certificate issuance procedures for publicly
1143 trusted certificates. In case the on-site components of the target
NIT: What is a publicly trusted certificate, reference ? Sounds like higher bars
fo Web PKI certificates (aka: those pound to domain names). Not quite clear
how this is applicable to on-site registrars.
1143 trusted certificates. In case the on-site components of the target
1144 domain cannot be operated securely enough for the needs of a
1145 registration authority, this service should be transferred to an off-
1146 site backend component that has a sufficient level of security.
1148 Appendix C. History of Changes TBD RFC Editor: please delete
1150 From IETF draft 01 -> IETF draft 02:
1152 * Architecture: clarify registrar role including RA/LRA/enrollment
1153 proxy
1155 * CMP: add reference to CoAP Transport for CMPV2 and Constrained
1156 BRSKI
1158 From IETF draft 05 -> IETF draft ae-01:
1160 * Renamed the repo and files from anima-brski-async-enroll to anima-
1161 brski-ae
1163 * Added graphics for abstract protocol overview as suggested by
1164 Toerless Eckert
1166 * Balanced (sub-)sections and their headers
1168 * Added details on CMP instance, now called BRSKI-CMP
1170 From IETF draft 04 -> IETF draft 05:
1172 * David von Oheimb became the editor.
1174 * Streamline wording, consolidate terminology, improve grammar, etc.
1176 * Shift the emphasis towards supporting alternative enrollment
1177 protocols.
1179 * Update the title accordingly - preliminary change to be approved.
1181 * Move comments on EST and detailed application examples to
1182 informative annex.
1184 * Move the remaining text of section 3 as two new sub-sections of
1185 section 1.
1187 From IETF draft 03 -> IETF draft 04:
1189 * Moved UC2-related parts defining the pledge in responder mode to a
1190 separate document. This required changes and adaptations in
1191 several sections. Main changes concerned the removal of the
1192 subsection for UC2 as well as the removal of the YANG model
1193 related text as it is not applicable in UC1.
1195 * Updated references to the Lightweight CMP Profile.
1197 * Added David von Oheimb as co-author.
1199 From IETF draft 02 -> IETF draft 03:
1201 * Housekeeping, deleted open issue regarding YANG voucher-request in
1202 UC2 as voucher-request was enhanced with additional leaf.
1204 * Included open issues in YANG model in UC2 regarding assertion
1205 value agent-proximity and CSR encapsulation using SZTP sub
1206 module).
1208 From IETF draft 01 -> IETF draft 02:
1210 * Defined call flow and objects for interactions in UC2. Object
1211 format based on draft for JOSE signed voucher artifacts and
1212 aligned the remaining objects with this approach in UC2 .
1214 * Terminology change: issue #2 pledge-agent -> registrar-agent to
1215 better underline agent relation.
1217 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
1218 and pledge-responder-mode to better address the pledge operation.
1220 * Communication approach between pledge and registrar-agent changed
1221 by removing TLS-PSK (former section TLS establishment) and
1222 associated references to other drafts in favor of relying on
1223 higher layer exchange of signed data objects. These data objects
1224 are included also in the pledge-voucher-request and lead to an
1225 extension of the YANG module for the voucher-request (issue #12).
1227 * Details on trust relationship between registrar-agent and
1228 registrar (issue #4, #5, #9) included in UC2.
1230 * Recommendation regarding short-lived certificates for registrar-
1231 agent authentication towards registrar (issue #7) in the security
1232 considerations.
1234 * Introduction of reference to agent signing certificate using SKID
1235 in agent signed data (issue #11).
1237 * Enhanced objects in exchanges between pledge and registrar-agent
1238 to allow the registrar to verify agent-proximity to the pledge
1239 (issue #1) in UC2.
1241 * Details on trust relationship between registrar-agent and pledge
1242 (issue #5) included in UC2.
1244 * Split of use case 2 call flow into sub sections in UC2.
1246 From IETF draft 00 -> IETF draft 01:
1248 * Update of scope in Section 1.2 to include in which the pledge acts
1249 as a server. This is one main motivation for use case 2.
1251 * Rework of use case 2 to consider the transport between the pledge
1252 and the pledge-agent. Addressed is the TLS channel establishment
1253 between the pledge-agent and the pledge as well as the endpoint
1254 definition on the pledge.
1256 * First description of exchanged object types (needs more work)
1258 * Clarification in discovery options for enrollment endpoints at the
1259 domain registrar based on well-known endpoints in Section 4.4 do
1260 not result in additional /.well-known URIs. Update of the
1261 illustrative example. Note that the change to /brski for the
1262 voucher-related endpoints has been taken over in the BRSKI main
1263 document.
1265 * Updated references.
1267 * Included Thomas Werner as additional author for the document.
1269 From individual version 03 -> IETF draft 00:
1271 * Inclusion of discovery options of enrollment endpoints at the
1272 domain registrar based on well-known endpoints in Section 4.4 as
1273 replacement of section 5.1.3 in the individual draft. This is
1274 intended to support both use cases in the document. An
1275 illustrative example is provided.
1277 * Missing details provided for the description and call flow in
1278 pledge-agent use case UC2, e.g. to accommodate distribution of CA
1279 certificates.
1281 * Updated CMP example in Section 5 to use Lightweight CMP instead of
1282 CMP, as the draft already provides the necessary /.well-known
1283 endpoints.
1285 * Requirements discussion moved to separate section in Section 3.
1286 Shortened description of proof of identity binding and mapping to
1287 existing protocols.
1289 * Removal of copied call flows for voucher exchange and registrar
1290 discovery flow from [RFC8995] in Section 4 to avoid doubling or
1291 text or inconsistencies.
1293 * Reworked abstract and introduction to be more crisp regarding the
1294 targeted solution. Several structural changes in the document to
1295 have a better distinction between requirements, use case
1296 description, and solution description as separate sections.
1297 History moved to appendix.
1299 From individual version 02 -> 03:
1301 * Update of terminology from self-contained to authenticated self-
1302 contained object to be consistent in the wording and to underline
1303 the protection of the object with an existing credential. Note
1304 that the naming of this object may be discussed. An alternative
1305 name may be attestation object.
1307 * Simplification of the architecture approach for the initial use
1308 case having an offsite PKI.
1310 * Introduction of a new use case utilizing authenticated self-
1311 contain objects to onboard a pledge using a commissioning tool
1312 containing a pledge-agent. This requires additional changes in
1313 the BRSKI call flow sequence and led to changes in the
1314 introduction, the application example,and also in the related
1315 BRSKI-AE call flow.
1317 * Update of provided examples of the addressing approach used in
1318 BRSKI to allow for support of multiple enrollment protocols in
1319 Section 4.3.
1321 From individual version 01 -> 02:
1323 * Update of introduction text to clearly relate to the usage of
1324 IDevID and LDevID.
1326 * Definition of the addressing approach used in BRSKI to allow for
1327 support of multiple enrollment protocols in Section 4.3. This
1328 section also contains a first discussion of an optional discovery
1329 mechanism to address situations in which the registrar supports
1330 more than one enrollment approach. Discovery should avoid that
1331 the pledge performs a trial and error of enrollment protocols.
1333 * Update of description of architecture elements and changes to
1334 BRSKI in Section 4.1.
1336 * Enhanced consideration of existing enrollment protocols in the
1337 context of mapping the requirements to existing solutions in
1338 Section 3 and in Section 5.
1340 From individual version 00 -> 01:
1342 * Update of examples, specifically for building automation as well
1343 as two new application use cases in Appendix B.
1345 * Deletion of asynchronous interaction with MASA to not complicate
1346 the use case. Note that the voucher exchange can already be
1347 handled in an asynchronous manner and is therefore not considered
1348 further. This resulted in removal of the alternative path the
1349 MASA in Figure 1 and the associated description in Section 4.1.
1351 * Enhancement of description of architecture elements and changes to
1352 BRSKI in Section 4.1.
1354 * Consideration of existing enrollment protocols in the context of
1355 mapping the requirements to existing solutions in Section 3.
1357 * New section starting Section 5 with the mapping to existing
1358 enrollment protocols by collecting boundary conditions.
1360 Authors' Addresses
1362 David von Oheimb (editor)
1363 Siemens AG
1364 Otto-Hahn-Ring 6
1365 81739 Munich
1366 Germany
1367 Email: [email protected]
1368 URI: https://www.siemens.com/
1370 Steffen Fries
1371 Siemens AG
1372 Otto-Hahn-Ring 6
1373 81739 Munich
1374 Germany
1375 Email: [email protected]
1376 URI: https://www.siemens.com/
1378 Hendrik Brockhaus
1379 Siemens AG
1380 Otto-Hahn-Ring 6
1381 81739 Munich
1382 Germany
1383 Email: [email protected]
1384 URI: https://www.siemens.com/
1385 Eliot Lear
1386 Cisco Systems
1387 Richtistrasse 7
1388 CH-8304 Wallisellen
1389 Switzerland
1390 Phone: +41 44 878 9200
1391 Email: [email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
