--- 1/draft-ietf-acme-dtnnodeid-06.txt 2021-11-14 19:13:11.788269883 -0800 +++ 2/draft-ietf-acme-dtnnodeid-07.txt 2021-11-14 19:13:11.844271287 -0800 @@ -1,19 +1,19 @@ Automated Certificate Management Environment B. Sipos Internet-Draft RKF Engineering -Intended status: Experimental 13 October 2021 -Expires: 16 April 2022 +Intended status: Experimental 14 November 2021 +Expires: 18 May 2022 Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension - draft-ietf-acme-dtnnodeid-06 + draft-ietf-acme-dtnnodeid-07 Abstract This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 16 April 2022. + This Internet-Draft will expire on 18 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -333,32 +333,32 @@ server validates control of the Node ID by verifying that received Response Bundles correspond with the BP Node and client account key being validated. Similar to the ACME use case for validating email address ownership [RFC8823], this challenge splits the token into several parts, each being transported by a different channel, and the Key Authorization result requires combining all parts of the token. The token parts are: - token-chal This token is unique to, and identifies, each ACME + token-chal: This token is unique to, and identifies, each ACME authorization. It is contained in the Challenge Object of Section 3.1 as well as the Challenge Bundle of Section 3.3 and Response Bundle of Section 3.4. Each authorization can consist of multiple Challenge Bundles (e.g. taking different routes), but they all share the same token-chal value. This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization) and also allows the ACME client's BP agent to filter-in only valid Challenge Bundles. This token is also accessible to DTN on-path eavesdroppers. - token-bundle This token is unique to each Challenge Bundle sent by + token-bundle: This token is unique to each Challenge Bundle sent by the ACME server. It is contained in the Challenge Bundle of Section 3.3 and Response Bundle of Section 3.4. This ensures that the Key Authorization is bound to the ability to receive the Challenge Bundle and not just have access to the ACME Challenge Object. This token is also accessible to DTN on-path eavesdroppers. For each ACME server, the pair of token-chal and token-bundle values is the unique correlator between Challenge and Response bundles. Because multiple Challenge Bundles can be sent to validate the same @@ -467,24 +467,24 @@ source (required, array of string): An unordered list of possible source Node ID of bundles originating at the BP agent(s) of the ACME server. See Section 3.5 for a discussion of multi- perspective validation using multiple sources. The array SHALL be non-empty. The array MAY contain Node IDs which are not actually used as a challenge bundle source. token-chal (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits - of entropy. It MUST contain any characters outside the base64url - alphabet as described in Section 5 of [RFC4648]. Trailing '=' - padding characters MUST be stripped. See [RFC4086] for additional - information on randomness requirements. + of entropy. It MUST NOT contain any characters outside the + base64url alphabet as described in Section 5 of [RFC4648]. + Trailing '=' padding characters MUST be stripped. See [RFC4086] + for additional information on randomness requirements. { "type": "dtn-nodeid-01", "url": "https://example.com/acme/chall/prV_B7yEyA4", "source": ["dtn://acme-server/"], "token-chal": "tPUZNY4ONIk6LxErRFEjVw" } The token-chal value included in this object is fixed for the entire challenge, and may correspond with multiple separate token-bundle values when multiple Challenge Bundles are sent for a single @@ -968,38 +968,38 @@ This specification adds to the ACME registry and BP registry for this behavior. 8.1. ACME Identifier Types Within the "Automated Certificate Management Environment (ACME) Protocol" registry [IANA-ACME], the following entry has been added to the "ACME Identifier Types" sub-registry. - +=======+==================================+ + +===========+==================================+ | Label | Reference | - +=======+==================================+ - | uri | This specification and [RFC3986] | - +-------+----------------------------------+ + +===========+==================================+ + | bundleEID | This specification and [RFC3986] | + +-----------+----------------------------------+ Table 1 8.2. ACME Validation Methods Within the "Automated Certificate Management Environment (ACME) Protocol" registry [IANA-ACME], the following entry has been added to the "ACME Validation Methods" sub-registry. +===============+=================+======+====================+ | Label | Identifier Type | ACME | Reference | +===============+=================+======+====================+ - | dtn-nodeid-01 | uri | Y | This specification | + | dtn-nodeid-01 | bundleEID | Y | This specification | +---------------+-----------------+------+--------------------+ Table 2 8.3. Bundle Administrative Record Types Within the "Bundle Protocol" registry [IANA-BP], the following entries have been added to the "Bundle Administrative Record Types" sub-registry. @@ -1232,21 +1232,21 @@ For the single challenge bundle in this example, the token-bundle (transported as byte string via BP) has the base64url-encoded value of: "p3yRYFU4KxwQaHQjJ2RdiQ" The minimal-but-valid Challenge Bundle is shown in Figure 2. This challenge requires that the ACME client respond within a 60 second time window. - [ + [_ [ 7, / BP version / 0x22, / flags: user-app-ack, payload-is-an-admin-record / 0, / CRC type: none / [1, "//acme-client/"], / destination / [1, "//acme-server/"], / source / [1, "//acme-server/"], / report-to / [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / 60000 / lifetime: 60s / ], @@ -1273,21 +1273,21 @@ Authorization value (a single string split across lines for readability) is: "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw." "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" The minimal-but-valid Response Bundle is shown in Figure 3. This response indicates that there is 30 seconds remaining in the response time window. - [ + [_ [ 7, / BP version / 0x02, / flags: payload-is-an-admin-record / 0, / CRC type: none / [1, "//acme-server/"], / destination / [1, "//acme-client/"], / source / [1, 0], / report-to: none / [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / 30000 / lifetime: 30s / ],