idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (22 December 2020) is 1218 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 261
== Missing Reference: 'AAD-scope' is mentioned on line 261, but not defined
-- Looks like a reference, but probably isn't: '0' on line 1102
-- Looks like a reference, but probably isn't: '40' on line 1102
-- Looks like a reference, but probably isn't: '2' on line 1661
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE'
** 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-25
== 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 (-31) exists of
draft-ietf-dtn-bpbis-30
Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 22 December 2020
5 Expires: 25 June 2021
7 DTN Bundle Protocol Security COSE Security Contexts
8 draft-bsipos-dtn-bpsec-cose-04
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 is also defined for BPSec interoperation.
17 Status of This Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at https://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on 25 June 2021.
34 Copyright Notice
36 Copyright (c) 2020 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents (https://trustee.ietf.org/
41 license-info) in effect on the date of publication of this document.
42 Please review these documents carefully, as they describe your rights
43 and restrictions with respect to this document. Code Components
44 extracted from this document must include Simplified BSD License text
45 as described in Section 4.e of the Trust Legal Provisions and are
46 provided without warranty as described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
51 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 4
53 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4
54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
55 3. BPSec Security Context . . . . . . . . . . . . . . . . . . . 4
56 3.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5
57 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 5
58 3.2.1. Key Containers . . . . . . . . . . . . . . . . . . . 6
59 3.2.2. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 6
60 3.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7
61 3.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 8
62 3.3.2. Confidentiality Messages . . . . . . . . . . . . . . 9
63 3.4. Key Considerations . . . . . . . . . . . . . . . . . . . 10
64 3.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 10
65 3.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 10
66 3.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 11
67 3.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 11
68 3.6.1. Security Source Authentication . . . . . . . . . . . 11
69 3.6.2. Policy Recommendations . . . . . . . . . . . . . . . 12
70 4. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 12
71 4.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 13
72 4.2. Interoperability Algorithms . . . . . . . . . . . . . . . 13
73 4.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 15
74 4.3.1. PKIX Certificates . . . . . . . . . . . . . . . . . . 16
75 5. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 16
76 5.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 17
77 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
79 7.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 18
80 7.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 19
81 7.3. Threat: Certificate Validation Vulnerabilities . . . . . 19
82 7.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 19
83 7.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 20
84 7.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 20
85 7.7. Threat: Passive Leak of Key Material . . . . . . . . . . 20
86 7.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 21
87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
88 8.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 21
89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
91 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
92 10.2. Informative References . . . . . . . . . . . . . . . . . 23
93 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24
94 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 25
95 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 26
96 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 29
97 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 32
98 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 34
99 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 36
100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
102 1. Introduction
104 The Bundle Protocol Security (BPSec) Specification
105 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block
106 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but
107 does not specify any security contexts to be used by either of the
108 security block types. The CBOR Object Signing and Encryption (COSE)
109 specification [RFC8152] defines a structure, encoding, and algorithms
110 to use for cryptographic signing and encryption.
112 This document describes how to use the algorithms and encodings of
113 COSE within BPSec blocks to apply those algorithms to Bundle security
114 in Section 3. A bare minimum of interoperability algorithms and
115 algorithm parameters is specified by this document in Section 4. The
116 focus of the recommended algorithms is to allow BPSec to be used in a
117 Public Key Infrastructure (PKI) as described in Section 1.2.
119 Examples of specific uses are provided in Appendix A to aid in
120 implementation support of the interoperability algorithms.
122 1.1. Scope
124 This document describes a profile of COSE which is tailored for use
125 in BPSec and a method of including full COSE messages within BPSec
126 security blocks. This document does not address:
128 * Policies or mechanisms for issuing Public Key Infrastructure Using
129 X.509 (PKIX) certificates; provisioning, deploying, or accessing
130 certificates and private keys; deploying or accessing certificate
131 revocation lists (CRLs); or configuring security parameters on an
132 individual entity or across a network.
134 * Uses of COSE beyond the profile defined in this document.
136 * How those COSE algorithms are intended to be used within a larger
137 security context. Many header parameters used by COSE (e.g., key
138 identifiers) depend on the network environment and security policy
139 related to that environment.
141 1.2. PKIX Environments and CA Policy
143 This specification gives requirements about how to use PKIX
144 certificates issued by a Certificate Authority (CA), but does not
145 define any mechanisms for how those certificates come to be.
147 To support the PKIX uses defined in this document, the CA(s) issuing
148 certificates for BP nodes are aware of the end use of the
149 certificate, have a mechanism for verifying ownership of a Node ID,
150 and are issuing certificates directly for that Node ID. BPSec
151 security acceptors authenticate the Node ID of security sources when
152 verifying integrity (see Section 3.6.1) using a public key provided
153 by a PKIX certificate (see Section 4.3.1) following the certificate
154 profile of Section 5.
156 1.3. Use of CDDL
158 This document defines CBOR structure using the Concise Data
159 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure
160 can be extracted from the XML version of this document using the
161 XPath expression:
163 '//sourcecode[@type="cddl"]'
165 The following initial fragment defines the top-level symbols of this
166 document's CDDL, including the ASB data structure with its parameter/
167 result sockets.
169 start = AAD-value / ext-data-asb
171 2. Requirements Language
173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
175 "OPTIONAL" in this document are to be interpreted as described in BCP
176 14 [RFC2119] [RFC8174] when, and only when, they appear in all
177 capitals, as shown here.
179 3. BPSec Security Context
181 This document specifies a single security context for use in both
182 BPSec integrity and confidentiality blocks. This is done to save
183 code points allocated to this specification and to simplify the
184 encoding of COSE-in-BPSec; the BPSec block type uniquely defines the
185 acceptable parameters and COSE messages which can be present.
187 The COSE security context SHALL have the Security Context ID
188 specified in Section 8.1.
190 Both types of security block can use the same parameters, defined in
191 Section 3.2, to carry public key-related information and each type of
192 security block allows specific COSE message results, defined in
193 Section 3.3.
195 3.1. Security Scope
197 The scope here refers to the set of information used by the security
198 context to cryptographically bind with the plaintext data being
199 integrity-protected or confididentiality-protected. This information
200 is generically referred to as additional authenticated data (AAD),
201 which is also the term used by COSE to describe the same data.
203 The sources for AAD within the COSE context are described below,
204 controlled by the AAD Scope Flags parameter of Section 3.2.2, and
205 implemented as defined in Section 3.5.1.
207 Bundle Primary Block The primary block identifies a bundle and, once
208 created, the contents of this block are immutable. Changes to the
209 primary block associated with the security target indicate that
210 the target is no longer in its original bundle. Including this
211 data as part of AAD ensures that security target appears in the
212 same bundle that the security source intended.
214 Target Block Metadata When the target block is a canonical block
215 (i.e., not the primary block) it contains its block-type-specific
216 data, which is the subject of the security operation, but also
217 metadata identifying the block. This metadata explicitly excludes
218 the CRC type and value fields because the CRC is derived from the
219 block-type-specific data. Including this data as part of AAD
220 ensures that the target data appears in the same block that the
221 security source intended.
223 Security Block Metadata The BPSec block containing the security
224 result for which the AAD is assembled also has metadata
225 identifying the block. Including this data as part of AAD ensures
226 that the security result appears in the same block that the
227 security source intended.
229 3.2. Parameters
231 Each COSE context parameter value SHALL consist of the COSE structure
232 indicated by Table 1 in its decoded (CBOR item) form. Each security
233 block MAY contain any number of each parameter type. When a
234 parameter is not present, the security acceptor SHALL use the Default
235 Value of Table 1.
237 +==============+=============+======================+===========+
238 | Parameter ID | Parameter | Reference | Default |
239 | | Structure | | Value |
240 +==============+=============+======================+===========+
241 | 1 | COSE_Key | [RFC8152] | none |
242 +--------------+-------------+----------------------+-----------+
243 | 2 | COSE_KeySet | [RFC8152] | none |
244 +--------------+-------------+----------------------+-----------+
245 | 3 | COSE_X509 | [I-D.ietf-cose-x509] | none |
246 | | as x5chain | | |
247 +--------------+-------------+----------------------+-----------+
248 | 4 | COSE_X509 | [I-D.ietf-cose-x509] | none |
249 | | as x5bag | | |
250 +--------------+-------------+----------------------+-----------+
251 | 5 | AAD_Scope | Section 3.2.2 of | 0x7 (all |
252 | | | this RFC | contexts) |
253 +--------------+-------------+----------------------+-----------+
255 Table 1: COSE Security Parameters
257 $bpsec-param-pair /= [1, COSE_Key]
258 $bpsec-param-pair /= [2, COSE_KeySet]
259 $bpsec-param-pair /= [3, x5chain: COSE_X509]
260 $bpsec-param-pair /= [4, x5bag: COSE_X509]
261 $bpsec-param-pair /= [5, AAD-scope]
263 Figure 1: COSE context parameters CDDL
265 3.2.1. Key Containers
267 Implementations capable of handling asymmetric-keyed algorithms
268 SHOULD support the public key handling parameters of Table 1. See
269 Section 4.3 for a definition of how the aggregate of all public keys
270 and certificates in security parameters apply to each security
271 result.
273 COSE security parameters SHALL NOT contain any private key material.
274 The security parameters are all stored in the bundle as plaintext and
275 are visible to any bundle handlers.
277 3.2.2. AAD Scope
279 The AAD Scope parameter controls what data is included in the AAD for
280 both integrity and confidentiality operations. The AAD Scope
281 parameter SHALL be encoded as a unit value with bit flags defined in
282 Table 2. The default value for this parameter has all flags set
283 which has the AAD include all available context.
285 A CDDL representation of this definition is included in Figure 2 for
286 reference.
288 +==================+========+===============================+
289 | Name | Code | Description |
290 +==================+========+===============================+
291 | has-primary-ctx | 0x01 | If bit is set, indicates that |
292 | | | the primary block is included |
293 | | | in AAD scope. |
294 +------------------+--------+-------------------------------+
295 | has-target-ctx | 0x02 | If bit is set, indicates that |
296 | | | the target block metadata is |
297 | | | included in AAD scope. |
298 +------------------+--------+-------------------------------+
299 | has-security-ctx | 0x04 | If bit is set, indicates that |
300 | | | the security block metadata |
301 | | | is included in AAD scope. |
302 +------------------+--------+-------------------------------+
303 | Reserved | others | |
304 +------------------+--------+-------------------------------+
306 Table 2: AAD Scope Flags
308 AAD-scope = uint .bits AAD-scope-flags
309 AAD-scope-flags = &(
310 has-primary-ctx: 0,
311 has-target-ctx: 1,
312 has-security-ctx: 2,
313 )
315 Figure 2: AAD Scope CDDL
317 3.3. Results
319 Although each COSE context result is a COSE message, the types of
320 message allowed depend upon the security block type in which the
321 result is present: only MAC or signature messages are allowed in a
322 BIB and only encryption messages are allowed in a BCB.
324 The code points for Result ID values are identical to the existing
325 COSE message-marking tags in Section 2 of [RFC8152]. This avoids the
326 need for value-mapping between code points of the two registries.
328 When embedding COSE messages, the CBOR structure SHALL be directly
329 included within the abstract security block (ASB) CBOR structure.
330 There is no use of embedded encoded CBOR (e.g. CBOR encoded as a
331 byte string) in this specification. When embedding COSE messages,
332 the CBOR-tagged form SHALL NOT be used. The Result ID values already
333 provide the same information as the COSE tags (using the same code
334 points).
336 These generic requirements are formalized in the CDDL fragment of
337 Figure 3.
339 $bpsec-result-pair /= [16, COSE_Encrypt0]
340 $bpsec-result-pair /= [17, COSE_Mac0]
341 $bpsec-result-pair /= [18, COSE_Sign1]
342 $bpsec-result-pair /= [96, COSE_Encrypt]
343 $bpsec-result-pair /= [97, COSE_Mac]
344 $bpsec-result-pair /= [98, COSE_Sign]
346 Figure 3: COSE context results CDDL
348 3.3.1. Integrity Messages
350 When used within a Block Integrity Block, the COSE context SHALL
351 allow only the Result IDs from Table 3. Each integrity result value
352 SHALL consist of the COSE message indicated by Table 3 in its decoded
353 form.
355 +===========+==================+===========+
356 | Result ID | Result Structure | Reference |
357 +===========+==================+===========+
358 | 97 | COSE_Mac | [RFC8152] |
359 +-----------+------------------+-----------+
360 | 17 | COSE_Mac0 | [RFC8152] |
361 +-----------+------------------+-----------+
362 | 98 | COSE_Sign | [RFC8152] |
363 +-----------+------------------+-----------+
364 | 18 | COSE_Sign1 | [RFC8152] |
365 +-----------+------------------+-----------+
367 Table 3: COSE Integrity Results
369 Each integrity result SHALL use the "detached" payload form with nil
370 payload value. The integrity result for COSE_Mac and COSE_Mac0
371 messages are computed by the procedure in Section 6.3 of [RFC8152].
372 The integrity result for COSE_Sign and COSE_Sign1 messages are
373 computed by the procedure in Section 4.4 of [RFC8152].
375 The COSE "protected attributes from the application" used for a
376 signature or MAC result SHALL be the encoded data defined in
377 Section 3.5.1. The COSE payload used for a signature or MAC result
378 SHALL be either the block-type-specific data of the target, if the
379 target is not the primary block, or an empty byte string if the
380 target is the primary block.
382 3.3.2. Confidentiality Messages
384 When used within a Block Confidentiality Block, COSE context SHALL
385 allow only the Result IDs from Table 4. Each confidentiality result
386 value SHALL consist of the COSE message indicated by Table 4 in its
387 decoded form.
389 +===========+==================+===========+
390 | Result ID | Result Structure | Reference |
391 +===========+==================+===========+
392 | 96 | COSE_Encrypt | [RFC8152] |
393 +-----------+------------------+-----------+
394 | 16 | COSE_Encrypt0 | [RFC8152] |
395 +-----------+------------------+-----------+
397 Table 4: COSE Confidentiality Results
399 Only algorithms which support Authenticated Encryption with
400 Authenticated Data (AEAD) SHALL be usable in the first (content)
401 layer of a confidentiality result. Because COSE encryption with AEAD
402 appends the authentication tag with the ciphertext, the size of the
403 block-type-specific-data will grow after an encryption operation.
404 Security acceptors MUST NOT assume that the size of the plaintext is
405 the same as the size of the ciphertext.
407 Each confidentiality result SHALL use the "detached" payload form
408 with nil payload value. The confidentiality result for COSE_Encrypt
409 and COSE_Encrypt0 messages are computed by the procedure in
410 Section 5.3 of [RFC8152].
412 The COSE "protected attributes from the application" used for an
413 encryption result SHALL be the encoded data defined in Section 3.5.1.
414 The COSE payload used for an encryption result SHALL be the block-
415 type-specific data of the target. Because confidentiality of the
416 primary block is disallowed by BPSec, there is no logic here for
417 handling a BCB with a target on the primary block.
419 3.4. Key Considerations
421 This specification does not impose any additional key requirements
422 beyond those already specified for each COSE algorithim required in
423 Section 4.
425 3.5. Canonicalization Algorithms
427 Generating or processing COSE messages for the COSE context follows
428 the profile defined in Section 4 with the "protected attributes from
429 the application" (i.e., the "external_aad" item) generated as defined
430 in Section 3.5.1.
432 3.5.1. Generating AAD
434 The AAD used for both integrity and confidentiality messages SHALL be
435 the determistically encoded form of a CBOR array containing the
436 following:
438 1. The first item SHALL be either: the CBOR array (unencoded) form
439 of the primary block of the bundle if the AAD Scope has the has-
440 primary-ctx flag set, otherwise the null value.
442 2. The second item SHALL be either: a CBOR array containing the
443 first three fields of the target block (i.e., the block type
444 code, block number, and control flags) if the AAD Scope has the
445 has-target-ctx flag set, otherwise the null value.
447 3. The third item SHALL be either: a CBOR array containing the first
448 three fields of the security block containing the result (i.e.,
449 the block type code, block number, and control flags) if the AAD
450 Scope has the has-security-ctx flag set, otherwise the null
451 value.
453 A CDDL representation of this data is shown below in Figure 4.
455 AAD-value = bstr .cbor AAD-structure
456 AAD-structure = [
457 primary-ctx: null / primary-block, ; if has-primary-ctx is set
458 target-ctx: null / block-metadata, ; if has-target-ctx is set
459 security-ctx: null / block-metadata ; if has-security-ctx is set
460 ]
461 ; The first three fields of BP "canonical-block-structure"
462 block-metadata = [
463 block-type-code: uint,
464 block-number: uint,
465 block-control-flags,
466 ]
467 Figure 4: COSE context AAD CDDL
469 3.5.2. Payload Data
471 When correlating between BPSec target block-type-specific-data and
472 COSE plaintext or payload, any byte string SHALL be handled in its
473 decoded (CBOR item) form. This means any CBOR header or tag in a
474 source encoding are ignored for the purposes of security processing.
475 This also means that if the source byte string was encoded in a non-
476 conforming way, for example in indefinite-length form or with a non-
477 minimum-size lengnth, the security processing always treats it in a
478 determistically encoded CBOR form.
480 3.6. Processing
482 This section describes block-level requirements for handling COSE
483 security data.
485 Security results generated for BIB or BCB results SHALL conform to
486 the COSE profile of Section 4. Security acceptors SHOULD
488 3.6.1. Security Source Authentication
490 This section explains how the certificate profile of Section 5 is
491 used by a security acceptor to both validate an end-entity
492 certificate and to use that certificate to authenticate the security
493 source for the COSE security context.
495 Because of the standard policy of using separate certificates for
496 transport, signing, and encryption (see Section 5.1) a single Node ID
497 is likely to be associated with mulitple certificates, and any or all
498 of those certificates can be present as security parameters (see
499 Section 3.2.1). When present, a security acceptor SHALL use an "x5t"
500 identifier from a COSE recipient to identify an end-entity
501 certificate to use for result processing. Security acceptors SHALL
502 NOT assume that a validated certificate containing a NODE-ID matching
503 a security source is enough to associate a certificate with a COSE
504 message or recipient.
506 3.6.1.1. Certificate Path and Purpose Validation
508 For each end-entity certificate referenced by a COSE context result,
509 the security acceptor SHALL perform the certification path validation
510 of [RFC5280] up to one of the acceptor's trusted CA certificates. If
511 enabled by local policy, the entity SHALL perform an OCSP check of
512 each certificate providing OCSP authoritiy information in accordance
513 with [RFC6960]. If certificate validation fails or if security
514 policy disallows a certificate for any reason, the acceptor SHALL
515 treat the associated security result as failed. Leaving out part of
516 the certification chain can cause the entity to fail to validate a
517 certificate if the left-out certificates are unknown to the entity
518 (see Section 7.2).
520 For each end-entity certificate referenced by a COSE context result,
521 the security acceptor SHALL apply security policy to the Key Usage
522 extension (if present) and Extended Key Usage extension (if present)
523 in accordance with Section 4.2.1.12 of [RFC5280] and the profile in
524 Section 5.
526 3.6.1.2. Node ID Authentication
528 If required by security policy, for each end-entity certificate
529 referenced by a COSE context result the security acceptor SHALL
530 validate the certificate NODE-ID in accordance with Section 6 of
531 [RFC6125] using the NODE-ID reference identifier from either the
532 Security Source (if present) or the Bundle Source (as the implied
533 security source). If the NODE-ID validation result is Failure or if
534 the result is Absent and security policy requires an authenticated
535 Node ID, the security acceptor SHALL treat the result as failed.
537 3.6.2. Policy Recommendations
539 A RECOMMENDED security policy is to enable the use of OCSP checking
540 when internet connectivity is present. A RECOMMENDED security policy
541 is that if an Extended Key Usage is present that it needs to contain
542 "id-kp-bundleSecurity" to be usable as an end-entity certificate for
543 with COSE security results. A RECOMMENDED security policy is to
544 require a validated Node ID (of Section 3.6.1.2) and to ignore any
545 other identifiers in the end-entity certificate.
547 This policy relies on and informs the certificate requirements in
548 Section 4.3.1. This policy assumes that a DTN-aware CA (see
549 Section 1.2) will only issue a certificate for a Node ID when it has
550 verified that the private key holder actually controls the DTN node;
551 this is needed to avoid the threat identified in Section 7.4. This
552 policy requires that a certificate contain a NODE-ID and allows the
553 certificate to also contain network-level identifiers. A tailored
554 policy on a more controlled network could relax the requirement on
555 Node ID validation and/or Extended Key Usage presence.
557 4. COSE Profile for BPSec
559 This section contains requirements which apply to the use of COSE
560 within BPSec across any security context use.
562 4.1. COSE Messages
564 When generating a BPSec result, security sources SHALL use encode
565 COSE labels with a uint value. When processing a BPSec result,
566 security acceptors MAY handle COSE labels with with a tstr value.
568 When used in a BPSec result, each COSE message SHALL contain an
569 explicit algorithm identifier in the lower (content) layers. When
570 available and not implied by the bundle source, a COSE message SHALL
571 contain a key identifier in the highest (recipient) layer. See
572 Section 4.3 for specifics about asymmetric key identifiers. When a
573 key identifier is not available, BPSec acceptors SHALL use the
574 Security Source (if available) and the Bundle Source to imply which
575 keys can be used for security operations. Using implied keys has an
576 interoperability risk, see Section 7.5 for details. A BPSec security
577 operation always occurs within the context of the immutable primary
578 block with its parameters (specifically the Source Node ID) and the
579 security block with its optional Security Source.
581 The algorithms required by this profile focuses on networks using
582 shared symmetric-keys, with recommended algorithms for Elliptic Curve
583 (EC) keypairs and RSA keypairs. The focus of this profile is to
584 enable interoperation between security sources and acceptors on an
585 open network, where more explicit COSE parameters make it easier for
586 BPSec acceptors to avoid assumptions and avoid out-of-band
587 parameters. The requirements of this profile still allow the use of
588 potentially not-easily-interoperable algorithms and message/recipient
589 configurations for use by private networks, where message size is
590 more important than explicit COSE parameters.
592 4.2. Interoperability Algorithms
594 [NOTE: The required list is identical to the
595 [I-D.ietf-dtn-bpsec-interop-sc] list.] The set of integrity
596 algorithms needed for interoperability is listed here. The full set
597 of COSE algorithms available is managed at [IANA-COSE].
599 Implementations conforming to this specification SHALL support the
600 symmetric keyed and key-encryption algorithms of Table 5.
601 Implementations capable of doing so SHOULD support the asymmetric
602 keyed and key-encryption algorithms of Table 5.
604 +=================+============+============+======+================+
605 | BPSec Block | COSE | Name | Code | Implementation |
606 | | Layer | | | Requirements |
607 +=================+============+============+======+================+
608 | Integrity | 1 | HMAC | 5 | Required |
609 | | | 256/256 | | |
610 +-----------------+------------+------------+------+----------------+
611 | Integrity | 1 | ES256 | -7 | Recommended |
612 +-----------------+------------+------------+------+----------------+
613 | Integrity | 1 | EdDSA | -8 | Recommended |
614 +-----------------+------------+------------+------+----------------+
615 | Integrity | 1 | PS256 | -37 | Recommended |
616 +-----------------+------------+------------+------+----------------+
617 | Confidentiality | 1 | A256GCM | 3 | Required |
618 +-----------------+------------+------------+------+----------------+
619 | Confidentiality | 2 | A256KW | -5 | Required |
620 +-----------------+------------+------------+------+----------------+
621 | Confidentiality | 2 | ECDH-ES + | -31 | Recommended |
622 | | | A256KW | | |
623 +-----------------+------------+------------+------+----------------+
624 | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended |
625 | | | w/ SHA-256 | | |
626 +-----------------+------------+------------+------+----------------+
628 Table 5: Interoperability Algorithms
630 The following are recommended key and recipient uses within COSE/
631 BPSec:
633 Symmetric Key Integrity: When generating a BIB result from a
634 symmetric key, implementations SHOULD use either a COSE_Mac0 or a
635 COSE_Mac using the private key directly. When a COSE_Mac is used
636 with a direct key, the recipient layer SHALL include a key
637 identifier.
639 EC Keypair Integrity: When generating a BIB result from an EC
640 keypair, implementations SHOULD use either a COSE_Sign1 or a
641 COSE_Sign using the private key directly. When a COSE_Sign is
642 used with an EC keypair, the recipient layer SHALL include a
643 public key identifier (see Section 4.3).
645 RSA Keypair Integrity: When generating a BIB result from an RSA
646 keypair, implementations SHOULD use either a COSE_Sign1 or a
647 COSE_Sign using the private key directly. When a COSE_Sign is
648 used with an RSA keypair, the recipient layer SHALL include a
649 public key identifier (see Section 4.3). When a COSE_Sign or
650 COSE_Sign1 is used with an RSA keypair, the signature uses a PSS
651 salt in accordance with Section 2 of [RFC8230].
653 Symmetric Key Confidentiality: When generating a BCB result from an
654 symmetric key, implementations SHOULD use a COSE_Encrypt message
655 with a recipient containing a key-wrapped CEK. When generating a
656 BCB result from a symmetric key, implementations SHOULD NOT use
657 COSE_Encrypt0 or COSE_Encrypt with direct content encryption key
658 (CEK). Doing so risks key overuse and the vulnerabilities
659 associated with large amount of ciphertext from the same key.
660 When a COSE_Encrypt is used with an overall key-encryption key
661 (KEK), the recipient layer SHALL include a key identifier for the
662 KEK.
664 EC Keypair Confidentiality: When generating a BCB result from an EC
665 keypair, implementations SHOULD use a COSE_Encrypt message with a
666 recipient containing a key-wrapped CEK. When a COSE_Encrypt is
667 used with an EC keypair, the recipient layer SHALL include a
668 public key identifier (see Section 4.3). When a COSE_Encrypt is
669 used with an EC keypair, the security source SHALL generate an
670 ephemeral EC keypair for each security operation. When processing
671 a COSE_Encrypt with an EC keypair, the security acceptor SHALL
672 process all KDF and HMAC context data from the recipient headers
673 in accordance with Section 11.2 of [RFC8152] even though the
674 source is not required to provide any of those parameters.
676 RSA Keypair Confidentiality: When generating a BCB result from an
677 RSA keypair, implementations SHOULD use a COSE_Encrypt message
678 with a recipient containing a key-wrapped CEK. When a
679 COSE_Encrypt is used with an RSA keypair, the recipient layer
680 SHALL include a public key identifier (see Section 4.3).
682 4.3. Asymmetric Key Types and Identifiers
684 This section applies when a BIB uses a public key for verification,
685 or when a BCB uses a public key for encryption. When using
686 asymmetric keyed algorithms, the security source SHALL include a
687 public key identifier as a recipient header. The public key
688 identifier SHALL be either a "kid" [RFC8152], an "x5t"
689 [I-D.ietf-cose-x509], or an equivalent identifier.
691 When a BIB result contains a "kid" identifier, the security source
692 SHOULD include an appropriate COSE public key in the security
693 parameters. When BIB result contains a "x5t" identifier, the
694 security source SHOULD include an appropriate PKIX certificate chain
695 in the security parameters. For a BIB, if all potential security
696 acceptors are known to possess related public key and/or certificate
697 data then the public key parameters can be omitted. Risks of not
698 including related data are described in Section 7.5 and Section 7.6.
700 When present, public keys and certificates SHOULD be included as ASB
701 parameters rather than within ASB results. This provides size
702 efficiency when multiple security results are present because they
703 will all be from the same security source and likely share the same
704 public key material. Security acceptors SHALL still process public
705 keys or certificates present in a result as applying to that
706 individual result.
708 Security acceptors SHALL aggregate all public keys from all
709 parameters within a single BIB or BCB, independent of encoded type or
710 order of parameters. Because each context contains a single set of
711 security parameters which apply to all results in the same context,
712 security acceptors SHALL treat all public keys as being related to
713 the security source itself and potentially applying to every result.
715 4.3.1. PKIX Certificates
717 When PKIX certificates are present as parameters, security sources
718 SHOULD include the entire certification chain to the root CA. When
719 PKIX certificates are used by security acceptors and the end-entity
720 certificate is not explicitly trusted (i.e. pinned), the security
721 acceptor SHALL perform the certification path validation of [RFC5280]
722 up to one or more trusted CA certificates. Leaving out part of the
723 certification chain can cause the security acceptor to fail to
724 validate a BIB if the left-out certificates are unknown to the
725 acceptor (see Section 7.6).
727 The end entity certificate associated with a BPSec security source
728 SHALL adhere to the profile of Section 5.
730 5. PKIX Certificate Profile
732 All end-entity certificates used for BPSec SHALL conform to
733 [RFC5280], or any updates or successors to that profile.
735 This profile requires Version 3 certificates due to the extensions
736 used by this profile. Security acceptors SHALL reject as invalid
737 Version 1 and Version 2 end-entity certificates.
739 Security acceptors SHALL accept certificates that contain an empty
740 Subject field or contain a Subject without a Common Name. Identity
741 information in end-entity certificates is contained entirely in the
742 subjectAltName extension as a NODE-ID, as defined in
743 [I-D.ietf-dtn-tcpclv4].
745 All end-entity and CA certificates used for BPSec SHOULD contain both
746 a Subject Key Identifier and an Authority Key Identifier extension in
747 accordance with [RFC5280]. Security acceptors SHOULD NOT rely on
748 either a Subject Key Identifier and an Authority Key Identifier being
749 present in any received certificate. Including key identifiers
750 simplifies the work of an entity needing to assemble a certification
751 chain.
753 A BPSec end-entity certificate SHALL contain a NODE-ID which
754 authenticates the Node ID of the security source. The identifier
755 type NODE-ID is defined in [I-D.ietf-dtn-tcpclv4].
757 When allowed by CA policy, a BPSec end-entity certificate SHOULD
758 contain a PKIX Extended Key Usage extension in accordance with
759 Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage
760 extension is present, it SHALL contain a key purpose "id-kp-
761 bundleSecurity" as defined in [I-D.ietf-dtn-tcpclv4]. The "id-kp-
762 bundleSecurity" purpose MAY be combined with other purposes in the
763 same certificate.
765 When allowed by CA policy, a BPSec end-entity certificate SHALL
766 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
767 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE
768 security are: digitalSignature, nonRepudiation, keyEncipherment, and
769 keyAgreement. The specific algorithms used by COSE messages in
770 security results determine which of those key uses are exercised.
771 See Section 5.1 for discussion of key use policies across multiple
772 certificates.
774 A BPSec end-entity certificate MAY contain an Online Certificate
775 Status Protocol (OCSP) URI within an Authority Information Access
776 extension in accordance with Section 4.2.2.1 of [RFC5280]. Security
777 acceptors are not expected to have continuous internet connectivity
778 sufficient to perform OCSP verification.
780 5.1. Multiple-Certificate Uses
782 A RECOMMENDED security policy is to limit asymmetric keys (and thus
783 public key certificates) to single uses among the following:
785 Bundle transport: With key uses as defined in the convergence layer
786 specification(s).
788 Block signing: With key use digitalSignature and/or nonRepudiation
790 Block encryption: With key use keyEncipherment and/or keyAgreement
791 This policy is the same one recommended by Section 6 of [RFC8551] for
792 email security and by Section 5.2 of [NIST-SP800-57] more generally.
793 Effectively this means that a BP node uses separate certificates for
794 transport (e.g., as a TCPCL entity), BIB signing (as a security
795 source), and BCB encryption (as a security acceptor).
797 6. Implementation Status
799 [NOTE to the RFC Editor: please remove this section before
800 publication, as well as the reference to [RFC7942] and
801 [github-dtn-bpsec-cose].]
803 This section records the status of known implementations of the
804 protocol defined by this specification at the time of posting of this
805 Internet-Draft, and is based on a proposal described in [RFC7942].
806 The description of implementations in this section is intended to
807 assist the IETF in its decision processes in progressing drafts to
808 RFCs. Please note that the listing of any individual implementation
809 here does not imply endorsement by the IETF. Furthermore, no effort
810 has been spent to verify the information presented here that was
811 supplied by IETF contributors. This is not intended as, and must not
812 be construed to be, a catalog of available implementations or their
813 features. Readers are advised to note that other implementations can
814 exist.
816 An example implementation of COSE over Blocks has been created as a
817 GitHub project [github-dtn-bpsec-cose] and is intended to use as a
818 proof-of-concept and as a possible source of interoperability
819 testing. This example implementation only handles CBOR encoding/
820 decoding and cryptographic functions, it does not construct actual
821 BIB or BCB and does not integrate with a BP Agent.
823 7. Security Considerations
825 This section separates security considerations into threat categories
826 based on guidance of BCP 72 [RFC3552].
828 All of the security considerations of the underlying BPSec
829 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
831 7.1. Threat: BPSec Block Replay
833 The bundle's primary block contains fields which uniquely identify a
834 bundle: the Source Node ID, Creation Timestamp, and fragment
835 parameters (see Section 4.2.2 of [I-D.ietf-dtn-bpbis]). These same
836 fields are used to correlate Administrative Records with the bundles
837 for which the records were generated. Including the primary block in
838 the AAD for BPSec integrity and confidentiality binds the
839 verification of the secured block to its parent bundle and disallows
840 replay of any block with its BIB or BCB.
842 This profile of COSE limits the encryption algorithms to only AEAD in
843 order to include the context of the encrypted data as AAD. If an
844 agent mistakenly allows the use of non-AEAD encryption when
845 decrypting and verifying a BCB, the possibility of block replay
846 attack is present.
848 7.2. Threat: Untrusted End-Entity Certificate
850 The profile in Section 3.6.1 uses end-entity certificates chained up
851 to a trusted root CA. A security source can include a certificate
852 set which does not contain the full chain, possibly excluding
853 intermediate or root CAs. In an environment where security acceptors
854 are known to already contain needed root and intermediate CAs there
855 is no need to include those CAs, but this has a risk of an acceptor
856 not actually having one of the needed CAs.
858 7.3. Threat: Certificate Validation Vulnerabilities
860 Even when a security acceptor is operating properly an attacker can
861 attempt to exploit vulnerabilities within certificate check
862 algorithms or configuration to authenticate using an invalid
863 certificate. An invalid certificate exploit could lead to higher-
864 level security issues and/or denial of service to the Node ID being
865 impersonated.
867 There are many reasons, described in [RFC5280] and [RFC6125], why a
868 certificate can fail to validate, including using the certificate
869 outside of its valid time interval, using purposes for which it was
870 not authorized, or using it after it has been revoked by its CA.
871 Validating a certificate is a complex task and can require network
872 connectivity outside of the primary BP convergence layer network
873 path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The
874 configuration and use of particular certificate validation methods
875 are outside of the scope of this document.
877 7.4. Threat: BP Node Impersonation
879 When certificates are referenced by BIB results it is possible that
880 the certificate does not contain a NODE-ID or does contain one but
881 has a mismatch with the actual security source (see Section 1.2).
882 Having a CA-validated certificate does not alone guarantee the
883 identity of the security source from which the certificate is
884 provided; additional validation procedures in Section 4.3.1 bind the
885 Node ID based on the contents of the certificate.
887 7.5. Threat: Unidentifiable Key
889 The profile in Section 4.2 recommends key identifiers when possible
890 and the parameters in section Section 3.2 allow encoding public keys
891 where available. If the application using a COSE Integrity or COSE
892 Confidentiality context leaves out key identification data (in a COSE
893 recipient structure), the security acceptor for those BPSec blocks
894 only has the primary block available to use when verifying or
895 decrypting the target block. This leads to a situation, identified
896 in BPSec Security Considerations, where a signature is verified to be
897 valid but not from the expected Security Source.
899 Because the key identifier headers are unprotected (see Section 4.3),
900 there is still the possibility that an active attacker removes or
901 alters key identifier(s) in the result. This can cause the security
902 acceptor to not be able to properly verify a valid signature or not
903 use the correct private key to decrypt valid ciphertext.
905 7.6. Threat: Non-Trusted Public Key
907 The profile in Section 4.2 allows the use of PKIX which typically
908 involves end-entity certificates chained up to a trusted root CA.
909 This allows a BIB to contain end-entity certificates not previously
910 known to a security acceptor but still trust the certificate by
911 verifying it up to a trusted CA. In an environment where security
912 acceptors are known to already contain needed root and intermediate
913 CAs there is no need to include those CAs in a proper chain within
914 the security parameters, but this has a risk of an acceptor not
915 actually having one of the needed CAs.
917 Because the security parameters are not included as AAD, there is
918 still the possibility that an active attacker removes or alters
919 certification chain data in the parameters. This can cause the
920 security acceptor to be able to verify a valid signature but not
921 trust the public key used to perform the verification.
923 7.7. Threat: Passive Leak of Key Material
925 It is important that the key requirements of Section 3.2 apply only
926 to public keys and PKIX certificates. Including non-public key
927 material in ASB parameters will expose that material in the bundle
928 data and over the bundle convergence layer during transport.
930 7.8. Threat: Algorithm Vulnerabilities
932 Because this use of COSE leaves the specific algorithms chosen for
933 BIB and BCB use up to the applications securing bundle data, it is
934 important to use only COSE algorithms which are marked as recommended
935 in the IANA registry [IANA-COSE].
937 8. IANA Considerations
939 Registration procedures referred to in this section are defined in
940 [RFC8126].
942 8.1. BPSec Security Contexts
944 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
945 entry has been added to the "BPSec Security Context Identifiers" sub-
946 registry.
948 +==========+=============+=====================+
949 | Value | Description | Reference |
950 +==========+=============+=====================+
951 | TBD-COSE | COSE | This specification. |
952 +----------+-------------+---------------------+
954 Table 6
956 9. Acknowledgments
958 The interoperability minimum algorithms and parameters are based on
959 the draft [I-D.ietf-dtn-bpsec-interop-sc].
961 10. References
963 10.1. Normative References
965 [IANA-BUNDLE]
966 IANA, "Bundle Protocol",
967 .
969 [IANA-COSE]
970 IANA, "CBOR Object Signing and Encryption (COSE)",
971 .
973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
974 Requirement Levels", BCP 14, RFC 2119,
975 DOI 10.17487/RFC2119, March 1997,
976 .
978 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
979 Housley, R., and W. Polk, "Internet X.509 Public Key
980 Infrastructure Certificate and Certificate Revocation List
981 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
982 .
984 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
985 Verification of Domain-Based Application Service Identity
986 within Internet Public Key Infrastructure Using X.509
987 (PKIX) Certificates in the Context of Transport Layer
988 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
989 2011, .
991 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
992 Galperin, S., and C. Adams, "X.509 Internet Public Key
993 Infrastructure Online Certificate Status Protocol - OCSP",
994 RFC 6960, DOI 10.17487/RFC6960, June 2013,
995 .
997 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
998 Writing an IANA Considerations Section in RFCs", BCP 26,
999 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1000 .
1002 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
1003 RFC 8152, DOI 10.17487/RFC8152, July 2017,
1004 .
1006 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1007 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1008 May 2017, .
1010 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
1011 and Encryption (COSE) Messages", RFC 8230,
1012 DOI 10.17487/RFC8230, September 2017,
1013 .
1015 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
1016 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
1017 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
1018 April 2019, .
1020 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
1021 Definition Language (CDDL): A Notational Convention to
1022 Express Concise Binary Object Representation (CBOR) and
1023 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
1024 June 2019, .
1026 [I-D.ietf-dtn-bpsec]
1027 Birrane, E. and K. McKeever, "Bundle Protocol Security
1028 Specification", Work in Progress, Internet-Draft, draft-
1029 ietf-dtn-bpsec-25, 1 December 2020,
1030 .
1032 [I-D.ietf-dtn-tcpclv4]
1033 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
1034 Tolerant Networking TCP Convergence Layer Protocol Version
1035 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
1036 tcpclv4-24, 7 December 2020,
1037 .
1039 [I-D.ietf-cose-x509]
1040 Schaad, J., "CBOR Object Signing and Encryption (COSE):
1041 Header parameters for carrying and referencing X.509
1042 certificates", Work in Progress, Internet-Draft, draft-
1043 ietf-cose-x509-08, 14 December 2020,
1044 .
1046 10.2. Informative References
1048 [NIST-SP800-57]
1049 National Institute of Standards and Technology,
1050 "Recommendation for Key Management - Part 1: General",
1051 NIST Special Publication 800-57 Revision 4, DOI 10.6028/
1052 NIST.SP.800-57pt1r5, May 2020,
1053 .
1056 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1057 Text on Security Considerations", BCP 72, RFC 3552,
1058 DOI 10.17487/RFC3552, July 2003,
1059 .
1061 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1062 Code: The Implementation Status Section", BCP 205,
1063 RFC 7942, DOI 10.17487/RFC7942, July 2016,
1064 .
1066 [I-D.ietf-dtn-bpbis]
1067 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
1068 Version 7", Work in Progress, Internet-Draft, draft-ietf-
1069 dtn-bpbis-30, 10 December 2020,
1070 .
1072 [I-D.ietf-dtn-bpsec-interop-sc]
1073 Birrane, E., "BPSec Default Security Contexts", Work in
1074 Progress, Internet-Draft, draft-ietf-dtn-bpsec-interop-sc-
1075 02, 1 November 2020, .
1078 [github-dtn-bpsec-cose]
1079 Sipos, B., "DTN Bundle Protocol Security COSE Security
1080 Contexts",
1081 .
1083 Appendix A. Examples
1085 These examples are intended to have the correct structure of COSE
1086 security blocks but in some cases use simplified algorithm parameters
1087 or smaller key sizes than are required by the actual COSE profile
1088 defined in this documents. Each example indicates how it differs
1089 from the actual profile if there is a meaningful difference.
1091 All of these examples operate within the context of the bundle
1092 primary block of Figure 5 with a security target block of Figure 6.
1093 All example figures use the extended diagnostic notation [RFC8610].
1095 [
1096 7, / BP version /
1097 0, / flags /
1098 0, / CRC type /
1099 [1, "//dst/svc"], / destination /
1100 [1, "//src/"], / source /
1101 [1, "//src/"], / report-to /
1102 [0, 40], / timestamp /
1103 1000000 / lifetime /
1104 ]
1106 Figure 5: Primary block CBOR diagnostic
1108 [
1109 7, / type code - bundle age /
1110 2, / block num /
1111 0, / flags /
1112 0, / CRC type /
1113 <<300>> / type-specific-data: age /
1114 ]
1116 Figure 6: Target block CBOR diagnostic
1118 All of the examples also operate within a security block containing
1119 the AAD Scope parameter with only "has-primary-ctx" and "has-target-
1120 ctx" flags set. This results in a consistent AAD-value as shown in
1121 Figure 7, which is used as the bytestring for COSE external_aad in
1122 all of the examples. Note that the AAD-value is itself a bytestring
1123 which happens to contain encoded CBOR.
1125 <<[
1126 [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ],
1127 [ 0, 40 ], 1000000 ], / primary-ctx /
1128 [ 7, 2, 0 ], / target-ctx /
1129 null / security-ctx /
1130 ]>>
1132 Figure 7: Example scope AAD-value CBOR diagnostic
1134 The only differences between these examples which use EC or RSA
1135 keypairs and a use of a PKIX public key certificate are: the
1136 parameters would have an x5chain parameter instead of a COSE_Key
1137 type, and the recipient would contain an "x5t" value instead of a
1138 "kid" value. Neither of these is a change to a protected header so,
1139 given the same private key, there would be no change to the signature
1140 or wrapped-key data.
1142 A.1. Symmetric Key COSE_Mac0
1144 This is an example of a MAC with recipient having a 256-bit symmetric
1145 key identified by a "kid".
1147 [
1148 {
1149 / kty / 1: 4, / symmetric /
1150 / kid / 2: 'ExampleMAC',
1151 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1152 99dbae4ce45c'
1153 }
1154 ]
1156 Figure 8: Symmetric Key
1158 The external_aad is the encoded data from Figure 7. The payload is
1159 the encoded target block-type-specific data from Figure 6.
1161 [
1162 "MAC0", / context /
1163 h'a10105', / protected /
1164 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1165 72632f820018281a000f424083070200f6', / external_aad /
1166 h'19012c' / payload /
1167 ]
1169 Figure 9: MAC_structure CBOR diagnostic
1171 [
1172 [2], / targets /
1173 0, / security context TBD /
1174 1, / flags: params-present /
1175 [ / parameters /
1176 [
1177 5, / AAD-scope /
1178 0x03 / has-primary-ctx | has-target-ctx /
1179 ]
1180 ],
1181 [
1182 [ / target block #2 /
1183 [ / result /
1184 17, / COSE_Mac0 tag /
1185 [
1186 <<{ / protected /
1187 / alg / 1:5 / HMAC 256//256 /
1188 }>>,
1189 { / unprotected /
1190 / kid / 4:'ExampleMAC'
1191 },
1192 null, / payload /
1193 h'190264a1e6a9734990e552660df3c4641efb88fd6439aba866577c7b
1194 6d174b87' / tag /
1195 ]
1196 ]
1197 ]
1198 ]
1199 ]
1201 Figure 10: Abstract Security Block CBOR diagnostic
1203 A.2. EC Keypair COSE_Sign1
1205 This is an example of a signature with a recipient having a P-256
1206 curve EC keypair identified by a "kid". The associated public key is
1207 included as a security parameter.
1209 [
1210 { / signing private key /
1211 / kty / 1: 2, / EC2 /
1212 / kid / 2: 'ExampleEC2',
1213 / crv / -1: 1, / P-256 /
1214 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1215 e4fe0a1787a8',
1216 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1217 1639960a0c7a',
1218 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1219 89786ea63842'
1220 }
1221 ]
1223 Figure 11: Example Keys
1225 The external_aad is the encoded data from Figure 7. The payload is
1226 the encoded target block-type-specific data from Figure 6.
1228 [
1229 "Signature1", / context /
1230 h'a10126', / protected /
1231 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1232 72632f820018281a000f424083070200f6', / external_aad /
1233 h'19012c' / payload /
1234 ]
1236 Figure 12: Sig_structure CBOR diagnostic
1238 [
1239 [2], / targets /
1240 0, / security context TBD /
1241 1, / flags: params-present /
1242 [ / parameters /
1243 [
1244 1, / COSE key /
1245 { / public key /
1246 / kty / 1: 2, / EC2 /
1247 / kid / 2: 'ExampleEC2',
1248 / crv / -1: 1, / P-256 /
1249 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbdd
1250 b8b5e4fe0a1787a8',
1251 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715f
1252 afbc1639960a0c7a'
1253 }
1254 ],
1255 [
1256 5, / AAD-scope /
1257 0x03 / has-primary-ctx | has-target-ctx /
1258 ]
1259 ],
1260 [
1261 [ / target block #2 /
1262 [ / result /
1263 18, / COSE_Sign1 tag /
1264 [
1265 <<{ / protected /
1266 / alg / 1:-7 / ES256 /
1267 }>>,
1268 { / unprotected /
1269 / kid / 4:'ExampleEC2'
1270 },
1271 null, / payload /
1272 h'eb085c162bac4ec45c974766b897ee227b189fa257a8fb195c830f04
1273 f6d6a90318b3e915938e4d32c1baace8aa0bf983f52efcbf1b127b296e72673f3d73
1274 3023' / signature /
1275 ]
1276 ]
1277 ]
1278 ]
1279 ]
1281 Figure 13: Abstract Security Block CBOR diagnostic
1283 A.3. RSA Keypair COSE_Sign1
1285 This is an example of a signature with a recipient having a 1024-bit
1286 RSA keypair identified by a "kid". The associated public key is
1287 included as a security parameter.
1289 This key strength is not supposed to be a secure configuration, only
1290 intended to explain the procedure. This signature uses a random
1291 salt, so the full signature output is not deterministic.
1293 [
1294 { / signing private key /
1295 / kty / 1: 3, / RSA /
1296 / kid / 2: 'ExampleRSA',
1297 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1298 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1299 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1300 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1301 25',
1302 / e / -2: h'010001',
1303 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1304 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1305 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1306 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1307 01',
1308 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1309 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1310 c3d00e75',
1311 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1312 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1313 7effb9f1',
1314 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1315 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1316 7eea427e1',
1317 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1318 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1319 05ba3af91',
1320 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1321 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1322 f4f92865ca3'
1323 }
1324 ]
1326 Figure 14: Example Keys
1328 The external_aad is the encoded data from Figure 7. The payload is
1329 the encoded target block-type-specific data from Figure 6.
1331 [
1332 "Signature1", / context /
1333 h'a1013824', / protected /
1334 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1335 72632f820018281a000f424083070200f6', / external_aad /
1336 h'19012c' / payload /
1337 ]
1339 Figure 15: Sig_structure CBOR diagnostic
1341 [
1342 [2], / targets /
1343 0, / security context TBD /
1344 1, / flags: params-present /
1345 [ / parameters /
1346 [
1347 1, / COSE key /
1348 { / public key /
1349 / kty / 1: 3, / RSA /
1350 / kid / 2: 'ExampleRSA',
1351 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c67
1352 681231da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded6774
1353 4ed620707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d78
1354 35d2d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb
1355 2925',
1356 / e / -2: h'010001'
1357 }
1358 ],
1359 [
1360 5, / AAD-scope /
1361 0x03 / has-primary-ctx | has-target-ctx /
1362 ]
1363 ],
1364 [
1365 [ / target block #2 /
1366 [ / result /
1367 18, / COSE_Sign1 tag /
1368 [
1369 <<{ / protected /
1370 / alg / 1:-37 / PS256 /
1371 }>>,
1372 { / unprotected /
1373 / kid / 4:'ExampleRSA'
1374 },
1375 null, / payload /
1376 h'2229cec7cd4e77e55b7ef39e0305931527e3075e7cad4969ecf1bdc5
1377 cb8662435128718c7ba465d2251a770a6c48ddc62f515fca43482ae137fffa67c86b
1378 c60b3b838875621b276235bdc4269f45fd0c08fdd607650d03ae75b86364f7f5f2cc
1379 442d60e72bff7939478deba7e3492ea96f8ac1f953583df897138f66c16bc2
1380 07' / signature /
1381 ]
1382 ]
1383 ]
1384 ]
1385 ]
1387 Figure 16: Abstract Security Block CBOR diagnostic
1389 A.4. Symmetric KEK COSE_Encrypt
1391 This is an example of an encryption with a random CEK and an explicit
1392 key-encryption key (KEK) identified by a "kid". The keys used are
1393 shown in Figure 17.
1395 [
1396 {
1397 / kty / 1: 4, / symmetric /
1398 / kid / 2: 'ExampleKEK',
1399 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf
1400 ae38ad7a972e'
1401 },
1402 {
1403 / kty / 1: 4, / symmetric /
1404 / kid / 2: 'ExampleCEK',
1405 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1406 99dbae4ce45c'
1407 }
1408 ]
1410 Figure 17: Example Keys
1412 The external_aad is the encoded data from Figure 7. The payload is
1413 the encoded target block-type-specific data from Figure 6.
1415 [
1416 "Encrypt", / context /
1417 h'a10103', / protected /
1418 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1419 72632f820018281a000f424083070200f6' / external_aad /
1420 ]
1422 Figure 18: Enc_structure CBOR diagnostic
1424 [
1425 [2], / targets /
1426 0, / security context TBD /
1427 1, / flags: params-present /
1428 [ / parameters /
1429 [
1430 5, / AAD-scope /
1431 0x03 / has-primary-ctx | has-target-ctx /
1432 ]
1433 ],
1434 [
1435 [ / target block #2 /
1436 [ / result /
1437 96, / COSE_Encrypt tag /
1438 [
1439 <<{ / protected /
1440 / alg / 1:3 / A256GCM /
1441 }>>,
1442 { / unprotected /
1443 / iv / 5: h'6f3093eba5d85143c3dc484a'
1444 },
1445 null, / payload /
1446 [
1447 [ / recipient /
1448 h'', / protected /
1449 { / unprotected /
1450 / alg / 1:-5, / A256KW /
1451 / kid / 4:'ExampleKEK'
1452 },
1453 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26
1454 d403a6331159e3d691a708e9984d' / key-wrapped /
1455 ]
1456 ]
1457 ]
1458 ]
1459 ]
1460 ]
1461 ]
1463 Figure 19: Abstract Security Block CBOR diagnostic
1465 [
1466 7, / type code - bundle age /
1467 2, / block num /
1468 0, / flags /
1469 0, / CRC type /
1470 h'63bb162d8ee2e8175cfc340b6df978864907a2' / ciphertext /
1471 ]
1472 Figure 20: Encrypted Target block CBOR diagnostic
1474 A.5. EC Keypair COSE_Encrypt
1476 This is an example of an encryption with an P-256 curve ephemeral
1477 sender keypair and a static recipient keypair identified by a "kid".
1478 The keys used are shown in Figure 21.
1480 [
1481 { / sender ephemeral private key /
1482 / kty / 1: 2, / EC2 /
1483 / crv / -1: 1, / P-256 /
1484 / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788
1485 ca57d1df6bcc',
1486 / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c
1487 9c0670f28d62',
1488 / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088
1489 0f9d9c3b122a'
1490 },
1491 { / recipient private key /
1492 / kty / 1: 2, / EC2 /
1493 / kid / 2: 'ExampleEC2',
1494 / crv / -1: 1, / P-256 /
1495 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5
1496 e4fe0a1787a8',
1497 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc
1498 1639960a0c7a',
1499 / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51
1500 89786ea63842'
1501 },
1502 {
1503 / kty / 1: 4, / symmetric /
1504 / kid / 2: 'ExampleCEK',
1505 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1506 99dbae4ce45c'
1507 }
1508 ]
1510 Figure 21: Example Keys
1512 The external_aad is the encoded data from Figure 7. The payload is
1513 the encoded target block-type-specific data from Figure 6.
1515 [
1516 "Encrypt", / context /
1517 h'a10103', / protected /
1518 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1519 72632f820018281a000f424083070200f6' / external_aad /
1520 ]
1522 Figure 22: Enc_structure CBOR diagnostic
1524 [
1525 [2], / targets /
1526 0, / security context TBD /
1527 1, / flags: params-present /
1528 [ / parameters /
1529 [
1530 1, / COSE key /
1531 { / public key /
1532 / kty / 1: 2, / EC2 /
1533 / kid / 2: 'ExampleEC2',
1534 / crv / -1: 1, / P-256 /
1535 / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbdd
1536 b8b5e4fe0a1787a8',
1537 / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715f
1538 afbc1639960a0c7a'
1539 }
1540 ],
1541 [
1542 5, / AAD-scope /
1543 0x03 / has-primary-ctx | has-target-ctx /
1544 ]
1545 ],
1546 [
1547 [ / target block #2 /
1548 [ / result /
1549 96, / COSE_Encrypt tag /
1550 [
1551 <<{ / protected /
1552 / alg / 1:3 / A256GCM /
1553 }>>,
1554 { / unprotected /
1555 / iv / 5: h'6f3093eba5d85143c3dc484a'
1556 },
1557 null, / payload /
1558 [
1559 [ / recipient /
1560 h'', / protected /
1561 { / unprotected /
1562 / alg / 1:-31, / ECDH-ES + A256KW /
1563 / kid / 4:'ExampleEC2',
1564 / ephemeral key / -1:{
1565 1:2,
1566 -1:1,
1567 -2:h'fedaba748882050d1bef8ba992911898f554450952070
1568 aeb4788ca57d1df6bcc',
1569 -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2
1570 f493c1c9c0670f28d62'
1571 },
1572 / PartyU nonce / -22:h'e6bd83a5a06841c2ea1dd4eebaaa
1573 f252'
1574 },
1575 h'e20b6fd9b46cdaae9e67ccf4893706802a7acb0c3b3a792b3fcb
1576 a110f2f27d7972934f4e6497ac89' / key-wrapped /
1577 ]
1578 ]
1579 ]
1580 ]
1581 ]
1582 ]
1583 ]
1585 Figure 23: Abstract Security Block CBOR diagnostic
1587 [
1588 7, / type code - bundle age /
1589 2, / block num /
1590 0, / flags /
1591 0, / CRC type /
1592 h'63bb162d8ee2e8175cfc340b6df978864907a2' / ciphertext /
1593 ]
1595 Figure 24: Encrypted Target block CBOR diagnostic
1597 A.6. RSA Keypair COSE_Encrypt
1599 This is an example of an encrypion with a recipient having a 1024-bit
1600 RSA keypair identified by a "kid". The associated public key is
1601 included as a security parameter.
1603 This key strength is not supposed to be a secure configuration, only
1604 intended to explain the procedure. This padding scheme uses a random
1605 salt, so the full layer-2 ciphertext output is not deterministic.
1607 [
1608 { / recipient private key /
1609 / kty / 1: 3, / RSA /
1610 / kid / 2: 'ExampleRSA',
1611 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812
1612 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6
1613 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2
1614 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29
1615 25',
1616 / e / -2: h'010001',
1617 / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d
1618 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde
1619 eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a
1620 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f
1621 01',
1622 / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd
1623 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e
1624 c3d00e75',
1625 / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0
1626 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955
1627 7effb9f1',
1628 / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6
1629 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc
1630 7eea427e1',
1631 / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04
1632 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89
1633 05ba3af91',
1634 / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e
1635 d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65
1636 f4f92865ca3'
1637 },
1638 {
1639 / kty / 1: 4, / symmetric /
1640 / kid / 2: 'ExampleCEK',
1641 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39
1642 99dbae4ce45c'
1643 }
1644 ]
1646 Figure 25: Example Keys
1648 The external_aad is the encoded data from Figure 7. The payload is
1649 the encoded target block-type-specific data from Figure 6.
1651 [
1652 "Encrypt", / context /
1653 h'a10103', / protected /
1654 h'83880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73
1655 72632f820018281a000f424083070200f6' / external_aad /
1656 ]
1658 Figure 26: Enc_structure CBOR diagnostic
1660 [
1661 [2], / targets /
1662 0, / security context TBD /
1663 1, / flags: params-present /
1664 [ / parameters /
1665 [
1666 1, / COSE key /
1667 { / public key /
1668 / kty / 1: 3, / RSA /
1669 / kid / 2: 'ExampleRSA',
1670 / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c67
1671 681231da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded6774
1672 4ed620707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d78
1673 35d2d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb
1674 2925',
1675 / e / -2: h'010001'
1676 }
1677 ],
1678 [
1679 5, / AAD-scope /
1680 0x03 / has-primary-ctx | has-target-ctx /
1681 ]
1682 ],
1683 [
1684 [ / target block #2 /
1685 [ / result /
1686 96, / COSE_Encrypt tag /
1687 [
1688 <<{ / protected /
1689 / alg / 1:3 / A256GCM /
1690 }>>,
1691 { / unprotected /
1692 / iv / 5: h'6f3093eba5d85143c3dc484a'
1693 },
1694 null, / payload /
1695 [
1696 [ / recipient /
1697 h'', / protected /
1698 { / unprotected /
1699 / alg / 1:-41, / RSAES-OAEP w SHA-256 /
1700 / kid / 4:'ExampleRSA'
1701 },
1702 h'69e76a39b908090f55b1048c95bd1683d9ce702fd9ed4a149650
1703 72fd411936ade41a36a9f62921635d14406eb0e1fa3c02ca0d957a4a44006aa3c03e
1704 326867964b166f8731ebcb20d413fd8f26c57c337689dc42235bfd2b928619b0d4f2
1705 7ec118c608ad9d18c881bc5124833483ded5f5fb079805f3e299fa45f756ecc4c3
1706 e6' / key-wrapped /
1707 ]
1708 ]
1709 ]
1710 ]
1711 ]
1712 ]
1713 ]
1715 Figure 27: Abstract Security Block CBOR diagnostic
1717 [
1718 7, / type code - bundle age /
1719 2, / block num /
1720 0, / flags /
1721 0, / CRC type /
1722 h'63bb162d8ee2e8175cfc340b6df978864907a2' / ciphertext /
1723 ]
1725 Figure 28: Encrypted Target block CBOR diagnostic
1727 Author's Address
1729 Brian Sipos
1730 RKF Engineering Solutions, LLC
1731 7500 Old Georgetown Road
1732 Suite 1275
1733 Bethesda, MD 20814-6198
1734 United States of America
1736 Email: BSipos@rkf-eng.com