idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-06.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 (3 June 2021) is 1057 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 381
== Missing Reference: 'AAD-scope' is mentioned on line 381, but not defined
-- Looks like a reference, but probably isn't: '0' on line 1242
-- Looks like a reference, but probably isn't: '40' on line 1242
-- Looks like a reference, but probably isn't: '1' on line 1831
-- 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 (-28) exists of
draft-ietf-dtn-tcpclv4-26
== 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-05
Summary: 2 errors (**), 0 flaws (~~), 6 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 3 June 2021
5 Expires: 5 December 2021
7 DTN Bundle Protocol Security COSE Security Context
8 draft-bsipos-dtn-bpsec-cose-06
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 5 December 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. Raw Public 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 . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . 30
97 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 31
98 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 33
99 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 36
100 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 38
101 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 41
102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
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 | (empty |
261 | | | document | bstr) |
262 +-----------+------------------------+------------------+-----------+
263 | 4 | additional-unprotected | Section 2.2.2 | "{}" |
264 | | | of this | (empty |
265 | | | document | map) |
266 +-----------+------------------------+------------------+-----------+
267 | 5 | AAD_Scope | Section 2.2.3 | "0x7" |
268 | | | of this | (all AAD |
269 | | | document | contexts) |
270 +-----------+------------------------+------------------+-----------+
272 Table 1: COSE Security Parameters
274 2.2.1. Raw Public Key Containers
276 Implementations capable of handling asymmetric-keyed algorithms
277 SHOULD support raw public key handling in COSE_Key and COSE_KeySet
278 parameters.
280 No more than one total COSE_Key or COSE_KeySet parameter SHALL be
281 present in a single security block. Security acceptors are sill
282 required to aggregate multiple parameters, if present, in
283 Section 3.3.
285 Key container parameters SHALL NOT contain any private key material.
286 The security parameters are all stored in the bundle as plaintext and
287 are visible to any bundle handlers.
289 $bpsec-cose-param /= [1, COSE_Key]
290 $bpsec-cose-param /= [2, COSE_KeySet]
292 Figure 2: Key Containers CDDL
294 2.2.2. Additional Header Maps
296 The two parameters Additional Protected and Additional Unprotected
297 allow de-duplicating header items which are common to all COSE
298 results. Both additional header values contain a CBOR map which is
299 to be merged with each of the result's unprotected headers. Although
300 the additional header items are all treated as unprotected from the
301 perspective of the COSE message, the additional protected map is
302 included within the "external_aad" (see Section 2.5.1). The expected
303 use of additional header map is to contain a certificate (chain) or
304 identifier (see Section 3.3) which applies to all results in the same
305 security block.
307 Following the same pattern as COSE, when both additional header maps
308 are present in a single security block they SHALL not contain any
309 duplicated labels. Security acceptors SHALL treat a pair of
310 additional header maps containing duplicated labels as invalid.
312 No more than one of each Additional Protected and Additional
313 Unprotected parameter SHALL be present in a single security block.
314 Security acceptors SHALL treat a security block with multiple
315 instances of either additional header type as invalid. There is no
316 well-defined behavior for a security acceptor to handle multiple
317 Additional Protected parameters.
319 Security sources SHOULD NOT include an additional header parameter
320 which represents an empty map. Security acceptors SHALL handle empty
321 header map parameters, specifically the Additional Protected
322 parameter because it is part of the external_aad.
324 Security acceptors SHALL treat the aggregate of both additional
325 header maps as being present in the "unprotected" header map of the
326 highest-layers of the COSE message of each result. For single-layer
327 messages (i.e., COSE_Encrypt0, COSE_MAC0, and COSE_Sign1) the
328 additional headers apply to the message itself (layer 1) and for
329 other messages the additional headers apply to the final recipients.
330 If the same header label is present in a additional header map and a
331 COSE layer's headers the item in the result header SHALL take
332 precedence (i.e., the additional header items are added only if they
333 are not already present in a layer's header).
335 Additional header maps SHALL NOT contain any private key material.
336 The security parameters are all stored in the bundle as plaintext and
337 are visible to any bundle handlers.
339 $bpsec-cose-param /= [3, additional-protected]
340 additional-protected = empty_or_serialized_map
342 $bpsec-cose-param /= [4, additional-unprotected]
343 additional-unprotected = header_map
345 Figure 3: Additional Headers CDDL
347 2.2.3. AAD Scope
349 The AAD Scope parameter controls what data is included in the AAD for
350 both integrity and confidentiality operations. The AAD Scope
351 parameter SHALL be encoded as a uint value with bit flags defined in
352 Table 2. All reserved bits SHALL be set to zero (which will be
353 elided by CBOR encoding) by security sources. All reserved bits
354 SHALL be ignored by security acceptors. The default value for this
355 parameter has all flags set, meaning the AAD includes all available
356 context.
358 A CDDL representation of this definition is included in Figure 4 for
359 reference.
361 +==================+========+===============================+
362 | Name | Code | Description |
363 +==================+========+===============================+
364 | has-primary-ctx | 0x01 | If bit is set, indicates that |
365 | | | the primary block is included |
366 | | | in AAD scope. |
367 +------------------+--------+-------------------------------+
368 | has-target-ctx | 0x02 | If bit is set, indicates that |
369 | | | the target block metadata is |
370 | | | included in AAD scope. |
371 +------------------+--------+-------------------------------+
372 | has-security-ctx | 0x04 | If bit is set, indicates that |
373 | | | the security block metadata |
374 | | | is included in AAD scope. |
375 +------------------+--------+-------------------------------+
376 | Reserved | others | |
377 +------------------+--------+-------------------------------+
379 Table 2: AAD Scope Flags
381 $bpsec-cose-param /= [5, AAD-scope]
382 AAD-scope = uint .bits AAD-scope-flags
383 AAD-scope-flags = &(
384 has-primary-ctx: 0,
385 has-target-ctx: 1,
386 has-security-ctx: 2,
387 )
389 Figure 4: AAD Scope CDDL
391 2.3. Results
393 Although each COSE context result is a COSE message, the types of
394 message allowed depend upon the security block type in which the
395 result is present: only MAC or signature messages are allowed in a
396 BIB and only encryption messages are allowed in a BCB.
398 The code points for Result ID values are identical to the existing
399 COSE message-marking tags in Section 2 of [RFC8152]. This avoids the
400 need for value-mapping between code points of the two registries.
402 When embedding COSE messages, the message CBOR structure SHALL be
403 encoded as a byte string used as the result value. This allows a
404 security acceptor to skip over unwanted results without needing to
405 decode the result structure. When embedding COSE messages, the CBOR-
406 tagged form SHALL NOT be used. The Result ID values already provide
407 the same information as the COSE tags (using the same code points).
409 These generic requirements are formalized in the CDDL fragment of
410 Figure 5.
412 $bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0]
413 $bpsec-cose-result /= [17, bstr .cbor COSE_Mac0]
414 $bpsec-cose-result /= [18, bstr .cbor COSE_Sign1]
415 $bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt]
416 $bpsec-cose-result /= [97, bstr .cbor COSE_Mac]
417 $bpsec-cose-result /= [98, bstr .cbor COSE_Sign]
419 Figure 5: COSE context results CDDL
421 2.3.1. Integrity Messages
423 When used within a Block Integrity Block, the COSE context SHALL
424 allow only the Result IDs from Table 3. Each integrity result value
425 SHALL consist of the COSE message indicated by Table 3 in its non-
426 tagged encoded form.
428 +===========+====================+===========+
429 | Result ID | Result Structure | Reference |
430 +===========+====================+===========+
431 | 97 | encoded COSE_Mac | [RFC8152] |
432 +-----------+--------------------+-----------+
433 | 17 | encoded COSE_Mac0 | [RFC8152] |
434 +-----------+--------------------+-----------+
435 | 98 | encoded COSE_Sign | [RFC8152] |
436 +-----------+--------------------+-----------+
437 | 18 | encoded COSE_Sign1 | [RFC8152] |
438 +-----------+--------------------+-----------+
440 Table 3: COSE Integrity Results
442 Each integrity result SHALL use the "detached" payload form with
443 "null" payload value. The integrity result for COSE_Mac and
444 COSE_Mac0 messages are computed by the procedure in Section 6.3 of
445 [RFC8152]. The integrity result for COSE_Sign and COSE_Sign1
446 messages are computed by the procedure in Section 4.4 of [RFC8152].
448 The COSE "protected attributes from the application" used for a
449 signature or MAC result SHALL be the encoded data defined in
450 Section 2.5.1. The COSE payload used for a signature or MAC result
451 SHALL be either the block-type-specific data of the target, if the
452 target is not the primary block, or an empty byte string if the
453 target is the primary block.
455 2.3.2. Confidentiality Messages
457 When used within a Block Confidentiality Block, COSE context SHALL
458 allow only the Result IDs from Table 4. Each confidentiality result
459 value SHALL consist of the COSE message indicated by Table 4 in its
460 non-tagged encoded form.
462 +===========+=======================+===========+
463 | Result ID | Result Structure | Reference |
464 +===========+=======================+===========+
465 | 96 | encoded COSE_Encrypt | [RFC8152] |
466 +-----------+-----------------------+-----------+
467 | 16 | encoded COSE_Encrypt0 | [RFC8152] |
468 +-----------+-----------------------+-----------+
470 Table 4: COSE Confidentiality Results
472 Only algorithms which support Authenticated Encryption with
473 Authenticated Data (AEAD) SHALL be usable in the first (content)
474 layer of a confidentiality result. Because COSE encryption with AEAD
475 appends the authentication tag with the ciphertext, the size of the
476 block-type-specific-data will grow after an encryption operation.
477 Security acceptors MUST NOT assume that the size of the plaintext is
478 the same as the size of the ciphertext.
480 Each confidentiality result SHALL use the "detached" payload form
481 with "null" payload value. The confidentiality result for
482 COSE_Encrypt and COSE_Encrypt0 messages are computed by the procedure
483 in Section 5.3 of [RFC8152].
485 The COSE "protected attributes from the application" used for an
486 encryption result SHALL be the encoded data defined in Section 2.5.1.
487 The COSE payload used for an encryption result SHALL be the block-
488 type-specific data of the target. Because confidentiality of the
489 primary block is disallowed by BPSec, there is no logic here for
490 handling a BCB with a target on the primary block.
492 2.4. Key Considerations
494 This specification does not impose any additional key requirements
495 beyond those already specified for each COSE algorithm required in
496 Section 3.
498 2.5. Canonicalization Algorithms
500 Generating or processing COSE messages for the COSE context follows
501 the profile defined in Section 3 with the "protected attributes from
502 the application" (i.e., the "external_aad" item) generated as defined
503 in Section 2.5.1.
505 2.5.1. Generating AAD
507 The AAD used for both integrity and confidentiality messages SHALL be
508 the deterministically encoded form of a CBOR array containing the
509 following:
511 1. The first item SHALL be either: the CBOR array (unencoded) form
512 of the primary block of the bundle if the AAD Scope has the has-
513 primary-ctx flag set, otherwise the null value.
515 2. The second item SHALL be either: a CBOR array containing the
516 first three fields of the target block (i.e., the block type
517 code, block number, and control flags) if the AAD Scope has the
518 has-target-ctx flag set, otherwise the null value.
520 3. The third item SHALL be either: a CBOR array containing the first
521 three fields of the security block containing the result (i.e.,
522 the block type code, block number, and control flags) if the AAD
523 Scope has the has-security-ctx flag set, otherwise the null
524 value.
526 4. The fourth item SHALL be the Additional Protected header map,
527 which is a bstr value and has a default value of the empty bstr.
529 A CDDL representation of this data is shown below in Figure 6.
531 AAD-structure = [
532 ; non-null if has-primary-ctx is set
533 primary-ctx: null / primary-block,
534 ; non-null if has-target-ctx is set
535 target-ctx: null / block-metadata,
536 ; non-null if has-security-ctx is set
537 security-ctx: null / block-metadata,
538 ; copy of additional-protected (or default)
539 additional-protected
540 ]
541 ; The first three fields of BP "canonical-block-structure"
542 block-metadata = [
543 block-type-code: uint,
544 block-number: uint,
545 block-control-flags,
546 ]
548 Figure 6: COSE context AAD CDDL
550 2.5.2. Payload Data
552 When correlating between BPSec target block-type-specific-data and
553 COSE plaintext or payload, any byte string SHALL be handled in its
554 decoded (CBOR item) form. This means any CBOR header or tag in a
555 source encoding are ignored for the purposes of security processing.
556 This also means that if the source byte string was encoded in a non-
557 conforming way, for example in indefinite-length form or with a non-
558 minimum-size length, the security processing always treats it in a
559 deterministically encoded CBOR form.
561 2.6. Processing
563 This section describes block-level requirements for handling COSE
564 security data.
566 All security results generated for BIB or BCB blocks SHALL conform to
567 the COSE profile of Section 3 with header augmentation as defined in
568 Section 2.2.2.
570 2.6.1. Node Authentication
572 This section explains how the certificate profile of Section 4 is
573 used by a security acceptor to both validate an end-entity
574 certificate and to use that certificate to authenticate the security
575 source for an integrity result. For a confidentiality result, some
576 of the requirements in this section are implicit in an implementation
577 using a private key associated with a certificate used by a result
578 recipient. It is an implementation matter to ensure that a BP agent
579 is configured to generate or receive results associated with valid
580 certificates.
582 A security source MAY prohibit generating a result (either integrity
583 or confidentiality) for an end-entity certificate which is not
584 considered valid according to Section 2.6.1.2. Generating a result
585 which is likely to be discarded is wasteful of bundle size and
586 transport resources.
588 2.6.1.1. Certificate Identification
590 Because of the standard policy of using separate certificates for
591 transport, signing, and encryption (see Section 4.1) a single Node ID
592 is likely to be associated with multiple certificates, and any or all
593 of those certificates MAY be present within an "x5bag" in an
594 Additional Protected parameter (see Section 2.2.2). When present, a
595 security acceptor SHALL use an "x5chain" or "x5t" to identify an end-
596 entity certificate to use for result processing. Security acceptors
597 SHALL NOT assume that a validated certificate containing a NODE-ID
598 matching a security source is enough to associate a certificate with
599 a COSE message or recipient (see Section 3.3).
601 2.6.1.2. Certificate Validation
603 For each end-entity certificate contained in or identified by by a
604 COSE result, the security acceptor SHALL perform the certification
605 path validation of Section 6 of [RFC5280] up to one of the acceptor's
606 trusted CA certificates. When evaluating a certificate Validity
607 period, the security acceptor SHALL use the bundle Creation Timestamp
608 time (if not unknown) as the reference instead of the current time.
609 If enabled by local policy, the entity SHALL perform an OCSP check of
610 each certificate providing OCSP authority information in accordance
611 with [RFC6960]. If certificate validation fails or if security
612 policy disallows a certificate for any reason, the acceptor SHALL
613 treat the associated security result as failed. Leaving out part of
614 the certification chain can cause the entity to fail to validate a
615 certificate if the left-out certificates are unknown to the entity
616 (see Section 6.2).
618 For each end-entity certificate contained in or identified by a COSE
619 context result, the security acceptor SHALL apply security policy to
620 the Key Usage extension (if present) and Extended Key Usage extension
621 (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the
622 profile in Section 4.
624 2.6.1.3. Node ID Authentication
626 If required by security policy, for each end-entity certificate
627 referenced by a COSE context integrity result the security acceptor
628 SHALL validate the certificate NODE-ID in accordance with Section 6
629 of [RFC6125] using the NODE-ID reference identifier from the Security
630 Source of the containing security block. If the NODE-ID validation
631 result is Failure or if the result is Absent and security policy
632 requires an authenticated Node ID, the security acceptor SHALL treat
633 the result as failed.
635 2.6.2. Policy Recommendations
637 A RECOMMENDED security policy is to enable the use of OCSP checking
638 when internet connectivity is present. A RECOMMENDED security policy
639 is that if an Extended Key Usage is present that it needs to contain
640 "id-kp-bundleSecurity" of [IANA-SMI] to be usable as an end-entity
641 certificate for COSE security results. A RECOMMENDED security policy
642 is to require a validated Node ID (of Section 2.6.1.3) and to ignore
643 any other identifiers in the end-entity certificate.
645 This policy relies on and informs the certificate requirements in
646 Section 3.3.1 and Section 4. This policy assumes that a DTN-aware CA
647 (see Section 1.2) will only issue a certificate for a Node ID when it
648 has verified that the private key holder actually controls the DTN
649 node; this is needed to avoid the threat identified in Section 6.4.
650 This policy requires that a certificate contain a NODE-ID and allows
651 the certificate to also contain network-level identifiers. A
652 tailored policy on a more controlled network could relax the
653 requirement on Node ID validation and/or Extended Key Usage presence.
655 3. COSE Profile for BPSec
657 This section contains requirements which apply to the use of COSE
658 within the BPSec security context defined in this document.
660 3.1. COSE Messages
662 When generating a BPSec result, security sources SHALL use only COSE
663 labels with a uint value. When processing a BPSec result, security
664 acceptors MAY handle COSE labels with with a tstr value.
666 When used in a BPSec result, each COSE message SHALL contain an
667 explicit algorithm identifier in the lower (content) layers. When
668 available and not implied by the bundle source, a COSE message SHALL
669 contain a key identifier in the highest (recipient) layer. See
670 Section 3.3 for specifics about asymmetric key identifiers. When a
671 key identifier is not available, BPSec acceptors SHALL use the
672 Security Source (if available) and the Bundle Source to imply which
673 keys can be used for security operations. Using implied keys has an
674 interoperability risk, see Section 6.5 for details. A BPSec security
675 operation always occurs within the context of the immutable primary
676 block with its parameters (specifically the Source Node ID) and the
677 security block with its optional Security Source.
679 The algorithms required by this profile focuses on networks using
680 shared symmetric-keys, with recommended algorithms for Elliptic Curve
681 (EC) keypairs and RSA keypairs. The focus of this profile is to
682 enable interoperation between security sources and acceptors on an
683 open network, where more explicit COSE parameters make it easier for
684 BPSec acceptors to avoid assumptions and avoid out-of-band
685 parameters. The requirements of this profile still allow the use of
686 potentially not-easily-interoperable algorithms and message/recipient
687 configurations for use by private networks, where message size is
688 more important than explicit COSE parameters.
690 3.2. Interoperability Algorithms
692 The set of integrity algorithms needed for interoperability is listed
693 here. The full set of COSE algorithms available is managed at
694 [IANA-COSE].
696 Implementations conforming to this specification SHALL support the
697 symmetric keyed and key-encryption algorithms of Table 5.
698 Implementations capable of doing so SHOULD support the asymmetric
699 keyed and key-encryption algorithms of Table 5.
701 | The layer-1 required list is identical to the
702 | [I-D.ietf-dtn-bpsec-default-sc] context list.
704 +=================+============+============+======+================+
705 | BPSec Block | COSE | Name | Code | Implementation |
706 | | Layer | | | Requirements |
707 +=================+============+============+======+================+
708 | Integrity | 1 | HMAC | 5 | Required |
709 | | | 256/256 | | |
710 +-----------------+------------+------------+------+----------------+
711 | Integrity | 1 | ES256 | -7 | Recommended |
712 +-----------------+------------+------------+------+----------------+
713 | Integrity | 1 | EdDSA | -8 | Recommended |
714 +-----------------+------------+------------+------+----------------+
715 | Integrity | 1 | PS256 | -37 | Recommended |
716 +-----------------+------------+------------+------+----------------+
717 | Confidentiality | 1 | A256GCM | 3 | Required |
718 +-----------------+------------+------------+------+----------------+
719 | Confidentiality | 2 | A256KW | -5 | Required |
720 +-----------------+------------+------------+------+----------------+
721 | Confidentiality | 2 | ECDH-ES + | -31 | Recommended |
722 | | | A256KW | | |
723 +-----------------+------------+------------+------+----------------+
724 | Confidentiality | 2 | ECDH-SS + | -34 | Recommended |
725 | | | A256KW | | |
726 +-----------------+------------+------------+------+----------------+
727 | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended |
728 | | | w/ SHA-256 | | |
729 +-----------------+------------+------------+------+----------------+
731 Table 5: Interoperability Algorithms
733 The following are recommended key and recipient uses within COSE/
734 BPSec:
736 Symmetric Key Integrity: When generating a BIB result from a
737 symmetric key, implementations SHALL use a COSE_Mac0 using the
738 private key directly. When a COSE_Mac0 is used with a direct key,
739 the headers SHALL include a key identifier ("kid" header).
741 EC Keypair Integrity: When generating a BIB result from an EC
742 keypair, implementations SHALL use a COSE_Sign1 using the private
743 key directly. When a COSE_Sign1 is used with an EC keypair, the
744 headers SHALL include a public key identifier (see Section 3.3).
746 RSA Keypair Integrity: When generating a BIB result from an RSA
747 keypair, implementations SHALL use a COSE_Sign1 using the private
748 key directly. When a COSE_Sign1 is used with an RSA keypair, the
749 headers SHALL include a public key identifier (see Section 3.3).
750 When a COSE signature is generated with an RSA keypair, the
751 signature uses a PSS salt in accordance with Section 2 of
752 [RFC8230].
754 Symmetric Key Confidentiality: When generating a BCB result from an
755 symmetric key, implementations SHALL use a COSE_Encrypt message
756 with a recipient containing an indirect (wrapped or derived)
757 content encryption key (CEK). When generating a BCB result from a
758 symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or
759 COSE_Encrypt with direct CEK. Doing so risks key overuse and the
760 vulnerabilities associated with large amount of ciphertext from
761 the same key. When a COSE_Encrypt is used with an overall key-
762 encryption key (KEK), the recipient layer SHALL include a key
763 identifier for the KEK.
765 EC Keypair Confidentiality: When generating a BCB result from an EC
766 keypair, implementations SHALL use a COSE_Encrypt message with a
767 recipient containing an indirect (wrapped or derived) CEK. When a
768 COSE_Encrypt is used with an EC keypair, the recipient layer SHALL
769 include a public key identifier (see Section 3.3). When a
770 COSE_Encrypt is used with an EC keypair, the security source SHALL
771 either generate an ephemeral EC keypair or choose a unique PartyU
772 Nonce for each security operation. When processing a COSE_Encrypt
773 with an EC keypair, the security acceptor SHALL process all KDF
774 and HMAC context data from the recipient headers in accordance
775 with Section 11.2 of [RFC8152] even though the source is not
776 required to provide any of those parameters.
778 RSA Keypair Confidentiality: When generating a BCB result from an
779 RSA keypair, implementations SHALL use a COSE_Encrypt message with
780 a recipient containing a key-wrapped CEK. When a COSE_Encrypt is
781 used with an RSA keypair, the recipient layer SHALL include a
782 public key identifier (see Section 3.3).
784 3.3. Asymmetric Key Types and Identifiers
786 This section applies when a BIB uses a public key for verification or
787 key-wrap, or when a BCB uses a public key for encryption or key-wrap.
788 When using asymmetric keyed algorithms, the security source SHALL
789 include a public key container or public key identifier as a
790 recipient header. The public key identifier SHALL be either a "kid"
791 of [RFC8152], an "x5t" or "x5chain" of [I-D.ietf-cose-x509], or an
792 equivalent identifier.
794 When a BIB result contains a "kid" identifier, the security source
795 MAY include an appropriate COSE public key "COSE_Key" in a key
796 container security parameter (see Section 2.2.1). When BIB result
797 contains a "x5t" identifier, the security source MAY include an
798 appropriate PKIX certificate container ("x5chain" or "x5bag" of
799 [I-D.ietf-cose-x509]) in a direct COSE header or an additional header
800 security parameter (see Section 2.2.2). When a BIB result contains
801 an "x5chain", the security source SHOULD NOT also include an "x5t" as
802 the first certificate in the chain is implicitly the applicable end-
803 entity certificate. For a BIB, if all potential security acceptors
804 are known to possess related public key and/or certificate data then
805 the public key or additional header parameters can be omitted. Risks
806 of not including related data are described in Section 6.5 and
807 Section 6.6.
809 When present, public keys and certificates SHOULD be included as
810 additional header parameters rather than within result COSE messages.
811 This provides size efficiency when multiple security results are
812 present because they will all be from the same security source and
813 likely share the same public key material. Security acceptors SHALL
814 still process public keys or certificates present in a result message
815 or recipient as applying to that individual COSE level.
817 Security acceptors SHALL aggregate all COSE_Key objects from all
818 parameters within a single BIB or BCB, independent of encoded type or
819 order of parameters. Because each context contains a single set of
820 security parameters which apply to all results in the same context,
821 security acceptors SHALL treat all public keys as being related to
822 the security source itself and potentially applying to every result.
824 3.3.1. Policy Recommendations
826 The RECOMMENDED priority policy for including PKIX material for BIB
827 results is as follows:
829 1. When receivers are not known to possess certificate chains, a
830 full chain is included (as an "x5chain").
832 2. When receivers are known to possess root and intermediate CAs,
833 just the end-entity certificate is included (again as an
834 "x5chain").
836 3. When receivers are known to possess associated chains including
837 end-entity certificates, a certificate thumbnail (as an "x5t").
839 4. Some arbitrary identifier is used to correlate to an end-entity
840 certificate (as a "kid").
842 5. The BIB Security Source is used to imply an associated end-entity
843 certificate which identifies that Node ID.
845 When PKIX certificates are used by security acceptors and the end-
846 entity certificate is not explicitly trusted (i.e. pinned), the
847 security acceptor SHALL perform the certification path validation of
848 Section 2.6.1.2 up to one or more trusted CA certificates. Leaving
849 out part of the certification chain can cause the security acceptor
850 to fail to validate a BIB if the left-out certificates are unknown to
851 the acceptor (see Section 6.6).
853 Any end-entity certificate associated with a BPSec security source
854 SHALL adhere to the profile of Section 4.
856 4. PKIX Certificate Profile
858 This section contains requirements on certificates used for the COSE
859 context, while Section 3.3 contains requirements for how such
860 certificates are transported or identified.
862 All end-entity certificates used for BPSec SHALL conform to
863 [RFC5280], or any updates or successors to that profile.
865 This profile requires Version 3 certificates due to the extensions
866 used by this profile. Security acceptors SHALL reject as invalid
867 Version 1 and Version 2 end-entity certificates.
869 Security acceptors SHALL accept certificates that contain an empty
870 Subject field or contain a Subject without a Common Name. Identity
871 information in end-entity certificates is contained entirely in the
872 subjectAltName extension as a NODE-ID, as defined in
873 [I-D.ietf-dtn-tcpclv4].
875 All end-entity and CA certificates used for BPSec SHOULD contain both
876 a Subject Key Identifier extension in accordance with Section 4.2.1.2
877 of [RFC5280] and an Authority Key Identifier extension in accordance
878 with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT
879 rely on either a Subject Key Identifier and an Authority Key
880 Identifier being present in any received certificate. Including key
881 identifiers simplifies the work of an entity needing to assemble a
882 certification chain.
884 A BPSec end-entity certificate SHALL contain a NODE-ID which
885 authenticates the Node ID of the security source (for integrity) or
886 the security acceptor (for confidentiality). The identifier type
887 NODE-ID is defined in [I-D.ietf-dtn-tcpclv4].
889 When allowed by CA policy, a BPSec end-entity certificate SHOULD
890 contain a PKIX Extended Key Usage extension in accordance with
891 Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage
892 extension is present, it SHALL contain a key purpose "id-kp-
893 bundleSecurity" of [IANA-SMI]. The "id-kp-bundleSecurity" purpose
894 MAY be combined with other purposes in the same certificate.
896 When allowed by CA policy, a BPSec end-entity certificate SHALL
897 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
898 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE
899 security are: digitalSignature, nonRepudiation, keyEncipherment, and
900 keyAgreement. The specific algorithms used by COSE messages in
901 security results determine which of those key uses are exercised.
902 See Section 4.1 for discussion of key use policies across multiple
903 certificates.
905 A BPSec end-entity certificate MAY contain an Online Certificate
906 Status Protocol (OCSP) URI within an Authority Information Access
907 extension in accordance with Section 4.2.2.1 of [RFC5280]. Security
908 acceptors are not expected to have continuous internet connectivity
909 sufficient to perform OCSP verification.
911 4.1. Multiple-Certificate Uses
913 A RECOMMENDED security policy is to limit asymmetric keys (and thus
914 public key certificates) to single uses among the following:
916 Bundle transport: With key uses as defined in the convergence layer
917 specification(s).
919 Block signing: With key use digitalSignature and/or nonRepudiation.
921 Block encryption: With key use keyEncipherment and/or keyAgreement.
923 This policy is the same one recommended by Section 6 of [RFC8551] for
924 email security and by Section 5.2 of [NIST-SP800-57] more generally.
925 Effectively this means that a BP node uses separate certificates for
926 transport (e.g., as a TCPCL entity), BIB signing (as a security
927 source), and BCB encryption (as a security acceptor).
929 5. Implementation Status
931 This section is to be removed before publishing as an RFC.
933 [NOTE to the RFC Editor: please remove this section before
934 publication, as well as the reference to [RFC7942] and
935 [github-dtn-bpsec-cose].]
936 This section records the status of known implementations of the
937 protocol defined by this specification at the time of posting of this
938 Internet-Draft, and is based on a proposal described in [RFC7942].
939 The description of implementations in this section is intended to
940 assist the IETF in its decision processes in progressing drafts to
941 RFCs. Please note that the listing of any individual implementation
942 here does not imply endorsement by the IETF. Furthermore, no effort
943 has been spent to verify the information presented here that was
944 supplied by IETF contributors. This is not intended as, and must not
945 be construed to be, a catalog of available implementations or their
946 features. Readers are advised to note that other implementations can
947 exist.
949 An example implementation of COSE over Blocks has been created as a
950 GitHub project [github-dtn-bpsec-cose] and is intended to use as a
951 proof-of-concept and as a possible source of interoperability
952 testing. This example implementation only handles CBOR encoding/
953 decoding and cryptographic functions, it does not construct actual
954 BIB or BCB and does not integrate with a BP Agent.
956 6. Security Considerations
958 This section separates security considerations into threat categories
959 based on guidance of BCP 72 [RFC3552].
961 All of the security considerations of the underlying BPSec
962 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
964 6.1. Threat: BPSec Block Replay
966 The bundle's primary block contains fields which uniquely identify a
967 bundle: the Source Node ID, Creation Timestamp, and fragment
968 parameters (see Section 4.3.1 of [I-D.ietf-dtn-bpbis]). These same
969 fields are used to correlate Administrative Records with the bundles
970 for which the records were generated. Including the primary block in
971 the AAD Scope for integrity and confidentiality (see Section 2.2.3)
972 binds the verification of the secured block to its parent bundle and
973 disallows replay of any block with its BIB or BCB.
975 This profile of COSE limits the encryption algorithms to only AEAD in
976 order to include the context of the encrypted data as AAD. If an
977 agent mistakenly allows the use of non-AEAD encryption when
978 decrypting and verifying a BCB, the possibility of block replay
979 attack is present.
981 6.2. Threat: Untrusted End-Entity Certificate
983 The profile in Section 2.6.1 uses end-entity certificates chained up
984 to a trusted root CA. A security source can include a certificate
985 set which does not contain the full chain, possibly excluding
986 intermediate or root CAs. In an environment where security acceptors
987 are known to already contain needed root and intermediate CAs there
988 is no need to include those CAs, but this has a risk of an acceptor
989 not actually having one of the needed CAs.
991 6.3. Threat: Certificate Validation Vulnerabilities
993 Even when a security acceptor is operating properly an attacker can
994 attempt to exploit vulnerabilities within certificate check
995 algorithms or configuration to authenticate using an invalid
996 certificate. An invalid certificate exploit could lead to higher-
997 level security issues and/or denial of service to the Node ID being
998 impersonated.
1000 There are many reasons, described in [RFC5280] and [RFC6125], why a
1001 certificate can fail to validate, including using the certificate
1002 outside of its valid time interval, using purposes for which it was
1003 not authorized, or using it after it has been revoked by its CA.
1004 Validating a certificate is a complex task and can require network
1005 connectivity outside of the primary BP convergence layer network
1006 path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The
1007 configuration and use of particular certificate validation methods
1008 are outside of the scope of this document.
1010 6.4. Threat: BP Node Impersonation
1012 When certificates are referenced by BIB results it is possible that
1013 the certificate does not contain a NODE-ID or does contain one but
1014 has a mismatch with the actual security source (see Section 1.2).
1015 Having a CA-validated certificate does not alone guarantee the
1016 identity of the security source from which the certificate is
1017 provided; additional validation procedures in Section 2.6.1 bind the
1018 Node ID based on the contents of the certificate.
1020 6.5. Threat: Unidentifiable Key
1022 The profile in Section 3.2 recommends key identifiers when possible
1023 and the parameters in section Section 2.2 allow encoding public keys
1024 where available. If the application using a COSE Integrity or COSE
1025 Confidentiality context leaves out key identification data (in a COSE
1026 recipient structure), the security acceptor for those BPSec blocks
1027 only has the primary block available to use when verifying or
1028 decrypting the target block. This leads to a situation, identified
1029 in BPSec Security Considerations, where a signature is verified to be
1030 valid but not from the expected Security Source.
1032 Because the key identifier headers are unprotected (see Section 3.3),
1033 there is still the possibility that an active attacker removes or
1034 alters key identifier(s) in the result. This can cause the security
1035 acceptor to not be able to properly verify a valid signature or not
1036 use the correct private key to decrypt valid ciphertext.
1038 6.6. Threat: Non-Trusted Public Key
1040 The profile in Section 3.2 allows the use of PKIX which typically
1041 involves end-entity certificates chained up to a trusted root CA.
1042 This allows a BIB to contain end-entity certificates not previously
1043 known to a security acceptor but still trust the certificate by
1044 verifying it up to a trusted CA. In an environment where security
1045 acceptors are known to already contain needed root and intermediate
1046 CAs there is no need to include those CAs in a proper chain within
1047 the security parameters, but this has a risk of an acceptor not
1048 actually having one of the needed CAs.
1050 Because the security parameters are not included as AAD, there is
1051 still the possibility that an active attacker removes or alters
1052 certification chain data in the parameters. This can cause the
1053 security acceptor to be able to verify a valid signature but not
1054 trust the public key used to perform the verification.
1056 6.7. Threat: Passive Leak of Key Material
1058 It is important that the key requirements of Section 2.2 apply only
1059 to public keys and PKIX certificates. Including non-public key
1060 material in ASB parameters will expose that material in the bundle
1061 data and over the bundle convergence layer during transport.
1063 6.8. Threat: Algorithm Vulnerabilities
1065 Because this use of COSE leaves the specific algorithms chosen for
1066 BIB and BCB use up to the applications securing bundle data, it is
1067 important to use only COSE algorithms which are marked as recommended
1068 in the IANA registry [IANA-COSE].
1070 7. IANA Considerations
1072 Registration procedures referred to in this section are defined in
1073 [RFC8126].
1075 7.1. BPSec Security Contexts
1077 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
1078 entry has been added to the "BPSec Security Context Identifiers" sub-
1079 registry.
1081 +==========+=============+=====================+
1082 | Value | Description | Reference |
1083 +==========+=============+=====================+
1084 | TBD-COSE | COSE | This specification. |
1085 +----------+-------------+---------------------+
1087 Table 6
1089 8. Acknowledgments
1091 The interoperability minimum algorithms and parameters are based on
1092 the draft [I-D.ietf-dtn-bpsec-default-sc].
1094 9. References
1096 9.1. Normative References
1098 [IANA-BUNDLE]
1099 IANA, "Bundle Protocol",
1100 .
1102 [IANA-COSE]
1103 IANA, "CBOR Object Signing and Encryption (COSE)",
1104 .
1106 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers",
1107 .
1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1110 Requirement Levels", BCP 14, RFC 2119,
1111 DOI 10.17487/RFC2119, March 1997,
1112 .
1114 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1115 Housley, R., and W. Polk, "Internet X.509 Public Key
1116 Infrastructure Certificate and Certificate Revocation List
1117 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1118 .
1120 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1121 Verification of Domain-Based Application Service Identity
1122 within Internet Public Key Infrastructure Using X.509
1123 (PKIX) Certificates in the Context of Transport Layer
1124 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1125 2011, .
1127 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1128 Galperin, S., and C. Adams, "X.509 Internet Public Key
1129 Infrastructure Online Certificate Status Protocol - OCSP",
1130 RFC 6960, DOI 10.17487/RFC6960, June 2013,
1131 .
1133 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1134 Writing an IANA Considerations Section in RFCs", BCP 26,
1135 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1136 .
1138 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
1139 RFC 8152, DOI 10.17487/RFC8152, July 2017,
1140 .
1142 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1143 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1144 May 2017, .
1146 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
1147 and Encryption (COSE) Messages", RFC 8230,
1148 DOI 10.17487/RFC8230, September 2017,
1149 .
1151 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
1152 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
1153 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
1154 April 2019, .
1156 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
1157 Definition Language (CDDL): A Notational Convention to
1158 Express Concise Binary Object Representation (CBOR) and
1159 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
1160 June 2019, .
1162 [I-D.ietf-dtn-bpsec]
1163 III, E. J. B. and K. McKeever, "Bundle Protocol Security
1164 Specification", Work in Progress, Internet-Draft, draft-
1165 ietf-dtn-bpsec-27, 16 February 2021,
1166 .
1168 [I-D.ietf-dtn-tcpclv4]
1169 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
1170 Tolerant Networking TCP Convergence Layer Protocol Version
1171 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
1172 tcpclv4-26, 15 February 2021,
1173 .
1175 [I-D.ietf-cose-x509]
1176 Schaad, J., "CBOR Object Signing and Encryption (COSE):
1177 Header parameters for carrying and referencing X.509
1178 certificates", Work in Progress, Internet-Draft, draft-
1179 ietf-cose-x509-08, 14 December 2020,
1180 .
1182 9.2. Informative References
1184 [NIST-SP800-57]
1185 National Institute of Standards and Technology,
1186 "Recommendation for Key Management - Part 1: General",
1187 NIST Special Publication 800-57 Revision 4, DOI 10.6028/
1188 NIST.SP.800-57pt1r5, May 2020,
1189 .
1192 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1193 Text on Security Considerations", BCP 72, RFC 3552,
1194 DOI 10.17487/RFC3552, July 2003,
1195 .
1197 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1198 Code: The Implementation Status Section", BCP 205,
1199 RFC 7942, DOI 10.17487/RFC7942, July 2016,
1200 .
1202 [I-D.ietf-dtn-bpbis]
1203 Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
1204 Protocol Version 7", Work in Progress, Internet-Draft,
1205 draft-ietf-dtn-bpbis-31, 25 January 2021,
1206 .
1208 [I-D.ietf-dtn-bpsec-default-sc]
1209 III, E. J. B., White, A., and S. Heiner, "BPSec Default
1210 Security Contexts", Work in Progress, Internet-Draft,
1211 draft-ietf-dtn-bpsec-default-sc-05, 26 April 2021,
1212 .
1215 [github-dtn-bpsec-cose]
1216 Sipos, B., "DTN Bundle Protocol Security COSE Security
1217 Context", .
1219 [github-dtn-demo-agent]
1220 Sipos, B., "Demo Convergence Layer Agent",
1221 .
1223 Appendix A. Examples
1225 These examples are intended to have the correct structure of COSE
1226 security blocks but in some cases use simplified algorithm parameters
1227 or smaller key sizes than are required by the actual COSE profile
1228 defined in this documents. Each example indicates how it differs
1229 from the actual profile if there is a meaningful difference.
1231 All of these examples operate within the context of the bundle
1232 primary block of Figure 7 with a security target block of Figure 8.
1233 All example figures use the extended diagnostic notation [RFC8610].
1235 [
1236 7, / BP version /
1237 0, / flags /
1238 0, / CRC type /
1239 [1, "//dst/svc"], / destination /
1240 [1, "//src/"], / source /
1241 [1, "//src/"], / report-to /
1242 [0, 40], / timestamp /
1243 1000000 / lifetime /
1244 ]
1246 Figure 7: Primary block CBOR diagnostic
1248 [
1249 1, / type code: payload /
1250 1, / block num /
1251 0, / flags /
1252 0, / CRC type /
1253 <<"hello">> / block-type-specific-data /
1254 ]
1256 Figure 8: Target block CBOR diagnostic
1258 All of the block integrity block examples operate within the context
1259 of the "frame" block of Figure 9, and block confidentiality block
1260 examples within the frame block of Figure 10.
1262 [
1263 11, / type code: BIB /
1264 3, / block num /
1265 0, / flags /
1266 0, / CRC type /
1267 b'' / block-type-specific-data to be replaced /
1268 ]
1270 Figure 9: Block integrity block frame CBOR diagnostic
1272 [
1273 12, / type code: BCB /
1274 3, / block num /
1275 0, / flags /
1276 0, / CRC type /
1277 b'' / block-type-specific-data to be replaced /
1278 ]
1280 Figure 10: Block confidentiality block frame CBOR diagnostic
1282 All of the examples also operate within a security block containing
1283 the AAD Scope parameter with only "has-primary-ctx" and "has-target-
1284 ctx" flags set. This results in a consistent AAD-structure as shown
1285 in Figure 11, which is encoded as the byte string for COSE
1286 external_aad in all of the examples.
1288 [
1289 [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ],
1290 [ 0, 40 ], 1000000 ], / primary-ctx /
1291 [ 1, 1, 0 ], / target-ctx /
1292 null, / security-ctx /
1293 '' / additional-protected /
1294 ]
1296 Figure 11: Example scope AAD-structure CBOR diagnostic
1298 The only differences between these examples which use EC or RSA
1299 keypairs and a use of a PKIX public key certificate are: the
1300 parameters would have an x5chain parameter instead of a COSE_Key
1301 type, and the recipient would contain an "x5t" value instead of a
1302 "kid" value. Neither of these is a change to a protected header so,
1303 given the same private key, there would be no change to the signature
1304 or wrapped-key data.
1306 Because each of the encryption examples use the same CEK within the
1307 same AAD, the target ciphertext is also identical. The target block
1308 after application of the encryption is shown in Figure 12.
1310 [
1311 1, / type code: payload /
1312 1, / block num /
1313 0, / flags /
1314 0, / CRC type /
1315 h'1fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f96b1' / ciphertext /
1316 ]
1318 Figure 12: Encrypted Target block CBOR diagnostic
1320 A.1. Symmetric Key COSE_Mac0
1322 This is an example of a MAC with recipient having a 256-bit symmetric
1323 key identified by a "kid".
1325 [
1326 {
1327 / kty / 1: 4, / symmetric /
1328 / kid / 2: 'ExampleMAC',
1329 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1330 99dbae4ce45c'
1331 }
1332 ]
1334 Figure 13: Symmetric Key
1336 The external_aad is the encoded data from Figure 11. The payload is
1337 the encoded target block-type-specific data from Figure 8.
1339 [
1340 "MAC0", / context /
1341 h'a10105', / protected /
1342 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1343 72632f820018281a000f424083010100f640', / external_aad /
1344 h'6568656c6c6f' / payload /
1345 ]
1347 Figure 14: MAC_structure CBOR diagnostic
1349 [1], / targets /
1350 0, / security context TBD-COSE /
1351 1, / flags: params-present /
1352 [1, "//src/"], / security source /
1353 [ / parameters /
1354 [
1355 5, / AAD-scope /
1356 0x03 / has-primary-ctx | has-target-ctx /
1357 ]
1358 ],
1359 [
1360 [ / target block #1 /
1361 [ / result /
1362 17, / COSE_Mac0 tag /
1363 <<[
1364 <<{ / protected /
1365 / alg / 1:5 / HMAC 256//256 /
1366 }>>,
1367 { / unprotected /
1368 / kid / 4:'ExampleMAC'
1369 },
1370 null, / payload detached /
1371 h'cea75ab637d2c4499ceca970ec1acc9f789f382b06571a0bdba9cd5a0a
1372 b48f0e' / tag /
1373 ]>>
1374 ]
1375 ]
1376 ]
1378 Figure 15: Abstract Security Block CBOR diagnostic
1380 The final bundle is encoded as the byte string:
1382 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1383 632f820018281a000f4240850b030000584c810100018201662f2f7372632f818205
1384 038181821158358443a10105a1044a4578616d706c654b6579f65820cea75ab637d2
1385 c4499ceca970ec1acc9f789f382b06571a0bdba9cd5a0ab48f0e8501010000466568
1386 656c6c6fff'
1388 A.2. EC Keypair COSE_Sign1
1390 This is an example of a signature with a recipient having a P-256
1391 curve EC keypair identified by a "kid". The associated public key is
1392 included as a security parameter.
1394 [
1395 { / signing private key /
1396 / kty / 1: 2, / EC2 /
1397 / kid / 2: 'ExampleEC2',
1398 / crv / -1: 1, / P-256 /
1399 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1400 e4fe0a1787a8',
1401 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1402 1639960a0c7a',
1403 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1404 89786ea63842'
1405 }
1406 ]
1408 Figure 16: Example Keys
1410 The external_aad is the encoded data from Figure 11. The payload is
1411 the encoded target block-type-specific data from Figure 8.
1413 [
1414 "Signature1", / context /
1415 h'a10126', / protected /
1416 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1417 72632f820018281a000f424083010100f640', / external_aad /
1418 h'6568656c6c6f' / payload /
1419 ]
1421 Figure 17: Sig_structure CBOR diagnostic
1423 [1], / targets /
1424 0, / security context TBD-COSE /
1425 1, / flags: params-present /
1426 [1, "//src/"], / security source /
1427 [ / parameters /
1428 [
1429 5, / AAD-scope /
1430 0x03 / has-primary-ctx | has-target-ctx /
1431 ]
1432 ],
1433 [
1434 [ / target block #1 /
1435 [ / result /
1436 18, / COSE_Sign1 tag /
1437 <<[
1438 <<{ / protected /
1439 / alg / 1:-7 / ES256 /
1440 }>>,
1441 { / unprotected /
1442 / kid / 4:'ExampleEC2'
1443 },
1444 null, / payload detached /
1445 h'b9e130d0b26d35d02299ca27601aab5c36efabefe1608da0c065368ce9
1446 a78e76e90a26c20caf294d2735861a16ff53b0173a801ceb6993da62c76863a8261a
1447 ee' / signature /
1448 ]>>
1449 ]
1450 ]
1451 ]
1453 Figure 18: Abstract Security Block CBOR diagnostic
1455 The final bundle is encoded as the byte string:
1457 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1458 632f820018281a000f4240850b030000586c810100018201662f2f7372632f818205
1459 038181821258558443a10126a1044a4578616d706c65454332f65840b9e130d0b26d
1460 35d02299ca27601aab5c36efabefe1608da0c065368ce9a78e76e90a26c20caf294d
1461 2735861a16ff53b0173a801ceb6993da62c76863a8261aee8501010000466568656c
1462 6c6fff'
1464 A.3. RSA Keypair COSE_Sign1
1466 This is an example of a signature with a recipient having a 1024-bit
1467 RSA keypair identified by a "kid". The associated public key is
1468 included as a security parameter.
1470 This key strength is not supposed to be a secure configuration, only
1471 intended to explain the procedure. This signature uses a random
1472 salt, so the full signature output is not deterministic.
1474 [
1475 { / signing private key /
1476 / kty / 1: 3, / RSA /
1477 / kid / 2: 'ExampleRSA',
1478 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1479 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1480 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1481 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1482 25',
1483 / e / -2: h'010001',
1484 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1485 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1486 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1487 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1488 01',
1489 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1490 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1491 c3d00e75',
1492 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1493 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1494 7effb9f1',
1495 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1496 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1497 7eea427e1',
1498 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1499 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1500 05ba3af91',
1501 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1502 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1503 f4f92865ca3'
1504 }
1505 ]
1507 Figure 19: Example Keys
1509 The external_aad is the encoded data from Figure 11. The payload is
1510 the encoded target block-type-specific data from Figure 8.
1512 [
1513 "Signature1", / context /
1514 h'a1013824', / protected /
1515 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1516 72632f820018281a000f424083010100f640', / external_aad /
1517 h'6568656c6c6f' / payload /
1518 ]
1520 Figure 20: Sig_structure CBOR diagnostic
1522 [1], / targets /
1523 0, / security context TBD-COSE /
1524 1, / flags: params-present /
1525 [1, "//src/"], / security source /
1526 [ / parameters /
1527 [
1528 5, / AAD-scope /
1529 0x03 / has-primary-ctx | has-target-ctx /
1530 ]
1531 ],
1532 [
1533 [ / target block #1 /
1534 [ / result /
1535 18, / COSE_Sign1 tag /
1536 <<[
1537 <<{ / protected /
1538 / alg / 1:-37 / PS256 /
1539 }>>,
1540 { / unprotected /
1541 / kid / 4:'ExampleRSA'
1542 },
1543 null, / payload detached /
1544 h'55dac638eb2b6e31386189e2e5afe0f2f6888c017013bf7ecbdb585c38
1545 2845dcb305ca1b43d727113c4616d4185bbbafcef83ca3cea8c583bddbddabc3c412
1546 590de368ccc695d887037f3afc97766edfddfaadd43c4d5a48725159d2fad2b9dee1
1547 30b0a4e990410d7d91a294747a9f53780f72987ed2a488d8b84e7590b418
1548 5a' / signature /
1549 ]>>
1550 ]
1551 ]
1552 ]
1554 Figure 21: Abstract Security Block CBOR diagnostic
1556 The final bundle is encoded as the byte string:
1558 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1559 632f820018281a000f4240850b03000058ad810100018201662f2f7372632f818205
1560 038181821258968444a1013824a1044a4578616d706c65525341f6588055dac638eb
1561 2b6e31386189e2e5afe0f2f6888c017013bf7ecbdb585c382845dcb305ca1b43d727
1562 113c4616d4185bbbafcef83ca3cea8c583bddbddabc3c412590de368ccc695d88703
1563 7f3afc97766edfddfaadd43c4d5a48725159d2fad2b9dee130b0a4e990410d7d91a2
1564 94747a9f53780f72987ed2a488d8b84e7590b4185a8501010000466568656c6c6fff'
1566 A.4. Symmetric KEK COSE_Encrypt
1568 This is an example of an encryption with a random CEK and an explicit
1569 key-encryption key (KEK) identified by a "kid". The keys used are
1570 shown in Figure 22.
1572 [
1573 {
1574 / kty / 1: 4, / symmetric /
1575 / kid / 2: 'ExampleKEK',
1576 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf
1577 ae38ad7a972e'
1578 },
1579 {
1580 / kty / 1: 4, / symmetric /
1581 / kid / 2: 'ExampleCEK',
1582 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1583 99dbae4ce45c'
1584 }
1585 ]
1587 Figure 22: Example Keys
1589 The external_aad is the encoded data from Figure 11.
1591 [
1592 "Encrypt", / context /
1593 h'a10103', / protected /
1594 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1595 72632f820018281a000f424083010100f640' / external_aad /
1596 ]
1598 Figure 23: Enc_structure CBOR diagnostic
1600 The ASB item for this encryption operation is shown in Figure 24 and
1601 corresponds with the updated target block (containing the ciphertext)
1602 of Figure 12.
1604 [1], / targets /
1605 0, / security context TBD-COSE /
1606 1, / flags: params-present /
1607 [1, "//src/"], / security source /
1608 [ / parameters /
1609 [
1610 5, / AAD-scope /
1611 0x03 / has-primary-ctx | has-target-ctx /
1612 ]
1613 ],
1614 [
1615 [ / target block #1 /
1616 [ / result /
1617 96, / COSE_Encrypt tag /
1618 <<[
1619 <<{ / protected /
1620 / alg / 1:3 / A256GCM /
1621 }>>,
1622 { / unprotected /
1623 / iv / 5: h'6f3093eba5d85143c3dc484a'
1624 },
1625 null, / payload detached /
1626 [
1627 [ / recipient /
1628 h'', / protected /
1629 { / unprotected /
1630 / alg / 1:-5, / A256KW /
1631 / kid / 4:'ExampleKEK'
1632 },
1633 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d4
1634 03a6331159e3d691a708e9984d' / key-wrapped /
1635 ]
1636 ]
1637 ]>>
1638 ]
1639 ]
1640 ]
1642 Figure 24: Abstract Security Block CBOR diagnostic
1644 The final bundle is encoded as the byte string:
1646 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1647 632f820018281a000f4240850c0300005869810100018201662f2f7372632f818205
1648 03818182186058518443a10103a1054c6f3093eba5d85143c3dc484af6818340a201
1649 24044a4578616d706c654b454b5828917f2045e1169502756252bf119a94cdac6a9d
1650 8944245b5a9a26d403a6331159e3d691a708e9984d8501010000561fd25f64a2eea1
1651 2d4bb6c02d25bf33cec45f3e4f96b1ff'
1653 A.5. EC Keypair COSE_Encrypt
1655 This is an example of an encryption with an P-256 curve ephemeral
1656 sender keypair and a static recipient keypair identified by a "kid".
1657 The keys used are shown in Figure 25.
1659 [
1660 { / sender ephemeral private key /
1661 / kty / 1: 2, / EC2 /
1662 / crv / -1: 1, / P-256 /
1663 / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788
1664 ca57d1df6bcc',
1665 / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c
1666 9c0670f28d62',
1667 / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088
1668 0f9d9c3b122a'
1669 },
1670 { / recipient private key /
1671 / kty / 1: 2, / EC2 /
1672 / kid / 2: 'ExampleEC2',
1673 / crv / -1: 1, / P-256 /
1674 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1675 e4fe0a1787a8',
1676 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1677 1639960a0c7a',
1678 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1679 89786ea63842'
1680 },
1681 {
1682 / kty / 1: 4, / symmetric /
1683 / kid / 2: 'ExampleCEK',
1684 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1685 99dbae4ce45c'
1686 }
1687 ]
1689 Figure 25: Example Keys
1691 The external_aad is the encoded data from Figure 11.
1693 [
1694 "Encrypt", / context /
1695 h'a10103', / protected /
1696 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1697 72632f820018281a000f424083010100f640' / external_aad /
1698 ]
1700 Figure 26: Enc_structure CBOR diagnostic
1702 The ASB item for this encryption operation is shown in Figure 27 and
1703 corresponds with the updated target block (containing the ciphertext)
1704 of Figure 12.
1706 [1], / targets /
1707 0, / security context TBD-COSE /
1708 1, / flags: params-present /
1709 [1, "//src/"], / security source /
1710 [ / parameters /
1711 [
1712 5, / AAD-scope /
1713 0x03 / has-primary-ctx | has-target-ctx /
1714 ]
1715 ],
1716 [
1717 [ / target block #1 /
1718 [ / result /
1719 96, / COSE_Encrypt tag /
1720 <<[
1721 <<{ / protected /
1722 / alg / 1:3 / A256GCM /
1723 }>>,
1724 { / unprotected /
1725 / iv / 5: h'6f3093eba5d85143c3dc484a'
1726 },
1727 null, / payload detached /
1728 [
1729 [ / recipient /
1730 h'', / protected /
1731 { / unprotected /
1732 / alg / 1:-31, / ECDH-ES + A256KW /
1733 / kid / 4:'ExampleEC2',
1734 / ephemeral key / -1:{
1735 1:2,
1736 -1:1,
1737 -2:h'fedaba748882050d1bef8ba992911898f554450952070ae
1738 b4788ca57d1df6bcc',
1739 -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f4
1740 93c1c9c0670f28d62'
1741 }
1742 },
1743 h'cb530b03f1e4b09ec1a0ca19afafbf280284106ab407aaf9bfed6e
1744 666c8f2f9ab5465cf11ef02756' / key-wrapped /
1745 ]
1746 ]
1747 ]>>
1748 ]
1749 ]
1750 ]
1752 Figure 27: Abstract Security Block CBOR diagnostic
1754 The final bundle is encoded as the byte string:
1756 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1757 632f820018281a000f4240850c03000058b6810100018201662f2f7372632f818205
1758 038181821860589e8443a10103a1054c6f3093eba5d85143c3dc484af6818340a301
1759 381e044a4578616d706c6545433220a401022001215820fedaba748882050d1bef8b
1760 a992911898f554450952070aeb4788ca57d1df6bcc225820ceaa8e7ff4751a4f81c7
1761 0e98f1713378b0bd82a1414a2f493c1c9c0670f28d625828cb530b03f1e4b09ec1a0
1762 ca19afafbf280284106ab407aaf9bfed6e666c8f2f9ab5465cf11ef0275685010100
1763 00561fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f96b1ff'
1765 A.6. RSA Keypair COSE_Encrypt
1767 This is an example of an encryption with a recipient having a
1768 1024-bit RSA keypair identified by a "kid". The associated public
1769 key is included as a security parameter.
1771 This key strength is not supposed to be a secure configuration, only
1772 intended to explain the procedure. This padding scheme uses a random
1773 salt, so the full layer-2 ciphertext output is not deterministic.
1775 [
1776 { / recipient private key /
1777 / kty / 1: 3, / RSA /
1778 / kid / 2: 'ExampleRSA',
1779 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1780 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1781 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1782 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1783 25',
1784 / e / -2: h'010001',
1785 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1786 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1787 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1788 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1789 01',
1790 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1791 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1792 c3d00e75',
1793 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1794 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1795 7effb9f1',
1796 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1797 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1798 7eea427e1',
1799 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1800 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1801 05ba3af91',
1802 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1803 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1804 f4f92865ca3'
1805 },
1806 {
1807 / kty / 1: 4, / symmetric /
1808 / kid / 2: 'ExampleCEK',
1809 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1810 99dbae4ce45c'
1811 }
1812 ]
1814 Figure 28: Example Keys
1816 The external_aad is the encoded data from Figure 11.
1818 [
1819 "Encrypt", / context /
1820 h'a10103', / protected /
1821 h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1822 72632f820018281a000f424083010100f640' / external_aad /
1823 ]
1825 Figure 29: Enc_structure CBOR diagnostic
1827 The ASB item for this encryption operation is shown in Figure 30 and
1828 corresponds with the updated target block (containing the ciphertext)
1829 of Figure 12.
1831 [1], / targets /
1832 0, / security context TBD-COSE /
1833 1, / flags: params-present /
1834 [1, "//src/"], / security source /
1835 [ / parameters /
1836 [
1837 5, / AAD-scope /
1838 0x03 / has-primary-ctx | has-target-ctx /
1839 ]
1840 ],
1841 [
1842 [ / target block #1 /
1843 [ / result /
1844 96, / COSE_Encrypt tag /
1845 <<[
1846 <<{ / protected /
1847 / alg / 1:3 / A256GCM /
1848 }>>,
1849 { / unprotected /
1850 / iv / 5: h'6f3093eba5d85143c3dc484a'
1851 },
1852 null, / payload detached /
1853 [
1854 [ / recipient /
1855 h'', / protected /
1856 { / unprotected /
1857 / alg / 1:-41, / RSAES-OAEP w SHA-256 /
1858 / kid / 4:'ExampleRSA'
1859 },
1860 h'89d4367b14e3c663bf0352f8fc4b206f197d78f3f05dda90b3a88c
1861 db2354bdd25eee0cab60f987b6f1441afea8301fc4be22607569a5571bef86900ff8
1862 00a1b52764557382220afa2d115ddbe06729f8c621c440b6341deae871426a9038d0
1863 281d348d6fdf7c130139f5d1bb84c07d93f6d1eed15af81305cc634088fc3f79
1864 32' / key-wrapped /
1865 ]
1866 ]
1867 ]>>
1868 ]
1869 ]
1870 ]
1872 Figure 30: Abstract Security Block CBOR diagnostic
1874 The final bundle is encoded as the byte string:
1876 h'9f880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f7372
1877 632f820018281a000f4240850c03000058c2810100018201662f2f7372632f818205
1878 03818182186058aa8443a10103a1054c6f3093eba5d85143c3dc484af6818340a201
1879 3828044a4578616d706c65525341588089d4367b14e3c663bf0352f8fc4b206f197d
1880 78f3f05dda90b3a88cdb2354bdd25eee0cab60f987b6f1441afea8301fc4be226075
1881 69a5571bef86900ff800a1b52764557382220afa2d115ddbe06729f8c621c440b634
1882 1deae871426a9038d0281d348d6fdf7c130139f5d1bb84c07d93f6d1eed15af81305
1883 cc634088fc3f79328501010000561fd25f64a2eea12d4bb6c02d25bf33cec45f3e4f
1884 96b1ff'
1886 Author's Address
1888 Brian Sipos
1889 RKF Engineering Solutions, LLC
1890 7500 Old Georgetown Road
1891 Suite 1275
1892 Bethesda, MD 20814-6198
1893 United States of America
1895 Email: BSipos@rkf-eng.com