idnits 2.17.1 draft-ietf-anima-brski-async-enroll-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8995]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 774 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-17 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG D. von Oheimb, Ed. 3 Internet-Draft S. Fries 4 Intended status: Standards Track H. Brockhaus 5 Expires: 8 September 2022 Siemens 6 E. Lear 7 Cisco Systems 8 7 March 2022 10 BRSKI-AE: Alternative Enrollment Protocols in BRSKI 11 draft-ietf-anima-brski-async-enroll-05 13 Abstract 15 This document enhances Bootstrapping Remote Secure Key Infrastructure 16 (BRSKI, [RFC8995]) to allow employing alternative enrollment 17 protocols, such as CMP. 19 Using self-contained signed objects, the origin of enrollment 20 requests and responses can be authenticated independently of message 21 transfer. This supports end-to-end security and asynchronous 22 operation of certificate enrollment and provides flexibility where to 23 authenticate and authorize certification requests. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 8 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Supported environment . . . . . . . . . . . . . . . . . . 5 61 1.3. List of application examples . . . . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements discussion and mapping to solution elements . . 7 64 4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 10 66 4.2. Message exchange . . . . . . . . . . . . . . . . . . . . 13 67 4.2.1. Pledge - Registrar discovery and voucher exchange . . 13 68 4.2.2. Registrar - MASA voucher exchange . . . . . . . . . . 13 69 4.2.3. Pledge - Registrar - RA/CA certificate enrollment . . 13 70 4.2.4. Pledge - Registrar - enrollment status telemetry . . 16 71 4.2.5. Addressing scheme enhancements . . . . . . . . . . . 16 72 4.3. Domain registrar support of alternative enrollment 73 protocols . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5. Examples for signature-wrapping using existing enrollment 75 protocols . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.1. Instantiation to EST (informative) . . . . . . . . . . . 17 77 5.2. Instantiation to CMP (normative if CMP is chosen) . . . . 18 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . 20 84 Appendix A. Using EST for certificate enrollment . . . . . . . . 21 85 Appendix B. Application examples . . . . . . . . . . . . . . . . 22 86 B.1. Rolling stock . . . . . . . . . . . . . . . . . . . . . . 23 87 B.2. Building automation . . . . . . . . . . . . . . . . . . . 23 88 B.3. Substation automation . . . . . . . . . . . . . . . . . . 24 89 B.4. Electric vehicle charging infrastructure . . . . . . . . 24 90 B.5. Infrastructure isolation policy . . . . . . . . . . . . . 24 91 B.6. Sites with insufficient level of operational security . . 25 92 Appendix C. History of changes TBD RFC Editor: please delete . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 95 1. Introduction 97 1.1. Motivation 99 BRSKI, as defined in [RFC8995], specifies a solution for secure 100 automated zero-touch bootstrapping of new devices, so-called pledges. 101 This includes the discovery of the registrar in the target domain, 102 time synchronization, and the exchange of security information 103 necessary to establish mutual trust between pledges and the target 104 domain. 106 A pledge gains trust in the target domain via the domain registrar as 107 follows. It obtains security information about the domain, 108 specifically a domain certificate to be trusted, by requesting a 109 voucher object defined in [RFC8366]. Such a voucher is a self- 110 contained signed object originating from a Manufacturer Authorized 111 Signing Authority (MASA). Therefore, the voucher may be provided in 112 online mode (synchronously) or offline mode (asynchronously). The 113 pledge can authenticate the voucher because it is shipped with a 114 trust anchor of its manufacturer such that it can validate signatures 115 (including related certificates) by the MASA. 117 Trust by the target domain in a pledge is established by providing 118 the pledge with a domain-specific LDevID certificate. The 119 certification request of the pledge is signed using its IDevID secret 120 and can be validated by the target domain using the trust anchor of 121 the pledge manufacturer, which needs to pre-installed in the domain. 123 For enrolling devices with LDevID certificates, BRSKI typically 124 utilizes Enrollment over Secure Transport (EST) [RFC7030]. EST has 125 its specific characteristics, detailed in Appendix A. In particular, 126 it requires online or on-site availability of the RA for performing 127 the data origin authentication and final authorization decision on 128 the certification request. This type of enrollment can be called 129 'synchronous enrollment'. For various reasons, it may be preferable 130 to use alternative enrollment protocols such as the Certificate 131 Management Protocol (CMP) [RFC4210] profiled in 132 [I-D.ietf-lamps-lightweight-cmp-profile] or Certificate Management 133 over CMS (CMC) [RFC5272]. that are more flexible and independent of 134 the transfer mechanism because they represent certification request 135 messages as authenticated self-contained objects. 137 Depending on the application scenario, the required RA/CA components 138 may not be part of the registrar. They even may not be available on- 139 site but rather be provided by remote backend systems. The registrar 140 or its deployment site may not have an online connection with them or 141 the connectivity may be intermittent. This may be due to security 142 requirements for operating the backend systems or due to site 143 deployments where on-site or always-online operation may be not 144 feasible or too costly. In such scenarios, the authentication and 145 authorization of certification requests will not or can not be 146 performed on-site at enrollment time. In this document, enrollment 147 that is not performed in a (time-wise) consistent way is called 148 _asynchronous enrollment_. Asynchronous enrollment requires a store- 149 and-forward transfer of certification requests along with the 150 information needed for authenticating the requester. This allows 151 offline processing the request. 153 Application scenarios may also involve network segmentation, which is 154 utilized in industrial systems to separate domains with different 155 security needs. Such scenarios lead to similar requirements if the 156 TLS connection carrying the requester authentication is terminated 157 and thus request messages need to be forwarded on further channels 158 before the registrar/RA can authorize the certification request. In 159 order to preserve the requester authentication, authentication 160 information needs to be retained and ideally bound directly to the 161 certification request. 163 There are basically two approaches for forwarding certification 164 requests along with requester authentication information: 166 * A trusted component (e.g., a local RA) in the target domain is 167 needed that forwards the certification request combined with the 168 validated identity of the requester (e,g., its IDevID certificate) 169 and an indication of successful verification of the proof-of- 170 possession (of the corresponding private key) in a way preventing 171 changes to the combined information. When connectivity is 172 available, the trusted component forwards the certification 173 request together with the requester information (authentication 174 and proof-of-possession) for further processing. This approach 175 offers only hop-by-hop security. The backend PKI must rely on the 176 local pledge authentication result provided by the local RA when 177 performing the authorization of the certification request. In 178 BRSKI, the EST server is such a trusted component, being co- 179 located with the registrar in the target domain. 181 * Involved components use authenticated self-contained objects for 182 the enrollment, directly binding the certification request and the 183 requester authentication in a cryptographic way. This approach 184 supports end-to-end security, without the need to trust in 185 intermediate domain components. Manipulation of the request and 186 the requester identity information can be detected during the 187 validation of the self-contained signed object. 189 Focus of this document is the support of alternative enrollment 190 protocols that allow using authenticated self-contained objects for 191 device credential bootstrapping. This enhancement of BRSKI is named 192 BRSKI-AE, where AE stands for alternative enrollment protocols and 193 for asynchronous enrollment. This specification carries over the 194 main characteristics of BRSKI, namely that the pledge obtains trust 195 anchor information for authenticating the domain registrar and other 196 target domain components as well as a domain-specific X.509 device 197 certificate (the LDevID certificate) along with the corresponding 198 private key (the LDevID secret) and certificate chain. 200 The goals are to enhance BRSKI to 202 * support alternative enrollment protocols, 204 * support end-to-end security for enrollment, and 206 * make it applicable to scenarios involving asynchronous enrollment. 208 This is achieved by 210 * extending the well-known URI approach with an additional path 211 element indicating the enrollment protocol being used, and 213 * defining a certificate waiting indication and handling, for the 214 case that the certifying component is (temporarily) not available. 216 This specification can be applied to both synchronous and 217 asynchronous enrollment. 219 In contrast to BRSKI, this specification supports offering multiple 220 enrollment protocols on the infrastructure side, which enables 221 pledges and their developers to pick the preferred one. 223 1.2. Supported environment 225 BRSKI-AE is intended to be used in domains that may have limited 226 support of on-site PKI services and comprises application scenarios 227 like the following. 229 * There are requirements or implementation restrictions that do not 230 allow using EST for enrolling an LDevID certificate. 232 * Pledges and/or the target domain already have an established 233 certificate management approach different from EST that shall be 234 reused (e.g., in brownfield installations). 236 * There is no registration authority available on site in the target 237 domain. Connectivity to an off-site RA is intermittent or 238 entirely offline. A store-and-forward mechanism is used for 239 communicating with the off-site services. 241 * Authoritative actions of a local RA are limited and may not be 242 sufficient for authorizing certification requests by pledges. 243 Final authorization is done by an RA residing in the operator 244 domain. 246 1.3. List of application examples 248 Bootstrapping can be handled in various ways, depending on the 249 application domains. The informative Appendix B provides 250 illustrative examples from various industrial control system 251 environments and operational setups. They motivate the support of 252 alternative enrollment protocols, based on the following examples of 253 operational environments: 255 * Rolling stock 257 * Building automation 259 * Electrical substation automation 261 * Electric vehicle charging infrastructures 263 * Infrastructure isolation policy 265 * Sites with insufficient level of operational security 267 2. Terminology 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in 272 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 273 capitals, as shown here. 275 This document relies on the terminology defined in [RFC8995] and 276 [IEEE.802.1AR_2009].The following terms are defined in addition: 278 EE: End entity, in the BRSKI context called pledge. It is the 279 entity that is bootstrapped to the target domain. It holds a 280 public-private key pair, for which it requests a public-key 281 certificate. An identifier for the EE is given as the subject 282 name of the certificate. 284 RA: Registration authority, an optional system component to which a 285 CA delegates certificate management functions such as 286 authenticating requesters and performing authorization checks on 287 certification requests. 289 CA: Certification authority, issues certificates and provides 290 certificate status information. 292 target domain: The set of entities that share a common local trust 293 anchor, independent of where the entities are deployed. 295 site: Describes the locality where an entity, e.g., pledge, 296 registrar, RA, CA, is deployed. Different sites can belong to the 297 same target domain. 299 on-site: Describes a component or service or functionality available 300 in the target deployment site. 302 off-site: Describes a component or service or functionality 303 available in an operator site different from the target deployment 304 site. This may be a central site or a cloud service, to which 305 only a temporary connection is available. 307 asynchronous communication: Describes a time-wise interrupted 308 communication between a pledge (EE) and a registrar or PKI 309 component. 311 synchronous communication: Describes a time-wise uninterrupted 312 communication between a pledge (EE) and a registrar or PKI 313 component. 315 authenticated self-contained object: Describes in this context an 316 object that is cryptographically bound to the IDevID certificate 317 of a pledge. The binding is assumed to be provided through a 318 digital signature of the actual object using the IDevID secret. 320 3. Requirements discussion and mapping to solution elements 322 There were two main drivers for the definition of BRSKI-AE: 324 * The solution architecture may already use or require a certificate 325 management protocol other than EST. Therefore, this other 326 protocol should be usable for requesting LDevID certificates. 328 * The domain registrar may not be the (final) point that 329 authenticates and authorizes certification requests and the pledge 330 may not have a direct connection to it. Therefore, certification 331 requests should be self-contained signed objects. 333 Based on the intended target environment described in Section 1.2 and 334 the application examples described in Appendix B, the following 335 requirements are derived to support authenticated self-contained 336 objects as containers carrying certification requests. 338 At least the following properties are required: 340 * proof-of-possession: demonstrates access to the private key 341 corresponding to the public key contained in a certification 342 request. This is typically achieved by a self-signature using the 343 corresponding private key. 345 * proof-of-identity: provides data origin authentication of the 346 certification request. This typically is achieved by a signature 347 using the IDevID secret of the pledge. 349 Here is an incomplete list of solution examples, based on existing 350 technology described in IETF documents: 352 * Certification request objects: Certification requests are data 353 structures protecting only the integrity of the contained data and 354 providing proof-of-possession for a (locally generated) private 355 key. Examples for certification request data structures are: 357 - PKCS#10 [RFC2986]. This certification request structure is 358 self-signed to protect its integrity and prove possession of 359 the private key that corresponds to the public key included in 360 the request. 362 - CRMF [RFC4211]. Also this certificate request message format 363 supports integrity protection and proof-of-possession, 364 typically by a self-signature generated over (part of) the 365 structure with the private key corresponding to the included 366 public key. CRMF also supports further proof-of-possession 367 methods for types of keys that do not support any signature 368 algorithm. 370 The integrity protection of certification request fields includes 371 the public key because it is part of the data signed by the 372 corresponding private key. Yet note that for the above examples 373 this is not sufficient to provide data origin authentication, 374 i.e., proof-of-identity. This extra property can be achieved by 375 an additional binding to the IDevID of the pledge. This binding 376 to source authentication supports the authorization decision for 377 the certification request. The binding of data origin 378 authentication to the certification request may be delegated to 379 the protocol used for certificate management. 381 * Solution options for proof-of-identity: The certification request 382 should be bound to an existing authenticated credential (here, the 383 IDevID certificate) to enable a proof of identity and, based on 384 it, an authorization of the certification request. The binding 385 may be achieved through security options in an underlying 386 transport protocol such as TLS if the authorization of the 387 certification request is (completely) done at the next 388 communication hop. This binding can also be done in a transport- 389 independent way by wrapping the certification request with 390 signature employing an existing IDevID. the BRSKI context, this 391 will be the IDevID. This requirement is addressed by existing 392 enrollment protocols in various ways, such as: 394 - EST [RFC7030] utilizes PKCS#10 to encode the certification 395 request. The Certificate Signing Request (CSR) optionally 396 provides a binding to the underlying TLS session by including 397 the tls-unique value in the self-signed PKCS#10 structure. The 398 tls-unique value results from the TLS handshake. Since the TLS 399 handshake includes client authentication and the pledge 400 utilizes its IDevID for it, the proof-of-identity is provided 401 by such a binding to the TLS session. This can be supported 402 using the EST /simpleenroll endpoint. Note that the binding of 403 the TLS handshake to the CSR is optional in EST. As an 404 alternative to binding to the underlying TLS authentication in 405 the transport layer, [RFC7030] sketches wrapping the CSR with a 406 Full PKI Request message using an existing certificate. 408 - SCEP [RFC8894] supports using a shared secret (passphrase) or 409 an existing certificate to protect CSRs based on SCEP Secure 410 Message Objects using CMS wrapping ([RFC5652]). Note that the 411 wrapping using an existing IDevID in SCEP is referred to as 412 renewal. Thus SCEP does not rely on the security of the 413 underlying transfer. 415 - CMP [RFC4210] supports using a shared secret (passphrase) or an 416 existing certificate, which may be an IDevID credential, to 417 authenticate certification requests via the PKIProtection 418 structure in a PKIMessage. The certification request is 419 typically encoded utilizing CRMF, while PKCS#10 is supported as 420 an alternative. Thus CMP does not rely on the security of the 421 underlying transfer protocol. 423 - CMC [RFC5272] also supports utilizing a shared secret 424 (passphrase) or an existing certificate to protect 425 certification requests, which can be either in CRMF or PKCS#10 426 structure. The proof-of-identity can be provided as part of a 427 FullCMCRequest, based on CMS [RFC5652] and signed with an 428 existing IDevID secret. Thus CMC does not rely on the security 429 of the underlying transfer protocol. 431 4. Adaptations to BRSKI 433 In order to support alternative enrollment protocols, asynchronous 434 enrollment, and more general system architectures, BRSKI-AE lifts 435 some restrictions of BRSKI [RFC8995]. This way, authenticated self- 436 contained objects such as those described in Section 3 above can be 437 used for certificate enrollment. 439 The enhancements needed are kept to a minimum in order to ensure 440 reuse of already defined architecture elements and interactions. In 441 general, the communication follows the BRSKI model and utilizes the 442 existing BRSKI architecture elements. In particular, the pledge 443 initiates communication with the domain registrar and interacts with 444 the MASA as usual. 446 4.1. Architecture 448 The key element of BRSKI-AE is that the authorization of a 449 certification request MUST be performed based on an authenticated 450 self-contained object. The certification request is bound in a self- 451 contained way to a proof-of-origin based on the IDevID. 452 Consequently, the authentication and authorization of the 453 certification request MAY be done by the domain registrar and/or by 454 other domain components. These components may be offline or reside 455 in some central backend of the domain operator (off-site) as 456 described in Section 1.2. The registrar and other on-site domain 457 components may have no or only temporary (intermittent) connectivity 458 to them. The certification request MAY also be piggybacked on 459 another protocol. 461 This leads to generalizations in the placement and enhancements of 462 the logical elements as shown in Figure 1. 464 +------------------------+ 465 +--------------Drop-Ship--------------->| Vendor Service | 466 | +------------------------+ 467 | | M anufacturer| | 468 | | A uthorized |Ownership| 469 | | S igning |Tracker | 470 | | A uthority | | 471 | +--------------+---------+ 472 | ^ 473 | | 474 V | 475 +--------+ ......................................... | 476 | | . . | BRSKI- 477 | | . +------------+ +------------+ . | MASA 478 | Pledge | . | Join | | Domain <-----+ 479 | | . | Proxy | | Registrar/ | . 480 | <-------->............<-------> Enrollment | . 481 | | . | BRSKI-AE | Proxy/LRA | . 482 | IDevID | . | | +------^-----+ . 483 | | . +------------+ | . 484 | | . | . 485 +--------+ ...............................|......... 486 on-site "domain" components | 487 | e.g., RFC 4210, 488 | RFC 7030, ... 489 .............................................|..................... 490 . +---------------------------+ +--------v------------------+ . 491 . | Public-Key Infrastructure <-----+ Registration Authority | . 492 . | PKI CA +-----> PKI RA | . 493 . +---------------------------+ +---------------------------+ . 494 ................................................................... 495 off-site or central "domain" components 497 Figure 1: Architecture overview using off-site PKI components 499 The architecture overview in Figure 1 has the same logical elements 500 as BRSKI, but with more flexible placement of the authentication and 501 authorization checks on certification requests. Depending on the 502 application scenario, the registrar MAY still do all of these checks 503 (as is the case in BRSKI), or part of them, or none of them. 505 The following list describes the on-site components in the target 506 domain of the pledge shown in Figure 1. 508 * Join Proxy: same functionality as described in BRSKI [RFC8995]. 510 * Domain Registrar / Enrollment Proxy / LRA: in BRSKI-AE, the domain 511 registrar has mostly the same functionality as in BRSKI, namely to 512 facilitate the communication of the pledge with the MASA and the 513 PKI. Yet in contrast to BRSKI, the registrar offers different 514 enrollment protocols and MAY act as a local registration authority 515 (LRA) or simply as an enrollment proxy. In such cases, the domain 516 registrar forwards the certification request to some off-site RA 517 component, which performs at least part of the authorization. 518 This also covers the case that the registrar has only intermittent 519 connection and forwards the certification request to the RA upon 520 re-established connectivity. 522 Note: To support alternative enrollment protocols, the URI scheme 523 for addressing the domain registrar is generalized (see 524 Section 4.2.5). 526 The following list describes the components provided by the vendor or 527 manufacturer outside the target domain. 529 * MASA: general functionality as described in BRSKI [RFC8995]. The 530 voucher exchange with the MASA via the domain registrar is 531 performed as described in BRSKI. 533 Note: The interaction with the MASA may be synchronous (voucher 534 request with nonce) or asynchronous (voucher request without 535 nonce). 537 * Ownership tracker: as defined in BRSKI. 539 The following list describes the target domain components that can 540 optionally be operated in the off-site backend of the target domain. 542 * PKI RA: Performs certificate management functions for the domain 543 as a centralized public-key infrastructure for the domain 544 operator. As far as not already done by the domain registrar, it 545 performs the final validation and authorization of certification 546 requests. 548 * PKI CA: Performs certificate generation by signing the certificate 549 structure requested in already authenticated and authorized 550 certification requests. 552 Based on the diagram in Section 2.1 of BRSKI [RFC8995] and the 553 architectural changes, the original protocol flow is divided into 554 three phases showing commonalities and differences to the original 555 approach as follows. 557 * Discovery phase: same as in BRSKI steps (1) and (2) 558 * Voucher exchange phase: same as in BRSKI steps (3) and (4). 560 * Enrollment phase: step (5) is changed to employing an alternative 561 enrollment protocol that uses authenticated self-contained 562 objects. 564 4.2. Message exchange 566 The behavior of a pledge described in Section 2.1 of BRSKI [RFC8995] 567 is kept with one exception. After finishing the Imprint step (4), 568 the Enroll step (5) MUST be performed with an enrollment protocol 569 utilizing authenticated self-contained objects. Section 5 discusses 570 selected suitable enrollment protocols and options applicable. 572 4.2.1. Pledge - Registrar discovery and voucher exchange 574 The discovery phase and voucher exchange are applied as specified in 575 [RFC8995]. 577 4.2.2. Registrar - MASA voucher exchange 579 This voucher exchange is performed as specified in [RFC8995]. 581 4.2.3. Pledge - Registrar - RA/CA certificate enrollment 583 As stated in Section 3, the enrollment MUST be performed using an 584 authenticated self-contained object providing not only proof-of- 585 possession but also proof-of-identity (source authentication). 587 +--------+ +------------+ +------------+ 588 | Pledge | | Domain | | Operator | 589 | | | Registrar | | RA/CA | 590 | | | (JRC) | | (OPKI) | 591 +--------+ +------------+ +------------+ 592 /--> | | 593 [Optional request of CA certificates] | | 594 |---------- CA Certs Request ------------>| | 595 | [if connection to operator domain is available] | 596 | |-Request CA Certs ->| 597 | |<-CA Certs Response-| 598 |<-------- CA Certs Response--------------| | 599 /--> | | 600 [Optional request of attributes to be included in Cert Request] | 601 |---------- Attribute Request ----------->| | 602 | [if connection to operator domain is available] | 603 | |-Attribute Request->| 604 | |<- Attrib Response -| 605 |<--------- Attribute Response -----------| | 606 /--> | | 607 [Certification request] | | 608 |-------------- Cert Request ------------>| | 609 | [when connection to off-site components is unavailable] | 610 |<----- optional: Cert Waiting Response --| | 611 | | | 612 |-------optional: Cert Polling ---------->| | 613 | | | 614 | [when connection to off-site components is available] | 615 | |--- Cert Request -->| 616 | |<-- Cert Response --| 617 |<------------- Cert Response ------------| | 618 /--> | | 619 [Optional certificate confirmation] | | 620 |-------------- Cert Confirm ------------>| | 621 | |--- Cert Confirm -->| 622 | |<-- PKI Confirm ----| 623 |<------------- PKI/Registrar Confirm ----| | 625 Figure 2: Certificate enrollment 627 The following list provides an abstract description of the flow 628 depicted in Figure 2. 630 * CA Cert Request: The pledge optionally requests the latest 631 relevant CA certificates. This ensures that the pledge has the 632 complete set of current CA certificates beyond the pinned-domain- 633 cert (which is contained in the voucher and may be just the domain 634 registrar certificate). 636 * CA Cert Response: It MUST contain the current root CA certificate, 637 which typically is the LDevID trust anchor, and any additional 638 certificates that the pledge may need to validate certificates. 640 * Attribute Request: Typically, the automated bootstrapping occurs 641 without local administrative configuration of the pledge. 642 Nevertheless, there are cases in which the pledge may also include 643 additional attributes specific to the target domain into the 644 certification request. To get these attributes in advance, the 645 attribute request can be used. 647 * Attribute Response: It MUST contain the attributes to be included 648 in the subsequent certification request. 650 * Cert Request: This certification request MUST contain the 651 authenticated self-contained object ensuring both proof-of- 652 possession of the corresponding private key and proof-of-identity 653 of the requester. 655 * Cert Response: The certification response message MUST contain on 656 success the requested certificate and MAY include further 657 information, like certificates of intermediate CAs. 659 * Cert Waiting Response: Optional waiting indication for the pledge, 660 which SHOULD poll for a Cert Response after a given time. To this 661 end, a request identifier is necessary. The request identifier 662 may be either part of the enrollment protocol or can be derived 663 from the certification request. 665 * Cert Polling: This SHOULD be used by the pledge in reaction to a 666 Cert Waiting Response to query the registrar whether the 667 certification request meanwhile has been processed. It MUST be 668 answered either by another Cert Waiting, or the Cert Response. 670 * Cert Confirm: An optional confirmation sent after the requested 671 certificate has been received and validated. It contains a 672 positive or negative confirmation by the pledge whether the 673 certificate was successfully enrolled and fits its needs. 675 * PKI/Registrar Confirm: An acknowledgment by the PKI or registrar 676 that MUST be sent on reception of the Cert Confirm. 678 The generic messages described above may be implemented using various 679 enrollment protocols supporting authenticated self-contained objects, 680 as described in Section 3. Examples are available in Section 5. 682 4.2.4. Pledge - Registrar - enrollment status telemetry 684 The enrollment status telemetry is performed as specified in 685 [RFC8995]. In BRSKI this is described as part of the enrollment 686 phase, but due to the generalization on the enrollment protocol 687 described in this document it fits better as a separate step here. 689 4.2.5. Addressing scheme enhancements 691 BRSKI-AE provides generalizations to the addressing scheme defined in 692 BRSKI [RFC8995] to accommodate alternative enrollment protocols that 693 use authenticated self-contained objects for certification requests. 694 As this is supported by various existing enrollment protocols, they 695 can be directly employed (see also Section 5). 697 The addressing scheme in BRSKI for certification requests and the 698 related CA certificates and CSR attributes retrieval functions uses 699 the definition from EST [RFC7030]; here on the example of simple 700 enrollment: "/.well-known/est/simpleenroll". This approach is 701 generalized to the following notation: "/.well-known//" in which refers to a 703 certificate enrollment protocol. Note that enrollment is considered 704 here a message sequence that contains at least a certification 705 request and a certification response. The following conventions are 706 used in order to provide maximal compatibility to BRSKI: 708 * : MUST reference the protocol being used, 709 which MAY be CMP, CMC, SCEP, EST [RFC7030] as in BRSKI, or a newly 710 defined approach. 712 Note: additional endpoints (well-known URIs) at the registrar may 713 need to be defined by the enrollment protocol being used. 715 * : if present, the path component MUST describe, 716 depending on the enrollment protocol being used, the operation 717 requested. Enrollment protocols are expected to define their 718 request endpoints, as done by existing protocols (see also 719 Section 5). 721 4.3. Domain registrar support of alternative enrollment protocols 723 Well-known URIs for various endpoints on the domain registrar are 724 already defined as part of the base BRSKI specification or indirectly 725 by EST. In addition, alternative enrollment endpoints MAY be 726 supported at the registrar. The pledge will recognize whether its 727 preferred enrollment option is supported by the domain registrar by 728 sending a request to its preferred enrollment endpoint and evaluating 729 the HTTP response status code. 731 The following list of endpoints provides an illustrative example for 732 a domain registrar supporting several options for EST as well as for 733 CMP to be used in BRSKI-AE. The listing contains the supported 734 endpoints to which the pledge may connect for bootstrapping. This 735 includes the voucher handling as well as the enrollment endpoints. 736 The CMP related enrollment endpoints are defined as well-known URIs 737 in CMP Updates [I-D.ietf-lamps-cmp-updates] and the Lightweight CMP 738 profile [I-D.ietf-lamps-lightweight-cmp-profile]. 740 ,ct=voucher-cms+json 741 ,ct=json 742 ,ct=json 743 ;ct=pkcs7-mime 744 ;ct=pkcs7-mime 745 ;ct=pkcs7-mime 746 ;ct=pkixcmp 747 ;ct=pkixcmp 748 ;ct=pkixcmp 749 ;ct=pkixcmp 751 5. Examples for signature-wrapping using existing enrollment protocols 753 This section maps the requirements to support proof-of-possession and 754 proof-of-identity to selected existing enrollment protocols. 756 5.1. Instantiation to EST (informative) 758 When using EST [RFC7030], the following aspects and constraints need 759 to be considered and the given extra requirements need to be 760 fulfilled, which adapt Section 5.9.3 of BRSKI [RFC8995]: 762 * proof-of-possession is provided typically by using the specified 763 PKCS#10 structure in the request. Together with Full PKI 764 requests, also CRMF can be used. 766 * proof-of-identity needs to be achieved by signing the 767 certification request object using the Full PKI Request option 768 (including the /fullcmc endpoint). This provides sufficient 769 information for the RA to authenticate the pledge as the origin of 770 the request and to make an authorization decision on the received 771 certification request. Note: EST references CMC [RFC5272] for the 772 definition of the Full PKI Request. For proof-of-identity, the 773 signature of the SignedData of the Full PKI Request is performed 774 using the IDevID secret of the pledge. 776 Note: In this case the binding to the underlying TLS connection is 777 not necessary. 779 * When the RA is temporarily not available, as per Section 4.2.3 of 780 [RFC7030], an HTTP status code 202 should be returned by the 781 registrar, and the pledge will repeat the initial Full PKI Request 783 5.2. Instantiation to CMP (normative if CMP is chosen) 785 Note: Instead of referring to CMP as specified in [RFC4210] and 786 [I-D.ietf-lamps-cmp-updates], this document refers to the Lightweight 787 CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] because the 788 subset of CMP defined there is sufficient for the functionality 789 needed here. 791 When using CMP, the following requirements SHALL be fulfilled: 793 * For proof-of-possession, the approach defined in Section 4.1.1 794 (based on CRMF) or Section 4.1.4 (based on PKCS#10) of the 795 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] 796 SHALL be applied. 798 * proof-of-identity SHALL be provided by using signature-based 799 protection of the certification request message as outlined in 800 Section 3.2. of [I-D.ietf-lamps-lightweight-cmp-profile] using the 801 IDevID secret. 803 * When the Cert Response from the RA/CA is not available and if 804 polling is supported, the registrar SHALL a Cert Waiting Response 805 as specified in Sections 4.4 and 5.1.2 of 806 [I-D.ietf-lamps-lightweight-cmp-profile]. 808 * As far as requesting CA certificates or certificate request 809 attributes is supported, they SHALL be implemented as specified in 810 Sections 4.3.1 and 4.3.3 of 811 [I-D.ietf-lamps-lightweight-cmp-profile]. 813 TBD RFC Editor: please delete /* ToDo: The following aspects need to 814 be further specified: * Whether to use /getcacerts or the caPubs and 815 extraCerts fields to return trust anchor and CA Certificates * 816 Whether to use /getcertreqtemplate or modify the CRMF and use 817 raVerified * Whether to specify the usage of /p10 */ 819 6. IANA Considerations 821 This document does not require IANA actions. 823 7. Security Considerations 825 The security considerations as laid out in BRSKI [RFC8995] apply for 826 the discovery and voucher exchange as well as for the status exchange 827 information. 829 The security considerations as laid out in the Lightweight CMP 830 Profile [I-D.ietf-lamps-lightweight-cmp-profile] apply as far as CMP 831 is used. 833 8. Acknowledgments 835 We would like to thank Brian E. Carpenter, Michael Richardson, and 836 Giorgio Romanenghi for their input and discussion on use cases and 837 call flows. 839 9. References 841 9.1. Normative References 843 [I-D.ietf-lamps-cmp-updates] 844 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 845 Management Protocol (CMP) Updates", Work in Progress, 846 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 847 January 2022, . 850 [I-D.ietf-lamps-lightweight-cmp-profile] 851 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 852 Certificate Management Protocol (CMP) Profile", Work in 853 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 854 cmp-profile-10, 1 February 2022, 855 . 858 [IEEE.802.1AR_2009] 859 IEEE, "IEEE Standard for Local and metropolitan area 860 networks - Secure Device Identity", IEEE 802.1AR-2009, 861 DOI 10.1109/ieeestd.2009.5367679, 28 December 2009, 862 . 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 871 "Internet X.509 Public Key Infrastructure Certificate 872 Management Protocol (CMP)", RFC 4210, 873 DOI 10.17487/RFC4210, September 2005, 874 . 876 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 877 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 878 May 2017, . 880 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 881 "A Voucher Artifact for Bootstrapping Protocols", 882 RFC 8366, DOI 10.17487/RFC8366, May 2018, 883 . 885 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 886 and K. Watsen, "Bootstrapping Remote Secure Key 887 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 888 May 2021, . 890 9.2. Informative References 892 [IEC-62351-9] 893 International Electrotechnical Commission, "IEC 62351 - 894 Power systems management and associated information 895 exchange - Data and communications security - Part 9: 896 Cyber security key management for power system equipment", 897 IEC 62351-9, May 2017. 899 [ISO-IEC-15118-2] 900 International Standardization Organization / International 901 Electrotechnical Commission, "ISO/IEC 15118-2 Road 902 vehicles - Vehicle-to-Grid Communication Interface - Part 903 2: Network and application protocol requirements", ISO/ 904 IEC 15118-2, April 2014. 906 [NERC-CIP-005-5] 907 North American Reliability Council, "Cyber Security - 908 Electronic Security Perimeter", CIP 005-5, December 2013. 910 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1 911 (Draft)", December 2019. 913 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 914 Request Syntax Specification Version 1.7", RFC 2986, 915 DOI 10.17487/RFC2986, November 2000, 916 . 918 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 919 Certificate Request Message Format (CRMF)", RFC 4211, 920 DOI 10.17487/RFC4211, September 2005, 921 . 923 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 924 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 925 . 927 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 928 RFC 5652, DOI 10.17487/RFC5652, September 2009, 929 . 931 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 932 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 933 . 935 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 936 "Enrollment over Secure Transport", RFC 7030, 937 DOI 10.17487/RFC7030, October 2013, 938 . 940 [RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol", 941 RFC 8894, DOI 10.17487/RFC8894, September 2020, 942 . 944 [UNISIG-Subset-137] 945 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 946 FFFIS; V1.0.0", December 2015, 947 . 951 http://www.kmc-subset137.eu/index.php/download/ 953 Appendix A. Using EST for certificate enrollment 955 When using EST with BRSKI, pledges interact via TLS with the domain 956 registrar, which acts both as EST server and as registration 957 authority (RA). The TLS connection is mutually authenticated, where 958 the pledge uses its IDevID certificate issued by its manufacturer. 960 In order to provide a strong proof-of-origin of the certification 961 request, EST has the option to include in the certification request 962 the so-called tls-unique value [RFC5929] of the underlying TLS 963 channel. This binding of the proof-of-identity of the TLS client, 964 which is supposed to be the certificate requester, to the proof-of- 965 possession for the private key is conceptually non-trivial and 966 requires specific support by TLS implementations. 968 The registrar terminates the security association with the pledge at 969 TLS level and thus the binding between the certification request and 970 the authentication of the pledge. The EST server uses the 971 authenticated pledge identity provided by the IDevID for checking the 972 authorization of the pledge for the given certification request 973 before issuing to the pledge a domain-specific certificate (LDevID 974 certificate). This approach typically requires online or on-site 975 availability of the RA for performing the final authorization 976 decision for the certification request. 978 Using EST for BRSKI has the advantage that the mutually authenticated 979 TLS connection established between the pledge and the registrar can 980 be reused for protecting the message exchange needed for enrolling 981 the LDevID certificate. This strongly simplifies the implementation 982 of the enrollment message exchange. 984 Yet the use of TLS has the limitation that this cannot provide 985 auditability nor end-to-end security for the certificate enrollment 986 request because the TLS session is transient and terminates at the 987 registrar. This is a problem in particular if the enrollment is done 988 via multiple hops, part of which may not even be network-based. 990 A further limitation of using EST as the certificate enrollment 991 protocol is that due to using PKCS#10 structures in enrollment 992 requests, the only possible proof-of-possession method is a self- 993 signature, which excludes requesting certificates for key types that 994 do not support signing. 996 Appendix B. Application examples 998 This informative annex provides some detail to the application 999 examples listed in Section 1.3. 1001 B.1. Rolling stock 1003 Rolling stock or railroad cars contain a variety of sensors, 1004 actuators, and controllers, which communicate within the railroad car 1005 but also exchange information between railroad cars building a train, 1006 with track-side equipment, and/or possibly with backend systems. 1007 These devices are typically unaware of backend system connectivity. 1008 Managing certificates may be done during maintenance cycles of the 1009 railroad car, but can already be prepared during operation. 1010 Preparation will include generating certification requests, which are 1011 collected and later forwarded for processing, once the railroad car 1012 is connected to the operator backend. The authorization of the 1013 certification request is then done based on the operator's asset/ 1014 inventory information in the backend. 1016 UNISIG has included a CMP profile for enrollment of TLS certificates 1017 of on-board and track-side components in the Subset-137 specifying 1018 the ETRAM/ETCS on-line key management for train control systems 1019 [UNISIG-Subset-137]. 1021 B.2. Building automation 1023 In building automation scenarios, a detached building or the basement 1024 of a building may be equipped with sensors, actuators, and 1025 controllers that are connected with each other in a local network but 1026 with only limited or no connectivity to a central building management 1027 system. This problem may occur during installation time but also 1028 during operation. In such a situation a service technician collects 1029 the necessary data and transfers it between the local network and the 1030 central building management system, e.g., using a laptop or a mobile 1031 phone. This data may comprise parameters and settings required in 1032 the operational phase of the sensors/actuators, like a component 1033 certificate issued by the operator to authenticate against other 1034 components and services. 1036 The collected data may be provided by a domain registrar already 1037 existing in the local network. In this case connectivity to the 1038 backend PKI may be facilitated by the service technician's laptop. 1039 Alternatively, the data can also be collected from the pledges 1040 directly and provided to a domain registrar deployed in a different 1041 network as preparation for the operational phase. In this case, 1042 connectivity to the domain registrar may also be facilitated by the 1043 service technician's laptop. 1045 B.3. Substation automation 1047 In electrical substation automation scenarios, a control center 1048 typically hosts PKI services to issue certificates for Intelligent 1049 Electronic Devices (IEDs) operated in a substation. Communication 1050 between the substation and control center is performed through a 1051 proxy/gateway/DMZ, which terminates protocol flows. Note that 1052 [NERC-CIP-005-5] requires inspection of protocols at the boundary of 1053 a security perimeter (the substation in this case). In addition, 1054 security management in substation automation assumes central support 1055 of several enrollment protocols in order to support the various 1056 capabilities of IEDs from different vendors. The IEC standard 1057 IEC62351-9 [IEC-62351-9] specifies mandatory support of two 1058 enrollment protocols: SCEP [RFC8894] and EST [RFC7030] for the 1059 infrastructure side, while the IED must only support one of the two. 1061 B.4. Electric vehicle charging infrastructure 1063 For electric vehicle charging infrastructure, protocols have been 1064 defined for the interaction between the electric vehicle and the 1065 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 1066 between the charging point and the charging point operator (e.g. 1067 OCPP [OCPP]). Depending on the authentication model, unilateral or 1068 mutual authentication is required. In both cases the charging point 1069 uses an X.509 certificate to authenticate itself in TLS connections 1070 between the electric vehicle and the charging point. The management 1071 of this certificate depends, among others, on the selected backend 1072 connectivity protocol. In the case of OCPP, this protocol is meant 1073 to be the only communication protocol between the charging point and 1074 the backend, carrying all information to control the charging 1075 operations and maintain the charging point itself. This means that 1076 the certificate management needs to be handled in-band of OCPP. This 1077 requires the ability to encapsulate the certificate management 1078 messages in a transport-independent way. Authenticated self- 1079 containment will support this by allowing the transport without a 1080 separate enrollment protocol, binding the messages to the identity of 1081 the communicating endpoints. 1083 B.5. Infrastructure isolation policy 1085 This refers to any case in which network infrastructure is normally 1086 isolated from the Internet as a matter of policy, most likely for 1087 security reasons. In such a case, limited access to external PKI 1088 services will be allowed in carefully controlled short periods of 1089 time, for example when a batch of new devices is deployed, and 1090 forbidden or prevented at other times. 1092 B.6. Sites with insufficient level of operational security 1094 The registration authority performing (at least part of) the 1095 authorization of a certification request is a critical PKI component 1096 and therefore requires higher operational security than components 1097 utilizing the issued certificates for their security features. CAs 1098 may also demand higher security in the registration procedures. 1099 Especially the CA/Browser forum currently increases the security 1100 requirements in the certificate issuance procedures for publicly 1101 trusted certificates. In case the on-site components of the target 1102 domain cannot be operated securely enough for the needs of a 1103 registration authority, this service should be transferred to an off- 1104 site backend component that has a sufficient level of security. 1106 Appendix C. History of changes TBD RFC Editor: please delete 1108 From IETF draft 04 -> IETF draft 05: 1110 * David von Oheimb became the editor. 1112 * Streamline wording, consolidate terminology, improve grammar, etc. 1114 * Shift the emphasis towards supporting alternative enrollment 1115 protocols. 1117 * Update the title accordingly - preliminary change to be approved. 1119 * Move comments on EST and detailed application examples to 1120 informative annex. 1122 * Move the remaining text of section 3 as two new sub-sections of 1123 section 1. 1125 From IETF draft 03 -> IETF draft 04: 1127 * Moved UC2 related parts defining the pledge in responder mode to a 1128 separate document. This required changes and adaptations in 1129 several sections. Main changes concerned the removal of the 1130 subsection for UC2 as well as the removal of the YANG model 1131 related text as it is not applicable in UC1. 1133 * Updated references to the Lightweight CMP Profile. 1135 * Added David von Oheimb as co-author. 1137 From IETF draft 02 -> IETF draft 03: 1139 * Housekeeping, deleted open issue regarding YANG voucher-request in 1140 UC2 as voucher-request was enhanced with additional leaf. 1142 * Included open issues in YANG model in UC2 regarding assertion 1143 value agent-proximity and CSR encapsulation using SZTP sub 1144 module). 1146 From IETF draft 01 -> IETF draft 02: 1148 * Defined call flow and objects for interactions in UC2. Object 1149 format based on draft for JOSE signed voucher artifacts and 1150 aligned the remaining objects with this approach in UC2 . 1152 * Terminology change: issue #2 pledge-agent -> registrar-agent to 1153 better underline agent relation. 1155 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode 1156 and pledge-responder-mode to better address the pledge operation. 1158 * Communication approach between pledge and registrar-agent changed 1159 by removing TLS-PSK (former section TLS establishment) and 1160 associated references to other drafts in favor of relying on 1161 higher layer exchange of signed data objects. These data objects 1162 are included also in the pledge-voucher-request and lead to an 1163 extension of the YANG module for the voucher-request (issue #12). 1165 * Details on trust relationship between registrar-agent and 1166 registrar (issue #4, #5, #9) included in UC2. 1168 * Recommendation regarding short-lived certificates for registrar- 1169 agent authentication towards registrar (issue #7) in the security 1170 considerations. 1172 * Introduction of reference to agent signing certificate using SKID 1173 in agent signed data (issue #11). 1175 * Enhanced objects in exchanges between pledge and registrar-agent 1176 to allow the registrar to verify agent-proximity to the pledge 1177 (issue #1) in UC2. 1179 * Details on trust relationship between registrar-agent and pledge 1180 (issue #5) included in UC2. 1182 * Split of use case 2 call flow into sub sections in UC2. 1184 From IETF draft 00 -> IETF draft 01: 1186 * Update of scope in Section 1.2 to include in which the pledge acts 1187 as a server. This is one main motivation for use case 2. 1189 * Rework of use case 2 to consider the transport between the pledge 1190 and the pledge-agent. Addressed is the TLS channel establishment 1191 between the pledge-agent and the pledge as well as the endpoint 1192 definition on the pledge. 1194 * First description of exchanged object types (needs more work) 1196 * Clarification in discovery options for enrollment endpoints at the 1197 domain registrar based on well-known endpoints in Section 4.3 do 1198 not result in additional /.well-known URIs. Update of the 1199 illustrative example. Note that the change to /brski for the 1200 voucher related endpoints has been taken over in the BRSKI main 1201 document. 1203 * Updated references. 1205 * Included Thomas Werner as additional author for the document. 1207 From individual version 03 -> IETF draft 00: 1209 * Inclusion of discovery options of enrollment endpoints at the 1210 domain registrar based on well-known endpoints in Section 4.3 as 1211 replacement of section 5.1.3 in the individual draft. This is 1212 intended to support both use cases in the document. An 1213 illustrative example is provided. 1215 * Missing details provided for the description and call flow in 1216 pledge-agent use case UC2, e.g. to accommodate distribution of CA 1217 certificates. 1219 * Updated CMP example in Section 5 to use Lightweight CMP instead of 1220 CMP, as the draft already provides the necessary /.well-known 1221 endpoints. 1223 * Requirements discussion moved to separate section in Section 3. 1224 Shortened description of proof of identity binding and mapping to 1225 existing protocols. 1227 * Removal of copied call flows for voucher exchange and registrar 1228 discovery flow from [RFC8995] in Section 4 to avoid doubling or 1229 text or inconsistencies. 1231 * Reworked abstract and introduction to be more crisp regarding the 1232 targeted solution. Several structural changes in the document to 1233 have a better distinction between requirements, use case 1234 description, and solution description as separate sections. 1235 History moved to appendix. 1237 From individual version 02 -> 03: 1239 * Update of terminology from self-contained to authenticated self- 1240 contained object to be consistent in the wording and to underline 1241 the protection of the object with an existing credential. Note 1242 that the naming of this object may be discussed. An alternative 1243 name may be attestation object. 1245 * Simplification of the architecture approach for the initial use 1246 case having an offsite PKI. 1248 * Introduction of a new use case utilizing authenticated self- 1249 contain objects to onboard a pledge using a commissioning tool 1250 containing a pledge-agent. This requires additional changes in 1251 the BRSKI call flow sequence and led to changes in the 1252 introduction, the application example,and also in the related 1253 BRSKI-AE call flow. 1255 * Update of provided examples of the addressing approach used in 1256 BRSKI to allow for support of multiple enrollment protocols in 1257 Section 4.2.5. 1259 From individual version 01 -> 02: 1261 * Update of introduction text to clearly relate to the usage of 1262 IDevID and LDevID. 1264 * Definition of the addressing approach used in BRSKI to allow for 1265 support of multiple enrollment protocols in Section 4.2.5. This 1266 section also contains a first discussion of an optional discovery 1267 mechanism to address situations in which the registrar supports 1268 more than one enrollment approach. Discovery should avoid that 1269 the pledge performs a trial and error of enrollment protocols. 1271 * Update of description of architecture elements and changes to 1272 BRSKI in Section 4.1. 1274 * Enhanced consideration of existing enrollment protocols in the 1275 context of mapping the requirements to existing solutions in 1276 Section 3 and in Section 5. 1278 From individual version 00 -> 01: 1280 * Update of examples, specifically for building automation as well 1281 as two new application use cases in Appendix B. 1283 * Deletion of asynchronous interaction with MASA to not complicate 1284 the use case. Note that the voucher exchange can already be 1285 handled in an asynchronous manner and is therefore not considered 1286 further. This resulted in removal of the alternative path the 1287 MASA in Figure 1 and the associated description in Section 4.1. 1289 * Enhancement of description of architecture elements and changes to 1290 BRSKI in Section 4.1. 1292 * Consideration of existing enrollment protocols in the context of 1293 mapping the requirements to existing solutions in Section 3. 1295 * New section starting Section 5 with the mapping to existing 1296 enrollment protocols by collecting boundary conditions. 1298 Authors' Addresses 1300 David von Oheimb (editor) 1301 Siemens AG 1302 Otto-Hahn-Ring 6 1303 81739 Munich 1304 Germany 1305 Email: david.von.oheimb@siemens.com 1306 URI: https://www.siemens.com/ 1308 Steffen Fries 1309 Siemens AG 1310 Otto-Hahn-Ring 6 1311 81739 Munich 1312 Germany 1313 Email: steffen.fries@siemens.com 1314 URI: https://www.siemens.com/ 1316 Hendrik Brockhaus 1317 Siemens AG 1318 Otto-Hahn-Ring 6 1319 81739 Munich 1320 Germany 1321 Email: hendrik.brockhaus@siemens.com 1322 URI: https://www.siemens.com/ 1323 Eliot Lear 1324 Cisco Systems 1325 Richtistrasse 7 1326 CH-8304 Wallisellen 1327 Switzerland 1328 Phone: +41 44 878 9200 1329 Email: lear@cisco.com