idnits 2.17.1 draft-sipos-acme-dtnnodeid-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2020) is 1399 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-25 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-22 == Outdated reference: A later version (-14) exists of draft-ietf-acme-email-smime-08 == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-21 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Experimental June 26, 2020 5 Expires: December 28, 2020 7 Automated Certificate Management Environment (ACME) Delay-Tolerant 8 Networking (DTN) Node ID Validation Extension 9 draft-sipos-acme-dtnnodeid-01 11 Abstract 13 This document specifies an extension to the Automated Certificate 14 Management Environment (ACME) protocol which allows validating the 15 Delay-Tolerant Networking (DTN) Node ID for an ACME client. The use 16 of a Uniform Resource Identifier (URI) as ACME identifier is also 17 specified. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 28, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. URI Identifier . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 4 57 4.1. DTN Node ID Challenge Request Object . . . . . . . . . . 6 58 4.2. DTN Node ID Challenge Response Object . . . . . . . . . . 7 59 4.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 8 60 4.4. ACME Node ID Validation Response Bundles . . . . . . . . 9 61 4.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 10 62 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6.1. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 11 65 6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 11 66 6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 11 67 6.4. Multiple Certificate Claims . . . . . . . . . . . . . . . 12 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 12 70 7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 12 71 7.3. BP Bundle Administrative Record Types . . . . . . . . . . 13 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 15 77 Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 16 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Although the original purpose of the Automatic Certificate Management 83 Environment (ACME) [RFC8555] was to allow PKI certificate authorities 84 to validate network domain names of clients, the same mechanism can 85 be used to validate any of the subject claims supported by the PKIX 86 profile [RFC5280]. In the case of this specification, the claim 87 being validated is a Subject Alternative Name (SAN) of type Uniform 88 Resource Identifier (URI) used to represent the Node ID of a Delay- 89 Tolerant Networking (DTN) Node. 91 The basic unit of data exchange in a DTN is a Bundle 92 [I-D.ietf-dtn-bpbis], which consists of a data payload with 93 accompanying metadata. A DTN Node ID is a URI with a specific set of 94 allowed schemes [I-D.ietf-dtn-bpbis] which determines how bundles are 95 routed within a DTN. A Node ID is used to identify the source and 96 destination of a Bundle and is used for routing through intermediate 97 nodes. More detailed descriptions of the rationale and capabilities 98 of these networks can be found in "Delay-Tolerant Network 99 Architecture" [RFC4838]. 101 When a certificate request contains a SAN URI which could be used as 102 a DTN Node ID, the ACME server offers a challenge type to validate 103 that Node ID. In order to validate a Node ID, the ACME server sends 104 an ACME Node ID Validation Challenge Bundle with a destination of the 105 Node ID being validated. The BP agent on that node receives the 106 Challenge Bundle, generates an ACME signature, and sends an ACME Node 107 ID Validation Response Bundle with the signature. Finally, the ACME 108 server receives the Response Bundle and checks that the signature 109 came from the client account key associated with the original 110 request. 112 Because the DTN Node ID is used both for routing bundles between BP 113 agents and for multiplexing services within a BP agent, there is no 114 possibility to separate the ACME validation of a Node ID from normal 115 bundle handling on that same Node ID. This leaves Bundle 116 administrative records as a way to leave the Node ID unchanged while 117 disambiguating from normal service data bundles. 119 The scope and behavior of this validation mechanism is similar to 120 that of secured email validation of [I-D.ietf-acme-email-smime]. For 121 that reason some token splitting terminology in this document is 122 taken from the email specification. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 In this document, several terms are shortened for the sake of 133 terseness. These terms are: 135 Challenge Request: This is a shortened form of the full "DTN Node ID 136 Challenge Request Object". It is a JSON object created by the 137 ACME server for challenge type "dtn-nodeid-01". 139 Challenge Response: This is a shortened form of the full "DTN Node 140 ID Challenge Response Object". It is a JSON object created by the 141 ACME client to authorize a challenge type "dtn-nodeid-01". 143 Challenge Bundle: This is a shortened form of the full "ACME Node ID 144 Validation Challenge Bundle". It is a Bundle created by the ACME 145 server to challenge a Node ID claim. 147 Response Bundle: This is a shortened form of the full "ACME Node ID 148 Validation Response Bundle". It is a Bundle created by the BP 149 agent managed by the ACME client to validate a Node ID claim. 151 3. URI Identifier 153 This specification is the first to make use of a URI to identify a 154 service for a certificate request in ACME. The URI-type identifier 155 is general purpose, and validating ownership of a URI requires a 156 specific purpose related to its "scheme" component. In this 157 document, the only purpose for which a URI identifier is validated is 158 as a DTN Node ID (see Section 4), but other specifications can define 159 challenge types for other URI uses. 161 Identifiers of type "uri" MUST appear in an extensionRequest 162 attribute [RFC2985] requesting a subjectAltName extension of type 163 uniformResourceIdentifier having a value consistent with the 164 requirements of [RFC3986]. 166 If an ACME server wishes to request proof that a user controls a URI, 167 it SHALL create an authorization with the identifier type "uri". The 168 value field of the identifier SHALL contain the textual form of the 169 URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT 170 decode or attempt to dereference the URI value on its own. It is the 171 responsibility of a validation method to ensure the URI ownership via 172 scheme-specific means authorized by the ACME client. 174 An identifier for the URL "dtn://example/service" would be formatted 175 as: 177 {"type": "uri", "value": "dtn://example/service"} 179 4. DTN Node ID Validation 181 The DTN Node ID validation method proves control over a Node ID by 182 requiring the ACME client to configure a BP agent to respond to 183 specific Challenge Bundles sent from the ACME server. The ACME 184 server validates control of the Node ID URI by verifying that 185 received Response Bundles correspond with the BP Node and client 186 account key being validated. 188 Similar to the ACME use case for validating email address ownership 189 [I-D.ietf-acme-email-smime], this challenge splits the token into two 190 parts. Each part reaches the client through a different channel: one 191 via the ACME channel in the challenge object, the other via the DTN 192 channel within the Challenge Bundle. The Key Authorization result 193 requires that the ACME client have access to the results of each 194 channel to get both parts of the token. 196 The DTN Node ID Challenge SHALL only be allowed for URIs usable as a 197 DTN Node ID, which are currently the schemes "dtn" and "ipn" as 198 defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node 199 ID validation, the ACME server SHALL define a challenge object in 200 accordance with Section 4.1. Once this challenge object is defined, 201 the ACME client may begin the validation. 203 To initiate a Node ID validation, the ACME client performs the 204 following steps: 206 1. The ACME client obtains the challenge from the 207 challenge object in accordance with Section 4.1. 209 2. The ACME client indicates to the BP agent the challenge which is authorized for use. 212 3. The ACME client POSTs a challenge response to the challenge URL 213 on the ACME server accordance with Section 7.5.1 of [RFC8555]. 214 The payload object is constructed in accordance with Section 4.2. 216 4. The ACME client waits for indication from the BP agent that a 217 Challenge Bundle has been received, including its 218 payload. 220 5. The ACME client concatenates with and 221 computes the Key Authorization in accordance with Section 8.1 of 222 [RFC8555] using the full token and client account key. 224 6. The ACME client indicates to the BP agent the Key Authorization 225 result, which will result in a Response Bundle being sent back to 226 the ACME server. 228 7. The ACME client waits for the authorization to be finalized on 229 the ACME server in accordance with Section 7.5.1 of [RFC8555]. 231 8. Once the challenge is completed (successfully or not), the ACME 232 client indicates to the BP agent that the validation is no longer usable. 235 Upon receiving a challenge response from an ACME client, the ACME 236 server verifies the client's control over the Node ID by performing 237 the following steps: 239 1. The ACME server generates the two-part challenge token and 240 computes the expected Key Authorization in accordance with 241 Section 8.1 of [RFC8555] using the concatenated token and client 242 account key. 244 2. The ACME server sends one or more Challenge Bundles in accordance 245 with Section 4.3. 247 3. The ACME server waits for Response Bundle(s) for a limited 248 interval of time. A default response interval, used when the 249 challenge does not contain an RTT, SHOULD be a configurable 250 parameter of the ACME server. If the ACME client indicated an 251 RTT value in the challenge object, the response interval SHOULD 252 be twice the RTT (with limiting logic applied as described 253 below). The lower limit on response waiting time is network- 254 specific, but SHOULD be no shorter than one second. The upper 255 limit on response waiting time is network-specific, but SHOULD be 256 no longer than one minute (60 seconds) for a terrestrial-only 257 DTN. Responses are encoded in accordance with Section 4.4. 259 4. Once received and decoded, the ACME server checks the contents of 260 each Response Bundle in accordance with Section 4.5. After all 261 Challenge Bundles have either been responded to or timed-out, the 262 validation procedure is successful only if all responses are 263 successful. 265 An ACME server MAY send multiple challenges from different origins in 266 the DTN network to avoid possible man-in-the-middle (MitM) attacks, 267 as recommended in Section 10.2 of [RFC8555]. If responses are 268 received from multiple challenges, any response failure SHALL cause a 269 failure of the overall validation. Each response failure MAY be 270 indicated to the ACME client as a validation subproblem. 272 When responding to a Challenge Bundle, a BP agent SHALL send a single 273 Response Bundle in accordance with Section 4.4. A BP agent SHALL 274 respond to ACME challenges only within the interval of time, only for 275 the Node ID, and only for the validation token indicated by the ACME 276 client. A BP agent SHALL respond to multiple challenges with the 277 same parameters. These correspond with the ACME server validating 278 via multiple routing paths. 280 4.1. DTN Node ID Challenge Request Object 282 The DTN Node ID Challenge request object is defined by the ACME 283 server when it supports validating Node IDs. 285 The DTN Node ID Challenge request object has the following content: 287 type (required, string): The string "dtn-nodeid-01". 289 token-part2 (required, string): A random value that uniquely 290 identifies the challenge. This value MUST have at least 64 bits 291 of entropy. It MUST NOT contain any characters outside the 292 base64url alphabet as described in Section 5 of [RFC4648]. 293 Trailing '=' padding characters MUST be stripped. See [RFC4086] 294 for additional information on randomness requirements. 296 { 297 "type": "dtn-nodeid-01", 298 "url": "https://example.com/acme/chall/prV_B7yEyA4", 299 "status": "pending", 300 "token-part2": "qXjSp7npR2Y" 301 } 303 The only over-the-wire data required by ACME for a Challenge Bundle 304 is a nonce token, but the response data needs a client account key to 305 generate the Key Authorization. The client account key is kept 306 within the ACME client, the BP agent needs only the derived Key 307 Authorization for its Response Bundle. 309 4.2. DTN Node ID Challenge Response Object 311 The DTN Node ID Challenge response object is defined by the ACME 312 client when it authorizes validation of a Node ID. Because a DTN has 313 the potential for significantly longer delays than a non-DTN network, 314 the ACME client is able to inform the ACME server if a particular 315 validation round-trip is expected to take longer than normal network 316 delays (on the order of seconds). 318 The DTN Node ID Challenge response object has the following content: 320 rtt (optional, number): An expected round-trip time (RTT), in 321 seconds, between sending a Challenge Bundle and receiving a 322 Response Bundle. This value is a hint to the ACME server for how 323 long to wait for responses but is not authoritative. The minimum 324 RTT value SHALL be zero. There is no special significance to 325 zero-value RTT, it simply indicates the response is expected in 326 less than the least significant unit used by the ACME client. 328 { 329 "rtt": 300.0 330 } 332 A challenge response is not sent until the BP agent has been 333 configured to properly respond to the challenge, so the RTT value is 334 meant to indicate any node-specific path delays expected to 335 encountered from the ACME server. Because there is no requirement on 336 the path (or paths) which bundles may traverse between the ACME 337 server and the BP agent, and the ACME server is likely to attempt 338 some path diversity, the RTT value SHOULD be pessimistic. 340 4.3. ACME Node ID Validation Challenge Bundles 342 Each ACME Node ID Validation Challenge Bundle has parameters as 343 listed here: 345 Bundle Processing Control Flags: The payload SHALL be indicated as 346 an administrative record. 348 Destination EID: The Destination EID SHALL be identical to the Node 349 ID being validated. The ACME server SHOULD NOT perform URI 350 normalization on the Node ID given by the ACME client. 352 Source Node EID: The Source Node EID SHALL indicate the Endpoint ID 353 of the ACME server performing the challenge. 355 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 356 to the time at which the challenge was generated. The Lifetime 357 SHALL indicate the response interval for which ACME server will 358 accept responses to this challenge. 360 Administrative Record Type Code: Set to the ACME Node ID Validation 361 type code defined by this specification. 363 Administrative Record Content: The ACME challenge administrative 364 record content SHALL consist of a CBOR array with two elements. 365 The first element SHALL be a challenge indicator value 1, 366 represented as a CBOR unsigned integer. The second element SHALL 367 be the ACME challenge token-part1, represented as a CBOR text 368 string. The token-part1 is a random value that uniquely 369 identifies the challenge. This value MUST have at least 64 bits 370 of entropy. See [RFC4086] for additional information on 371 randomness requirements. 373 An ACME challenge administrative record would have CBOR diagnostic 374 notation as: 376 [ 377 1, / challenge indicator / 378 "LVMo24VdNAw" / token-part1 / 379 ] 381 Challenge Bundles SHOULD be BIB-signed in accordance with 382 [I-D.ietf-dtn-bpsec] if the ACME server is capable of signing 383 bundles. BP agents MAY refuse to respond to a Challenge Bundle which 384 is signed by a known ACME server but has an invalid signature. 385 Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any 386 other method). 388 4.4. ACME Node ID Validation Response Bundles 390 Each ACME Node ID Validation Response Bundle has parameters as listed 391 here: 393 Bundle Processing Control Flags: The payload SHALL be indicated as 394 an administrative record. 396 Destination EID: The Destination EID SHALL be identical to the 397 Source Node EID of the Challenge Bundle to which this response 398 corresponds. 400 Source Node EID: The Source Node EID SHALL be identical to the the 401 Destination EID of the Challenge Bundle to which this response 402 corresponds. 404 Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set 405 to the time at which the response was generated. The response 406 Lifetime SHALL indicate the response interval remaining if the 407 Challenge Bundle indicated a limited Lifetime. 409 Administrative Record Type Code: Set to the ACME Node ID Validation 410 type code defined by this specification. 412 Administrative Record Content: The ACME response administrative 413 record content SHALL consist of a CBOR array with two elements. 414 The first element SHALL be a response indicator value 2, 415 represented as a CBOR unsigned integer. The second element SHALL 416 be the ACME Key Authorization in accordance with Section 8.1 of 417 [RFC8555], represented as a CBOR text string. 419 An ACME response administrative record would have CBOR diagnostic 420 notation (truncated for terseness) as: 422 [ 423 2, / response indicator / 424 "qXjSp7npR2YtUyjbhV00DA.9jg46WB3...fm21mqTI" / key authorization / 425 ] 427 Response Bundles MAY be BIB-signed in accordance with 428 [I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles. 429 A BIB on the bundle gives no more security than the Key Authorization 430 itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or 431 any other method). 433 4.5. Response Bundle Checks 435 A proper Response Bundle meets all of the following criteria: 437 The Response Bundle was received within the time interval allowed 438 for the challenge. 440 The Response Bundle Source Node ID is identical to the Node ID 441 being validated. The comparison of Node IDs SHALL use the 442 comparison logic of [RFC3986] and scheme-based normalization of 443 those schemes specified in [I-D.ietf-dtn-bpbis]. 445 The response payload contains the expected Key Authorization 446 computed by the ACME server. 448 Any of the failures above SHALL cause the validation to fail. Any of 449 the failures above SHOULD be indicated as subproblems to the ACME 450 client. 452 5. Implementation Status 454 [NOTE to the RFC Editor: please remove this section before 455 publication, as well as the reference to [RFC7942] and 456 [github-acme-dtnnodeid].] 458 This section records the status of known implementations of the 459 protocol defined by this specification at the time of posting of this 460 Internet-Draft, and is based on a proposal described in [RFC7942]. 461 The description of implementations in this section is intended to 462 assist the IETF in its decision processes in progressing drafts to 463 RFCs. Please note that the listing of any individual implementation 464 here does not imply endorsement by the IETF. Furthermore, no effort 465 has been spent to verify the information presented here that was 466 supplied by IETF contributors. This is not intended as, and must not 467 be construed to be, a catalog of available implementations or their 468 features. Readers are advised to note that other implementations can 469 exist. 471 An example implementation of the this draft of ACME has been created 472 as a GitHub project [github-acme-dtnnodeid] and is intended to use as 473 a proof-of-concept and as a possible source of interoperability 474 testing. This example implementation only constructs encoded bundles 475 and does not attempt to provide a full BP Agent interface. 477 6. Security Considerations 479 This section separates security considerations into threat categories 480 based on guidance of BCP 72 [RFC3552]. 482 6.1. Threat: Passive Leak of Bundle Data 484 Because this challenge mechanism is used to bootstrap security 485 between DTN Nodes, the challenge and its response are likely to be 486 transferred in plaintext. The ACME data itself is a random token 487 (nonce) and a cryptographic signature, so there is no sensitive data 488 to be leaked within the Node ID Validation bundle exchange. 490 Under certain circumstances, when BPSEC key material is available to 491 the BP agent managed by the ACME client, the use of a BCB for the 492 Request Bundle and/or Response Bundle can give additional 493 confidentiality to the bundle metadata. This is not expected to be a 494 general use case, as the whole point of ACME is to validate 495 identifiers of untrusted client services. 497 6.2. Threat: BP Node Impersonation 499 As described in Section 8.1 of [RFC8555], it is possible for an 500 active attacker to alter data on both ACME client channel and the DTN 501 validation channel. 503 One way to mitigate single-path MitM attacks is to attempt validation 504 of the same Node ID via multiple bundle routing paths, as recommended 505 in Section 4. It is not a trivial task to guarantee bundle routing 506 though, so more advanced techniques such as onion routing (using 507 bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) could be 508 employed. 510 Under certain circumstances, when BPSEC key material is available to 511 the BP agent managed by the ACME client, the use of a BIB signature 512 on the Response Bundle can give additional assurance that the 513 response is coming from a valid BP agent. 515 6.3. Threat: Denial of Service 517 The behaviors described in this section all amount to a potential 518 denial-of-service to a BP agent. 520 A malicious entity can continually send ACME Node ID challenges to a 521 BP agent. The victim BP agent can ignore ACME challenges which do 522 not conform to the specific time interval and challenge token for 523 which the ACME client has informed the BP agent that challenges are 524 expected. The victim BP agent can require all Challenge Bundles to 525 be BIB-signed to ensure authenticity of the challenge. 527 Similar to other validation methods, an ACME server validating a DTN 528 Node ID could be used as a denial of service amplifier. For this 529 reason any ACME server can rate-limit validation activities for 530 individual clients and individual certificate requests. 532 6.4. Multiple Certificate Claims 534 A single certificate request can contain a mixed set of SAN claims, 535 including combinations of "dns" and "uri" claims. There is no 536 restriction on how a certificate combines these claims, but each 537 claim needs to be validated to issue such a certificate. This is no 538 different than the existing behavior of [RFC8555] but is mentioned 539 here to make sure that CA policy handles such situations. The 540 specific use case of [I-D.ietf-dtn-tcpclv4] allows, and for some 541 network policies requires, that a certificate authenticate both the 542 DNS name of an entity as well as the Node ID of the entity. 544 7. IANA Considerations 546 This specification adds to the ACME registry and BP registry for this 547 behavior. 549 7.1. ACME Identifier Type 551 Within the "Automated Certificate Management Environment (ACME) 552 Protocol" registry [IANA-ACME], the following entry has been added to 553 the "ACME Identifier Types" sub-registry. 555 +-------+--------------------+ 556 | Label | Reference | 557 +-------+--------------------+ 558 | uri | This specification | 559 +-------+--------------------+ 561 7.2. ACME Validation Method 563 Within the "Automated Certificate Management Environment (ACME) 564 Protocol" registry [IANA-ACME], the following entry has been added to 565 the "ACME Validation Methods" sub-registry. 567 +---------------+-----------------+------+--------------------+ 568 | Label | Identifier Type | ACME | Reference | 569 +---------------+-----------------+------+--------------------+ 570 | dtn-nodeid-01 | uri | Y | This specification | 571 +---------------+-----------------+------+--------------------+ 573 7.3. BP Bundle Administrative Record Types 575 Within the "Bundle Protocol" registry [IANA-BP], the following entry 576 has been added to the "Bundle Administrative Record Types" sub- 577 registry. [NOTE to the RFC Editor: For RFC5050 compatibility this 578 value needs to be no larger than 15, but such compatibility is not 579 needed. BPbis has no upper limit on this code point value.] 581 +-------+-------------------------+--------------------+ 582 | Value | Description | Reference | 583 +-------+-------------------------+--------------------+ 584 | TBD | ACME Node ID Validation | This specification | 585 +-------+-------------------------+--------------------+ 587 8. Acknowledgments 589 This specification is based on DTN use cases related to PKIX 590 certificate generation. 592 9. References 594 9.1. Normative References 596 [I-D.ietf-dtn-bpbis] 597 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 598 Version 7", draft-ietf-dtn-bpbis-25 (work in progress), 599 May 2020. 601 [I-D.ietf-dtn-bpsec] 602 Birrane, E. and K. McKeever, "Bundle Protocol Security 603 Specification", draft-ietf-dtn-bpsec-22 (work in 604 progress), March 2020. 606 [IANA-ACME] 607 IANA, "Automated Certificate Management Environment (ACME) 608 Protocol", . 610 [IANA-BP] IANA, "Bundle Protocol", 611 . 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 619 Classes and Attribute Types Version 2.0", RFC 2985, 620 DOI 10.17487/RFC2985, November 2000, 621 . 623 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 624 Text on Security Considerations", BCP 72, RFC 3552, 625 DOI 10.17487/RFC3552, July 2003, 626 . 628 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 629 Resource Identifier (URI): Generic Syntax", STD 66, 630 RFC 3986, DOI 10.17487/RFC3986, January 2005, 631 . 633 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 634 "Randomness Requirements for Security", BCP 106, RFC 4086, 635 DOI 10.17487/RFC4086, June 2005, 636 . 638 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 639 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 640 . 642 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 643 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 644 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 645 April 2007, . 647 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 648 Housley, R., and W. Polk, "Internet X.509 Public Key 649 Infrastructure Certificate and Certificate Revocation List 650 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 651 . 653 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 654 Code: The Implementation Status Section", BCP 205, 655 RFC 7942, DOI 10.17487/RFC7942, July 2016, 656 . 658 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 659 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 660 May 2017, . 662 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 663 Kasten, "Automatic Certificate Management Environment 664 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 665 . 667 9.2. Informative References 669 [github-acme-dtnnodeid] 670 Sipos, B., "ACME Node ID Example Implementation", 671 . 673 [I-D.ietf-acme-email-smime] 674 Melnikov, A., "Extensions to Automatic Certificate 675 Management Environment for end user S/MIME certificates", 676 draft-ietf-acme-email-smime-08 (work in progress), June 677 2020. 679 [I-D.ietf-dtn-bibect] 680 Burleigh, S., "Bundle-in-Bundle Encapsulation", draft- 681 ietf-dtn-bibect-03 (work in progress), February 2020. 683 [I-D.ietf-dtn-tcpclv4] 684 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 685 Tolerant Networking TCP Convergence Layer Protocol Version 686 4", draft-ietf-dtn-tcpclv4-21 (work in progress), June 687 2020. 689 Appendix A. Administrative Record Types CDDL 691 [NOTE to the RFC Editor: The "TBD" in this CDDL is replaced by the 692 "ACME Node ID Validation" administrative record type code.] 694 The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles 695 is: 697 ; All ACME records have the same structure 698 $admin-record /= [TBD, acme-record] 699 acme-record = $acme-record .within acme-record-structure 700 acme-record-structure = [ 701 type-code: uint, 702 acme-content: tstr 703 ] 704 ; The type code distinguishes the purpose 705 $acme-record /= [ 706 1, 707 challenge-token: tstr 708 ] 709 $acme-record /= [ 710 2, 711 key-authorization: tstr 712 ] 714 Appendix B. Example Bundles 716 Author's Address 718 Brian Sipos 719 RKF Engineering Solutions, LLC 720 7500 Old Georgetown Road 721 Suite 1275 722 Bethesda, MD 20814-6198 723 United States of America 725 Email: BSipos@rkf-eng.com