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