[Anima] draft-ietf-anim-brski-ae-08 review (was: Re: I-D Action: draft-ietf-anima-brski-ae-09.txt)

[Toerless Eckert <[e-mail]>]

Attached just for the record the review of draft-ietf-anima-brski-ae-08 that lead to -08.
All issues have nicely been resolved in -09, will now post shepherd writeup.

Thanks a lot
    Toerless

>From eckert Tue Dec  5 16:42:31 2023
Date: Tue, 5 Dec 2023 16:42:31 +0100
To: [e-mail]
Subject: Pre: review of draft-ietf-anima-brski-ae-08
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
rom: Toerless Eckert <[e-mail]>
Status: RO
Content-Length: 92164
Lines: 1927


pre-post to authors, final will go to list.

main two issues which we can hopefully sort out in todays call.
  - title name change 
  - removal of 624-629

Cheers
    Toerless

---
Dear BRSKI-AE authors

Thank you very much for this work. This review is part of the documents
Shepherd review, in which i will refer to this text and which i'll post soon

I think the document is in very good shape with just very few issue left which
i think are easy to fix. Sorry for requesting some knucklehead formalisms,
but they are going to be helpful to novices in the field who will read the RFC.

I will refrain from trying to proof-read the english except for few to me
seemingly obvious cases because i am not a native english speaker either.

Format is idnits.

---

draft-ietf-anima-brski-ae-08.txt:
  == Missing Reference: 'LCMPP' is mentioned on line 465, but not defined

  == Outdated reference: draft-ietf-ace-cmpv2-coap-transport has been
     published as RFC 9482



2	ANIMA WG                                              D. von Oheimb, Ed.
3	Internet-Draft                                                  S. Fries
4	Intended status: Standards Track                            H. Brockhaus
5	Expires: 2 June 2024                                             Siemens
6	                                                        30 November 2023

8	          BRSKI-AE: Alternative Enrollment Protocols in BRSKI
9	                      draft-ietf-anima-brski-ae-08

11	Abstract

13	   This document defines an enhancement of Bootstrapping Remote Secure
14	   Key Infrastructure (BRSKI, RFC 8995) that supports alternative
15	   certificate enrollment protocols, such as CMP.  This offers the
16	   following advantages.

Major: 

During IETF/IESG review of what became RFC9262, we had a reviewer who did not like the
target name "Traffic Engineering for BIER" (because of ultimately not too shabby arguments),
so we had to have a re-naming contest in the WG and finally renamed it to "Tree Engineering".

Now, when i look at "Alternative Enrollment" protocols and read the text, even this abstract,
then i am thinking that a significant part of the text is about those protocols having to
support authenticate self-contained signed objects. Which does really not become clear
from the title and name "alternative". Alternative for example could also describe 
a protocol which like EST does NOT meet the the requirements that this document
defines as MUST

So: How about renaming this document to "Advantageous Enrollment Protocols in BRSKI",
and simply define "advantageous" to be protocols supporting "authenticated self-contained signed objects".
Which pretty much is what this document does anyhow - already in this abstract. 

Aka: Change title, add sentence making it clear this document defines advantageous to
men supporting authenticated self-contained signed objects", go through the text, replace
all instances of "alternative" with "advantageous" (unless there is a reason in specific
instances not to - but i don't think there is such an instance).

18	   Using authenticated self-contained signed objects for certification
19	   requests and responses, their origin can be authenticated
20	   independently of message transfer.  This supports end-to-end
21	   authentication (proof of origin) also over multiple hops, as well as
22	   asynchronous operation of certificate enrollment.  This in turn
23	   provides architectural flexibility where to ultimately authenticate

s/where/where and when/ ??

24	   and authorize certification requests while retaining full-strength
25	   integrity and authenticity of certification requests.

27	About This Document

29	   This note is to be removed before publishing as an RFC.

31	   Status information for this document may be found at
32	   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.

34	   Source for this draft and an issue tracker can be found at
35	   https://github.com/anima-wg/anima-brski-ae.

37	Status of This Memo

39	   This Internet-Draft is submitted in full conformance with the
40	   provisions of BCP 78 and BCP 79.

42	   Internet-Drafts are working documents of the Internet Engineering
43	   Task Force (IETF).  Note that other groups may also distribute
44	   working documents as Internet-Drafts.  The list of current Internet-
45	   Drafts is at https://datatracker.ietf.org/drafts/current/.

47	   Internet-Drafts are draft documents valid for a maximum of six months
48	   and may be updated, replaced, or obsoleted by other documents at any
49	   time.  It is inappropriate to use Internet-Drafts as reference
50	   material or to cite them other than as "work in progress."

52	   This Internet-Draft will expire on 2 June 2024.

54	Copyright Notice

56	   Copyright (c) 2023 IETF Trust and the persons identified as the
57	   document authors.  All rights reserved.

59	   This document is subject to BCP 78 and the IETF Trust's Legal
60	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
61	   license-info) in effect on the date of publication of this document.
62	   Please review these documents carefully, as they describe your rights
63	   and restrictions with respect to this document.  Code Components
64	   extracted from this document must include Revised BSD License text as
65	   described in Section 4.e of the Trust Legal Provisions and are
66	   provided without warranty as described in the Revised BSD License.

68	Table of Contents

70	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
71	     1.1.  Supported Scenarios . . . . . . . . . . . . . . . . . . .   4
72	     1.2.  List of Application Examples  . . . . . . . . . . . . . .   5
73	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
74	   3.  Basic Requirements and Mapping to Solutions . . . . . . . . .   7
75	     3.1.  Solution Options for Proof of Possession  . . . . . . . .   7
76	     3.2.  Solution Options for Proof of Identity  . . . . . . . . .   8
77	   4.  Adaptations to BRSKI  . . . . . . . . . . . . . . . . . . . .   9
78	     4.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  10
79	     4.2.  Message Exchange  . . . . . . . . . . . . . . . . . . . .  14
80	       4.2.1.  Pledge - Registrar Discovery  . . . . . . . . . . . .  14
81	       4.2.2.  Pledge - Registrar - MASA Voucher Exchange  . . . . .  14
82	       4.2.3.  Pledge - Registrar - MASA Voucher Status Telemetry  .  15
83	       4.2.4.  Pledge - Registrar - RA/CA Certificate Enrollment . .  15
84	       4.2.5.  Pledge - Registrar Enrollment Status Telemetry  . . .  18
85	     4.3.  Enhancements to the Endpoint Addressing Scheme of
86	           BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . .  18
87	   5.  Instantiation to Existing Enrollment Protocols  . . . . . . .  20
88	     5.1.  BRSKI-CMP: Instantiation to CMP . . . . . . . . . . . . .  20
89	     5.2.  Support of Other Enrollment Protocols . . . . . . . . . .  22
90	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
91	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
92	   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
93	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
94	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
95	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
96	   Appendix A.  Application Examples . . . . . . . . . . . . . . . .  27
97	     A.1.  Rolling Stock . . . . . . . . . . . . . . . . . . . . . .  27
98	     A.2.  Building Automation . . . . . . . . . . . . . . . . . . .  27
99	     A.3.  Substation Automation . . . . . . . . . . . . . . . . . .  28
100	     A.4.  Electric Vehicle Charging Infrastructure  . . . . . . . .  28
101	     A.5.  Infrastructure Isolation Policy . . . . . . . . . . . . .  29
102	     A.6.  Sites with Insufficient Level of Operational Security . .  29
103	   Appendix B.  History of Changes TBD RFC Editor: please delete . .  29
104	   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  38
105	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

107	1.  Introduction

109	   BRSKI [RFC8995] is typically used with EST as the enrollment protocol

Please expand on first use (EAFU) every "normal" abbreviation e.g. here "Enrollment over Secure Transport",
and provide a reference for it if it exists (e.g.: RFC7030 here). Reference should also be included
in the terminology definition of abbreviations.

A normal abbreviation is one which does not have a "*" after it in:

https://www.rfc-editor.org/materials/abbrev.expansion.txt

Those with "*" are considered well-known and don't require expansion or references
as far as RFC Editor is concerned. E.g.: HTTP or TLS. Security experts may still
ask you for version numbers of TLS and references for it, but you can let that be
a problem of SEC AD review.

If you use an abbreviation that is not in the abbreviation list, please make
a remark for RFC editor to consider adding it if you think it's important enough.
If you think there is a specific abbreviation that should be marked as well-known,
you can also have that argument with RFC-Editor, likely during AUTH48 (aka: some time
away).

(This whole knucklehead details about abbreviations and references brought to you
 with kudos to Brian Carpenter, who made me a fan when he asked me for all the same
 in RFC8994 ;-))

110	   for device certificates employing HTTP over TLS for its message
111	   transfer.  BRSKI-AE is a variant using alternative enrollment
112	   protocols with authenticated self-contained objects for device
113	   certificate enrollment.

115	   This specification carries over the main characteristics of BRSKI,
116	   namely:

118	   *  The pledge is assumed to have got IDevID credentials during its

s/got/received/

EOFU: IDevID, reference is 802.1AR,


119	      production.  It uses them to authenticate itself to the MASA, the

reference for MASA: RFC8995

120	      Manufacturer Authorized Signing Authority, and to the registrar,
121	      the access point of the target domain, and to possibly further
122	      components of the domain where it will be operated.

124	   *  The pledge first obtains via the voucher exchange a trust anchor

voucher [RFC8366]

125	      for authenticating entities in the domain such as the domain
126	      registrar.

128	   *  The pledge then generates a device private key, called the LDevID

EOFU: LDevID, reference 802.1AR

129	      secret, and obtains a domain-specific device certificate, called
130	      the LDevID certificate, along with its certificate chain.

132	   The goals of BRSKI-AE are to provide an enhancement of BRSKI for
133	   LDevID certificate enrollment using, alternatively to EST, a protocol
134	   that

136	   *  supports end-to-end authentication over multiple hops

138	   *  enables secure message exchange over any kind of transfer,
139	      including asynchronous delivery.

141	   Note: The BRSKI voucher exchange of the pledge with the registrar and
142	   MASA uses authenticated self-contained objects, so the voucher
143	   exchange already has these properties.

145	   The well-known URI approach of BRSKI and EST messages is extended
146	   with an additional path element indicating the enrollment protocol
147	   being used.

149	   Based on the definition of the overall approach and specific
150	   endpoints, this specification enables the registrar to offer multiple
151	   enrollment protocols, from which pledges and their developers can
152	   then pick the most suitable one.

154	   Note: BRSKI (RFC 8995) specifies how to use HTTP over TLS, but
155	   further variants are known, such as Constrained BRSKI
156	   [I-D.ietf-anima-constrained-voucher] using CoAP over DTLS.  In the
157	   sequel, 'HTTP' and 'TLS' are just references to the most common case,
158	   where variants such as using CoAP and/or DTLS are meant to be
159	   subsumed - the differences are not relevant here.

minor:  suggest to add text like the following to make the scope of the document clearer.

  This specification is sufficient together with its references
  to support BRSKI with Lightweight CMP Profile (LCMPP) [RFC9483]. Combining
  BRSKI with a protocol or profile other than LCMPP will require additional IANA
  registrations based on the rules specified in this document. It may also
  require additional protocol specifications for details of the protocol/profile
  (similar to [RFC9483]), which are outside the scope of this document.


161	1.1.  Supported Scenarios

163	   BRSKI-AE is intended to be used situations like the following.

165	   *  pledges and/or the target domain reusing an already established
166	      certificate enrollment protocol different from EST, such as CMP

EOFU, reference: CMP

Whow, CMP is not in RFC editor list. Shame on SEC area, please get that fixed.
LCMPP  neither. E.g.: find place at the end , add [RFC-Editor]: please add 
CMP, ..., LCMPP, ... to RFC-editor abbreviations list - This should have been
caught during RFC9483 ;-)

168	   *  scenarios indirectly excluding the use of EST for certificate
169	      enrollment, such as:

171	      -  the RA not being co-located with the registrar while requiring

EAFU: RA, not sure which reference

172	         end-to-end authentication of requesters, which EST does not
173	         support over multiple hops

175	      -  the RA or CA operator requiring auditable proof of origin of

EAFU: CA, not sure which reference.

176	         CSRs, which is not possible neither with the transient source
177	         authentication provided by TLS.

179	      -  certificate requests for types of keys that do not support
180	         signing, such as KEM and key agreement keys, which is not

EAFU: KEM

181	         supported by EST because it uses PKCS#10 CSRs expecting proof-

EAFU: PKCS#10, CSR...

182	         of-possession via a self-signature

184	      -  pledge implementations using security libraries not providing
185	         EST support or a TLS library that does not support providing
186	         the so-called tls-unique value [RFC5929] needed by EST for
187	         strong binding of the source authentication

189	   *  no full RA functionality being available on-site in the target
190	      domain, while connectivity to an off-site RA may be intermittent
191	      or entirely offline.

193	   *  authoritative actions of a local RA at the registrar being not
194	      sufficient for fully and reliably authorizing pledge certification
195	      requests, which may be due to missing data access or due to an
196	      insufficient level of security, for instance regarding the local
197	      storage of private keys

199	1.2.  List of Application Examples

201	   Bootstrapping can be handled in various ways, depending on the
202	   application domains.  The informative Appendix A provides
203	   illustrative examples from various industrial control system
204	   environments and operational setups.  They motivate the support of
205	   alternative enrollment protocols, based on the following examples of
206	   operational environments:

208	   *  rolling stock

210	   *  building automation

212	   *  electrical substation automation

214	   *  electric vehicle charging infrastructures

216	   *  infrastructure isolation policy

218	   *  sites with insufficient level of operational security

220	2.  Terminology

222	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
223	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
224	   "OPTIONAL" in this document are to be interpreted as described in
225	   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
226	   capitals, as shown here.

228	   This document relies on the terminology defined in [RFC8995],
229	   [RFC5280], and [IEEE_802.1AR-2018].  The following terms are
230	   described partly in addition.

232	   asynchronous communication:  time-wise interrupted delivery of
233	      messages, here between a pledge and the registrar or an RA

235	   authenticated self-contained object:  data structure that is
236	      cryptographically bound to the identity of its originator by an
237	      attached digital signature on the actual object, using a private
238	      key of the originator such as the IDevID secret.

240	   backend:  placement of a domain component separately from the domain
241	      registrar; may be on-site or off-site

243	   BRSKI-AE:  BRSKI with *A*lternative *E*nrollment, a variation of
244	      BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol
245	      between pledge and the registrar, is replaced by enrollment
246	      protocols that support end-to-end authentication of the pledge to
247	      the RA, such as Lightweight CMP.

249	   local RA (LRA):  a subordinate RA that is close to entities being
250	      enrolled and separate from a subsequent RA.  In BRSKI-AE it is
251	      needed if a backend RA is used, and in this case the LRA is co-
252	      located with the registrar.

254	   LCMPP:  Lightweight CMP Profile [RFC9483]

256	   on-site:  locality of a component or service or functionality at the
257	      site of the registrar

259	   off-site:  locality of component or service or functionality, such as
260	      RA or CA, not at the site of the registrar.  This may be a central
261	      site or a cloud service, to which connection may be intermittent.

263	   pledge:  device that is to be bootstrapped to a target domain.  It
264	      requests an LDevID, a Locally significant Device IDentifier, using
265	      IDevID credentials installed by its manufacturer.

267	   RA:  Registration Authority, the PKI component to which a CA
268	      typically delegates certificate management functions such as
269	      authenticating pledges and performing authorization checks on
270	      certification requests

272	   registrar:  short for domain registrar

274	   site:  the locality where an entity, such as a pledge, registrar, or
275	      PKI component is deployed.  The target domain may have multiple
276	      sites.

278	   synchronous communication:  time-wise uninterrupted delivery of
279	      messages, here between a pledge and a registrar or PKI component

281	   target domain:  the domain that a pledge is going to be bootstrapped
282	      to

s/to/into/

284	3.  Basic Requirements and Mapping to Solutions

286	   Based on the intended target scenarios described in Section 1.1 and
287	   the application examples described in Appendix A, the following
288	   requirements are derived to support authenticated self-contained
289	   objects as containers carrying certification requests.

291	   At least the following properties are required for a certification
292	   request:

294	   *  Proof of possession: demonstrates access to the private key
295	      corresponding to the public key contained in a certification
296	      request.  This is typically achieved by a self-signature using the
297	      corresponding private key but can also be achieved indirectly, see
298	      [RFC4210], Section 4.3.

300	   *  Proof of identity, also called proof of origin: provides data
301	      origin authentication of the certification request.  Typically
302	      this is achieved by a signature using the pledge IDevID secret
303	      over some data, which needs to include a sufficiently strong
304	      identifier of the pledge, such as the device serial number
305	      typically included in the subject of the IDevID certificate.

307	   The rest of this section gives an non-exhaustive list of solution
308	   examples, based on existing technology described in IETF documents:

310	3.1.  Solution Options for Proof of Possession

312	   Certificate signing request (CSR) objects: CSRs are data structures
313	   protecting only the integrity of the contained data and providing
314	   proof of possession for a (locally generated) private key.  Important
315	   types of CSR data structures are:

317	   *  PKCS#10 [RFC2986].  This very common form of CSR is self-signed to
318	      protect its integrity and to prove possession of the private key
319	      that corresponds to the public key included in the request.


321	   *  CRMF [RFC4211].  This less common but more general CSR format

EAFU CRMF

322	      supports several ways of integrity protection and proof of
323	      possession- Typically a self-signature is used generated over
324	      (part of) the structure with the private key corresponding to the
325	      included public key.  CRMF also supports further proof-of-
326	      possession methods for types of keys that do not have signing
327	      capability.  For details see [RFC4211], Section 4.

329	   Note: The integrity protection of CSRs includes the public key
330	   because it is part of the data signed by the corresponding private
331	   key.  Yet this signature does not provide data origin authentication,
332	   i.e., proof of identity of the requester because the key pair
333	   involved is fresh.

335	3.2.  Solution Options for Proof of Identity

337	   Binding a certificate signing request (CSR) to an existing
338	   authenticated credential (the BRSKI context, the IDevID certificate)
339	   enables proof of origin, which in turn supports an authorization
340	   decision on the CSR.

342	   The binding of data origin authentication to the CSR is typically
343	   delegated to the protocol used for certificate management.  This
344	   binding may be achieved through security options in an underlying
345	   transport protocol such as TLS if the authorization of the
346	   certification request is (sufficiently) done at the next
347	   communication hop.  Depending on the key type, the binding can also
348	   be done in a stronger, transport-independent way by wrapping the CSR
349	   with a signature.

351	   This requirement is addressed by existing enrollment protocols in
352	   various ways, such as:

354	   *  EST [RFC7030], also its variant EST-coaps [RFC9148], utilizes
355	      PKCS#10 to encode Certificate Signing Requests (CSRs).  While such
356	      a CSR was not designed to include a proof of origin, there is a
357	      limited, indirect way of binding it to the source authentication
358	      of the underlying TLS session.  This is achieved by including in
359	      the CSR the tls-unique value [RFC5929] resulting from the TLS
360	      handshake.  As this is optionally supported by the EST
361	      "/simpleenroll" endpoint used in BRSKI and the TLS handshake
362	      employed in BRSKI includes certificate-based client authentication
363	      of the pledge with its IDevID credentials, the proof of pledge
364	      identity being an authenticated TLS client can be bound to the
365	      CSR.

367	      Yet this binding is only valid in the context of the TLS session
368	      established with the registrar acting as the EST server and
369	      typically also as an RA.  So even such a cryptographic binding of
370	      the authenticated pledge identity to the CSR is not visible nor
371	      verifiable to authorization points outside the registrar, such as
372	      a RA in the backend.  What the registrar must do is to

s/a/a (second)/ ??
(because you start explaning the initial registrar is also RA.)

373	      authenticate and pre-authorize the pledge and to indicate this to
374	      the RA by signing the forwarded certificate request with its

s/RA/(second) RA/ ?

375	      private key and a related certificate that has the id-kp-cmcRA
376	      extended key usage attribute.

378	      [RFC7030], Section 2.5 sketches wrapping PKCS#10-formatted CSRs
379	      with a Full PKI Request message sent to the "/fullcmc" endpoint.
380	      This would allow for source authentication at message level, such
381	      that the registrar could forward it to external RAs in a
382	      meaningful way.  This approach is so far not sufficiently
383	      described and likely has not been implemented.

385	   *  SCEP [RFC8894] supports using a shared secret (passphrase) or an
386	      existing certificate to protect CSRs based on SCEP Secure Message
387	      Objects using CMS wrapping ([RFC5652]).  Note that the wrapping
388	      using an existing IDevID in SCEP is referred to as 'renewal'.
389	      This way SCEP does not rely on the security of the underlying
390	      message transfer.

392	   *  CMP [RFC4210] supports using a shared secret (passphrase) or an
393	      existing certificate, which may be an IDevID credential, to
394	      authenticate certification requests via the PKIProtection
395	      structure in a PKIMessage.  The certification request is typically
396	      encoded utilizing CRMF, while PKCS#10 is supported as an
397	      alternative.  Thus, CMP does not rely on the security of the
398	      underlying message transfer.

400	   *  CMC [RFC5272] also supports utilizing a shared secret (passphrase)
401	      or an existing certificate to protect certification requests,
402	      which can be either in CRMF or PKCS#10 structure.  The proof of
403	      identity can be provided as part of a FullCMCRequest, based on CMS
404	      [RFC5652] and signed with an existing IDevID secret.  Thus also
405	      CMC does not rely on the security of the underlying message
406	      transfer.

This would be a place for a quick summary stating that EST does not meet the
advantageous requirements of this document, but CMP, CMC and SCEP do meet them, and maybe
another sentence to say why this document primarily focusses on specifying
details for LCMPP ?

408	4.  Adaptations to BRSKI

410	   To enable using alternative certificate enrollment protocols
411	   supporting end-to-end authentication, asynchronous enrollment, and
412	   more general system architectures, BRSKI-AE provides some
413	   generalizations on BRSKI [RFC8995].  This way, authenticated self-
414	   contained objects such as those described in Section 3 above can be
415	   used for certificate enrollment, and RA functionality can be
416	   distributed freely in the target domain.

418	   The enhancements needed are kept to a minimum in order to ensure
419	   reuse of already defined architecture elements and interactions.  In
420	   general, the communication follows the BRSKI model and utilizes the
421	   existing BRSKI architecture elements.  In particular, the pledge
422	   initiates communication with the domain registrar and interacts with
423	   the MASA as usual for voucher request and response processing.

425	4.1.  Architecture

427	   The key element of BRSKI-AE is that the authorization of a
428	   certification request MUST be performed based on an authenticated
429	   self-contained object.  The certification request is bound in a self-
430	   contained way to a proof of origin based on the IDevID credentials.
431	   Consequently, the certification request may be transferred using any
432	   mechanism or protocol.  Authentication and authorization of the
433	   certification request can be done by the domain registrar and/or by
434	   backend domain components.  As mentioned in Section 1.1, these
435	   components may be offline or off-site.  The registrar and other on-
436	   site domain components may have no or only temporary (intermittent)
437	   connectivity to them.

439	   This leads to generalizations in the placement and enhancements of
440	   the logical elements as shown in Figure 1.

442	                                            +------------------------+
443	      +--------------Drop-Ship------------->| Vendor Service         |
444	      |                                     +------------------------+
445	      |                                     | M anufacturer|         |
446	      |                                     | A uthorized  |Ownership|
447	      |                                     | S igning     |Tracker  |
448	      |                                     | A uthority   |         |
449	      |                                     +--------------+---------+
450	      |                                                      ^
451	      |                                                      |
452	      V                                                      |
453	   +--------+     .........................................  |
454	   |        |     .                                       .  | BRSKI-
455	   |        |     .  +-------+          +--------------+  .  | MASA
456	   | Pledge |     .  | Join  |          | Domain       |<----+
457	   |        |<------>| Proxy |<-------->| Registrar w/ |  .
458	   |        |     .  |.......|          | LRA or RA    |  .
459	   | IDevID |     .  +-------+          +--------------+  .
460	   |        |   BRSKI-AE over TLS                ^        .
461	   +--------+   using, e.g., [LCMPP]             |        .
462	                  .                              |        .
463	                  ...............................|.........
464	               on-site (local) domain components |
465	                                                 | e.g., [LCMPP]
466	                                                 |
467	    .............................................|..................
468	    . Public-Key Infrastructure                  v                 .
469	    . +---------+     +------------------------------------------+ .
470	    . |         |<----+   Registration Authority                 | .
471	    . |    CA   +---->|   RA (unless part of Domain Registrar)   | .
472	    . +---------+     +------------------------------------------+ .
473	    ................................................................
474	            backend (central or off-site) domain components

476	        Figure 1: Architecture Overview Using Backend PKI Components

478	   The architecture overview in Figure 1 has the same logical elements
479	   as BRSKI, but with more flexible placement of the authentication and
480	   authorization checks on certification requests.  Depending on the
481	   application scenario, the registrar MAY still do all of these checks
482	   (as is the case in BRSKI), or part of them.

484	   The following list describes the on-site components in the target
485	   domain of the pledge shown in Figure 1.

487	   *  Join Proxy: same functionality as described in BRSKI [RFC8995],
488	      Section 4

490	   *  Domain Registrar including LRA or RA functionality: in BRSKI-AE,
491	      the domain registrar has mostly the same functionality as in
492	      BRSKI, namely to act as the gatekeeper of the domain for
493	      onboarding new devices and to facilitate the communication of
494	      pledges with their MASA and the domain PKI.  Yet there are some
495	      generalizations and specific requirements:

497	      1.  The registrar MUST support at least one certificate enrollment
498	          protocol with authenticated self-contained objects for
499	          certification requests.  To this end, the URI scheme for
500	          addressing endpoints at the registrar is generalized (see
501	          Section 4.3).

503	      2.  Rather than having full RA functionality, the registrar MAY
504	          act as a local registration authority (LRA) and delegate part
505	          of its involvement in certificate enrollment to a backend RA,
506	          called RA.  In such scenarios the registrar optionally checks
507	          certification requests it receives from pledges and forwards
508	          them to the RA.  The RA performs the remaining parts of the
509	          enrollment request validation and authorization.  Note that to
510	          this end the RA may need information regarding the
511	          authorization of pledges from the registrar or from other
512	          sources.  On the way back, the registrar forwards responses by
513	          the PKI to the pledge on the same channel.

515	          Note: In order to support end-to-end authentication of the
516	          pledge across the registrar to the RA, the certification
517	          request structure signed by the pledge needs to be retained by
518	          the registrar, and the registrar cannot use for its
519	          communication with the PKI a enrollment protocol different to
520	          the one used by the pledge.

522	      3.  The use of a certificate enrollment protocol with
523	          authenticated self-contained objects gives freedom how to
524	          transfer enrollment messages between pledge and RA.
525	          Regardless how this transfer is protected and how messages are
526	          routed, also in case that the RA is not part of the registrar
527	          it MUST be guaranteed, like in BRSKI, that the RA accepts
528	          certification requests for LDevIDs only with the consent of
529	          the registrar.  See Section 7 for details how this can be
530	          achieved.

532	   Despite of the above generalizations to the enrollment phase, the
533	   final step of BRSKI, namely the enrollment status telemetry, is kept
534	   as it is.

536	   The following list describes the components provided by the vendor or
537	   manufacturer outside the target domain.

539	   *  MASA: functionality as described in BRSKI [RFC8995].  The voucher
540	      exchange with the MASA via the domain registrar is performed as
541	      described in BRSKI.

543	      Note: From the definition of the interaction with the MASA in
544	      [RFC8995], Section 5 follows that it may be synchronous (using
545	      voucher request with nonces) or asynchronous (using nonceless
546	      voucher requests).

548	   *  Ownership tracker: as defined in BRSKI.

550	   The following list describes backend target domain components, which
551	   may be located on-site or off-site in the target domain.

553	   *  RA: performs centralized certificate management functions as a
554	      public-key infrastructure for the domain operator.  As far as not
555	      already done by the domain registrar, it performs the final
556	      validation and authorization of certification requests.
557	      Otherwise, the RA co-located with the domain registrar directly
558	      connects to the CA.

560	   *  CA, also called domain CA: generates domain-specific certificates
561	      according to certification requests that have been authenticated
562	      and authorized by the registrar and/or and an extra RA.

564	   Based on the diagram in BRSKI [RFC8995], Section 2.1 and the
565	   architectural changes, the original protocol flow is divided into
566	   several phases showing commonalities and differences to the original
567	   approach as follows.

569	   *  Discovery phase: mostly as in BRSKI step (1).  For details see
570	      Section 4.2.1.

572	   *  Identification phase: same as in BRSKI step (2).

574	   *  Voucher exchange phase: same as in BRSKI steps (3) and (4).

576	   *  Voucher status telemetry: same as in BRSKI directly after step
577	      (4).

579	   *  Certificate enrollment phase: the use of EST in step (5) is
580	      changed to employing a certificate enrollment protocol that uses
581	      an authenticated self-contained object for requesting the LDevID
582	      certificate.

584	      For transporting the certificate enrollment request and response
585	      messages, the (D)TLS channel established between pledge and
586	      registrar is RECOMMENDED to use.  To this end, the enrollment
587	      protocol, the pledge, and the registrar need to support the usage
588	      of the existing channel for certificate enrollment.  Due to this
589	      recommended architecture, typically the pledge does not need to
590	      establish additional connections for certificate enrollment and
591	      the registrar retains full control over the certificate enrollment
592	      traffic.

594	   *  Enrollment status telemetry: the final exchange of BRSKI step (5).

596	4.2.  Message Exchange

598	   The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is
599	   kept, with one major exception.  After finishing the Imprint step
600	   (4), the Enroll step (5) MUST be performed with an enrollment
601	   protocol utilizing authenticated self-contained objects, as explained
602	   in Section 3.  Section 5 discusses selected suitable enrollment
603	   protocols and options applicable.

605	   An abstract overview of the BRSKI-AE protocol can be found at
606	   [BRSKI-AE-overview].

608	4.2.1.  Pledge - Registrar Discovery

610	   Discovery as specified in BRSKI [RFC8995], Section 4 does not support
611	   discovery of registrars with enhanced feature sets.  A pledge cannot
612	   find out in this way whether discovered registrars support the
613	   certificate enrollment protocol it expects, such as CMP.

615	   As a more general solution, the BRSKI discovery mechanism can be
616	   extended to provide upfront information on the capabilities of
617	   registrars.  Future work such as [I-D.eckert-anima-brski-discovery]
618	   may provide this.

620	   In the absence of such a generally applicable solution, BRSKI-AE
621	   deployments may use their particular way of doing discovery.
622	   Section 5.1 defines a minimalist approach that MAY be used for CMP.

624	   In controlled environments where the specific BRSKI features required
625	   by pledges and the features supported by the registrar(s) are known
626	   and considered during engineering, also the following optimistic
627	   approach MAY be followed.  Each pledge simply assumes that all
628	   registrars involved support BRSKI-AE with the enrollment protocol(s)
629	   that it requires.

I thought the conclusion of our IETF118 side meeting was to remove paragraph 624 - 629
in favor of the text from 620-622/section 5.1 for brski-lcmpp. 

Aka: please remove 624-629.

But Feel free to add after 622:

  Similar approaches may be used for other advantageous enrollment protocols.

Aka: Whenever someone wants to use another protocol like SCEP or CMC, and brski-discovery
is not ready then, they'd need to specify a new service name. No big deal. Just
not scalable or preferred.



631	4.2.2.  Pledge - Registrar - MASA Voucher Exchange

633	   The voucher exchange is performed as specified in [RFC8995].

635	4.2.3.  Pledge - Registrar - MASA Voucher Status Telemetry

637	   The voucher status telemetry is performed as specified in [RFC8995],
638	   Section 5.7.

640	4.2.4.  Pledge - Registrar - RA/CA Certificate Enrollment

642	   This replaces the EST integration for PKI bootstrapping described in
643	   [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
644	   final phase, see below).

646	   The certificate enrollment phase may involve transmission of several
647	   messages.  Details can depend on the application scenario, the
648	   employed enrollment protocol, and other factors.

650	   The only message exchange REQUIRED is for the actual certificate
651	   request and response.  Further message exchanges MAY be performed as
652	   needed.

654	   Note: The message exchanges marked OPTIONAL in the below Figure 2
655	   cover all those supported by the use of EST in BRSKI.  The last
656	   OPTIONAL one, namely certificate confirmation, is not supported by
657	   EST, but by CMP and other enrollment protocols.

659	   +--------+                        +------------+       +------------+
660	   | Pledge |                        | Domain     |       | Operator   |
661	   |        |                        | Registrar  |       | RA/CA      |
662	   |        |                        |  (JRC)     |       | (PKI)      |
663	   +--------+                        +------------+       +------------+
664	    |                                         |                       |
665	    |  [OPTIONAL request of CA certificates]  |                       |
666	    |--------- CA Certs Request (1) --------->|                       |
667	    |                                         | [OPTIONAL forwarding] |
668	    |                                         |---CA Certs Request -->|
669	    |                                         |<--CA Certs Response---|
670	    |<-------- CA Certs Response (2) ---------|                       |
671	    |                                         |                       |
672	    |  [OPTIONAL request of attributes        |                       |
673	    |   to include in Certificate Request]    |                       |
674	    |--------- Attribute Request (3) -------->|                       |
675	    |                                         | [OPTIONAL forwarding] |
676	    |                                         |--- Attribute Req. --->|
677	    |                                         |<-- Attribute Resp. ---|
678	    |<-------- Attribute Response (4) --------|                       |
679	    |                                         |                       |
680	    |  [REQUIRED certificate request]         |                       |
681	    |--------- Certificate Request (5) ------>|                       |
682	    |                                         | [OPTIONAL forwarding] |
683	    |                                         |--- Certificate Req.-->|
684	    |                                         |<--Certificate Resp.---|
685	    |<-------- Certificate Response (6) ------|                       |
686	    |                                         |                       |
687	    |  [OPTIONAL certificate confirmation]    |                       |
688	    |--------- Certificate Confirm (7) ------>|                       |
689	    |                                         | [OPTIONAL forwarding] |
690	    |                                         |---Certificate Conf.-->|
691	    |                                         |<---- PKI Confirm -----|
692	    |<-------- PKI/Registrar Confirm (8) -----|                       |

694	                      Figure 2: Certificate Enrollment

696	   Note: Connections between the registrar and the PKI components of the
697	   operator (RA, CA, etc.) may be intermittent or off-line.  Messages
698	   should be sent as soon as sufficient transfer capacity is available.

700	   The label [OPTIONAL forwarding] in Figure 2 means that on receiving
701	   from a pledge a request message of the given type, the registrar MAY
702	   answer the request directly itself.  In this case, it MUST
703	   authenticate its responses with the same credentials as used for
704	   authenticating itself at TLS level for the voucher exchange.
705	   Otherwise the registrar MUST forward the request to the RA and
706	   forward any resulting response back to the pledge.

708	   Note: The decision whether to forward a request or to answer it
709	   directly can depend on various static and dynamic factors.  They
710	   include the application scenario, the capabilities of the registrar
711	   and of the local RA possibly co-located with the registrar, the
712	   enrollment protocol being used, and the specific contents of the
713	   request.

715	   Note: There are several options how the registrar could be able to
716	   directly answer requests for CA certificates or for certificate
717	   request attributes.  It could cache responses obtained from the
718	   domain PKI and later use their contents for responding to requests
719	   asking for the same data.  The contents could also be explicit
720	   provisioned at the registrar.

722	   Note: Certificate requests typically need to be handled by the
723	   backend PKI, but the registrar can answer them directly with an error
724	   response in case it determines that such a request should be
725	   rejected, for instance because is not properly authenticated or not
726	   authorized.
727	   Also certificate confirmation messages will usually be forwarded to
728	   the backend PKI, but if the registrar knows that they are not needed
729	   or wanted there it can acknowledge such messages directly.

731	   The following list provides an abstract description of the flow
732	   depicted in Figure 2.

734	   *  CA Certs Request (1): The pledge optionally requests the latest
735	      relevant CA certificates.  This ensures that the pledge has the
736	      complete set of current CA certificates beyond the pinned-domain-
737	      cert (which is contained in the voucher and may be just the domain
738	      registrar certificate).

740	   *  CA Certs Response (2): This MUST contain any intermediate CA
741	      certificates that the pledge may need to validate certificates and
742	      MAY contain the LDevID trust anchor.

744	   *  Attribute Request (3): Typically, the automated bootstrapping
745	      occurs without local administrative configuration of the pledge.
746	      Nevertheless, there are cases in which the pledge may also include
747	      additional attributes specific to the target domain into the
748	      certification request.  To get these attributes in advance, the
749	      attribute request may be used.

751	      For example, [RFC8994], Section 6.11.7.2 specifies how the
752	      attribute request is used to signal to the pledge the acp-node-
753	      name field required for enrollment into an ACP domain.

755	   *  Attribute Response (4): This MUST contain the attributes to be
756	      included in the subsequent certification request.

758	   *  Certificate Request (5): This MUST contain the authenticated self-
759	      contained object ensuring both proof of possession of the
760	      corresponding private key and proof of identity of the requester.

762	   *  Certificate Response (6): This MUST contain on success the
763	      requested certificate and MAY include further information, like
764	      certificates of intermediate CAs and any additional trust anchors.

766	   *  Certificate Confirm (7): An optional confirmation sent after the
767	      requested certificate has been received and validated.  If sent,
768	      it MUST contain a positive or negative confirmation by the pledge
769	      to the PKI whether the certificate was successfully enrolled and
770	      fits its needs.

772	   *  PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST
773	      be sent on reception of the Cert Confirm.

775	   The generic messages described above may be implemented using any
776	   certificate enrollment protocol that supports authenticated self-
777	   contained objects for the certificate request as described in
778	   Section 3.  Examples are available in Section 5.

780	   Note that the optional certificate confirmation by the pledge to the
781	   PKI described above is independent of the mandatory enrollment status
782	   telemetry done between the pledge and the registrar in the final
783	   phase of BRSKI-AE, described next.

785	4.2.5.  Pledge - Registrar Enrollment Status Telemetry

787	   The enrollment status telemetry is performed as specified in
788	   [RFC8995], Section 5.9.4.

790	   In BRSKI this is described as part of the certificate enrollment
791	   step, but due to the generalization on the enrollment protocol
792	   described in this document its regarded as a separate phase here.

794	4.3.  Enhancements to the Endpoint Addressing Scheme of BRSKI

796	   BRSKI-AE provides generalizations to the addressing scheme defined in
797	   BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
798	   protocols that use authenticated self-contained objects for
799	   certification requests.  As this is supported by various existing
800	   enrollment protocols, they can be employed without modifications to
801	   existing RAs/CAs supporting the respective enrollment protocol (see
802	   also Section 5).

804	   The addressing scheme in BRSKI for certification requests and the
805	   related CA certificates and CSR attributes retrieval functions uses
806	   the definition from EST [RFC7030], here on the example of simple
807	   enrollment: "/.well-known/est/simpleenroll".  This approach is
808	   generalized to the following notation: "/.well-known/<enrollment-
809	   protocol>/<request>" in which <enrollment-protocol> refers to a
810	   certificate enrollment protocol.  Note that enrollment is considered
811	   here a message sequence that contains at least a certification
812	   request and a certification response.  The following conventions are
813	   used to provide maximal compatibility with BRSKI:

815	   *  <enrollment-protocol>: MUST reference the protocol being used.
816	      Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as
817	      in [RFC9483] and Section 5.1 below.  Values for other existing
818	      protocols such as CMC and SCEP, or for newly defined protocols are
819	      outside the scope of this document.  For use of the <enrollment-
820	      protocol> and <request> URI components, they would need to

s/to/to be/

821	      specified in a suitable RFC and placed into the Well-Known URIs
822	      registry, like done for EST in [RFC7030].

s/like done/as/

824	   *  <request>: if present, this path component MUST describe,
825	      depending on the enrollment protocol being used, the operation
826	      requested.  Enrollment protocols are expected to define their
827	      request endpoints, as done by existing protocols (see also
828	      Section 5).

830	   Well-known URIs for various endpoints on the domain registrar are
831	   already defined as part of the base BRSKI specification or indirectly
832	   by EST.  In addition, alternative enrollment endpoints MAY be
833	   supported at the registrar.

835	   A pledge SHOULD use the endpoints defined for the enrollment
836	   protocol(s) that it is capable of and is willing to use.  It will
837	   recognize whether its preferred protocol or the request that it tries
838	   to perform is understood and supported by the domain registrar by
839	   sending a request to its preferred enrollment endpoint according to
840	   the above addressing scheme and evaluating the HTTP status code in
841	   the response.  If the pledge uses endpoints that are not
842	   standardized, it risks that the registrar does not recognize and
843	   accept them even if supporting the intended protocol and operation.

845	   The following list of endpoints provides an illustrative example for
846	   a domain registrar supporting several options for EST as well as for
847	   CMP to be used in BRSKI-AE.  The listing contains the supported
848	   endpoints to which the pledge may connect for bootstrapping.  This
849	   includes the voucher handling as well as the enrollment endpoints.
850	   The CMP-related enrollment endpoints are defined as well-known URIs
851	   in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483].

853	     /.well-known/brski/voucherrequest
854	     /.well-known/brski/voucher_status
855	     /.well-known/brski/enrollstatus
856	     /.well-known/est/cacerts
857	     /.well-known/est/csrattrs
858	     /.well-known/est/fullcmc
859	     /.well-known/cmp/getcacerts
860	     /.well-known/cmp/getcertreqtemplate
861	     /.well-known/cmp/initialization
862	     /.well-known/cmp/p10

864	5.  Instantiation to Existing Enrollment Protocols

866	   This section maps the generic requirements to support proof of
867	   possession and proof of identity to selected existing certificate
868	   enrollment protocols and specifies further aspects of using such
869	   enrollment protocols in BRSKI-AE.

871	5.1.  BRSKI-CMP: Instantiation to CMP

873	   Instead of referring to CMP as specified in [RFC4210] and [RFC9480],
874	   this document refers to the Lightweight CMP Profile (LCMPP) [RFC9483]
875	   because the subset of CMP defined there is sufficient for the
876	   functionality needed here.

878	   When using CMP, adherence to the LCMPP [RFC9483] is REQUIRED.  In
879	   particular, the following specific requirements apply (cf.
880	   Figure 2).

882	   *  CA Certs Request (1) and Response (2):
883	      Requesting CA certificates over CMP is OPTIONAL.
884	      If supported, it SHALL be implemented as specified in [RFC9483],
885	      Section 4.3.1.

887	   *  Attribute Request (3) and Response (4):
888	      Requesting certificate request attributes over CMP is OPTIONAL.
889	      If supported, it SHALL be implemented as specified in [RFC9483],
890	      Section 4.3.3.

892	      Alternatively, the registrar MAY modify the contents of requested
893	      certificate contents as specified in [RFC9483], Section 5.2.3.2.

895	   *  Certificate Request (5) and Response (6):
896	      Certificates SHALL be requested and provided as specified in the
897	      LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483],
898	      Section 4.1.4 (based on PKCS#10).

900	      Proof of possession SHALL be provided in a way suitable for the
901	      key type.  Proof of identity SHALL be provided by signature-based
902	      protection of the certification request message as outlined in
903	      [RFC9483], Section 3.2 using the IDevID secret.

905	      Note: When the registrar forwards a certification request by the
906	      pledge to a backend RA, the registrar is recommended to wrap the
907	      original certification request in a nested message signed with its
908	      own credentials as described in [RFC9483], Section 5.2.2.1.  This
909	      explicitly conveys the consent by the registrar to the RA while
910	      retaining the certification request with its proof of origin
911	      provided by the pledge signature.

913	      In case additional trust anchors (besides the pinned-domain-cert)
914	      need to be conveyed to the pledge, this SHOULD be done in the
915	      caPubs field of the certificate response message rather than in a
916	      CA Certs Response.

918	   *  Certificate Confirm (7) and PKI/Registrar Confirm (8):
919	      Explicit confirmation of new certificates to the RA/CA MAY be used
920	      as specified in [RFC9483], Section 4.1.1.

922	      Note: Independently of certificate confirmation within CMP,
923	      enrollment status telemetry with the registrar will be performed
924	      as described in BRSKI [RFC8995], Section 5.9.4.

926	   *  If delayed delivery of responses (for instance, to support
927	      asynchronous enrollment) within CMP is needed, it SHALL be
928	      performed as specified in Section 4.4 and Section 5.1.2 of
929	      [RFC9483].

931	   Note: The way in which messages are exchanged between the registrar
932	   and backend PKI components (i.e., RA or CA) is out of scope of this
933	   document.  Due to the general independence of CMP of message
934	   transfer, it can be freely chosen according to the needs of the
935	   application scenario (e.g., using HTTP), while security
936	   considerations apply, see Section 7, and guidance can be found in
937	   [RFC9483], Section 6.

939	   BRSKI-AE with CMP can also be combined with Constrained BRSKI
940	   [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
941	   message transport as described by CoAP Transport for CMP
942	   [I-D.ietf-ace-cmpv2-coap-transport].  In this scenario, of course the
943	   EST-specific parts of [I-D.ietf-anima-constrained-voucher] do not
944	   apply.

946	   For BRSKI-AE scenarios where a general solution (cf.  Section 4.2.1)
947	   for discovering registrars with CMP support is not available, the
948	   following minimalist approach MAY be used.  Perform discovery as
949	   defined in BRSKI [RFC8995], Appendix B but using the service name
950	   "brski-registrar-cmp" (defined in Section 6) instead of "brski-
951	   registrar" (defined in [RFC8995], Section 8.6).  Note that this
952	   approach does not support join proxies.

954	5.2.  Support of Other Enrollment Protocols

956	   Further instantiations of BRSKI-AE can be done.  They are left for
957	   future work.

959	   In particular, CMC [RFC5272] (using its in-band source authentication
960	   options) and SCEP [RFC8894] (using its 'renewal' option) could be
961	   used.

963	   The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might
964	   also be used here.  For EST-fullCMC further specification is
965	   necessary.

967	6.  IANA Considerations

969	   This document requires one IANA action: register in the Service Name
970	   and Transport Protocol Port Number Registry
971	   (https://www.iana.org/assignments/service-names-port-numbers/service-
972	   names-port-numbers.xhtml) the following service name.

974	   *Service Name:* brski-registrar-cmp
975	   *Transport Protocol(s):* tcp
976	   *Assignee:* IESG [e-mail] (mailto:[e-mail])
977	   *Contact:* IESG [e-mail] (mailto:[e-mail])
978	   *Description:* Bootstrapping Remote Secure Key Infrastructure
979	   registrar with CMP capabilities

Please change the name to brski-registrar-lcmpp and the explanation
accordingly to "...registrar with LCMPP profile [RFC9483]"

980	   *Reference:* [THISRFC]

982	7.  Security Considerations

984	   The security considerations laid out in BRSKI [RFC8995] apply for the
985	   discovery and voucher exchange as well as for the status exchange
986	   information.

988	   In particular, even if the registrar delegates part or all of its RA
989	   role during certificate enrollment to a separate system, it still
990	   must be made sure that the registrar takes part in the decision on
991	   accepting or declining a request to join the domain, as required in
992	   [RFC8995], Section 5.3.  As this pertains also to obtaining a valid
993	   domain-specific certificate, it must be made sure that a pledge
994	   cannot circumvent the registrar in the decision whether it is granted
995	   an LDevID certificate by the CA.  There are various ways how to
996	   fulfill this, including:

998	   *  implicit consent

1000	   *  the registrar signals its consent to the RA out-of-band before or
1001	      during the enrollment phase, for instance by entering the pledge
1002	      identity in a database.

1004	   *  the registrar provides its consent using an extra message that is
1005	      transferred on the same channel as the enrollment messages,
1006	      possibly in a TLS tunnel.

1008	   *  the registrar explicitly states its consent by signing, in
1009	      addition to the pledge, the authenticated self-contained
1010	      certificate enrollment request message.

1012	   Note: If EST was used, the registrar could give implicit consent on a
1013	   certification request by forwarding the request to a PKI entity using
1014	   a connection authenticated with a certificate containing an id-kp-
1015	   cmcRA extension.

1017	   When CMP is used, the security considerations laid out in the LCMPP
1018	   [RFC9483] apply.

1020	   Note that CMP messages are not encrypted.  This may give
1021	   eavesdroppers insight on which devices are bootstrapped in the
1022	   domain, and this in turn might also be used to selectively block the
1023	   enrollment of certain devices.  To prevent this, the underlying
1024	   message transport channel can be encrypted, for instance by employing
1025	   TLS.  On the link between the pledge and the registrar this is easily
1026	   achieved by reusing the existing TLS channel between them.

1028	8.  Acknowledgments

1030	   We thank Eliot Lear for his contributions as a co-author at an
1031	   earlier draft stage.

1033	   We thank Brian E.  Carpenter, Michael Richardson, and Giorgio
1034	   Romanenghi for their input and discussion on use cases and call
1035	   flows.

1037	   Moreover, we thank Toerless Eckert, Barry Leiba, Michael Richardson,
1038	   Rajeev Ranjan, and Rufus Buschart for their reviews with suggestions
1039	   for improvements.

Btw: I have started for my latest drafts to put the role under which review was done into parenthesis,
helps others to checkmark what type of reviews have been done, e.g.: Barry Leiba (SECdir review).
Haven't finished any RFC with that approach yet, so maybe someone will find a process reason to
remove such parenthesis again, but just wanted to give the suggestion (ignore if you like).


1041	9.  References
1042	9.1.  Normative References

1044	   [IEEE_802.1AR-2018]
1045	              IEEE, "IEEE Standard for Local and Metropolitan Area
1046	              Networks - Secure Device Identity", IEEE 802.1AR-2018,
1047	              DOI 10.1109/IEEESTD.2018.8423794, August 2018,
1048	              <https://ieeexplore.ieee.org/document/8423794>.

1050	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1051	              Requirement Levels", BCP 14, RFC 2119,
1052	              DOI 10.17487/RFC2119, March 1997,
1053	              <https://www.rfc-editor.org/rfc/rfc2119>.

1055	   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
1056	              "Internet X.509 Public Key Infrastructure Certificate
1057	              Management Protocol (CMP)", RFC 4210,
1058	              DOI 10.17487/RFC4210, September 2005,
1059	              <https://www.rfc-editor.org/rfc/rfc4210>.

1061	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1062	              Housley, R., and W. Polk, "Internet X.509 Public Key
1063	              Infrastructure Certificate and Certificate Revocation List
1064	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1065	              <https://www.rfc-editor.org/rfc/rfc5280>.

1067	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1068	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1069	              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

1071	   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
1072	              and K. Watsen, "Bootstrapping Remote Secure Key
1073	              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
1074	              May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

1076	   [RFC9480]  Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
1077	              Management Protocol (CMP) Updates", RFC 9480,
1078	              DOI 10.17487/RFC9480, November 2023,
1079	              <https://www.rfc-editor.org/rfc/rfc9480>.

1081	   [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
1082	              Certificate Management Protocol (CMP) Profile", RFC 9483,
1083	              DOI 10.17487/RFC9483, November 2023,
1084	              <https://www.rfc-editor.org/rfc/rfc9483>.

1086	9.2.  Informative References

1088	   [BRSKI-AE-overview]
1089	              S. Fries and D. von Oheimb, "BRSKI-AE Protocol Overview",
1090	              March 2023,
1091	              <https://datatracker.ietf.org/meeting/116/materials/
1092	              slides-116-anima-update-on-brski-ae-alternative-
1093	              enrollment-protocols-in-brski-00>.  Graphics on slide 4 of
1094	              the BRSKI-AE draft 04 status update at IETF 116.

1096	   [I-D.eckert-anima-brski-discovery]
1097	              Eckert, T. T., von Oheimb, D., and E. Dijk, "Discovery for
1098	              BRSKI variations", Work in Progress, Internet-Draft,
1099	              draft-eckert-anima-brski-discovery-01, 23 October 2023,
1100	              <https://datatracker.ietf.org/doc/html/draft-eckert-anima-
1101	              brski-discovery-01>.

1103	   [I-D.ietf-ace-cmpv2-coap-transport]
1104	              Sahni, M. and S. Tripathi, "Constrained Application
1105	              Protocol (CoAP) Transfer for the Certificate Management
1106	              Protocol", Work in Progress, Internet-Draft, draft-ietf-
1107	              ace-cmpv2-coap-transport-10, 15 May 2023,
1108	              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
1109	              cmpv2-coap-transport-10>.

1111	   [I-D.ietf-anima-constrained-voucher]
1112	              Richardson, M., Van der Stok, P., Kampanakis, P., and E.
1113	              Dijk, "Constrained Bootstrapping Remote Secure Key
1114	              Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
1115	              draft-ietf-anima-constrained-voucher-22, 21 November 2023,
1116	              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
1117	              constrained-voucher-22>.

1119	   [IEC-62351-9]
1120	              International Electrotechnical Commission, "IEC 62351 -
1121	              Power systems management and associated information
1122	              exchange - Data and communications security - Part 9:
1123	              Cyber security key management for power system equipment",
1124	              IEC 62351-9, May 2017.

1126	   [ISO-IEC-15118-2]
1127	              International Standardization Organization / International
1128	              Electrotechnical Commission, "ISO/IEC 15118-2 Road
1129	              vehicles - Vehicle-to-Grid Communication Interface - Part
1130	              2: Network and application protocol requirements", ISO/
1131	              IEC 15118-2, April 2014.

1133	   [NERC-CIP-005-5]
1134	              North American Reliability Council, "Cyber Security -
1135	              Electronic Security Perimeter", CIP 005-5, December 2013.

1137	   [OCPP]     Open Charge Alliance, "Open Charge Point Protocol 2.0.1
1138	              (Draft)", December 2019.

1140	   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
1141	              Request Syntax Specification Version 1.7", RFC 2986,
1142	              DOI 10.17487/RFC2986, November 2000,
1143	              <https://www.rfc-editor.org/rfc/rfc2986>.

1145	   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
1146	              Certificate Request Message Format (CRMF)", RFC 4211,
1147	              DOI 10.17487/RFC4211, September 2005,
1148	              <https://www.rfc-editor.org/rfc/rfc4211>.

1150	   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
1151	              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
1152	              <https://www.rfc-editor.org/rfc/rfc5272>.

1154	   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
1155	              RFC 5652, DOI 10.17487/RFC5652, September 2009,
1156	              <https://www.rfc-editor.org/rfc/rfc5652>.

1158	   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
1159	              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
1160	              <https://www.rfc-editor.org/rfc/rfc5929>.

1162	   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
1163	              "Enrollment over Secure Transport", RFC 7030,
1164	              DOI 10.17487/RFC7030, October 2013,
1165	              <https://www.rfc-editor.org/rfc/rfc7030>.

1167	   [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
1168	              RFC 8894, DOI 10.17487/RFC8894, September 2020,
1169	              <https://www.rfc-editor.org/rfc/rfc8894>.

1171	   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
1172	              Autonomic Control Plane (ACP)", RFC 8994,
1173	              DOI 10.17487/RFC8994, May 2021,
1174	              <https://www.rfc-editor.org/rfc/rfc8994>.

1176	   [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
1177	              Raza, "EST-coaps: Enrollment over Secure Transport with
1178	              the Secure Constrained Application Protocol", RFC 9148,
1179	              DOI 10.17487/RFC9148, April 2022,
1180	              <https://www.rfc-editor.org/rfc/rfc9148>.

1182	   [UNISIG-Subset-137]
1183	              UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
1184	              FFFIS; V1.0.0", December 2015,
1185	              <https://www.era.europa.eu/sites/default/files/filesystem/
1186	              ertms/ccs_tsi_annex_a_-_mandatory_specifications/
1187	              set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
1188	              _subset-137_v100.pdf>.
1189	              http://www.kmc-subset137.eu/index.php/download/

1191	Appendix A.  Application Examples

1193	   This informative annex provides some detail to the application
1194	   examples listed in Section 1.2.

1196	A.1.  Rolling Stock

1198	   Rolling stock or railroad cars contain a variety of sensors,
1199	   actuators, and controllers, which communicate within the railroad car
1200	   but also exchange information between railroad cars forming a train,
1201	   with track-side equipment, and/or possibly with backend systems.
1202	   These devices are typically unaware of backend system connectivity.
1203	   Enrolling certificates may be done during maintenance cycles of the
1204	   railroad car, but can already be prepared during operation.  Such
1205	   asynchronous enrollment will include generating certification
1206	   requests, which are collected and later forwarded for processing
1207	   whenever the railroad car gets connectivity with the backend PKI of
1208	   the operator.  The authorization of the certification request is then
1209	   done based on the operator's asset/inventory information in the
1210	   backend.

1212	   UNISIG has included a CMP profile for enrollment of TLS client and
1213	   server X.509 certificates of on-board and track-side components in
1214	   the Subset-137 specifying the ETRAM/ETCS online key management for
1215	   train control systems [UNISIG-Subset-137].

1217	A.2.  Building Automation

1219	   In building automation scenarios, a detached building or the basement
1220	   of a building may be equipped with sensors, actuators, and
1221	   controllers that are connected with each other in a local network but
1222	   with only limited or no connectivity to a central building management
1223	   system.  This problem may occur during installation time but also
1224	   during operation.  In such a situation a service technician collects
1225	   the necessary data and transfers it between the local network and the
1226	   central building management system, e.g., using a laptop or a mobile
1227	   phone.  This data may comprise parameters and settings required in
1228	   the operational phase of the sensors/actuators, like a component
1229	   certificate issued by the operator to authenticate against other
1230	   components and services.

1232	   The collected data may be provided by a domain registrar already
1233	   existing in the local network.  In this case connectivity to the
1234	   backend PKI may be facilitated by the service technician's laptop.
1235	   Alternatively, the data can also be collected from the pledges
1236	   directly and provided to a domain registrar deployed in a different
1237	   network as preparation for the operational phase.  In this case,
1238	   connectivity to the domain registrar may also be facilitated by the
1239	   service technician's laptop.

1241	A.3.  Substation Automation

1243	   In electrical substation automation scenarios, a control center
1244	   typically hosts PKI services to issue certificates for Intelligent
1245	   Electronic Devices operated in a substation.  Communication between
1246	   the substation and control center is performed through a
1247	   proxy/gateway/DMZ, which terminates protocol flows.  Note that
1248	   [NERC-CIP-005-5] requires inspection of protocols at the boundary of
1249	   a security perimeter (the substation in this case).  In addition,
1250	   security management in substation automation assumes central support
1251	   of several enrollment protocols in order to support the various
1252	   capabilities of IEDs from different vendors.  The IEC standard
1253	   IEC62351-9 [IEC-62351-9] specifies for the infrastructure side
1254	   mandatory support of two enrollment protocols: SCEP [RFC8894] and EST
1255	   [RFC7030], while an Intelligent Electronic Device may support only
1256	   one of them.

1258	A.4.  Electric Vehicle Charging Infrastructure

1260	   For electric vehicle charging infrastructure, protocols have been
1261	   defined for the interaction between the electric vehicle and the
1262	   charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
1263	   between the charging point and the charging point operator (e.g.
1264	   OCPP [OCPP]).  Depending on the authentication model, unilateral or
1265	   mutual authentication is required.  In both cases the charging point
1266	   uses an X.509 certificate to authenticate itself in TLS channels
1267	   between the electric vehicle and the charging point.  The management
1268	   of this certificate depends, among others, on the selected backend
1269	   connectivity protocol.  In the case of OCPP, this protocol is meant
1270	   to be the only communication protocol between the charging point and
1271	   the backend, carrying all information to control the charging
1272	   operations and maintain the charging point itself.  This means that
1273	   the certificate management needs to be handled in-band of OCPP.  This
1274	   requires the ability to encapsulate the certificate management
1275	   messages in a transport-independent way.  Authenticated self-
1276	   containment will support this by allowing the transport without a
1277	   separate enrollment protocol, binding the messages to the identity of
1278	   the communicating endpoints.

1280	A.5.  Infrastructure Isolation Policy

1282	   This refers to any case in which network infrastructure is normally
1283	   isolated from the Internet as a matter of policy, most likely for
1284	   security reasons.  In such a case, limited access to external PKI
1285	   services will be allowed in carefully controlled short periods of
1286	   time, for example when a batch of new devices is deployed, and
1287	   forbidden or prevented at other times.

1289	A.6.  Sites with Insufficient Level of Operational Security

1291	   The RA performing (at least part of) the authorization of a
1292	   certification request is a critical PKI component and therefore
1293	   requires higher operational security than components utilizing the
1294	   issued certificates for their security features.  CAs may also demand
1295	   higher security in the registration procedures from RAs, which domain
1296	   registrars with co-located RAs may not be able to fulfill.
1297	   Especially the CA/Browser forum currently increases the security
1298	   requirements in the certificate issuance procedures for publicly
1299	   trusted certificates, i.e., those placed in trust stores of browsers,
1300	   which may be used to connect with devices in the domain.  In case the
1301	   on-site components of the target domain cannot be operated securely
1302	   enough for the needs of an RA, this service should be transferred to
1303	   an off-site backend component that has a sufficient level of
1304	   security.

1306	Appendix B.  History of Changes TBD RFC Editor: please delete

1308	   List of reviewers:

1310	   *  Toerless Eckert (document shepherd)

1312	   *  Barry Leiba (SECDIR)

1314	   *  Michael Richardson

1316	   *  Rajeev Ranjan, Siemens

1318	   *  Rufus Buschart, Siemens

1320	   *  YANGDOCTORS Early review of 2021-08-15
1321	      (https://datatracker.ietf.org/doc/review-ietf-anima-brski-async-
1322	      enroll-03-yangdoctors-early-rahman-2021-08-15/) referred to the
1323	      PRM aspect of draft-ietf-anima-brski-async-enroll-03
1324	      (https://datatracker.ietf.org/doc/draft-ietf-anima-brski-async-
1325	      enroll/03/).  This has been carved out of the draft to a different
1326	      one and thus is no more applicable here.

1328	   IETF draft ae-07 -> ae-08:

1330	   *  Update references to service names in Section 5.1

1332	   IETF draft ae-06 -> ae-07:

1334	   *  Update subsections on discovery according to discussion in the
1335	      design team

1337	   *  In Section 5.1, replace 'mandatory' by 'REQUIRED' regarding
1338	      adherence to LCMPP,
1339	      in response to SECDIR Last Call Review of ae-06 by Barry Leiba

1341	   IETF draft ae-05 -> ae-06:

1343	   *  Extend section on discovery according to discussion in the design
1344	      team

1346	   *  Make explicit that MASA voucher status telemetry is as in BRSKI

1348	   *  Add note that on delegation, RA may need info on pledge
1349	      authorization

1351	   IETF draft ae-04 -> ae-05:

1353	   *  Remove entries from the terminology section that should be clear
1354	      from BRSKI

1356	   *  Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
1357	      RA/CA

1359	   *  Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the
1360	      terminology section

1362	   *  State clearly in Section 5.1 that LCMPP is mandatory when using
1363	      CMP

1365	   *  Change URL of BRSKI-AE-overview graphics to slide on IETF 116
1366	      meeting material

1368	   IETF draft ae-03 -> ae-04:

1370	   *  In response to SECDIR Early Review of ae-03 by Barry Leiba,

1372	      -  replace 'end-to-end security' by the more clear 'end-to-end
1373	         authentication'

1375	      -  restrict the meaning of the abbreviation 'AE' to 'Alternative
1376	         Enrollment'

1378	      -  replace 'MAY' by 'may' in requirement on delegated registrar
1379	         actions

1381	      -  re-phrase requirement on certificate request exchange, avoiding
1382	         MANDATORY

1384	      -  mention that further protocol names need be put in Well-Known
1385	         URIs registry

1387	      -  explain consequence of using non-standard endpoints, not
1388	         following SHOULD

1390	      -  remove requirement that 'caPubs' field in CMP responses SHOULD
1391	         NOT be used

1393	      -  add paragraph in security considerations on additional use of
1394	         TLS for CMP

1396	   *  In response to further internal reviews and suggestions for
1397	      generalization,

1399	      -  significantly cut down the introduction because the original
1400	         motivations and most explanations are no more needed and would
1401	         just make it lengthy to read

1403	      -  sort out asynchronous vs. offline transfer, offsite vs. backend
1404	         components

1406	      -  improve description of CSRs and proof of possession vs. proof
1407	         of origin

1409	      -  clarify that the channel between pledge and registrar is not
1410	         restricted to TLS, but in connection with constrained BRSKI may
1411	         also be DTLS.  Also move the references to Constrained BRSKI
1412	         and CoAPS to better contexts.

1414	      -  clarify that the registrar must not be circumvented in the
1415	         decision to grant and LDevID, and give hints and
1416	         recommendations how to make sure this

1418	      -  clarify that the cert enrollment phase may involve additional
1419	         messages and that BRSKI-AE replaces [RFC8995], Section 5.9
1420	         (except Section 5.9.4)

1422	      -  the certificate enrollment protocol needs to support transport
1423	         over (D)TLS only as far as its messages are transported between
1424	         pledge and registrar.

1426	      -  the certificate enrollment protocol chosen between pledge and
1427	         registrar needs to be used also for the upstream enrollment
1428	         exchange with the PKI only if end-to-end authentication shall
1429	         be achieved across the registrar to the PKI.

1431	      -  add that with CMP, further trust anchors SHOULD be transported
1432	         via caPubs

1434	      -  remove the former Appendix A: "Using EST for Certificate
1435	         Enrollment", moving relevant points to the list of scenarios in
1436	         Section 1.1: "Supported Scenarios",

1438	      -  streamline the item on EST in Section 3.2: "Solution Options
1439	         for Proof of Identity",

1441	      -  various minor editorial improvements like making the wording
1442	         more consistent

1444	   IETF draft ae-02 -> ae-03:

1446	   *  In response to review by Toerless Eckert,

1448	      -  many editorial improvements and clarifications as suggested,
1449	         such as the comparison to plain BRSKI, the description of
1450	         offline vs. synchronous message transfer and enrollment, and
1451	         better differentiation of RA flavors.

1453	      -  clarify that for transporting certificate enrollment messages
1454	         between pledge and registrar, the TLS channel established
1455	         between these two (via the join proxy) is used and the
1456	         enrollment protocol MUST support this.

1458	      -  clarify that the enrollment protocol chosen between pledge and
1459	         registrar MUST also be used for the upstream enrollment
1460	         exchange with the PKI.

1462	      -  extend the description and requirements on how during the
1463	         certificate enrollment phase the registrar MAY handle requests
1464	         by the pledge itself and otherwise MUST forward them to the PKI
1465	         and forward responses to the pledge.

1467	   *  Change "The registrar MAY offer different enrollment protocols" to
1468	      "The registrar MUST support at least one certificate enrollment
1469	      protocol ..."

1471	   *  In response to review by Michael Richardson,

1473	      -  slightly improve the structuring of the Message Exchange
1474	         Section 4.2 and add some detail on the request/response
1475	         exchanges for the enrollment phase

1477	      -  merge the 'Enhancements to the Addressing Scheme' Section 4.3
1478	         with the subsequent one: 'Domain Registrar Support of
1479	         Alternative Enrollment Protocols'

1481	      -  add reference to SZTP (RFC 8572)

1483	      -  extend venue information

1485	      -  convert output of ASCII-art figures to SVG format

1487	      -  various small other text improvements as suggested/provided

1489	   *  Remove the tentative informative instantiation to EST-fullCMC

1491	   *  Move Eliot Lear from co-author to contributor, add him to the
1492	      acknowledgments

1494	   *  Add explanations for terms such as 'target domain' and 'caPubs'

1496	   *  Fix minor editorial issues and update some external references

1498	   IETF draft ae-01 -> ae-02:

1500	   *  Architecture: clarify registrar role including RA/LRA/enrollment
1501	      proxy

1503	   *  CMP: add reference to CoAP Transport for CMPV2 and Constrained
1504	      BRSKI

1506	   *  Include venue information

1508	   From IETF draft 05 -> IETF draft ae-01:

1510	   *  Renamed the repo and files from anima-brski-async-enroll to anima-
1511	      brski-ae

1513	   *  Added graphics for abstract protocol overview as suggested by
1514	      Toerless Eckert

1516	   *  Balanced (sub-)sections and their headers

1518	   *  Added details on CMP instance, now called BRSKI-CMP
1519	   From IETF draft 04 -> IETF draft 05:

1521	   *  David von Oheimb became the editor.

1523	   *  Streamline wording, consolidate terminology, improve grammar, etc.

1525	   *  Shift the emphasis towards supporting alternative enrollment
1526	      protocols.

1528	   *  Update the title accordingly - preliminary change to be approved.

1530	   *  Move comments on EST and detailed application examples to
1531	      informative annex.

1533	   *  Move the remaining text of section 3 as two new sub-sections of
1534	      section 1.

1536	   From IETF draft 03 -> IETF draft 04:

1538	   *  Moved UC2-related parts defining the pledge in responder mode to a
1539	      separate document.  This required changes and adaptations in
1540	      several sections.  Main changes concerned the removal of the
1541	      subsection for UC2 as well as the removal of the YANG model
1542	      related text as it is not applicable in UC1.

1544	   *  Updated references to the Lightweight CMP Profile (LCMPP).

1546	   *  Added David von Oheimb as co-author.

1548	   From IETF draft 02 -> IETF draft 03:

1550	   *  Housekeeping, deleted open issue regarding YANG voucher-request in
1551	      UC2 as voucher-request was enhanced with additional leaf.

1553	   *  Included open issues in YANG model in UC2 regarding assertion
1554	      value agent-proximity and CSR encapsulation using SZTP sub
1555	      module).

1557	   From IETF draft 01 -> IETF draft 02:

1559	   *  Defined call flow and objects for interactions in UC2.  Object
1560	      format based on draft for JOSE signed voucher artifacts and
1561	      aligned the remaining objects with this approach in UC2 .

1563	   *  Terminology change: issue #2 pledge-agent -> registrar-agent to
1564	      better underline agent relation.

1566	   *  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
1567	      and pledge-responder-mode to better address the pledge operation.

1569	   *  Communication approach between pledge and registrar-agent changed
1570	      by removing TLS-PSK (former section TLS establishment) and
1571	      associated references to other drafts in favor of relying on
1572	      higher layer exchange of signed data objects.  These data objects
1573	      are included also in the pledge-voucher-request and lead to an
1574	      extension of the YANG module for the voucher-request (issue #12).

1576	   *  Details on trust relationship between registrar-agent and
1577	      registrar (issue #4, #5, #9) included in UC2.

1579	   *  Recommendation regarding short-lived certificates for registrar-
1580	      agent authentication towards registrar (issue #7) in the security
1581	      considerations.

1583	   *  Introduction of reference to agent signing certificate using SKID
1584	      in agent signed data (issue #11).

1586	   *  Enhanced objects in exchanges between pledge and registrar-agent
1587	      to allow the registrar to verify agent-proximity to the pledge
1588	      (issue #1) in UC2.

1590	   *  Details on trust relationship between registrar-agent and pledge
1591	      (issue #5) included in UC2.

1593	   *  Split of use case 2 call flow into sub sections in UC2.

1595	   From IETF draft 00 -> IETF draft 01:

1597	   *  Update of scope in Section 1.1 to include in which the pledge acts
1598	      as a server.  This is one main motivation for use case 2.

1600	   *  Rework of use case 2 to consider the transport between the pledge
1601	      and the pledge-agent.  Addressed is the TLS channel establishment
1602	      between the pledge-agent and the pledge as well as the endpoint
1603	      definition on the pledge.

1605	   *  First description of exchanged object types (needs more work)

1607	   *  Clarification in discovery options for enrollment endpoints at the
1608	      domain registrar based on well-known endpoints in Section 4.3 do
1609	      not result in additional /.well-known URIs.  Update of the
1610	      illustrative example.  Note that the change to /brski for the
1611	      voucher-related endpoints has been taken over in the BRSKI main
1612	      document.

1614	   *  Updated references.

1616	   *  Included Thomas Werner as additional author for the document.

1618	   From individual version 03 -> IETF draft 00:

1620	   *  Inclusion of discovery options of enrollment endpoints at the
1621	      domain registrar based on well-known endpoints in Section 4.3 as
1622	      replacement of section 5.1.3 in the individual draft.  This is
1623	      intended to support both use cases in the document.  An
1624	      illustrative example is provided.

1626	   *  Missing details provided for the description and call flow in
1627	      pledge-agent use case UC2, e.g. to accommodate distribution of CA
1628	      certificates.

1630	   *  Updated CMP example in Section 5 to use Lightweight CMP instead of
1631	      CMP, as the draft already provides the necessary /.well-known
1632	      endpoints.

1634	   *  Requirements discussion moved to separate section in Section 3.
1635	      Shortened description of proof-of-identity binding and mapping to
1636	      existing protocols.

1638	   *  Removal of copied call flows for voucher exchange and registrar
1639	      discovery flow from [RFC8995] in Section 4 to avoid doubling or
1640	      text or inconsistencies.

1642	   *  Reworked abstract and introduction to be more crisp regarding the
1643	      targeted solution.  Several structural changes in the document to
1644	      have a better distinction between requirements, use case
1645	      description, and solution description as separate sections.
1646	      History moved to appendix.

1648	   From individual version 02 -> 03:

1650	   *  Update of terminology from self-contained to authenticated self-
1651	      contained object to be consistent in the wording and to underline
1652	      the protection of the object with an existing credential.  Note
1653	      that the naming of this object may be discussed.  An alternative
1654	      name may be attestation object.

1656	   *  Simplification of the architecture approach for the initial use
1657	      case having an offsite PKI.

1659	   *  Introduction of a new use case utilizing authenticated self-
1660	      contain objects to onboard a pledge using a commissioning tool
1661	      containing a pledge-agent.  This requires additional changes in
1662	      the BRSKI call flow sequence and led to changes in the
1663	      introduction, the application example,and also in the related
1664	      BRSKI-AE call flow.

1666	   *  Update of provided examples of the addressing approach used in
1667	      BRSKI to allow for support of multiple enrollment protocols in
1668	      Section 4.3.

1670	   From individual version 01 -> 02:

1672	   *  Update of introduction text to clearly relate to the usage of
1673	      IDevID and LDevID.

1675	   *  Definition of the addressing approach used in BRSKI to allow for
1676	      support of multiple enrollment protocols in Section 4.3.  This
1677	      section also contains a first discussion of an optional discovery
1678	      mechanism to address situations in which the registrar supports
1679	      more than one enrollment approach.  Discovery should avoid that
1680	      the pledge performs a trial and error of enrollment protocols.

1682	   *  Update of description of architecture elements and changes to
1683	      BRSKI in Section 4.1.

1685	   *  Enhanced consideration of existing enrollment protocols in the
1686	      context of mapping the requirements to existing solutions in
1687	      Section 3 and in Section 5.

1689	   From individual version 00 -> 01:

1691	   *  Update of examples, specifically for building automation as well
1692	      as two new application use cases in Appendix A.

1694	   *  Deletion of asynchronous interaction with MASA to not complicate
1695	      the use case.  Note that the voucher exchange can already be
1696	      handled in an asynchronous manner and is therefore not considered
1697	      further.  This resulted in removal of the alternative path the
1698	      MASA in Figure 1 and the associated description in Section 4.1.

1700	   *  Enhancement of description of architecture elements and changes to
1701	      BRSKI in Section 4.1.

1703	   *  Consideration of existing enrollment protocols in the context of
1704	      mapping the requirements to existing solutions in Section 3.

1706	   *  New section starting Section 5 with the mapping to existing
1707	      enrollment protocols by collecting boundary conditions.

1709	Contributors

1711	   Eliot Lear
1712	   Cisco Systems
1713	   Richtistrasse 7
1714	   CH-8304 Wallisellen
1715	   Switzerland
1716	   Phone: [phone]
1717	   Email: [e-mail]

1719	Authors' Addresses

1721	   David von Oheimb (editor)
1722	   Siemens AG
1723	   Otto-Hahn-Ring 6
1724	   81739 Munich
1725	   Germany
1726	   Email: [e-mail]
1727	   URI:   https://www.siemens.com/

1729	   Steffen Fries
1730	   Siemens AG
1731	   Otto-Hahn-Ring 6
1732	   81739 Munich
1733	   Germany
1734	   Email: [e-mail]
1735	   URI:   https://www.siemens.com/

1737	   Hendrik Brockhaus
1738	   Siemens AG
1739	   Otto-Hahn-Ring 6
1740	   81739 Munich
1741	   Germany
1742	   Email: [e-mail]
1743	   URI:   https://www.siemens.com/