idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHALL not' in this paragraph:
Following the same pattern as COSE, when both additional header
maps are present in a single security block they SHALL not contain any
duplicated labels. Security acceptors SHALL treat a pair of additional
header maps containing duplicated labels as invalid.
-- The document date (16 March 2021) is 1136 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '5' on line 380
== Missing Reference: 'AAD-scope' is mentioned on line 380, but not defined
-- Looks like a reference, but probably isn't: '0' on line 1238
-- Looks like a reference, but probably isn't: '40' on line 1238
-- Looks like a reference, but probably isn't: '2' on line 1761
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SMI'
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053)
== Outdated reference: A later version (-27) exists of
draft-ietf-dtn-bpsec-26
== Outdated reference: A later version (-28) exists of
draft-ietf-dtn-tcpclv4-24
== Outdated reference: A later version (-09) exists of
draft-ietf-cose-x509-08
== Outdated reference: A later version (-11) exists of
draft-ietf-dtn-bpsec-default-sc-00
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--).
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: Standards Track 16 March 2021
5 Expires: 17 September 2021
7 DTN Bundle Protocol Security COSE Security Context
8 draft-bsipos-dtn-bpsec-cose-05
10 Abstract
12 This document defines a security context suitable for using CBOR
13 Object Signing and Encryption (COSE) algorithms within Bundle
14 Protocol Security (BPSec) integrity and confidentiality blocks. A
15 profile of COSE and for PKIX certificates are also defined for BPSec
16 interoperation.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at https://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on 17 September 2021.
35 Copyright Notice
37 Copyright (c) 2021 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents (https://trustee.ietf.org/
42 license-info) in effect on the date of publication of this document.
43 Please review these documents carefully, as they describe your rights
44 and restrictions with respect to this document. Code Components
45 extracted from this document must include Simplified BSD License text
46 as described in Section 4.e of the Trust Legal Provisions and are
47 provided without warranty as described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 4
54 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4
55 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
56 2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 4
57 2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5
58 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
59 2.2.1. Key Containers . . . . . . . . . . . . . . . . . . . 6
60 2.2.2. Additional Header Maps . . . . . . . . . . . . . . . 7
61 2.2.3. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 8
62 2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9
63 2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 10
64 2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 11
65 2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 11
66 2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 12
67 2.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 12
68 2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 13
69 2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 13
70 2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 14
71 2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 15
72 3. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 15
73 3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 15
74 3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 16
75 3.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 18
76 3.3.1. Policy Recommendations . . . . . . . . . . . . . . . 19
77 4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 20
78 4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 21
79 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
81 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 22
82 6.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 23
83 6.3. Threat: Certificate Validation Vulnerabilities . . . . . 23
84 6.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 23
85 6.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 23
86 6.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 24
87 6.7. Threat: Passive Leak of Key Material . . . . . . . . . . 24
88 6.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 24
89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
90 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 25
91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
93 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
94 9.2. Informative References . . . . . . . . . . . . . . . . . 27
95 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28
96 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 29
97 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 31
98 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 32
99 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 34
100 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 36
101 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 39
102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
104 1. Introduction
106 The Bundle Protocol Security (BPSec) Specification
107 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block
108 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but
109 does not specify any security contexts to be used by either of the
110 security block types. The CBOR Object Signing and Encryption (COSE)
111 specification [RFC8152] defines a structure, encoding, and algorithms
112 to use for cryptographic signing and encryption.
114 This document describes how to use the algorithms and encodings of
115 COSE within BPSec blocks to apply those algorithms to Bundle security
116 in Section 2. A bare minimum of interoperability algorithms and
117 algorithm parameters is specified by this document in Section 3. The
118 focus of the recommended algorithms is to allow BPSec to be used in a
119 Public Key Infrastructure (PKI) as described in Section 1.2.
121 Examples of specific uses are provided in Appendix A to aid in
122 implementation support of the interoperability algorithms.
124 1.1. Scope
126 This document describes a profile of COSE which is tailored for use
127 in BPSec and a method of including full COSE messages within BPSec
128 security blocks. This document does not address:
130 * Policies or mechanisms for issuing Public Key Infrastructure Using
131 X.509 (PKIX) certificates; provisioning, deploying, or accessing
132 certificates and private keys; deploying or accessing certificate
133 revocation lists (CRLs); or configuring security parameters on an
134 individual entity or across a network.
136 * Uses of COSE beyond the profile defined in this document.
138 * How those COSE algorithms are intended to be used within a larger
139 security context. Many header parameters used by COSE (e.g., key
140 identifiers) depend on the network environment and security policy
141 related to that environment.
143 1.2. PKIX Environments and CA Policy
145 This specification gives requirements about how to use PKIX
146 certificates issued by a Certificate Authority (CA), but does not
147 define any mechanisms for how those certificates come to be.
149 To support the PKIX uses defined in this document, the CA(s) issuing
150 certificates for BP nodes are aware of the end use of the
151 certificate, have a mechanism for verifying ownership of a Node ID,
152 and are issuing certificates directly for that Node ID. BPSec
153 security acceptors authenticate the Node ID of security sources when
154 verifying integrity (see Section 2.6.1) using a public key provided
155 by a PKIX certificate (see Section 2.6.1) following the certificate
156 profile of Section 4.
158 1.3. Use of CDDL
160 This document defines CBOR structure using the Concise Data
161 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure
162 can be extracted from the XML version of this document using the
163 XPath expression:
165 '//sourcecode[@type="cddl"]'
167 The following initial fragment defines the top-level symbols of this
168 document's CDDL, including the ASB data structure with its parameter/
169 result sockets.
171 start = bpsec-cose-asb / AAD-structure /
172 primary-block / extension-block /
173 MAC_structure / Sig_structure / Enc_structure / COSE_KeySet
175 1.4. Requirements Language
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
179 "OPTIONAL" in this document are to be interpreted as described in BCP
180 14 [RFC2119] [RFC8174] when, and only when, they appear in all
181 capitals, as shown here.
183 2. BPSec Security Context
185 This document specifies a single security context for use in both
186 BPSec integrity and confidentiality blocks. This is done to save
187 code points allocated to this specification and to simplify the
188 encoding of COSE-in-BPSec; the BPSec block type uniquely defines the
189 acceptable parameters and COSE messages which can be present.
191 The COSE security context SHALL have the Security Context ID
192 specified in Section 7.1.
194 Both types of security block can use the same parameters, defined in
195 Section 2.2, to carry public key-related information and each type of
196 security block allows specific COSE message results, defined in
197 Section 2.3.
199 ; Specialize the ASB for this context
200 bpsec-cose-asb = bpsec-context-use<
201 0, ; Context ID TBD-COSE
202 $bpsec-cose-param,
203 $bpsec-cose-result
204 >
205 $ext-data-asb /= bpsec-cose-asb
207 Figure 1: COSE context declaration CDDL
209 2.1. Security Scope
211 The scope here refers to the set of information used by the security
212 context to cryptographically bind with the plaintext data being
213 integrity-protected or confidentiality-protected. This information
214 is generically referred to as additional authenticated data (AAD),
215 which is also the term used by COSE to describe the same data.
217 The sources for AAD within the COSE context are described below,
218 controlled by the AAD Scope Flags parameter of Section 2.2.3, and
219 implemented as defined in Section 2.5.1.
221 Bundle Primary Block The primary block identifies a bundle and, once
222 created, the contents of this block are immutable. Changes to the
223 primary block associated with the security target indicate that
224 the target is no longer in its original bundle. Including this
225 data as part of AAD ensures that security target appears in the
226 same bundle that the security source intended.
228 Target Block Metadata When the target block is a canonical block
229 (i.e., not the primary block) it contains its block-type-specific
230 data, which is the subject of the security operation, but also
231 metadata identifying the block. This metadata explicitly excludes
232 the CRC type and value fields because the CRC is derived from the
233 block-type-specific data. Including this data as part of AAD
234 ensures that the target data appears in the same block that the
235 security source intended.
237 Security Block Metadata The BPSec block containing the security
238 result for which the AAD is assembled also has metadata
239 identifying the block. Including this data as part of AAD ensures
240 that the security result appears in the same block that the
241 security source intended.
243 2.2. Parameters
245 Each COSE context parameter value SHALL consist of the COSE structure
246 indicated by Table 1 in its decoded (CBOR item) form. Each security
247 block MAY contain any number of each parameter type. When a
248 parameter is not present, the security acceptor SHALL use the Default
249 Value of Table 1.
251 +===========+========================+===============+==============+
252 | Parameter | Parameter Structure | Reference | Default |
253 | ID | | | Value |
254 +===========+========================+===============+==============+
255 | 1 | COSE_Key | [RFC8152] | none |
256 +-----------+------------------------+---------------+--------------+
257 | 2 | COSE_KeySet | [RFC8152] | none |
258 +-----------+------------------------+---------------+--------------+
259 | 3 | additional-protected | Section 2.2.2 | '' |
260 | | | of this | |
261 | | | document | (empty |
262 | | | | bstr) |
263 +-----------+------------------------+---------------+--------------+
264 | 4 | additional-unprotected | Section 2.2.2 | {} |
265 | | | of this | |
266 | | | document | (empty |
267 | | | | map) |
268 +-----------+------------------------+---------------+--------------+
269 | 5 | AAD_Scope | Section 2.2.3 | 0x7 |
270 | | | of this | |
271 | | | document | (all AAD |
272 | | | | contexts) |
273 +-----------+------------------------+---------------+--------------+
275 Table 1: COSE Security Parameters
277 2.2.1. Key Containers
279 Implementations capable of handling asymmetric-keyed algorithms
280 SHOULD support the public key handling COSE_Key and COSE_KeySet
281 parameters.
283 No more than one total COSE_Key or COSE_KeySet parameter SHALL be
284 present in a single security block. Security acceptors are sill
285 required to aggregate multiple parameters, if present, in
286 Section 3.3.
288 Key container parameters SHALL NOT contain any private key material.
289 The security parameters are all stored in the bundle as plaintext and
290 are visible to any bundle handlers.
292 $bpsec-cose-param /= [1, COSE_Key]
293 $bpsec-cose-param /= [2, COSE_KeySet]
295 Figure 2: Key Containers CDDL
297 2.2.2. Additional Header Maps
299 The two parameters Additional Protected and Additional Unprotected
300 allow de-duplicating header items which are common to all COSE
301 results. Both additional header values contain a CBOR map which is
302 to be merged with each of the result's unprotected headers. Although
303 the additional header items are all treated as unprotected from the
304 perspective of the COSE message, the additional protected map is
305 included within the "external_aad" (see Section 2.5.1). The expected
306 use of additional header map is to contain a certificate (chain) or
307 identifier (see Section 3.3) which applies to all results in the same
308 security block.
310 Following the same pattern as COSE, when both additional header maps
311 are present in a single security block they SHALL not contain any
312 duplicated labels. Security acceptors SHALL treat a pair of
313 additional header maps containing duplicated labels as invalid.
315 No more than one of each Additional Protected and Additional
316 Unprotected parameter SHALL be present in a single security block.
317 Security acceptors SHALL treat a security block with multiple
318 instances of either additional header type as invalid. There is no
319 well-defined behavior for a security acceptor to handle multiple
320 Additional Protected parameters.
322 Security sources SHOULD NOT include an additional header parameter
323 which represents an empty map. Security acceptors SHALL handle empty
324 header map parameters, specifically the Additional Protected
325 parameter because it is part of the external_aad.
327 Security acceptors SHALL treat the aggregate of both additional
328 header maps as being present in the "unprotected" header map of the
329 COSE message of each result. If the same header label is present in
330 a additional header map and a result message the item in the result
331 message SHALL take precedence (i.e., the additional header items are
332 added only if they are not already present in a result message).
334 Additional header maps SHALL NOT contain any private key material.
335 The security parameters are all stored in the bundle as plaintext and
336 are visible to any bundle handlers.
338 $bpsec-cose-param /= [3, additional-protected]
339 additional-protected = empty_or_serialized_map
341 $bpsec-cose-param /= [4, additional-unprotected]
342 additional-unprotected = header_map
344 Figure 3: Additional Headers CDDL
346 2.2.3. AAD Scope
348 The AAD Scope parameter controls what data is included in the AAD for
349 both integrity and confidentiality operations. The AAD Scope
350 parameter SHALL be encoded as a uint value with bit flags defined in
351 Table 2. All reserved bits SHALL be set to zero (which will be
352 elided by CBOR encoding) by security sources. All reserved bits
353 SHALL be ignored by security acceptors. The default value for this
354 parameter has all flags set, meaning the AAD includes all available
355 context.
357 A CDDL representation of this definition is included in Figure 4 for
358 reference.
360 +==================+========+===============================+
361 | Name | Code | Description |
362 +==================+========+===============================+
363 | has-primary-ctx | 0x01 | If bit is set, indicates that |
364 | | | the primary block is included |
365 | | | in AAD scope. |
366 +------------------+--------+-------------------------------+
367 | has-target-ctx | 0x02 | If bit is set, indicates that |
368 | | | the target block metadata is |
369 | | | included in AAD scope. |
370 +------------------+--------+-------------------------------+
371 | has-security-ctx | 0x04 | If bit is set, indicates that |
372 | | | the security block metadata |
373 | | | is included in AAD scope. |
374 +------------------+--------+-------------------------------+
375 | Reserved | others | |
376 +------------------+--------+-------------------------------+
378 Table 2: AAD Scope Flags
380 $bpsec-cose-param /= [5, AAD-scope]
381 AAD-scope = uint .bits AAD-scope-flags
382 AAD-scope-flags = &(
383 has-primary-ctx: 0,
384 has-target-ctx: 1,
385 has-security-ctx: 2,
386 )
388 Figure 4: AAD Scope CDDL
390 2.3. Results
392 Although each COSE context result is a COSE message, the types of
393 message allowed depend upon the security block type in which the
394 result is present: only MAC or signature messages are allowed in a
395 BIB and only encryption messages are allowed in a BCB.
397 The code points for Result ID values are identical to the existing
398 COSE message-marking tags in Section 2 of [RFC8152]. This avoids the
399 need for value-mapping between code points of the two registries.
401 When embedding COSE messages, the message CBOR structure SHALL be
402 encoded as a byte string used as the result value. This allows a
403 security acceptor to skip over unwanted results without needing to
404 decode the result structure. When embedding COSE messages, the CBOR-
405 tagged form SHALL NOT be used. The Result ID values already provide
406 the same information as the COSE tags (using the same code points).
408 These generic requirements are formalized in the CDDL fragment of
409 Figure 5.
411 $bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0]
412 $bpsec-cose-result /= [17, bstr .cbor COSE_Mac0]
413 $bpsec-cose-result /= [18, bstr .cbor COSE_Sign1]
414 $bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt]
415 $bpsec-cose-result /= [97, bstr .cbor COSE_Mac]
416 $bpsec-cose-result /= [98, bstr .cbor COSE_Sign]
418 Figure 5: COSE context results CDDL
420 2.3.1. Integrity Messages
422 When used within a Block Integrity Block, the COSE context SHALL
423 allow only the Result IDs from Table 3. Each integrity result value
424 SHALL consist of the COSE message indicated by Table 3 in its
425 untagged encoded form.
427 +===========+====================+===========+
428 | Result ID | Result Structure | Reference |
429 +===========+====================+===========+
430 | 97 | encoded COSE_Mac | [RFC8152] |
431 +-----------+--------------------+-----------+
432 | 17 | encoded COSE_Mac0 | [RFC8152] |
433 +-----------+--------------------+-----------+
434 | 98 | encoded COSE_Sign | [RFC8152] |
435 +-----------+--------------------+-----------+
436 | 18 | encoded COSE_Sign1 | [RFC8152] |
437 +-----------+--------------------+-----------+
439 Table 3: COSE Integrity Results
441 Each integrity result SHALL use the "detached" payload form with nil
442 payload value. The integrity result for COSE_Mac and COSE_Mac0
443 messages are computed by the procedure in Section 6.3 of [RFC8152].
444 The integrity result for COSE_Sign and COSE_Sign1 messages are
445 computed by the procedure in Section 4.4 of [RFC8152].
447 The COSE "protected attributes from the application" used for a
448 signature or MAC result SHALL be the encoded data defined in
449 Section 2.5.1. The COSE payload used for a signature or MAC result
450 SHALL be either the block-type-specific data of the target, if the
451 target is not the primary block, or an empty byte string if the
452 target is the primary block.
454 2.3.2. Confidentiality Messages
456 When used within a Block Confidentiality Block, COSE context SHALL
457 allow only the Result IDs from Table 4. Each confidentiality result
458 value SHALL consist of the COSE message indicated by Table 4 in its
459 untagged encoded form.
461 +===========+=======================+===========+
462 | Result ID | Result Structure | Reference |
463 +===========+=======================+===========+
464 | 96 | encoded COSE_Encrypt | [RFC8152] |
465 +-----------+-----------------------+-----------+
466 | 16 | encoded COSE_Encrypt0 | [RFC8152] |
467 +-----------+-----------------------+-----------+
469 Table 4: COSE Confidentiality Results
471 Only algorithms which support Authenticated Encryption with
472 Authenticated Data (AEAD) SHALL be usable in the first (content)
473 layer of a confidentiality result. Because COSE encryption with AEAD
474 appends the authentication tag with the ciphertext, the size of the
475 block-type-specific-data will grow after an encryption operation.
476 Security acceptors MUST NOT assume that the size of the plaintext is
477 the same as the size of the ciphertext.
479 Each confidentiality result SHALL use the "detached" payload form
480 with nil payload value. The confidentiality result for COSE_Encrypt
481 and COSE_Encrypt0 messages are computed by the procedure in
482 Section 5.3 of [RFC8152].
484 The COSE "protected attributes from the application" used for an
485 encryption result SHALL be the encoded data defined in Section 2.5.1.
486 The COSE payload used for an encryption result SHALL be the block-
487 type-specific data of the target. Because confidentiality of the
488 primary block is disallowed by BPSec, there is no logic here for
489 handling a BCB with a target on the primary block.
491 2.4. Key Considerations
493 This specification does not impose any additional key requirements
494 beyond those already specified for each COSE algorithm required in
495 Section 3.
497 2.5. Canonicalization Algorithms
499 Generating or processing COSE messages for the COSE context follows
500 the profile defined in Section 3 with the "protected attributes from
501 the application" (i.e., the "external_aad" item) generated as defined
502 in Section 2.5.1.
504 2.5.1. Generating AAD
506 The AAD used for both integrity and confidentiality messages SHALL be
507 the deterministically encoded form of a CBOR array containing the
508 following:
510 1. The first item SHALL be either: the CBOR array (unencoded) form
511 of the primary block of the bundle if the AAD Scope has the has-
512 primary-ctx flag set, otherwise the null value.
514 2. The second item SHALL be either: a CBOR array containing the
515 first three fields of the target block (i.e., the block type
516 code, block number, and control flags) if the AAD Scope has the
517 has-target-ctx flag set, otherwise the null value.
519 3. The third item SHALL be either: a CBOR array containing the first
520 three fields of the security block containing the result (i.e.,
521 the block type code, block number, and control flags) if the AAD
522 Scope has the has-security-ctx flag set, otherwise the null
523 value.
525 4. The fourth item SHALL be the Additional Protected header map,
526 which is a bstr value and has a default value of the empty bstr.
528 A CDDL representation of this data is shown below in Figure 6.
530 AAD-structure = [
531 ; non-null if has-primary-ctx is set
532 primary-ctx: null / primary-block,
533 ; non-null if has-target-ctx is set
534 target-ctx: null / block-metadata,
535 ; non-null if has-security-ctx is set
536 security-ctx: null / block-metadata,
537 ; copy of additional-protected (or default)
538 additional-protected
539 ]
540 ; The first three fields of BP "canonical-block-structure"
541 block-metadata = [
542 block-type-code: uint,
543 block-number: uint,
544 block-control-flags,
545 ]
547 Figure 6: COSE context AAD CDDL
549 2.5.2. Payload Data
551 When correlating between BPSec target block-type-specific-data and
552 COSE plaintext or payload, any byte string SHALL be handled in its
553 decoded (CBOR item) form. This means any CBOR header or tag in a
554 source encoding are ignored for the purposes of security processing.
555 This also means that if the source byte string was encoded in a non-
556 conforming way, for example in indefinite-length form or with a non-
557 minimum-size length, the security processing always treats it in a
558 deterministically encoded CBOR form.
560 2.6. Processing
562 This section describes block-level requirements for handling COSE
563 security data.
565 Security results generated for BIB or BCB results SHALL conform to
566 the COSE profile of Section 3.
568 2.6.1. Node Authentication
570 This section explains how the certificate profile of Section 4 is
571 used by a security acceptor to both validate an end-entity
572 certificate and to use that certificate to authenticate the security
573 source for an integrity result. For a confidentiality result, some
574 of the requirements in this section are implicit in an implementation
575 using a private key associated with a certificate used by a result
576 recipient. It is an implementation matter to ensure that a BP agent
577 is configured to generate or receive results associated with valid
578 certificates.
580 A security source MAY prohibit generating a result (either integrity
581 or confidentiality) for an end-entity certificate which is not
582 considered valid according to Section 2.6.1.2. Generating a result
583 which is likely to be discarded is wasteful of bundle size and
584 transport resources.
586 2.6.1.1. Certificate Identification
588 Because of the standard policy of using separate certificates for
589 transport, signing, and encryption (see Section 4.1) a single Node ID
590 is likely to be associated with multiple certificates, and any or all
591 of those certificates MAY be present within an "x5bag" in an
592 Additional Protected parameter (see Section 2.2.2). When present, a
593 security acceptor SHALL use an "x5chain" or "x5t" to identify an end-
594 entity certificate to use for result processing. Security acceptors
595 SHALL NOT assume that a validated certificate containing a NODE-ID
596 matching a security source is enough to associate a certificate with
597 a COSE message or recipient (see Section 3.3).
599 2.6.1.2. Certificate Validation
601 For each end-entity certificate contained in or identified by by a
602 COSE result, the security acceptor SHALL perform the certification
603 path validation of Section 6 of [RFC5280] up to one of the acceptor's
604 trusted CA certificates. When evaluating a certificate Validity
605 period, the security acceptor SHALL use the bundle Creation Timestamp
606 time (if not unknown) as the reference instead of the current time.
607 If enabled by local policy, the entity SHALL perform an OCSP check of
608 each certificate providing OCSP authority information in accordance
609 with [RFC6960]. If certificate validation fails or if security
610 policy disallows a certificate for any reason, the acceptor SHALL
611 treat the associated security result as failed. Leaving out part of
612 the certification chain can cause the entity to fail to validate a
613 certificate if the left-out certificates are unknown to the entity
614 (see Section 6.2).
616 For each end-entity certificate contained in or identified by a COSE
617 context result, the security acceptor SHALL apply security policy to
618 the Key Usage extension (if present) and Extended Key Usage extension
619 (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the
620 profile in Section 4.
622 2.6.1.3. Node ID Authentication
624 If required by security policy, for each end-entity certificate
625 referenced by a COSE context integrity result the security acceptor
626 SHALL validate the certificate NODE-ID in accordance with Section 6
627 of [RFC6125] using the NODE-ID reference identifier from the Security
628 Source of the containing security block. If the NODE-ID validation
629 result is Failure or if the result is Absent and security policy
630 requires an authenticated Node ID, the security acceptor SHALL treat
631 the result as failed.
633 2.6.2. Policy Recommendations
635 A RECOMMENDED security policy is to enable the use of OCSP checking
636 when internet connectivity is present. A RECOMMENDED security policy
637 is that if an Extended Key Usage is present that it needs to contain
638 "id-kp-bundleSecurity" to be usable as an end-entity certificate for
639 COSE security results. A RECOMMENDED security policy is to require a
640 validated Node ID (of Section 2.6.1.3) and to ignore any other
641 identifiers in the end-entity certificate.
643 This policy relies on and informs the certificate requirements in
644 Section 3.3.1 and Section 4. This policy assumes that a DTN-aware CA
645 (see Section 1.2) will only issue a certificate for a Node ID when it
646 has verified that the private key holder actually controls the DTN
647 node; this is needed to avoid the threat identified in Section 6.4.
648 This policy requires that a certificate contain a NODE-ID and allows
649 the certificate to also contain network-level identifiers. A
650 tailored policy on a more controlled network could relax the
651 requirement on Node ID validation and/or Extended Key Usage presence.
653 3. COSE Profile for BPSec
655 This section contains requirements which apply to the use of COSE
656 within BPSec across any security context use.
658 3.1. COSE Messages
660 When generating a BPSec result, security sources SHALL use encode
661 COSE labels with a uint value. When processing a BPSec result,
662 security acceptors MAY handle COSE labels with with a tstr value.
664 When used in a BPSec result, each COSE message SHALL contain an
665 explicit algorithm identifier in the lower (content) layers. When
666 available and not implied by the bundle source, a COSE message SHALL
667 contain a key identifier in the highest (recipient) layer. See
668 Section 3.3 for specifics about asymmetric key identifiers. When a
669 key identifier is not available, BPSec acceptors SHALL use the
670 Security Source (if available) and the Bundle Source to imply which
671 keys can be used for security operations. Using implied keys has an
672 interoperability risk, see Section 6.5 for details. A BPSec security
673 operation always occurs within the context of the immutable primary
674 block with its parameters (specifically the Source Node ID) and the
675 security block with its optional Security Source.
677 The algorithms required by this profile focuses on networks using
678 shared symmetric-keys, with recommended algorithms for Elliptic Curve
679 (EC) keypairs and RSA keypairs. The focus of this profile is to
680 enable interoperation between security sources and acceptors on an
681 open network, where more explicit COSE parameters make it easier for
682 BPSec acceptors to avoid assumptions and avoid out-of-band
683 parameters. The requirements of this profile still allow the use of
684 potentially not-easily-interoperable algorithms and message/recipient
685 configurations for use by private networks, where message size is
686 more important than explicit COSE parameters.
688 3.2. Interoperability Algorithms
690 The set of integrity algorithms needed for interoperability is listed
691 here. The full set of COSE algorithms available is managed at
692 [IANA-COSE].
694 Implementations conforming to this specification SHALL support the
695 symmetric keyed and key-encryption algorithms of Table 5.
696 Implementations capable of doing so SHOULD support the asymmetric
697 keyed and key-encryption algorithms of Table 5.
699 | The layer-1 required list is identical to the
700 | [I-D.ietf-dtn-bpsec-default-sc] context list.
702 +=================+============+============+======+================+
703 | BPSec Block | COSE | Name | Code | Implementation |
704 | | Layer | | | Requirements |
705 +=================+============+============+======+================+
706 | Integrity | 1 | HMAC | 5 | Required |
707 | | | 256/256 | | |
708 +-----------------+------------+------------+------+----------------+
709 | Integrity | 1 | ES256 | -7 | Recommended |
710 +-----------------+------------+------------+------+----------------+
711 | Integrity | 1 | EdDSA | -8 | Recommended |
712 +-----------------+------------+------------+------+----------------+
713 | Integrity | 1 | PS256 | -37 | Recommended |
714 +-----------------+------------+------------+------+----------------+
715 | Confidentiality | 1 | A256GCM | 3 | Required |
716 +-----------------+------------+------------+------+----------------+
717 | Confidentiality | 2 | A256KW | -5 | Required |
718 +-----------------+------------+------------+------+----------------+
719 | Confidentiality | 2 | ECDH-ES + | -31 | Recommended |
720 | | | A256KW | | |
721 +-----------------+------------+------------+------+----------------+
722 | Confidentiality | 2 | ECDH-SS + | -34 | Recommended |
723 | | | A256KW | | |
724 +-----------------+------------+------------+------+----------------+
725 | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended |
726 | | | w/ SHA-256 | | |
727 +-----------------+------------+------------+------+----------------+
729 Table 5: Interoperability Algorithms
731 The following are recommended key and recipient uses within COSE/
732 BPSec:
734 Symmetric Key Integrity: When generating a BIB result from a
735 symmetric key, implementations SHALL use a COSE_Mac0 using the
736 private key directly. When a COSE_Mac0 is used with a direct key,
737 the headers SHALL include a key identifier ("kid" header).
739 EC Keypair Integrity: When generating a BIB result from an EC
740 keypair, implementations SHALL use a COSE_Sign1 using the private
741 key directly. When a COSE_Sign1 is used with an EC keypair, the
742 headers SHALL include a public key identifier (see Section 3.3).
744 RSA Keypair Integrity: When generating a BIB result from an RSA
745 keypair, implementations SHALL use a COSE_Sign1 using the private
746 key directly. When a COSE_Sign1 is used with an RSA keypair, the
747 headers SHALL include a public key identifier (see Section 3.3).
748 When a COSE signature is generated with an RSA keypair, the
749 signature uses a PSS salt in accordance with Section 2 of
750 [RFC8230].
752 Symmetric Key Confidentiality: When generating a BCB result from an
753 symmetric key, implementations SHALL use a COSE_Encrypt message
754 with a recipient containing an indirect (wrapped or derived)
755 content encryption key (CEK). When generating a BCB result from a
756 symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or
757 COSE_Encrypt with direct CEK. Doing so risks key overuse and the
758 vulnerabilities associated with large amount of ciphertext from
759 the same key. When a COSE_Encrypt is used with an overall key-
760 encryption key (KEK), the recipient layer SHALL include a key
761 identifier for the KEK.
763 EC Keypair Confidentiality: When generating a BCB result from an EC
764 keypair, implementations SHALL use a COSE_Encrypt message with a
765 recipient containing an indirect (wrapped or derived) CEK. When a
766 COSE_Encrypt is used with an EC keypair, the recipient layer SHALL
767 include a public key identifier (see Section 3.3). When a
768 COSE_Encrypt is used with an EC keypair, the security source SHALL
769 either generate an ephemeral EC keypair or choose a unique PartyU
770 Nonce for each security operation. When processing a COSE_Encrypt
771 with an EC keypair, the security acceptor SHALL process all KDF
772 and HMAC context data from the recipient headers in accordance
773 with Section 11.2 of [RFC8152] even though the source is not
774 required to provide any of those parameters.
776 RSA Keypair Confidentiality: When generating a BCB result from an
777 RSA keypair, implementations SHALL use a COSE_Encrypt message with
778 a recipient containing a key-wrapped CEK. When a COSE_Encrypt is
779 used with an RSA keypair, the recipient layer SHALL include a
780 public key identifier (see Section 3.3).
782 3.3. Asymmetric Key Types and Identifiers
784 This section applies when a BIB uses a public key for verification,
785 or when a BCB uses a public key for encryption. When using
786 asymmetric keyed algorithms, the security source SHALL include a
787 public key identifier as a recipient header. The public key
788 identifier SHALL be either a "kid" of [RFC8152], an "x5t" or
789 "x5chain" of [I-D.ietf-cose-x509], or an equivalent identifier.
791 When a BIB result contains a "kid" identifier, the security source
792 MAY include an appropriate COSE public key "COSE_Key" in a key
793 container security parameter (see Section 2.2.1). When BIB result
794 contains a "x5t" identifier, the security source MAY include an
795 appropriate PKIX certificate container ("x5chain" or "x5bag" of
796 [I-D.ietf-cose-x509]) in a direct COSE header or an additional header
797 security parameter (see Section 2.2.2). When a BIB result contains
798 an "x5chain", the security source SHOULD NOT also include an "x5t" as
799 the first certificate in the chain is implicitly the applicable end-
800 entity certificate. For a BIB, if all potential security acceptors
801 are known to possess related public key and/or certificate data then
802 the public key or additional header parameters can be omitted. Risks
803 of not including related data are described in Section 6.5 and
804 Section 6.6.
806 When present, public keys and certificates SHOULD be included as
807 additional header parameters rather than within result COSE messages.
808 This provides size efficiency when multiple security results are
809 present because they will all be from the same security source and
810 likely share the same public key material. Security acceptors SHALL
811 still process public keys or certificates present in a result message
812 or recipient as applying to that individual COSE level.
814 Security acceptors SHALL aggregate all COSE_Key objects from all
815 parameters within a single BIB or BCB, independent of encoded type or
816 order of parameters. Because each context contains a single set of
817 security parameters which apply to all results in the same context,
818 security acceptors SHALL treat all public keys as being related to
819 the security source itself and potentially applying to every result.
821 3.3.1. Policy Recommendations
823 The RECOMMENDED priority policy for including PKIX material for BIB
824 results is as follows:
826 1. When receivers are not known to possess certificate chains, a
827 full chain is included (as an "x5chain").
829 2. When receivers are known to possess root and intermediate CAs,
830 just the end-entity certificate is included (again as an
831 "x5chain").
833 3. When receivers are known to possess associated chains including
834 end-entity certificates, a certificate thumbnail (as an "x5t").
836 4. Some arbitrary identifier is used to correlate to an end-entity
837 certificate (as a "kid").
839 5. The BIB Security Source is used to imply an associated end-entity
840 certificate which identifies that Node ID.
842 When PKIX certificates are used by security acceptors and the end-
843 entity certificate is not explicitly trusted (i.e. pinned), the
844 security acceptor SHALL perform the certification path validation of
845 Section 2.6.1.2 up to one or more trusted CA certificates. Leaving
846 out part of the certification chain can cause the security acceptor
847 to fail to validate a BIB if the left-out certificates are unknown to
848 the acceptor (see Section 6.6).
850 Any end-entity certificate associated with a BPSec security source
851 SHALL adhere to the profile of Section 4.
853 4. PKIX Certificate Profile
855 This section contains requirements on certificates used for the COSE
856 context, while Section 3.3 contains requirements for how such
857 certificates are transported or identified.
859 All end-entity certificates used for BPSec SHALL conform to
860 [RFC5280], or any updates or successors to that profile.
862 This profile requires Version 3 certificates due to the extensions
863 used by this profile. Security acceptors SHALL reject as invalid
864 Version 1 and Version 2 end-entity certificates.
866 Security acceptors SHALL accept certificates that contain an empty
867 Subject field or contain a Subject without a Common Name. Identity
868 information in end-entity certificates is contained entirely in the
869 subjectAltName extension as a NODE-ID, as defined in
870 [I-D.ietf-dtn-tcpclv4].
872 All end-entity and CA certificates used for BPSec SHOULD contain both
873 a Subject Key Identifier extension in accordance with Section 4.2.1.2
874 of [RFC5280] and an Authority Key Identifier extension in accordance
875 with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT
876 rely on either a Subject Key Identifier and an Authority Key
877 Identifier being present in any received certificate. Including key
878 identifiers simplifies the work of an entity needing to assemble a
879 certification chain.
881 A BPSec end-entity certificate SHALL contain a NODE-ID which
882 authenticates the Node ID of the security source (for integrity) or
883 the security acceptor (for confidentiality). The identifier type
884 NODE-ID is defined in [I-D.ietf-dtn-tcpclv4].
886 When allowed by CA policy, a BPSec end-entity certificate SHOULD
887 contain a PKIX Extended Key Usage extension in accordance with
888 Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage
889 extension is present, it SHALL contain a key purpose "id-kp-
890 bundleSecurity" of [IANA-SMI]. The "id-kp-bundleSecurity" purpose
891 MAY be combined with other purposes in the same certificate.
893 When allowed by CA policy, a BPSec end-entity certificate SHALL
894 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
895 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE
896 security are: digitalSignature, nonRepudiation, keyEncipherment, and
897 keyAgreement. The specific algorithms used by COSE messages in
898 security results determine which of those key uses are exercised.
899 See Section 4.1 for discussion of key use policies across multiple
900 certificates.
902 A BPSec end-entity certificate MAY contain an Online Certificate
903 Status Protocol (OCSP) URI within an Authority Information Access
904 extension in accordance with Section 4.2.2.1 of [RFC5280]. Security
905 acceptors are not expected to have continuous internet connectivity
906 sufficient to perform OCSP verification.
908 4.1. Multiple-Certificate Uses
910 A RECOMMENDED security policy is to limit asymmetric keys (and thus
911 public key certificates) to single uses among the following:
913 Bundle transport: With key uses as defined in the convergence layer
914 specification(s).
916 Block signing: With key use digitalSignature and/or nonRepudiation.
918 Block encryption: With key use keyEncipherment and/or keyAgreement.
920 This policy is the same one recommended by Section 6 of [RFC8551] for
921 email security and by Section 5.2 of [NIST-SP800-57] more generally.
922 Effectively this means that a BP node uses separate certificates for
923 transport (e.g., as a TCPCL entity), BIB signing (as a security
924 source), and BCB encryption (as a security acceptor).
926 5. Implementation Status
928 This section is to be removed before publishing as an RFC.
930 [NOTE to the RFC Editor: please remove this section before
931 publication, as well as the reference to [RFC7942] and
932 [github-dtn-bpsec-cose].]
933 This section records the status of known implementations of the
934 protocol defined by this specification at the time of posting of this
935 Internet-Draft, and is based on a proposal described in [RFC7942].
936 The description of implementations in this section is intended to
937 assist the IETF in its decision processes in progressing drafts to
938 RFCs. Please note that the listing of any individual implementation
939 here does not imply endorsement by the IETF. Furthermore, no effort
940 has been spent to verify the information presented here that was
941 supplied by IETF contributors. This is not intended as, and must not
942 be construed to be, a catalog of available implementations or their
943 features. Readers are advised to note that other implementations can
944 exist.
946 An example implementation of COSE over Blocks has been created as a
947 GitHub project [github-dtn-bpsec-cose] and is intended to use as a
948 proof-of-concept and as a possible source of interoperability
949 testing. This example implementation only handles CBOR encoding/
950 decoding and cryptographic functions, it does not construct actual
951 BIB or BCB and does not integrate with a BP Agent.
953 6. Security Considerations
955 This section separates security considerations into threat categories
956 based on guidance of BCP 72 [RFC3552].
958 All of the security considerations of the underlying BPSec
959 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
961 6.1. Threat: BPSec Block Replay
963 The bundle's primary block contains fields which uniquely identify a
964 bundle: the Source Node ID, Creation Timestamp, and fragment
965 parameters (see Section 4.3.1 of [I-D.ietf-dtn-bpbis]). These same
966 fields are used to correlate Administrative Records with the bundles
967 for which the records were generated. Including the primary block in
968 the AAD Scope for integrity and confidentiality (see Section 2.2.3)
969 binds the verification of the secured block to its parent bundle and
970 disallows replay of any block with its BIB or BCB.
972 This profile of COSE limits the encryption algorithms to only AEAD in
973 order to include the context of the encrypted data as AAD. If an
974 agent mistakenly allows the use of non-AEAD encryption when
975 decrypting and verifying a BCB, the possibility of block replay
976 attack is present.
978 6.2. Threat: Untrusted End-Entity Certificate
980 The profile in Section 2.6.1 uses end-entity certificates chained up
981 to a trusted root CA. A security source can include a certificate
982 set which does not contain the full chain, possibly excluding
983 intermediate or root CAs. In an environment where security acceptors
984 are known to already contain needed root and intermediate CAs there
985 is no need to include those CAs, but this has a risk of an acceptor
986 not actually having one of the needed CAs.
988 6.3. Threat: Certificate Validation Vulnerabilities
990 Even when a security acceptor is operating properly an attacker can
991 attempt to exploit vulnerabilities within certificate check
992 algorithms or configuration to authenticate using an invalid
993 certificate. An invalid certificate exploit could lead to higher-
994 level security issues and/or denial of service to the Node ID being
995 impersonated.
997 There are many reasons, described in [RFC5280] and [RFC6125], why a
998 certificate can fail to validate, including using the certificate
999 outside of its valid time interval, using purposes for which it was
1000 not authorized, or using it after it has been revoked by its CA.
1001 Validating a certificate is a complex task and can require network
1002 connectivity outside of the primary BP convergence layer network
1003 path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The
1004 configuration and use of particular certificate validation methods
1005 are outside of the scope of this document.
1007 6.4. Threat: BP Node Impersonation
1009 When certificates are referenced by BIB results it is possible that
1010 the certificate does not contain a NODE-ID or does contain one but
1011 has a mismatch with the actual security source (see Section 1.2).
1012 Having a CA-validated certificate does not alone guarantee the
1013 identity of the security source from which the certificate is
1014 provided; additional validation procedures in Section 2.6.1 bind the
1015 Node ID based on the contents of the certificate.
1017 6.5. Threat: Unidentifiable Key
1019 The profile in Section 3.2 recommends key identifiers when possible
1020 and the parameters in section Section 2.2 allow encoding public keys
1021 where available. If the application using a COSE Integrity or COSE
1022 Confidentiality context leaves out key identification data (in a COSE
1023 recipient structure), the security acceptor for those BPSec blocks
1024 only has the primary block available to use when verifying or
1025 decrypting the target block. This leads to a situation, identified
1026 in BPSec Security Considerations, where a signature is verified to be
1027 valid but not from the expected Security Source.
1029 Because the key identifier headers are unprotected (see Section 3.3),
1030 there is still the possibility that an active attacker removes or
1031 alters key identifier(s) in the result. This can cause the security
1032 acceptor to not be able to properly verify a valid signature or not
1033 use the correct private key to decrypt valid ciphertext.
1035 6.6. Threat: Non-Trusted Public Key
1037 The profile in Section 3.2 allows the use of PKIX which typically
1038 involves end-entity certificates chained up to a trusted root CA.
1039 This allows a BIB to contain end-entity certificates not previously
1040 known to a security acceptor but still trust the certificate by
1041 verifying it up to a trusted CA. In an environment where security
1042 acceptors are known to already contain needed root and intermediate
1043 CAs there is no need to include those CAs in a proper chain within
1044 the security parameters, but this has a risk of an acceptor not
1045 actually having one of the needed CAs.
1047 Because the security parameters are not included as AAD, there is
1048 still the possibility that an active attacker removes or alters
1049 certification chain data in the parameters. This can cause the
1050 security acceptor to be able to verify a valid signature but not
1051 trust the public key used to perform the verification.
1053 6.7. Threat: Passive Leak of Key Material
1055 It is important that the key requirements of Section 2.2 apply only
1056 to public keys and PKIX certificates. Including non-public key
1057 material in ASB parameters will expose that material in the bundle
1058 data and over the bundle convergence layer during transport.
1060 6.8. Threat: Algorithm Vulnerabilities
1062 Because this use of COSE leaves the specific algorithms chosen for
1063 BIB and BCB use up to the applications securing bundle data, it is
1064 important to use only COSE algorithms which are marked as recommended
1065 in the IANA registry [IANA-COSE].
1067 7. IANA Considerations
1069 Registration procedures referred to in this section are defined in
1070 [RFC8126].
1072 7.1. BPSec Security Contexts
1074 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
1075 entry has been added to the "BPSec Security Context Identifiers" sub-
1076 registry.
1078 +==========+=============+=====================+
1079 | Value | Description | Reference |
1080 +==========+=============+=====================+
1081 | TBD-COSE | COSE | This specification. |
1082 +----------+-------------+---------------------+
1084 Table 6
1086 8. Acknowledgments
1088 The interoperability minimum algorithms and parameters are based on
1089 the draft [I-D.ietf-dtn-bpsec-default-sc].
1091 9. References
1093 9.1. Normative References
1095 [IANA-BUNDLE]
1096 IANA, "Bundle Protocol",
1097 .
1099 [IANA-COSE]
1100 IANA, "CBOR Object Signing and Encryption (COSE)",
1101 .
1103 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers",
1104 .
1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1107 Requirement Levels", BCP 14, RFC 2119,
1108 DOI 10.17487/RFC2119, March 1997,
1109 .
1111 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1112 Housley, R., and W. Polk, "Internet X.509 Public Key
1113 Infrastructure Certificate and Certificate Revocation List
1114 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1115 .
1117 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1118 Verification of Domain-Based Application Service Identity
1119 within Internet Public Key Infrastructure Using X.509
1120 (PKIX) Certificates in the Context of Transport Layer
1121 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1122 2011, .
1124 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1125 Galperin, S., and C. Adams, "X.509 Internet Public Key
1126 Infrastructure Online Certificate Status Protocol - OCSP",
1127 RFC 6960, DOI 10.17487/RFC6960, June 2013,
1128 .
1130 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1131 Writing an IANA Considerations Section in RFCs", BCP 26,
1132 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1133 .
1135 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
1136 RFC 8152, DOI 10.17487/RFC8152, July 2017,
1137 .
1139 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1140 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1141 May 2017, .
1143 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
1144 and Encryption (COSE) Messages", RFC 8230,
1145 DOI 10.17487/RFC8230, September 2017,
1146 .
1148 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
1149 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
1150 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
1151 April 2019, .
1153 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
1154 Definition Language (CDDL): A Notational Convention to
1155 Express Concise Binary Object Representation (CBOR) and
1156 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
1157 June 2019, .
1159 [I-D.ietf-dtn-bpsec]
1160 Birrane, E. and K. McKeever, "Bundle Protocol Security
1161 Specification", Work in Progress, Internet-Draft, draft-
1162 ietf-dtn-bpsec-26, 8 January 2021,
1163 .
1165 [I-D.ietf-dtn-tcpclv4]
1166 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
1167 Tolerant Networking TCP Convergence Layer Protocol Version
1168 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
1169 tcpclv4-24, 7 December 2020,
1170 .
1172 [I-D.ietf-cose-x509]
1173 Schaad, J., "CBOR Object Signing and Encryption (COSE):
1174 Header parameters for carrying and referencing X.509
1175 certificates", Work in Progress, Internet-Draft, draft-
1176 ietf-cose-x509-08, 14 December 2020,
1177 .
1179 9.2. Informative References
1181 [NIST-SP800-57]
1182 National Institute of Standards and Technology,
1183 "Recommendation for Key Management - Part 1: General",
1184 NIST Special Publication 800-57 Revision 4, DOI 10.6028/
1185 NIST.SP.800-57pt1r5, May 2020,
1186 .
1189 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1190 Text on Security Considerations", BCP 72, RFC 3552,
1191 DOI 10.17487/RFC3552, July 2003,
1192 .
1194 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1195 Code: The Implementation Status Section", BCP 205,
1196 RFC 7942, DOI 10.17487/RFC7942, July 2016,
1197 .
1199 [I-D.ietf-dtn-bpbis]
1200 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
1201 Version 7", Work in Progress, Internet-Draft, draft-ietf-
1202 dtn-bpbis-31, 25 January 2021,
1203 .
1205 [I-D.ietf-dtn-bpsec-default-sc]
1206 Birrane, E., "BPSec Default Security Contexts", Work in
1207 Progress, Internet-Draft, draft-ietf-dtn-bpsec-default-sc-
1208 00, 26 January 2021, .
1211 [github-dtn-bpsec-cose]
1212 Sipos, B., "DTN Bundle Protocol Security COSE Security
1213 Context", .
1215 [github-dtn-demo-agent]
1216 Sipos, B., "Demo Convergence Layer Agent",
1217 .
1219 Appendix A. Examples
1221 These examples are intended to have the correct structure of COSE
1222 security blocks but in some cases use simplified algorithm parameters
1223 or smaller key sizes than are required by the actual COSE profile
1224 defined in this documents. Each example indicates how it differs
1225 from the actual profile if there is a meaningful difference.
1227 All of these examples operate within the context of the bundle
1228 primary block of Figure 7 with a security target block of Figure 8.
1229 All example figures use the extended diagnostic notation [RFC8610].
1231 [
1232 7, / BP version /
1233 0, / flags /
1234 0, / CRC type /
1235 [1, "//dst/svc"], / destination /
1236 [1, "//src/"], / source /
1237 [1, "//src/"], / report-to /
1238 [0, 40], / timestamp /
1239 1000000 / lifetime /
1240 ]
1242 Figure 7: Primary block CBOR diagnostic
1244 [
1245 7, / type code - bundle age /
1246 2, / block num /
1247 0, / flags /
1248 0, / CRC type /
1249 <<300>> / type-specific-data: age /
1250 ]
1252 Figure 8: Target block CBOR diagnostic
1254 All of the examples also operate within a security block containing
1255 the AAD Scope parameter with only "has-primary-ctx" and "has-target-
1256 ctx" flags set. This results in a consistent AAD-structure as shown
1257 in Figure 9, which is encoded as the byte string for COSE
1258 external_aad in all of the examples.
1260 [
1261 [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ],
1262 [ 0, 40 ], 1000000 ], / primary-ctx /
1263 [ 7, 2, 0 ], / target-ctx /
1264 null, / security-ctx /
1265 '' / additional-protected /
1266 ]
1268 Figure 9: Example scope AAD-structure CBOR diagnostic
1270 The only differences between these examples which use EC or RSA
1271 keypairs and a use of a PKIX public key certificate are: the
1272 parameters would have an x5chain parameter instead of a COSE_Key
1273 type, and the recipient would contain an "x5t" value instead of a
1274 "kid" value. Neither of these is a change to a protected header so,
1275 given the same private key, there would be no change to the signature
1276 or wrapped-key data.
1278 Because each of the encryption examples use the same CEK within the
1279 same AAD, the target ciphertext is also identical. The target block
1280 after application of the encryption is shown in Figure 10.
1282 [
1283 7, / type code - bundle age /
1284 2, / block num /
1285 0, / flags /
1286 0, / CRC type /
1287 h'63bb166949afd31b50841ee05153b9cfaf788d' / ciphertext /
1288 ]
1290 Figure 10: Encrypted Target block CBOR diagnostic
1292 A.1. Symmetric Key COSE_Mac0
1294 This is an example of a MAC with recipient having a 256-bit symmetric
1295 key identified by a "kid".
1297 [
1298 {
1299 / kty / 1: 4, / symmetric /
1300 / kid / 2: 'ExampleMAC',
1301 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1302 99dbae4ce45c'
1303 }
1304 ]
1306 Figure 11: Symmetric Key
1308 The external_aad is the encoded data from Figure 9. The payload is
1309 the encoded target block-type-specific data from Figure 8.
1311 [
1312 "MAC0", / context /
1313 h'a10105', / protected /
1314 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1315 72632f820018281a000f424083070200f640', / external_aad /
1316 h'19012c' / payload /
1317 ]
1319 Figure 12: MAC_structure CBOR diagnostic
1321 [
1322 [2], / targets /
1323 0, / security context TBD-COSE /
1324 1, / flags: params-present /
1325 [ / parameters /
1326 [
1327 5, / AAD-scope /
1328 0x03 / has-primary-ctx | has-target-ctx /
1329 ]
1330 ],
1331 [
1332 [ / target block #2 /
1333 [ / result /
1334 17, / COSE_Mac0 tag /
1335 <<[
1336 <<{ / protected /
1337 / alg / 1:5 / HMAC 256//256 /
1338 }>>,
1339 { / unprotected /
1340 / kid / 4:'ExampleMAC'
1341 },
1342 null, / payload detached /
1343 h'fa8b08724db1f0f4097156b12e65a1e7d57cfcdd413ced62d9e20f2b
1344 a4efcea5' / tag /
1345 ]>>
1346 ]
1347 ]
1348 ]
1349 ]
1351 Figure 13: Abstract Security Block CBOR diagnostic
1353 A.2. EC Keypair COSE_Sign1
1355 This is an example of a signature with a recipient having a P-256
1356 curve EC keypair identified by a "kid". The associated public key is
1357 included as a security parameter.
1359 [
1360 { / signing private key /
1361 / kty / 1: 2, / EC2 /
1362 / kid / 2: 'ExampleEC2',
1363 / crv / -1: 1, / P-256 /
1364 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1365 e4fe0a1787a8',
1366 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1367 1639960a0c7a',
1368 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1369 89786ea63842'
1370 }
1371 ]
1373 Figure 14: Example Keys
1375 The external_aad is the encoded data from Figure 9. The payload is
1376 the encoded target block-type-specific data from Figure 8.
1378 [
1379 "Signature1", / context /
1380 h'a10126', / protected /
1381 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1382 72632f820018281a000f424083070200f640', / external_aad /
1383 h'19012c' / payload /
1384 ]
1386 Figure 15: Sig_structure CBOR diagnostic
1388 [
1389 [2], / targets /
1390 0, / security context TBD-COSE /
1391 1, / flags: params-present /
1392 [ / parameters /
1393 [
1394 5, / AAD-scope /
1395 0x03 / has-primary-ctx | has-target-ctx /
1396 ]
1397 ],
1398 [
1399 [ / target block #2 /
1400 [ / result /
1401 18, / COSE_Sign1 tag /
1402 <<[
1403 <<{ / protected /
1404 / alg / 1:-7 / ES256 /
1405 }>>,
1406 { / unprotected /
1407 / kid / 4:'ExampleEC2'
1408 },
1409 null, / payload detached /
1410 h'66358aa1ee41276688e417d7686db3914f3a6d061a31145912fc18ac
1411 68c1b980e9bbae2d18887677f9f8fb1d0a6133e62d89a2616826fd1109620122cde6
1412 eb5c' / signature /
1413 ]>>
1414 ]
1415 ]
1416 ]
1417 ]
1419 Figure 16: Abstract Security Block CBOR diagnostic
1421 A.3. RSA Keypair COSE_Sign1
1423 This is an example of a signature with a recipient having a 1024-bit
1424 RSA keypair identified by a "kid". The associated public key is
1425 included as a security parameter.
1427 This key strength is not supposed to be a secure configuration, only
1428 intended to explain the procedure. This signature uses a random
1429 salt, so the full signature output is not deterministic.
1431 [
1432 { / signing private key /
1433 / kty / 1: 3, / RSA /
1434 / kid / 2: 'ExampleRSA',
1435 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1436 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1437 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1438 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1439 25',
1440 / e / -2: h'010001',
1441 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1442 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1443 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1444 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1445 01',
1446 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1447 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1448 c3d00e75',
1449 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1450 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1451 7effb9f1',
1452 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1453 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1454 7eea427e1',
1455 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1456 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1457 05ba3af91',
1458 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1459 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1460 f4f92865ca3'
1461 }
1462 ]
1464 Figure 17: Example Keys
1466 The external_aad is the encoded data from Figure 9. The payload is
1467 the encoded target block-type-specific data from Figure 8.
1469 [
1470 "Signature1", / context /
1471 h'a1013824', / protected /
1472 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1473 72632f820018281a000f424083070200f640', / external_aad /
1474 h'19012c' / payload /
1475 ]
1477 Figure 18: Sig_structure CBOR diagnostic
1479 [
1480 [2], / targets /
1481 0, / security context TBD-COSE /
1482 1, / flags: params-present /
1483 [ / parameters /
1484 [
1485 5, / AAD-scope /
1486 0x03 / has-primary-ctx | has-target-ctx /
1487 ]
1488 ],
1489 [
1490 [ / target block #2 /
1491 [ / result /
1492 18, / COSE_Sign1 tag /
1493 <<[
1494 <<{ / protected /
1495 / alg / 1:-37 / PS256 /
1496 }>>,
1497 { / unprotected /
1498 / kid / 4:'ExampleRSA'
1499 },
1500 null, / payload detached /
1501 h'8e469941a292d3554c81d1a69330b88563b28b415cf777c694d83272
1502 550d232b57ed4046d03849c2ade086145339872f7712e36ab4c382c1c541185fb15c
1503 036f00fd2842dff3e9d4f4068716d853f7bfe13791521e28faf42db085ab259a009a
1504 dceeb2acb7852bec6ec5069fc0d237883da8656aa6773682c3e01bd9732028
1505 c6' / signature /
1506 ]>>
1507 ]
1508 ]
1509 ]
1510 ]
1512 Figure 19: Abstract Security Block CBOR diagnostic
1514 A.4. Symmetric KEK COSE_Encrypt
1516 This is an example of an encryption with a random CEK and an explicit
1517 key-encryption key (KEK) identified by a "kid". The keys used are
1518 shown in Figure 20.
1520 [
1521 {
1522 / kty / 1: 4, / symmetric /
1523 / kid / 2: 'ExampleKEK',
1524 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf
1525 ae38ad7a972e'
1526 },
1527 {
1528 / kty / 1: 4, / symmetric /
1529 / kid / 2: 'ExampleCEK',
1530 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1531 99dbae4ce45c'
1532 }
1533 ]
1535 Figure 20: Example Keys
1537 The external_aad is the encoded data from Figure 9.
1539 [
1540 "Encrypt", / context /
1541 h'a10103', / protected /
1542 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1543 72632f820018281a000f424083070200f640' / external_aad /
1544 ]
1546 Figure 21: Enc_structure CBOR diagnostic
1548 The ASB item for this encryption operation is shown in Figure 22 and
1549 corresponds with the updated target block (containing the ciphertext)
1550 of Figure 10.
1552 [
1553 [2], / targets /
1554 0, / security context TBD-COSE /
1555 1, / flags: params-present /
1556 [ / parameters /
1557 [
1558 5, / AAD-scope /
1559 0x03 / has-primary-ctx | has-target-ctx /
1560 ]
1561 ],
1562 [
1563 [ / target block #2 /
1564 [ / result /
1565 96, / COSE_Encrypt tag /
1566 <<[
1567 <<{ / protected /
1568 / alg / 1:3 / A256GCM /
1569 }>>,
1570 { / unprotected /
1571 / iv / 5: h'6f3093eba5d85143c3dc484a'
1572 },
1573 null, / payload detached /
1574 [
1575 [ / recipient /
1576 h'', / protected /
1577 { / unprotected /
1578 / alg / 1:-5, / A256KW /
1579 / kid / 4:'ExampleKEK'
1580 },
1581 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26
1582 d403a6331159e3d691a708e9984d' / key-wrapped /
1583 ]
1584 ]
1585 ]>>
1586 ]
1587 ]
1588 ]
1589 ]
1591 Figure 22: Abstract Security Block CBOR diagnostic
1593 A.5. EC Keypair COSE_Encrypt
1595 This is an example of an encryption with an P-256 curve ephemeral
1596 sender keypair and a static recipient keypair identified by a "kid".
1597 The keys used are shown in Figure 23.
1599 [
1600 { / sender ephemeral private key /
1601 / kty / 1: 2, / EC2 /
1602 / crv / -1: 1, / P-256 /
1603 / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788
1604 ca57d1df6bcc',
1605 / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c
1606 9c0670f28d62',
1607 / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088
1608 0f9d9c3b122a'
1609 },
1610 { / recipient private key /
1611 / kty / 1: 2, / EC2 /
1612 / kid / 2: 'ExampleEC2',
1613 / crv / -1: 1, / P-256 /
1614 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1615 e4fe0a1787a8',
1616 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1617 1639960a0c7a',
1618 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1619 89786ea63842'
1620 },
1621 {
1622 / kty / 1: 4, / symmetric /
1623 / kid / 2: 'ExampleCEK',
1624 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1625 99dbae4ce45c'
1626 }
1627 ]
1629 Figure 23: Example Keys
1631 The external_aad is the encoded data from Figure 9.
1633 [
1634 "Encrypt", / context /
1635 h'a10103', / protected /
1636 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1637 72632f820018281a000f424083070200f640' / external_aad /
1638 ]
1640 Figure 24: Enc_structure CBOR diagnostic
1642 The ASB item for this encryption operation is shown in Figure 25 and
1643 corresponds with the updated target block (containing the ciphertext)
1644 of Figure 10.
1646 [
1647 [2], / targets /
1648 0, / security context TBD-COSE /
1649 1, / flags: params-present /
1650 [ / parameters /
1651 [
1652 5, / AAD-scope /
1653 0x03 / has-primary-ctx | has-target-ctx /
1654 ]
1655 ],
1656 [
1657 [ / target block #2 /
1658 [ / result /
1659 96, / COSE_Encrypt tag /
1660 <<[
1661 <<{ / protected /
1662 / alg / 1:3 / A256GCM /
1663 }>>,
1664 { / unprotected /
1665 / iv / 5: h'6f3093eba5d85143c3dc484a'
1666 },
1667 null, / payload detached /
1668 [
1669 [ / recipient /
1670 h'', / protected /
1671 { / unprotected /
1672 / alg / 1:-31, / ECDH-ES + A256KW /
1673 / kid / 4:'ExampleEC2',
1674 / ephemeral key / -1:{
1675 1:2,
1676 -1:1,
1677 -2:h'fedaba748882050d1bef8ba992911898f554450952070
1678 aeb4788ca57d1df6bcc',
1679 -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2
1680 f493c1c9c0670f28d62'
1681 }
1682 },
1683 h'cb530b03f1e4b09ec1a0ca19afafbf280284106ab407aaf9bfed
1684 6e666c8f2f9ab5465cf11ef02756' / key-wrapped /
1685 ]
1686 ]
1687 ]>>
1688 ]
1689 ]
1690 ]
1691 ]
1693 Figure 25: Abstract Security Block CBOR diagnostic
1695 A.6. RSA Keypair COSE_Encrypt
1697 This is an example of an encryption with a recipient having a
1698 1024-bit RSA keypair identified by a "kid". The associated public
1699 key is included as a security parameter.
1701 This key strength is not supposed to be a secure configuration, only
1702 intended to explain the procedure. This padding scheme uses a random
1703 salt, so the full layer-2 ciphertext output is not deterministic.
1705 [
1706 { / recipient private key /
1707 / kty / 1: 3, / RSA /
1708 / kid / 2: 'ExampleRSA',
1709 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1710 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1711 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1712 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1713 25',
1714 / e / -2: h'010001',
1715 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1716 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1717 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1718 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1719 01',
1720 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1721 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1722 c3d00e75',
1723 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1724 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1725 7effb9f1',
1726 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1727 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1728 7eea427e1',
1729 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1730 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1731 05ba3af91',
1732 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1733 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1734 f4f92865ca3'
1735 },
1736 {
1737 / kty / 1: 4, / symmetric /
1738 / kid / 2: 'ExampleCEK',
1739 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1740 99dbae4ce45c'
1741 }
1742 ]
1743 Figure 26: Example Keys
1745 The external_aad is the encoded data from Figure 9.
1747 [
1748 "Encrypt", / context /
1749 h'a10103', / protected /
1750 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1751 72632f820018281a000f424083070200f640' / external_aad /
1752 ]
1754 Figure 27: Enc_structure CBOR diagnostic
1756 The ASB item for this encryption operation is shown in Figure 28 and
1757 corresponds with the updated target block (containing the ciphertext)
1758 of Figure 10.
1760 [
1761 [2], / targets /
1762 0, / security context TBD-COSE /
1763 1, / flags: params-present /
1764 [ / parameters /
1765 [
1766 5, / AAD-scope /
1767 0x03 / has-primary-ctx | has-target-ctx /
1768 ]
1769 ],
1770 [
1771 [ / target block #2 /
1772 [ / result /
1773 96, / COSE_Encrypt tag /
1774 <<[
1775 <<{ / protected /
1776 / alg / 1:3 / A256GCM /
1777 }>>,
1778 { / unprotected /
1779 / iv / 5: h'6f3093eba5d85143c3dc484a'
1780 },
1781 null, / payload detached /
1782 [
1783 [ / recipient /
1784 h'', / protected /
1785 { / unprotected /
1786 / alg / 1:-41, / RSAES-OAEP w SHA-256 /
1787 / kid / 4:'ExampleRSA'
1788 },
1789 h'66e76f3e924674c02c98ddef1cfee0d79718549849d1bb008993
1790 28d4b66c8ac481de1ddd258f20514cfe040ead00afeb0709ef22e67607ef5ab62562
1791 4753cb247152b54240e51e96b5d7fdd37cf97af23e2292d6c6a0d2a8ab25a82b8a6c
1792 af1d4fa2f1bd7f1fd17d89506e75a1e2687374aa2a1cf21ce387916039d84ecc14
1793 03' / key-wrapped /
1794 ]
1795 ]
1796 ]>>
1797 ]
1798 ]
1799 ]
1800 ]
1802 Figure 28: Abstract Security Block CBOR diagnostic
1804 Author's Address
1805 Brian Sipos
1806 RKF Engineering Solutions, LLC
1807 7500 Old Georgetown Road
1808 Suite 1275
1809 Bethesda, MD 20814-6198
1810 United States of America
1812 Email: BSipos@rkf-eng.com