idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-01.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 (June 26, 2020) is 1401 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: '0' on line 661
-- Looks like a reference, but probably isn't: '40' on line 661
-- Looks like a reference, but probably isn't: '2' on line 692
== Outdated reference: A later version (-27) exists of
draft-ietf-dtn-bpsec-22
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE'
** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053)
== Outdated reference: A later version (-31) exists of
draft-ietf-dtn-bpbis-25
== Outdated reference: A later version (-02) exists of
draft-ietf-dtn-bpsec-interop-sc-01
-- Obsolete informational reference (is this intentional?): RFC 7049
(Obsoleted by RFC 8949)
Summary: 1 error (**), 0 flaws (~~), 4 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 June 26, 2020
5 Expires: December 28, 2020
7 DTN Bundle Protocol Security COSE Security Contexts
8 draft-bsipos-dtn-bpsec-cose-01
10 Abstract
12 This document defines an integrity security context and a
13 confidentiality security context suitable for using CBOR Object
14 Signing and Encryption (COSE) algorithms within Bundle Protocol
15 Security (BPSec) blocks. A profile of COSE is 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 December 28, 2020.
35 Copyright Notice
37 Copyright (c) 2020 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
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
54 3. BPSec Security Contexts . . . . . . . . . . . . . . . . . . . 3
55 3.1. COSE Integrity Context . . . . . . . . . . . . . . . . . 3
56 3.2. COSE Confidentiality Context . . . . . . . . . . . . . . 4
57 4. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 5
58 4.1. Interoperability Algorithms . . . . . . . . . . . . . . . 5
59 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
61 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 8
62 6.2. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 8
63 6.3. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 8
64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
65 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 8
66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
68 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
69 9.2. Informative References . . . . . . . . . . . . . . . . . 10
70 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10
71 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 10
72 A.2. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 12
73 A.3. Symmetric Key COSE_Encrypt0 . . . . . . . . . . . . . . . 14
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
76 1. Introduction
78 The Bundle Protocol Security (BPSec) Specification
79 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block
80 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but
81 does not specify any security contexts to be used by either of the
82 security block types. The CBOR Object Signing and Encryption (COSE)
83 specification [RFC8152] defines a structure, encoding, and algorithms
84 to use for cryptographic signing and encryption.
86 This document describes how to use the algorithms and encodings of
87 COSE within BPSec blocks to apply those algorithms to Bundle security
88 in Section 3. A bare minimum of interoperability algorithms and
89 algorithm parameters is specified by this document in Section 4.
91 This document does not address how those COSE algorithms are intended
92 to be used within a larger security context.
94 2. Requirements Language
96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
98 "OPTIONAL" in this document are to be interpreted as described in BCP
99 14 [RFC2119] [RFC8174] when, and only when, they appear in all
100 capitals, as shown here.
102 3. BPSec Security Contexts
104 Rather than defining a single security context for both integrity and
105 confidentiality blocks, this document specifies two separate security
106 contexts which are analogous to the two BPSec block types. Each
107 security context allows a specific set of BPSec Result IDs.
109 The existing COSE message-marking tags in Section 2 of [RFC8152]
110 SHALL be used as BPSec Result ID values for all COSE security
111 contexts (see Table 1 and Table 2). This avoids the need for value-
112 mapping between code points of the two registries.
114 When embedding COSE messages, the CBOR-tagged form SHALL NOT be used.
115 The Result ID values already provide the same information as the COSE
116 tags.
118 3.1. COSE Integrity Context
120 The COSE Integrity Context has a Security Context ID of TBD-CI.
122 The integrity context SHALL allow only the Result IDs from Table 1.
123 Each integrity context result value SHALL consist of the COSE message
124 indicated by Table 1 in its decoded form.
126 +-----------+----------------+
127 | Result ID | Result Message |
128 +-----------+----------------+
129 | 97 | COSE_Mac |
130 | | |
131 | 17 | COSE_Mac0 |
132 | | |
133 | 98 | COSE_Sign |
134 | | |
135 | 18 | COSE_Sign1 |
136 +-----------+----------------+
138 Table 1: COSE Integrity Results
140 Each integrity result SHALL use the "detached" payload form with nil
141 payload value. The integrity result for COSE_Mac and COSE_Mac0
142 messages are computed by the procedure in Section 6.3 of [RFC8152].
143 The integrity result for COSE_Sign and COSE_Sign1 messages are
144 computed by the procedure in Section 4.4 of [RFC8152].
146 [NOTE: This differs from base BPSec in that the entire block and the
147 bundle primary is signed] The COSE "payload" used to generate a
148 signature or MAC result SHALL be the canonically serialized target
149 block, including the canonical block array structure. The COSE
150 "protected attributes from the application" used to generate a
151 signature or MAC result SHALL be either:
153 For a primary block target: An empty byte string.
155 For a canonical block target: The canonically serialized primary
156 block of the bundle.
158 3.2. COSE Confidentiality Context
160 The COSE Confidentiality Context has a Security Context ID of TBD-CC.
162 The confidentiality context SHALL allow only the Result IDs from
163 Table 2. Each confidentiality context result value SHALL consist of
164 the COSE message indicated by Table 2 in its decoded form.
166 +-----------+----------------+
167 | Result ID | Result Message |
168 +-----------+----------------+
169 | 96 | COSE_Encrypt |
170 | | |
171 | 16 | COSE_Encrypt0 |
172 +-----------+----------------+
174 Table 2: COSE Confidentiality Results
176 Only algorithms which support Authenticated Encryption with
177 Authenticated Data (AEAD) SHALL be usable in the first (content)
178 layer of a confidentiality result. Because COSE encryption with AEAD
179 appends the authentication tag with the ciphertext, the size of the
180 block-type-specific-data will grow after an encryption operation.
182 Each confidentiality result SHALL use the "detached" payload form
183 with nil payload value. The COSE plaintext and ciphertext correspond
184 exactly with the target block-type-specific-data. The
185 confidentiality result for COSE_Encrypt and COSE_Encrypt0 messages
186 are computed by the procedure in Section 5.3 of [RFC8152].
188 [NOTE: This differs from base BPSec in that AAD from the block and
189 the bundle primary is used] The COSE "plaintext" used to generate an
190 encrypt result SHALL be the block-type-specific-data of the target
191 block, the decoded byte string itself (not including the encoded CBOR
192 item header). The COSE "protected attributes from the application"
193 used to generate an encrypt result SHALL be the concatenation of the
194 following:
196 1. The canonically serialized primary block of the bundle.
198 2. The canonically serialized augmented target block, which has its
199 block-type-specific-data substituted with an empty byte string.
201 4. COSE Profile for BPSec
203 This section contains requirements which apply to the use of COSE
204 within BPSec across any security context use.
206 When used in a BPSec result, each COSE message SHALL contain an
207 explicit algorithm identifier in the lower (content) layers. A BPSec
208 security operation always occurs within the context of the immutable
209 primary block and its parameters. When available and not implied by
210 the bundle source, a COSE message SHOULD contain a key identifier in
211 the highest layer. When a key identifier is not available, BPSec
212 acceptors SHOULD use the Security Source (if available) and the
213 Bundle Source to imply which keys can be used for security
214 operations.
216 The algorithms required by this profile focuses on networks using
217 shared symmetric-keys, with recommended algorithms for Elliptic Curve
218 (EC) keypairs and RSA keypairs. The focus of this profile is to
219 enable interoperation between security sources and acceptors on an
220 open network, where more explicit COSE parameters make it easier for
221 BPSec acceptors to avoid assumptions and avoid out-of-band
222 parameters. The requirements of this profile still allow the use of
223 potentially not-easily-interoperable algorithms and message/recipient
224 configurations for use by private networks, where message size is
225 more important than explicit COSE parameters.
227 4.1. Interoperability Algorithms
229 [NOTE: The required list is identical to the
230 [I-D.ietf-dtn-bpsec-interop-sc] list.] The set of integrity
231 algorithms needed for interoperability is listed here. The full set
232 of COSE algorithms available is managed at [IANA-COSE].
234 Implementations conforming to this specification SHALL support the
235 symmetric keyed algorithms of Table 3. Implementations capable of
236 doing so SHOULD support the asymmetric keyed and key-encryption
237 algorithms of Table 3.
239 +------------------+--------+-------------+------+------------------+
240 | BPSec Block | COSE | Name | Code | Implementation |
241 | | Layer | | | Requirements |
242 +------------------+--------+-------------+------+------------------+
243 | Integrity | 1 | HMAC | 5 | Required |
244 | | | 256/256 | | |
245 | | | | | |
246 | Integrity | 1 | ES256 | -7 | Recommended |
247 | | | | | |
248 | Integrity | 1 | PS256 | -37 | Recommended |
249 | | | | | |
250 | Confidentiality | 1 | A256GCM | 3 | Required |
251 | | | | | |
252 | Confidentiality | 2 | A256KW | -5 | Recommended |
253 | | | | | |
254 | Integrity or | 2 | ECDH-ES + | -31 | Recommended |
255 | Confidentiality | | A256KW | | |
256 | | | | | |
257 | Integrity or | 2 | RSAES-OAEP | -41 | Recommended |
258 | Confidentiality | | w/ SHA-256 | | |
259 +------------------+--------+-------------+------+------------------+
261 Table 3: Interoperability Algorithms
263 The following are recommended key and recipient uses within COSE/
264 BPSec:
266 Symmetric Key Integrity: When generating a BIB result from a
267 symmetric key, implementations SHOULD use either a COSE_Mac0 or a
268 COSE_Mac using the private key directly. When a COSE_Mac is used
269 with a direct key, the recipient layer SHOULD include a key
270 identifier.
272 EC Keypair Integrity: When generating a BIB result from an EC
273 keypair, implementations SHOULD use either a COSE_Sign1 or a
274 COSE_Sign using the private key directly or a COSE_Mac from a
275 symmetric key with a layer-2 encryption of the symmetric key.
276 When a COSE_Sign or COSE_Mac is used with EC keypair, the
277 recipient layer SHOULD include a public key identifier.
279 RSA Keypair Integrity: When generating a BIB result from an RSA
280 keypair, implementations SHOULD use either a COSE_Sign1 or a
281 COSE_Sign using the private key directly or a COSE_Mac from a
282 symmetric key with a layer-2 key-wrap of the symmetric key. When
283 a COSE_Sign or COSE_Mac is used with RSA keypair, the recipient
284 layer SHOULD include a public key identifier. When a COSE_Sign or
285 COSE_Sign1 is used with RSA keypair, the signature uses a maximum-
286 length PSS salt in accordance with [RFC8230].
288 Symmetric Key Confidentiality: When generating a BCB result from an
289 symmetric key, implementations SHOULD use a COSE_Encrypt message
290 with a recipient containing a key-wrapped CEK. When generating a
291 BCB result from a symmetric key, implementations SHOULD NOT use
292 COSE_Encrypt0 or COSE_Encrypt with direct content encryption key
293 (CEK). Doing so risks key overuse and the vulnerabilities
294 associated with large amount of ciphertext from the same key.
296 EC Keypair Confidentiality: When generating a BCB result from an EC
297 keypair, implementations SHOULD use a COSE_Encrypt message with a
298 recipient containing a key-wrapped CEK.
300 RSA Keypair Confidentiality: When generating a BCB result from an
301 RSA keypair, implementations SHOULD use a COSE_Encrypt message
302 with a recipient containing a key-wrapped CEK.
304 5. Implementation Status
306 [NOTE to the RFC Editor: please remove this section before
307 publication, as well as the reference to [RFC7942] and
308 [github-dtn-bpsec-cose].]
310 This section records the status of known implementations of the
311 protocol defined by this specification at the time of posting of this
312 Internet-Draft, and is based on a proposal described in [RFC7942].
313 The description of implementations in this section is intended to
314 assist the IETF in its decision processes in progressing drafts to
315 RFCs. Please note that the listing of any individual implementation
316 here does not imply endorsement by the IETF. Furthermore, no effort
317 has been spent to verify the information presented here that was
318 supplied by IETF contributors. This is not intended as, and must not
319 be construed to be, a catalog of available implementations or their
320 features. Readers are advised to note that other implementations can
321 exist.
323 An example implementation of COSE over Blocks has been created as a
324 GitHub project [github-dtn-bpsec-cose] and is intended to use as a
325 proof-of-concept and as a possible source of interoperability
326 testing. This example implementation only handles CBOR encoding/
327 decoding and cryptographic functions, it does not construct actual
328 BIB or BCB and does not integrate with a BP Agent.
330 6. Security Considerations
332 This section separates security considerations into threat categories
333 based on guidance of BCP 72 [RFC3552].
335 All of the security considerations of the underlying BPSec
336 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
338 6.1. Threat: BPSec Block Replay
340 The bundle's primary block contains fields which uniquely identify a
341 bundle: the Source Node ID, Creation Timestamp, and fragment
342 parameters (see Section 4.2.2 of [I-D.ietf-dtn-bpbis]). These same
343 fields are used to correlate Administrative Records with the bundles
344 for which the records were generated. Including the primary block in
345 the AAD for BPSec integrity and confidentiality binds the
346 verification of the secured block to its parent bundle and disallows
347 replay of any block with its BIB or BCB.
349 This profile of COSE limits the encryption algorithms to only AEAD in
350 order to include the context of the encrypted data as AAD. If an
351 agent mistakenly allows the use of non-AEAD encryption when
352 decrypting and verifying a BCB, the possibility of block replay
353 attack is present.
355 6.2. Threat: Unidentifiable Key
357 The profile in Section 4.1 recommends key identifiers when possible.
358 If the application using a COSE Integrity or COSE Confidentiality
359 context leaves out key identification data (in a COSE recipient
360 structure), the security acceptor for those BPSec blocks only has the
361 primary block available to use when verifying or decrypting the
362 target block. This leads to a situation, identified in BPSec
363 Security Considerations, where a signature is verified to be valid
364 but not from the expected Security Source.
366 6.3. Threat: Algorithm Vulnerabilities
368 Because this use of COSE leaves the specific algorithms chosen for
369 BIB and BCB use up to the applications securing bundle data, it is
370 important to use only COSE algorithms which are marked as recommended
371 in the IANA registry [IANA-COSE].
373 7. IANA Considerations
375 Registration procedures referred to in this section are defined in
376 [RFC8126].
378 7.1. BPSec Security Contexts
380 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
381 entry has been added to the "BPSec Security Context Identifiers" sub-
382 registry.
384 +--------+----------------------+---------------------+
385 | Value | Description | Reference |
386 +--------+----------------------+---------------------+
387 | TBD-CI | COSE Integrity | This specification. |
388 | | | |
389 | TBD-CC | COSE Confidentiality | This specification. |
390 +--------+----------------------+---------------------+
392 8. Acknowledgments
394 The interoperability minimum algorithms and parameters are based on
395 the draft [I-D.ietf-dtn-bpsec-interop-sc].
397 9. References
399 9.1. Normative References
401 [I-D.ietf-dtn-bpsec]
402 Birrane, E. and K. McKeever, "Bundle Protocol Security
403 Specification", draft-ietf-dtn-bpsec-22 (work in
404 progress), March 2020.
406 [IANA-BUNDLE]
407 IANA, "Bundle Protocol",
408 .
410 [IANA-COSE]
411 IANA, "CBOR Object Signing and Encryption (COSE)",
412 .
414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
415 Requirement Levels", BCP 14, RFC 2119,
416 DOI 10.17487/RFC2119, March 1997,
417 .
419 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
420 Writing an IANA Considerations Section in RFCs", BCP 26,
421 RFC 8126, DOI 10.17487/RFC8126, June 2017,
422 .
424 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
425 RFC 8152, DOI 10.17487/RFC8152, July 2017,
426 .
428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
430 May 2017, .
432 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
433 and Encryption (COSE) Messages", RFC 8230,
434 DOI 10.17487/RFC8230, September 2017,
435 .
437 9.2. Informative References
439 [github-dtn-bpsec-cose]
440 Sipos, B., "DTN Bundle Protocol Security COSE Security
441 Contexts",
442 .
444 [I-D.ietf-dtn-bpbis]
445 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
446 Version 7", draft-ietf-dtn-bpbis-25 (work in progress),
447 May 2020.
449 [I-D.ietf-dtn-bpsec-interop-sc]
450 Birrane, E., "BPSec Interoperability Security Contexts",
451 draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
452 February 2020.
454 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
455 Text on Security Considerations", BCP 72, RFC 3552,
456 DOI 10.17487/RFC3552, July 2003,
457 .
459 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
460 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
461 October 2013, .
463 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
464 Code: The Implementation Status Section", BCP 205,
465 RFC 7942, DOI 10.17487/RFC7942, July 2016,
466 .
468 Appendix A. Examples
470 A.1. Symmetric Key COSE_Mac0
472 This is an example of a MAC with implied recipient (and its key
473 material). The two provided figures are CBOR diagnostic notation
474 [RFC7049] of the target block being signed and the Abstract Security
475 Block (which will itself be enveloped within a BIB).
477 The 256-bit key used is shown below.
479 / signing key /
480 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'
482 Symmetric Key
484 [
485 7, / BP version /
486 0, / flags /
487 0, / CRC type /
488 [1, '//dst/'], / destination /
489 [1, '//src/'], / source /
490 [1, '//src/'], / report-to /
491 [0, 40], / timestamp /
492 1000000 / lifetime /
493 ]
495 Figure 1: Primary block CBOR diagnostic
497 [
498 7, / type code - bundle age /
499 2, / block num /
500 0, / flags /
501 0, / CRC type /
502 h'19012c' / type-specific-data:
503 300 \ age \
504 /
505 ]
507 Figure 2: Target block CBOR diagnostic
509 The external_aad is the encoded primary block. The payload is the
510 encoded target block.
512 [
513 'MAC0', / context /
514 h'a10105', / protected /
515 h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018
516 281a000f4240', / external_aad /
517 h'85070200004319012c' / payload /
518 ]
520 Figure 3: MAC_structure CBOR diagnostic
522 [
523 [2], / targets /
524 0, / security context TBD /
525 0, / flags /
526 [
527 [ / target block #2 /
528 [ / result /
529 17, / COSE_Mac0 tag /
530 [
531 h'a10105' / protected {
532 \ alg \ 1:5 \ HMAC 256//256 \
533 } / ,
534 { / unprotected /
535 / kid / 4:'mykey'
536 },
537 null, / payload /
538 h'd98308918d36dc4190a93f84c8d857015b75b78edea3360282555257c3be
539 f847' / tag /
540 ]
541 ]
542 ]
543 ]
544 ]
546 Figure 4: Abstract Security Block CBOR diagnostic
548 A.2. RSA Keypair COSE_Sign1
550 This is an example of a signature with implied recipient (and its key
551 material). The two provided figures are CBOR diagnostic notation
552 [RFC7049] of the target block being signed and the Abstract Security
553 Block (which will itself be enveloped within a BIB).
555 The 512-bit private key used is below. It is not supposed to be a
556 secure configuration, only intended to explain the procedure. This
557 signature uses zero-length salt for deterministic output, which
558 differs from the parameter specified by [RFC8230] and is not
559 recommended for normal use.
561 -----BEGIN RSA PRIVATE KEY-----
562 MIIBOwIBAAJBAN21GdS0faAYgacepRmbr7TAT0wEuahjrBfAO0Dg1M5d37O9Tx9H
563 vZw2OEcLq2WTvf0Kja1JWpqdoJm17LghhPkCAwEAAQJBAMgkJo9n6EhQFyrgdTZq
564 3vES8gKz+U3TvJUsSdFFpZYsZhUaLKP9oxyIxl3IvK5iS0oAsW0nqI7aMcBoPmxZ
565 pQECIQDuyd5uzvS0wnrsDWoDhiTm6O+PJoMQix9yH99HBUhWKQIhAO2wDP7e/Nnr
566 A7rDSgM6+REGmt8I00NglFwShBUi4HJRAiAiJrLuTCEJXSsxaXW5DU1nzPa+FXb3
567 Pb6Alvha8vF2iQIgbC7WK2dJBNKv9uCOHlxIItSzxtIYfjFGNYYD8i7Wo5ECIQDp
568 5++fp04AMVAnE0uqNEnITkTWb91hAS8IjaYCqLGyEA==
569 -----END RSA PRIVATE KEY-----
571 [
572 7, / BP version /
573 0, / flags /
574 0, / CRC type /
575 [1, '//dst/'], / destination /
576 [1, '//src/'], / source /
577 [1, '//src/'], / report-to /
578 [0, 40], / timestamp /
579 1000000 / lifetime /
580 ]
582 Figure 5: Primary block CBOR diagnostic
584 [
585 7, / type code - bundle age /
586 2, / block num /
587 0, / flags /
588 0, / CRC type /
589 h'19012c' / type-specific-data:
590 300 \ age \
591 /
592 ]
594 Figure 6: Target block CBOR diagnostic
596 The external_aad is the encoded primary block. The payload is the
597 encoded target block.
599 [
600 'Signature1', / context /
601 h'a1013824', / protected /
602 h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018
603 281a000f4240', / external_aad /
604 h'85070200004319012c' / payload /
605 ]
607 Figure 7: Sig_structure CBOR diagnostic
609 [
610 [2], / targets /
611 0, / security context TBD /
612 0, / flags /
613 [
614 [ / target block #2 /
615 [ / result /
616 18, / COSE_Sign1 tag /
617 [
618 h'a1013824' / protected {
619 \ alg \ 1:-37 \ PS256 \
620 } / ,
621 { / unprotected /
622 / kid / 4:'mykey'
623 },
624 null, / payload /
625 h'1a35746072396c74275fd7b443a0d7391a0f92012a53e0accc543daa51ae
626 6faae551a4843a0bc7c3bf808e3638ddc381355b54cc60f4ca9dea15923b
627 5986e758' / signature /
628 ]
629 ]
630 ]
631 ]
632 ]
634 Figure 8: Abstract Security Block CBOR diagnostic
636 A.3. Symmetric Key COSE_Encrypt0
638 This is an example of an encryption with implied recipient (and its
639 direct content encryption key). The provided figures are CBOR
640 diagnostic notation [RFC7049] of the target block being encrypted,
641 the Abstract Security Block (which will itself be enveloped within a
642 BCB), and the resulting target block.
644 This example uses a single shared content encryption key, which is
645 not recommended for normal use. The 256-bit key used is shown below.
646 A random IV is generated for this operation and is indicated in a
647 standard way in the unprotected header.
649 / content encryption key /
650 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'
652 Symmetric Keys
654 [
655 7, / BP version /
656 0, / flags /
657 0, / CRC type /
658 [1, '//dst/'], / destination /
659 [1, '//src/'], / source /
660 [1, '//src/'], / report-to /
661 [0, 40], / timestamp /
662 1000000 / lifetime /
663 ]
665 Figure 9: Primary block CBOR diagnostic
667 [
668 7, / type code - bundle age /
669 2, / block num /
670 0, / flags /
671 0, / CRC type /
672 h'19012c' / type-specific-data:
673 300 \ age \
674 /
675 ]
677 Figure 10: Initial Target block CBOR diagnostic
679 The external_aad is a concatenation of the encoded primary block and
680 the encoded augmented target block (its block data removed).
682 [
683 'Encrypt0', / context /
684 h'a10103', / protected /
685 h'880700008201662f2f6473742f8201662f2f7372632f8201662f2f7372632f820018
686 281a000f4240850702000040' / external_aad /
687 ]
689 Figure 11: Enc_structure CBOR diagnostic
691 [
692 [2], / targets /
693 0, / security context TBD /
694 0, / flags /
695 [
696 [ / target block #2 /
697 [ / result /
698 16, / COSE_Encrypt0 tag /
699 [
700 h'a10103', / protected {
701 \ alg \ 1:3 \ A256GCM \
702 } /
703 { / unprotected /
704 / kid / 4:'mykey',
705 / iv / 5: h'6f3093eba5d85143c3dc484a'
706 },
707 null / payload /
708 ]
709 ]
710 ]
711 ]
712 ]
714 Figure 12: Abstract Security Block CBOR diagnostic
716 [
717 7, / type code - bundle age /
718 2, / block num /
719 0, / flags /
720 0, / CRC type /
721 h'63bb16685ef432a0e6f1d404da71959081a715' / ciphertext /
722 ]
724 Figure 13: Encrypted Target block CBOR diagnostic
726 Author's Address
728 Brian Sipos
729 RKF Engineering Solutions, LLC
730 7500 Old Georgetown Road
731 Suite 1275
732 Bethesda, MD 20814-6198
733 United States of America
735 Email: BSipos@rkf-eng.com