draft-ietf-acme-dtnnodeid-04.txt   draft-ietf-acme-dtnnodeid-05.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Updates: -ietf-dtn-bpbis (if approved) 6 June 2021 Updates: -ietf-dtn-bpbis (if approved) 22 September 2021
Intended status: Experimental Intended status: Experimental
Expires: 8 December 2021 Expires: 26 March 2022
Automated Certificate Management Environment (ACME) Delay-Tolerant Automated Certificate Management Environment (ACME) Delay-Tolerant
Networking (DTN) Node ID Validation Extension Networking (DTN) Node ID Validation Extension
draft-ietf-acme-dtnnodeid-04 draft-ietf-acme-dtnnodeid-05
Abstract Abstract
This document specifies an extension to the Automated Certificate This document specifies an extension to the Automated Certificate
Management Environment (ACME) protocol which allows an ACME server to Management Environment (ACME) protocol which allows an ACME server to
validate the Delay-Tolerant Networking (DTN) Node ID for an ACME validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
client. The DTN Node ID is encoded as a certificate Subject client. The DTN Node ID is encoded as a certificate Subject
Alternative Name (SAN) of type Uniform Resource Identifier (URI) and Alternative Name (SAN) of type otherName with a name form of
ACME Identifier type "uri". "bundleEID" and as an ACME Identifier type "bundleEID".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 December 2021. This Internet-Draft will expire on 26 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 5
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 7 2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 7
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 7 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 8
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 10 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 11
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 11 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 12
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 12 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13
3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 13 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 14
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 13 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 14
3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 15 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 15 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 16
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 16 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 17
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 16 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 17
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates . . . . . . . . . . . . . . . . . . . . . . 16 Certificates . . . . . . . . . . . . . . . . . . . . . . 17
6. Bundle Protocol Administrative Record Types Registry . . . . 17 6. Bundle Protocol Administrative Record Types Registry . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Threat: Passive Leak of Validation Data . . . . . . . . . 18 8.1. Threat: Passive Leak of Validation Data . . . . . . . . . 19
8.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18 8.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 19
8.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 19 8.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 20
8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 19 8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.5. Inherited Security Considerations . . . . . . . . . . . . 21
9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 20 8.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 21
9.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.3. Bundle Administrative Record Types . . . . . . . . . . . 20 9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. Bundle Administrative Record Types . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
Appendix B. Example Authorization . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Example Authorization . . . . . . . . . . . . . . . 27
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Although the original purpose of the Automatic Certificate Management Although the original purpose of the Automatic Certificate Management
Environment (ACME) [RFC8555] was to allow Public Key Infrastructure Environment (ACME) [RFC8555] was to allow Public Key Infrastructure
Using X.509 (PKIX) certificate authorities to validate network domain Using X.509 (PKIX) certificate authorities to validate network domain
names of clients, the same mechanism can be used to validate any of names of clients, the same mechanism can be used to validate any of
the subject claims supported by the PKIX profile [RFC5280]. the subject claims supported by the PKIX profile [RFC5280].
In the case of this specification, the claim being validated is a In the case of this specification, the claim being validated is a
Subject Alternative Name (SAN) of type Uniform Resource Identifier Subject Alternative Name (SAN) of type otherName with a name form of
(URI) used to represent the Node ID of a Delay-Tolerant Networking "bundleEID", which used to represent an Endpoint ID (EID) for a
(DTN) Node. A DTN Node ID is a URI with a specific set of allowed Delay-Tolerant Networking (DTN) bundle. Currently the URI schemes
schemes, and determines how bundles are routed within a DTN. "dtn" and "ipn" as defined in [I-D.ietf-dtn-bpbis] are valid for an
Currently the schemes "dtn" and "ipn" as defined in Endpoint ID. A DTN Node ID is an Endpoint ID with scheme-specific
[I-D.ietf-dtn-bpbis] are valid for a Node ID. restrictions to identify it as such; currently the "dtn" scheme uses
an empty demux part and the "ipn" scheme uses service number zero.
Because the SAN URI claim is new to ACME, a new ACME Identifier type
"bundleEID" is needed to manage this claim within ACME messaging. A
"bundleEID" claim can be part of a pre-authorization or as one of the
authorizations of an order containing any number of claims.
Once an ACME server validates a Node ID, either as a pre- Once an ACME server validates a Node ID, either as a pre-
authorization of the "uri" or as one of the authorizations of an authorization of the "bundleEID" or as one of the authorizations of
order containing a "uri", the client can finalize the order using an an order containing a "bundleEID", the client can finalize the order
associated certificate signing request (CSR). Because a single order using an associated certificate signing request (CSR). Because a
can contain multiple identifiers of multiple types, there can be single order can contain multiple identifiers of multiple types,
operational issues for a client attempting to, and possibly failing there can be operational issues for a client attempting to, and
to, validate those multiple identifiers as described in Section 5.1. possibly failing to, validate those multiple identifiers as described
Once a certificate is issued for a Node ID, how the ACME client in Section 5.1. Once a certificate is issued for a Node ID, how the
configures the Bundle Protocol (BP) agent with the new certificate is ACME client configures the Bundle Protocol (BP) agent with the new
an implementation matter. certificate is an implementation matter.
The scope and behavior of this validation mechanism is similar to The scope and behavior of this validation mechanism is similar to
that of secured email validation of [RFC8823]. that of secured email validation of [RFC8823].
This document also updates BPv7 to explicitly use the IANA This document also updates BPv7 to explicitly use the IANA
administrative record type registry in Section 6. administrative record type registry in Section 6.
1.1. Scope 1.1. Scope
This document describes the ACME messages, BPv7 payloads, and BPSec This document describes the ACME messages, BPv7 payloads, and BPSec
skipping to change at page 4, line 50 skipping to change at page 5, line 18
[I-D.ietf-dtn-bpbis], which consists of a data payload with [I-D.ietf-dtn-bpbis], which consists of a data payload with
accompanying metadata. An Endpoint ID is used as the destination of accompanying metadata. An Endpoint ID is used as the destination of
a Bundle and can indicate both a unicast or a multicast destination. a Bundle and can indicate both a unicast or a multicast destination.
A Node ID is used to identify the source of a Bundle and is used for A Node ID is used to identify the source of a Bundle and is used for
routing through intermediate nodes, including the final node(s) used routing through intermediate nodes, including the final node(s) used
to deliver a Bundle to its destination endpoint. A Node ID can also to deliver a Bundle to its destination endpoint. A Node ID can also
be used as an endpoint for administrative bundles. More detailed be used as an endpoint for administrative bundles. More detailed
descriptions of the rationale and capabilities of these networks can descriptions of the rationale and capabilities of these networks can
be found in "Delay-Tolerant Network Architecture" [RFC4838]. be found in "Delay-Tolerant Network Architecture" [RFC4838].
When a ACME client requests a pre-authorization or an order with a When an ACME client requests a pre-authorization or an order with a
"uri" having one of the DTN Node ID schemes, the ACME server offers a "bundleEID" identifier type having a value consistent with a Node ID
challenge type to validate that Node ID. If the ACME client attempts (see Section 4.2.5 of [I-D.ietf-dtn-bpbis]), the ACME server offers a
the authorization challenge to validate a Node ID, the ACME server "dtn-nodeid-01" challenge type to validate that Node ID. If the ACME
sends an ACME Node ID Validation Challenge Bundle with a destination client attempts the authorization challenge to validate a Node ID,
of the Node ID being validated. The BP agent on that node receives the ACME server sends an ACME Node ID Validation Challenge Bundle
the Challenge Bundle, generates an ACME key authorization digest, and with a destination of the Node ID being validated. The BP agent on
sends an ACME Node ID Validation Response Bundle in reply. An that node receives the Challenge Bundle, generates an ACME key
Integrity Gateway on the client side of the DTN can be used to attest authorization digest, and sends an ACME Node ID Validation Response
to the source of the Response Bundle. Finally, the ACME server Bundle in reply. An Integrity Gateway on the client side of the DTN
receives the Response Bundle and checks that the digest was generated can be used to attest to the source of the Response Bundle. Finally,
for the associated ACME challenge and from the client account key the ACME server receives the Response Bundle and checks that the
associated with the original request. This workflow is shown in the digest was generated for the associated ACME challenge and from the
diagram of Figure 1 and defined in Section 3. client account key associated with the original request. This
workflow is shown in the diagram of Figure 1 and defined in
Section 3.
+------------+ +------------+ +------------+ +------------+
| ACME |<===== HTTPS exchanges =====>| ACME | | ACME |<===== HTTPS exchanges =====>| ACME |
| Client | | Server | | Client | | Server |
+------------+ +------------+ +------------+ +------------+
| | ^ | | ^
Enable or disable Send | | (1) Enable or (6) disable (2) Send | |
challenge from server Challenge | | Indicate validation from server Challenge | |(5) Indicate
| Non-DTN | | Response | Non-DTN | | Response
~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~|~~~~~~~~~~ ~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~
V DTN V | V DTN V |
++------------++ ++------------++ ++------------++ ++------------++
|| Admin Elem.|| || Admin Elem.|| || Admin Elem.|| || Admin Elem.||
|+------------+| |+------------+| |+------------+| (3) Challenge |+------------+|
| Client's |<----- Challenge Bundle ---| Server's | | Client's |<------------- Bundle -----| Server's |
| BP Agent | | BP Agent | | BP Agent | | BP Agent |
+--------------+ +--------------+ +--------------+ +--------------+
| ^ | ^
| +-------------+ | | +-------------+ |
| | Integrity | | | | Integrity | (4) Response |
+---->| Gateway |---Response Bundle----+ +---->| Gateway |------ Bundle --------+
+-------------+ +-------------+
Figure 1: The relationships between Node ID Validation entities Figure 1: The relationships and flows between Node ID Validation
entities
Because the DTN Node ID is used both for routing bundles between BP Because the DTN Node ID is used both for routing bundles between BP
agents and for multiplexing administrative services within a BP agents and for multiplexing administrative services within a BP
agent, there is no possibility to separate the ACME validation of a agent, there is no possibility to separate the ACME validation of a
Node ID from normal bundle handling for that same Node ID. This Node ID from normal bundle handling for that same Node ID. This
leaves administrative record types as a way to leave the Node ID leaves administrative record types as a way to leave the Node ID
unchanged while disambiguating from other service data bundles. unchanged while disambiguating from other service data bundles.
There is nothing in this protocol which requires network-topological There is nothing in this protocol which requires network-topological
co-location of either the ACME client or ACME server with their co-location of either the ACME client or ACME server with their
skipping to change at page 6, line 42 skipping to change at page 7, line 32
Challenge Request: This is a shortened form of the full "DTN Node ID Challenge Request: This is a shortened form of the full "DTN Node ID
Challenge Request Object". It is a JSON object created by the Challenge Request Object". It is a JSON object created by the
ACME server for challenge type "dtn-nodeid-01". ACME server for challenge type "dtn-nodeid-01".
Challenge Response: This is a shortened form of the full "DTN Node Challenge Response: This is a shortened form of the full "DTN Node
ID Challenge Response Object". It is a JSON object created by the ID Challenge Response Object". It is a JSON object created by the
ACME client to authorize a challenge type "dtn-nodeid-01". ACME client to authorize a challenge type "dtn-nodeid-01".
Challenge Bundle: This is a shortened form of the full "ACME Node ID Challenge Bundle: This is a shortened form of the full "ACME Node ID
Validation Challenge Bundle". It is a Bundle created by the ACME Validation Challenge Bundle". It is a Bundle created by the BP
server to challenge a Node ID claim. agent managed by the ACME server to challenge a Node ID claim.
Response Bundle: This is a shortened form of the full "ACME Node ID Response Bundle: This is a shortened form of the full "ACME Node ID
Validation Response Bundle". It is a Bundle created by the BP Validation Response Bundle". It is a Bundle created by the BP
agent managed by the ACME client to validate a Node ID claim. agent managed by the ACME client to validate a Node ID claim.
2. URI ACME Identifier 2. Bundle Endpoint ID ACME Identifier
This specification is the first to make use of a URI to identify a
service for a certificate request in ACME. The URI-type identifier
is general purpose, and validating ownership of a URI requires a
specific purpose related to its "scheme" component. In this
document, the only purpose for which a URI ACME identifier is
validated is as a DTN Node ID (see Section 3), but other
specifications can define challenge types for other URI uses.
Identifiers of type "uri" in certificate requests MUST appear in an This specification is the first to make use of an Bundle Endpoint ID
extensionRequest attribute [RFC2985] containing a subjectAltName to identify a claim for a certificate request in ACME. In this
extension of type uniformResourceIdentifier having a value consistent document, the only purpose for which an Bundle Endpoint ID ACME
with the requirements of [RFC3986]. Because the identifier is validated is as a DTN Node ID (see Section 3), but
uniformResourceIdentifier is encoded as an IA5String it SHALL be other specifications can define challenge types for other Endpoint ID
treated as being in the percent-encoded form of Section 2.1 of uses.
[RFC3986]. Any "uri" identifier which fails to properly percent-
decode SHALL be rejected with an ACME error type of "malformed".
Identifiers of type "uri" present in ACME messages are unicode text Identifiers of type "bundleEID" in certificate requests MUST appear
strings and SHALL NOT be percent encoded. in an extensionRequest attribute [RFC2985] containing a
subjectAltName extension of type otherName with a name form of
"bundleEID" consistent with the requirements of Section 4.4.2.1 of
[I-D.ietf-dtn-tcpclv4]. Because the bundleEID is encoded as an
IA5String it SHALL be treated as being in the percent-encoded form of
Section 2.1 of [RFC3986]. Any "bundleEID" identifier which fails to
properly percent-decode SHALL be rejected with an ACME error type of
"malformed".
The ACME server SHALL decode and normalize (based on scheme-specific The ACME server SHALL decode and normalize (based on scheme-specific
syntax) all received identifiers of type "uri". Any "uri" identifier syntax) all received identifiers of type "bundleEID". Any
request which uses a scheme not handled by the ACME server or for "bundleEID" identifier request which uses a scheme not handled by the
which the URI does not match the scheme-specific syntax SHALL be ACME server or for which the URI does not match the scheme-specific
rejected with an ACME error type of "rejectedIdentifier". syntax SHALL be rejected with an ACME error type of
"rejectedIdentifier".
When an ACME server needs to request proof that a client controls a When an ACME server needs to request proof that a client controls a
URI, it SHALL create an authorization with the identifier type "uri". URI, it SHALL create an authorization with the identifier type
The ACME server SHALL NOT attempt to dereference the URI value on its "bundleEID". The ACME server SHALL NOT attempt to dereference the
own. It is the responsibility of a validation method to ensure the Endpoint ID value on its own. It is the responsibility of a
URI ownership via scheme-specific means authorized by the ACME validation method to ensure the URI ownership via scheme-specific
client. means authorized by the ACME client.
An identifier for the Node ID of "dtn://example/" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{"type": "uri", "value": "dtn://example/"} {"type": "bundleEID", "value": "dtn://example/"}
3. DTN Node ID Validation 3. DTN Node ID Validation
The DTN Node ID validation method proves control over a Node ID by The DTN Node ID validation method proves control over a Node ID by
requiring the ACME client to configure a BP agent to respond to requiring the ACME client to configure a BP agent to respond to
specific Challenge Bundles sent from the ACME server. The ACME specific Challenge Bundles sent from the ACME server. The ACME
server validates control of the Node ID URI by verifying that server validates control of the Node ID URI by verifying that
received Response Bundles correspond with the BP Node and client received Response Bundles correspond with the BP Node and client
account key being validated. account key being validated.
Similar to the ACME use case for validating email address ownership Similar to the ACME use case for validating email address ownership
[RFC8823], this challenge splits the token into several parts, each [RFC8823], this challenge splits the token into several parts, each
being transported by a different channel, and the Key Authorization being transported by a different channel, and the Key Authorization
result requires combining all parts of the token. The token parts result requires combining all parts of the token. The token parts
are: are:
"token-chal" This token is unique to, and constant for, each ACME "token-chal" This token is unique to, and constant for, each ACME
authorization. It is contained in the Challenge Object of authorization. It is contained in the Challenge Object of
Section 3.1 as well as the Challenge Bundle of Section 3.3. It Section 3.1 as well as the Challenge Bundle of Section 3.3 and
ensures that the Key Authorization is bound to the specific ACME Response Bundle of Section 3.4. Each authorization can consist of
challenge (and parent ACME authorization) and also allows the ACME multiple Challenge Bundles (e.g. taking different routes), but
client's BP agent to filter-in only valid Challenge Bundles. This they all share the same "token-chal" value. This ensures that the
token is also accessible to DTN on-path eavesdroppers. 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 the ACME server. It is contained in the Challenge Bundle of
Section 3.3 and ensures that the Key Authorization is bound to the Section 3.3 and Response Bundle of Section 3.4. This ensures that
ability to receive the Challenge Bundle. This token is also the Key Authorization is bound to the ability to receive the
accessible to DTN on-path eavesdroppers. Challenge Bundle and not just have access to the ACME Challenge
Object. This token is also accessible to DTN on-path
eavesdroppers.
The DTN Node ID Challenge SHALL only be allowed for URIs usable as a The DTN Node ID Challenge SHALL only be allowed for URIs usable as a
DTN Node ID, which are currently the schemes "dtn" and "ipn" as DTN Node ID, which are currently the schemes "dtn" and "ipn" as
defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node
ID validation, the ACME server SHALL define a challenge object in ID validation, the ACME server SHALL define a challenge object in
accordance with Section 3.1. Once this challenge object is defined, accordance with Section 3.1. Once this challenge object is defined,
the ACME client may begin the validation. the ACME client may begin the validation.
To initiate a Node ID validation, the ACME client performs the To initiate a Node ID validation, the ACME client performs the
following steps: following steps:
1. The ACME client POSTs a newOrder or newAuthz request including 1. The ACME client POSTs a newOrder or newAuthz request including
the identifier of type "uri" for the desired Node ID. From the identifier of type "bundleEID" for the desired Node ID. From
either of these entry points an authorization for the "uri" type either of these entry points an authorization for the "bundleEID"
is indicated by the ACME server. See Section 7.4 of [RFC8555] type is indicated by the ACME server. See Section 7.4 of
for more details. [RFC8555] for more details.
2. The ACME client obtains the challenge source Node ID and "token- 2. The ACME client obtains the challenge source Node ID and "token-
chal" from the challenge object in accordance with Section 3.1. chal" from the challenge object in accordance with Section 3.1.
3. The ACME client indicates to the administrative element of its BP 3. The ACME client indicates to the administrative element of its BP
agent the source Node ID and challenge "token-chal" which is agent the source Node ID and challenge "token-chal" which is
authorized for use and the associated client account key authorized for use and the associated client account key
thumbprint. The ACME client SHALL wait, if necessary, until the thumbprint. The ACME client SHALL wait, if necessary, until the
agent is configured before proceeding to the next step. agent is configured before proceeding to the next step.
skipping to change at page 9, line 30 skipping to change at page 10, line 30
9. Once the challenge is completed (successfully or not), the ACME 9. Once the challenge is completed (successfully or not), the ACME
client indicates to the BP agent that the validation source and client indicates to the BP agent that the validation source and
"token-chal" is no longer usable. If the authorization fails, "token-chal" is no longer usable. If the authorization fails,
the ACME client MAY retry the challenge from Step 3. the ACME client MAY retry the challenge from Step 3.
The ACME server verifies the client's control over a Node ID by The ACME server verifies the client's control over a Node ID by
performing the following steps: performing the following steps:
1. The ACME server receives a newOrder or newAuthz request including 1. The ACME server receives a newOrder or newAuthz request including
the identifier of type "uri", where the URI value is a Node ID. the identifier of type "bundleEID", where the URI value is a Node
ID.
2. The ACME server generates an authorization for the Node ID with 2. The ACME server generates an authorization for the Node ID with
challenge type "dtn-nodeid-01" in accordance with Section 3.1. challenge type "dtn-nodeid-01" in accordance with Section 3.1.
3. The ACME server receives a POST to the challenge URL indicated 3. The ACME server receives a POST to the challenge URL indicated
from the authorization object. The payload is handled in from the authorization object. The payload is handled in
accordance with Section 3.2. accordance with Section 3.2.
4. The ACME server sends, via the administrative element of its BP 4. The ACME server sends, via the administrative element of its BP
agent, one or more Challenge Bundles in accordance with agent, one or more Challenge Bundles in accordance with
Section 3.3. Each challenge bundle SHALL contain a distinct Section 3.3. Each challenge bundle SHALL contain a distinct
"token-bundle" to be able to correlate with a response bundle. "token-bundle" to be able to correlate with a response bundle.
Computing an expected Key Authorization digest is not necessary Computing an expected Key Authorization digest is not necessary
until a response is received. until a response is received.
5. The ACME server waits for Response Bundle(s) for a limited 5. The ACME server waits for Response Bundle(s) for a limited
interval of time (based on the challenge response object). interval of time (based on the challenge response object of
Responses are encoded in accordance with Section 3.4. Section 3.2). Responses are encoded in accordance with
Section 3.4.
6. Once received and decoded, the ACME server checks the contents of 6. Once received and decoded, the ACME server checks the contents of
each Response Bundle in accordance with Section 3.4.1. After all each Response Bundle in accordance with Section 3.4.1. After all
Challenge Bundles have either been responded to or timed-out, the Challenge Bundles have either been responded to or timed-out, the
validation procedure is successful only if all responses are validation procedure is successful only if all responses are
successful. If validation is not successful, a client may retry successful. If validation is not successful, a client may retry
the challenge which starts in Step 3. the challenge which starts in Step 3.
An ACME server MAY send multiple challenges from different origins in An ACME server MAY send multiple challenges from different origins in
the DTN network to avoid possible on-path attacks, as recommended in the DTN network to avoid possible on-path attacks, as recommended in
skipping to change at page 12, line 7 skipping to change at page 13, line 7
contain an RTT, SHOULD be a configurable parameter of the ACME contain an RTT, SHOULD be a configurable parameter of the ACME
server. If the ACME client indicated an RTT value in the object, the server. If the ACME client indicated an RTT value in the object, the
response interval SHOULD be twice the RTT (with limiting logic response interval SHOULD be twice the RTT (with limiting logic
applied as described below). The lower limit on response interval is applied as described below). The lower limit on response interval is
network-specific, but SHOULD NOT be shorter than one second. The network-specific, but SHOULD NOT be shorter than one second. The
upper limit on response interval is network-specific, but SHOULD NOT upper limit on response interval is network-specific, but SHOULD NOT
be longer than one minute (60 seconds) for a terrestrial-only DTN. be longer than one minute (60 seconds) for a terrestrial-only DTN.
3.3. ACME Node ID Validation Challenge Bundles 3.3. ACME Node ID Validation Challenge Bundles
Each Each ACME Node ID Validation Challenge Bundle SHALL be Each ACME Node ID Validation Challenge Bundle SHALL be structured and
structured and encoded in accordance with [I-D.ietf-dtn-bpbis]. encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Challenge Bundle has parameters as listed here: Each Challenge Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. The primary block Challenge Bundle from the Response Bundle. The primary block
flags MAY indicate that status reports are requested; such status flags MAY indicate that status reports are requested; such status
can be helpful to troubleshoot routing issues. can be helpful to troubleshoot routing issues.
Destination EID: The Destination EID SHALL be identical to the Node Destination EID: The Destination EID SHALL be identical to the Node
ID being validated. The ACME server SHOULD NOT perform URI ID being validated. The ACME server SHOULD NOT perform URI
normalization on the Node ID given by the ACME client. normalization on the Node ID given by the ACME client.
Source Node ID: The Source Node ID SHALL indicate the Node ID of the Source Node ID: The Source Node ID SHALL indicate the Node ID of the
ACME server performing the challenge. BP agent of the ACME server performing the challenge.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the challenge was generated. The Lifetime to the time at which the challenge was generated. The Lifetime
SHALL indicate the response interval for which ACME server will SHALL indicate the response interval (of Section 3.2) for which
accept responses to this challenge. ACME server will accept responses to this challenge.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 9.3. type code defined in Section 9.3.
Administrative Record Content: The Challenge Bundle administrative Administrative Record Content: The Challenge Bundle administrative
record content SHALL consist of a CBOR map containing two pairs: record content SHALL consist of a CBOR map containing two pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
"token-chal", copied from the challenge object, represented as "token-chal", copied from the challenge object, represented as
a CBOR byte string. a CBOR byte string.
skipping to change at page 13, line 20 skipping to change at page 14, line 20
accordance with Section 4 or with a Security Source identical to the accordance with Section 4 or with a Security Source identical to the
bundle Source Node. Challenge Bundles SHALL NOT be directly bundle Source Node. Challenge Bundles SHALL NOT be directly
encrypted by Block Confidentiality Block (BCB) or any other method encrypted by Block Confidentiality Block (BCB) or any other method
(see Section 8.1). (see Section 8.1).
3.3.1. Challenge Bundle Checks 3.3.1. Challenge Bundle Checks
A proper Challenge Bundle meets all of the following criteria: A proper Challenge Bundle meets all of the following criteria:
* The Challenge Bundle was received within the time interval allowed * The Challenge Bundle was received within the time interval allowed
for the challenge. for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Challenge Bundle.
* The Challenge Bundle Source Node ID is identical to the Node ID * The Challenge Bundle Source Node ID is identical to the Node ID
indicated in the ACME challenge object. The comparison of Node indicated in the ACME challenge object. The comparison of Node
IDs SHALL use the comparison logic of [RFC3986] and scheme-based IDs SHALL use the comparison logic of [RFC3986] and scheme-based
normalization of those schemes specified in [I-D.ietf-dtn-bpbis]. normalization of those schemes specified in [I-D.ietf-dtn-bpbis].
* The Challenge Bundle contains a BIB which covers at least the * The Challenge Bundle contains a BIB which covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation (i.e. is trusted and passes security-context-specific validation (i.e.
MAC or signature verification). MAC or signature verification).
skipping to change at page 13, line 42 skipping to change at page 14, line 43
* The challenge payload contains the "token-chal" as indicated in * The challenge payload contains the "token-chal" as indicated in
the ACME challenge object. The challenge payload contains a the ACME challenge object. The challenge payload contains a
"token-bundle" meeting the definition in Section 3.3. "token-bundle" meeting the definition in Section 3.3.
Any of the failures above SHALL cause the challenge bundle to be Any of the failures above SHALL cause the challenge bundle to be
deleted and otherwise ignored by the BP agent. The BP agent MAY send deleted and otherwise ignored by the BP agent. The BP agent MAY send
status reports about the deletion if allowed by security policy. status reports about the deletion if allowed by security policy.
3.4. ACME Node ID Validation Response Bundles 3.4. ACME Node ID Validation Response Bundles
Each Each ACME Node ID Validation Response Bundle SHALL be structured Each ACME Node ID Validation Response Bundle SHALL be structured and
and encoded in accordance with [I-D.ietf-dtn-bpbis]. encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Response Bundle has parameters as listed here: Each Response Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL NOT indicate that user application primary block flags SHALL NOT indicate that user application
acknowledgement is requested; this flag distinguishes the Response acknowledgement is requested; this flag distinguishes the Response
Bundle from the Challenge Bundle. The primary block flags MAY Bundle from the Challenge Bundle. The primary block flags MAY
indicate that status reports are requested; such status can be indicate that status reports are requested; such status can be
helpful to troubleshoot routing issues. helpful to troubleshoot routing issues.
Destination EID: The Destination EID SHALL be identical to the Destination EID: The Destination EID SHALL be identical to the
Source Node ID of the Challenge Bundle to which this response Source Node ID of the Challenge Bundle to which this response
corresponds. corresponds.
Source Node ID: The Source Node ID SHALL be identical to the the Source Node ID: The Source Node ID SHALL be identical to the
Destination EID of the Challenge Bundle to which this response Destination EID of the Challenge Bundle to which this response
corresponds. corresponds.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the response was generated. The response to the time at which the response was generated. The response
Lifetime SHALL indicate the response interval remaining if the Lifetime SHALL indicate the response interval remaining if the
Challenge Bundle indicated a limited Lifetime. Challenge Bundle indicated a limited Lifetime.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 9.3. type code defined in Section 9.3.
skipping to change at page 15, line 14 skipping to change at page 16, line 10
Response Bundles SHALL include a BIB in accordance with Section 4. Response Bundles SHALL include a BIB in accordance with Section 4.
Response Bundles SHALL NOT be directly encrypted by BCB or any other Response Bundles SHALL NOT be directly encrypted by BCB or any other
method (see Section 8.1 for explanation). method (see Section 8.1 for explanation).
3.4.1. Response Bundle Checks 3.4.1. Response Bundle Checks
A proper Response Bundle meets all of the following criteria: A proper Response Bundle meets all of the following criteria:
* The Response Bundle was received within the time interval allowed * The Response Bundle was received within the time interval allowed
for the challenge. for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Response Bundle.
* The Response Bundle Source Node ID is identical to the Node ID * The Response Bundle Source Node ID is identical to the Node ID
being validated. The comparison of Node IDs SHALL use the being validated. The comparison of Node IDs SHALL use the
comparison logic of [RFC3986] and scheme-based normalization of comparison logic of [RFC3986] and scheme-based normalization of
those schemes specified in [I-D.ietf-dtn-bpbis]. those schemes specified in [I-D.ietf-dtn-bpbis].
* The Response Bundle contains a BIB which covers at least the * The Response Bundle contains a BIB which covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation. is trusted and passes security-context-specific validation.
skipping to change at page 16, line 11 skipping to change at page 17, line 8
bundle. The exact means by which an integrity gateway validates a bundle. The exact means by which an integrity gateway validates a
bundle's source is network-specific, but could use physical-layer, bundle's source is network-specific, but could use physical-layer,
network-layer or BP-convergence-layer authentication. The bundle network-layer or BP-convergence-layer authentication. The bundle
source could also add its own BIB with a local-network-specific source could also add its own BIB with a local-network-specific
security context or local-network-specific key material (i.e. a group security context or local-network-specific key material (i.e. a group
key shared within the local network). key shared within the local network).
When an integrity gateway adds a BIB it SHALL be in accordance with When an integrity gateway adds a BIB it SHALL be in accordance with
[I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload [I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload
block and the primary block (either directly as a target or as block and the primary block (either directly as a target or as
additional authenticated data for the payload block signature). The additional authenticated data for the payload block MAC/signature).
Security Source of this BIB SHALL be either the bundle source Node ID The Security Source of this BIB SHALL be either the bundle source
itself or a routing node trusted by the destination node (see Node ID itself or a routing node trusted by the destination node (see
Section 8.2). Section 8.2).
5. Certificate Request Profile 5. Certificate Request Profile
The ultimate purpose of this ACME validation is to allow a CA to The ultimate purpose of this ACME validation is to allow a CA to
issue certificates following the profiles of Section 4.4.2 of issue certificates following the profiles of Section 4.4.2 of
[I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and
[I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as
bundle security certificates. bundle security certificates.
skipping to change at page 16, line 35 skipping to change at page 17, line 32
Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When
requesting a certificate which includes a Node ID SAN, the CSR SHOULD requesting a certificate which includes a Node ID SAN, the CSR SHOULD
include an Extended Key Usage of id-kp-bundleSecurity. When a bundle include an Extended Key Usage of id-kp-bundleSecurity. When a bundle
security certificate is issued based on a validated Node ID SAN, the security certificate is issued based on a validated Node ID SAN, the
certificate SHALL include an Extended Key Usage of id-kp- certificate SHALL include an Extended Key Usage of id-kp-
bundleSecurity. bundleSecurity.
5.1. Multiple Identity Claims 5.1. Multiple Identity Claims
A single bundle security CSR MAY contain a mixed set of SAN claims, A single bundle security CSR MAY contain a mixed set of SAN claims,
including combinations of "ip", "dns", and "uri" claims. There is no including combinations of "ip", "dns", and "bundleEID" claims. There
restriction on how a certificate combines these claims, but each is no restriction on how a certificate combines these claims, but
claim MUST be validated by an ACME server to issue such a certificate each claim MUST be validated by an ACME server to issue such a
as part of an associated ACME order. This is no different than the certificate as part of an associated ACME order. This is no
existing behavior of [RFC8555] but is mentioned here to make sure different than the existing behavior of [RFC8555] but is mentioned
that CA policy handles such situations; especially related to here to make sure that CA policy handles such situations; especially
validation failure of an identifier in the presence of multiple related to validation failure of an identifier in the presence of
identifiers. The specific use case of [I-D.ietf-dtn-tcpclv4] allows, multiple identifiers. The specific use case of
and for some network policies requires, that a certificate [I-D.ietf-dtn-tcpclv4] allows, and for some network policies
authenticate both the DNS name of an entity as well as the Node ID of requires, that a certificate authenticate both the DNS name of an
the entity. entity as well as the Node ID of the entity.
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates Certificates
ACME extensions specified in this document can be used to request ACME extensions specified in this document can be used to request
encryption-only or signing-only bundle security certificates. encryption-only or signing-only bundle security certificates.
In order to request signing only bundle security certificate, the CSR In order to request signing only bundle security certificate, the CSR
MUST include the key usage extension with digitalSignature and/or MUST include the key usage extension with digitalSignature and/or
nonRepudiation bits set and no other bits set. nonRepudiation bits set and no other bits set.
skipping to change at page 20, line 10 skipping to change at page 21, line 10
A malicious entity can continually send Response Bundles to a BP A malicious entity can continually send Response Bundles to a BP
agent. The victim BP agent can ignore Response Bundles which do not agent. The victim BP agent can ignore Response Bundles which do not
conform to the specific time interval or Source Node ID or challenge conform to the specific time interval or Source Node ID or challenge
token for an active Node ID validation. token for an active Node ID validation.
Similar to other validation methods, an ACME server validating a DTN Similar to other validation methods, an ACME server validating a DTN
Node ID could be used as a denial of service amplifier. For this Node ID could be used as a denial of service amplifier. For this
reason any ACME server can rate-limit validation activities for reason any ACME server can rate-limit validation activities for
individual clients and individual certificate requests. individual clients and individual certificate requests.
8.5. Inherited Security Considerations
Because this protocol relies on ACME for part of its operation, the
security considerations of [RFC8555] apply to all ACME client--server
exchanges during Node ID validation.
Because this protocol relies on BPv7 for part of its operation, the
security considerations of [I-D.ietf-dtn-bpbis] and
[I-D.ietf-dtn-bpsec] apply to all BP messaging during Node ID
validation.
8.6. Out-of-Scope BP Agent Communication
Although messaging between an ACME client or ACME server an its
associated BP agent are out-of-scope for this document, both of those
channels are critical to Node ID validation security. Either channel
can potentially leak data or provide attack vectors if not properly
secured. These channels need to protect against spoofing of
messaging in both directions to avoid interruption of normal
validation sequencing and to prevent false validations from
succeeding.
The ACME server and its BP agent exchange the outgoing "token-chal",
"token-bundle", and Key Authorization digest but these values do not
need to be confidential (they are also in plaintext over the BP
channel).
Depending on implementation details, the ACME client might transmit
the client account key thumbprint to its BP agent to allow computing
the Key Authorization digest on the BP agent. If an ACME client does
transmit its client account key thumbprint to a BP agent, it is
important that this data is kept confidential because it provides the
binding of the client account key to the Node ID validation (as well
as for all other types of ACME validation). Avoiding this
transmission would require a full round-trip between BP agent and
ACME client, which can be undesirable if the two are separated by a
long-delay network.
9. IANA Considerations 9. IANA Considerations
This specification adds to the ACME registry and BP registry for this This specification adds to the ACME registry and BP registry for this
behavior. behavior.
9.1. ACME Identifier Types 9.1. ACME Identifier Types
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Identifier Types" sub-registry. the "ACME Identifier Types" sub-registry.
skipping to change at page 23, line 40 skipping to change at page 25, line 40
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. J. Birrane, "Bundle Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
Protocol Version 7", Work in Progress, Internet-Draft, Protocol Version 7", Work in Progress, Internet-Draft,
draft-ietf-dtn-bpbis-31, 25 January 2021, draft-ietf-dtn-bpbis-31, 25 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-31>. <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpbis-31>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
III, E. J. B. and K. McKeever, "Bundle Protocol Security III, E. J. B. and K. McKeever, "Bundle Protocol Security
Specification", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-dtn-bpsec-27, 16 February 2021, ietf-dtn-bpsec-27, 16 February 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27>. <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-27>.
11.2. Informative References 11.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>. 2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
skipping to change at page 24, line 24 skipping to change at page 26, line 28
<https://www.rfc-editor.org/info/rfc7116>. <https://www.rfc-editor.org/info/rfc7116>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates", Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021, RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>. <https://www.rfc-editor.org/info/rfc8823>.
[I-D.ietf-dtn-bibect] [I-D.ietf-dtn-bibect]
Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in
Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18
February 2020, February 2020, <https://datatracker.ietf.org/doc/html/
<https://tools.ietf.org/html/draft-ietf-dtn-bibect-03>. draft-ietf-dtn-bibect-03>.
[I-D.ietf-dtn-tcpclv4] [I-D.ietf-dtn-tcpclv4]
Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence Layer Protocol Version Tolerant Networking TCP Convergence Layer Protocol Version
4", Work in Progress, Internet-Draft, draft-ietf-dtn- 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
tcpclv4-26, 15 February 2021, tcpclv4-26, 15 February 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-26>. <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
tcpclv4-26>.
[I-D.sipos-dtn-udpcl] [I-D.sipos-dtn-udpcl]
Sipos, B., "Delay-Tolerant Networking UDP Convergence Sipos, B., "Delay-Tolerant Networking UDP Convergence
Layer Protocol", Work in Progress, Internet-Draft, draft- Layer Protocol", Work in Progress, Internet-Draft, draft-
sipos-dtn-udpcl-01, 26 March 2021, sipos-dtn-udpcl-01, 26 March 2021,
<https://tools.ietf.org/html/draft-sipos-dtn-udpcl-01>. <https://datatracker.ietf.org/doc/html/draft-sipos-dtn-
udpcl-01>.
[I-D.bsipos-dtn-bpsec-cose] [I-D.bsipos-dtn-bpsec-cose]
Sipos, B., "DTN Bundle Protocol Security COSE Security Sipos, B., "DTN Bundle Protocol Security COSE Security
Context", Work in Progress, Internet-Draft, draft-bsipos- Context", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-05, 16 March 2021, dtn-bpsec-cose-06, 3 June 2021,
<https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose- <https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-
05>. bpsec-cose-06>.
[github-dtn-demo-agent] [github-dtn-demo-agent]
Sipos, B., "Python implementation of basic BPv7-related Sipos, B., "Python implementation of basic BPv7-related
protocols", protocols",
<https://github.com/BSipos-RKF/dtn-demo-agent/>. <https://github.com/BSipos-RKF/dtn-demo-agent/>.
[github-dtn-wireshark] [github-dtn-wireshark]
Sipos, B., "Wireshark Dissectors for BPv7-related Sipos, B., "Wireshark Dissectors for BPv7-related
Protocols", Protocols",
<https://github.com/BSipos-RKF/dtn-wireshark/>. <https://github.com/BSipos-RKF/dtn-wireshark/>.
 End of changes. 43 change blocks. 
160 lines changed or deleted 219 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/