From aeac43bba84fc2498e40f22142024e78e2485980 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 15 Aug 2024 22:07:25 +0000 Subject: [PATCH] Script updating gh-pages from fc2fff6. [ci skip] --- ...html => draft-ietf-cose-hash-envelope.html | 20 +- ...e.txt => draft-ietf-cose-hash-envelope.txt | 19 +- .../draft-steele-cose-hash-envelope.html | 1552 ---------------- .../draft-steele-cose-hash-envelope.txt | 328 ---- draft-steele-cose-hash-envelope-01/index.html | 45 - index.html | 79 +- .../draft-steele-cose-hash-envelope.html | 1552 ---------------- .../draft-steele-cose-hash-envelope.txt | 328 ---- steve/120-fixes/index.html | 45 - .../draft-steele-cose-hash-envelope.html | 1551 ---------------- .../draft-steele-cose-hash-envelope.txt | 337 ---- steve/120-submission/index.html | 45 - .../draft-steele-cose-hash-envelope.html | 1555 ----------------- .../draft-steele-cose-hash-envelope.txt | 332 ---- steve/streamline/index.html | 45 - 15 files changed, 42 insertions(+), 7791 deletions(-) rename draft-steele-cose-hash-envelope.html => draft-ietf-cose-hash-envelope.html (97%) rename draft-steele-cose-hash-envelope.txt => draft-ietf-cose-hash-envelope.txt (94%) delete mode 100644 draft-steele-cose-hash-envelope-01/draft-steele-cose-hash-envelope.html delete mode 100644 draft-steele-cose-hash-envelope-01/draft-steele-cose-hash-envelope.txt delete mode 100644 draft-steele-cose-hash-envelope-01/index.html delete mode 100644 steve/120-fixes/draft-steele-cose-hash-envelope.html delete mode 100644 steve/120-fixes/draft-steele-cose-hash-envelope.txt delete mode 100644 steve/120-fixes/index.html delete mode 100644 steve/120-submission/draft-steele-cose-hash-envelope.html delete mode 100644 steve/120-submission/draft-steele-cose-hash-envelope.txt delete mode 100644 steve/120-submission/index.html delete mode 100644 steve/streamline/draft-steele-cose-hash-envelope.html delete mode 100644 steve/streamline/draft-steele-cose-hash-envelope.txt delete mode 100644 steve/streamline/index.html diff --git a/draft-steele-cose-hash-envelope.html b/draft-ietf-cose-hash-envelope.html similarity index 97% rename from draft-steele-cose-hash-envelope.html rename to draft-ietf-cose-hash-envelope.html index 865b7ad..36907e8 100644 --- a/draft-steele-cose-hash-envelope.html +++ b/draft-ietf-cose-hash-envelope.html @@ -15,7 +15,7 @@ " name="description"> - + - + - - - - - - - - - - - - - - -
Internet-DraftCOSE Hash EnvelopeJuly 2024
Steele, et al.Expires 9 January 2025[Page]
-
-
-
-
Workgroup:
-
Network Working Group
-
Internet-Draft:
-
draft-steele-cose-hash-envelope-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
O. Steele
-
Transmute
-
-
-
S. Lasker
-
DataTrails
-
-
-
H. Birkholz
-
Fraunhofer SIT
-
-
-
-
-

COSE Hash Envelope

-
-

Abstract

-

This document defines new COSE header parameters for signaling a payload as an output of a hash function. -This mechanism enables faster validation as access to the original payload is not required for signature validation. -Additionally, hints of the detached payload's content format and availability are defined providing references to optional discovery mechanisms that can help to find original payload content.

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- The latest revision of this draft can be found at https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele-cose-hash-envelope.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-cose-hash-envelope/.

-

- Discussion of this document takes place on the - CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/.

-

Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 9 January 2025.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

COSE defined detached payloads in Section 2 of [RFC9052], using nil as the payload. -In order to verify a signature over a detached payload, the verifier must have access to the payload content. -Storing a hash of the content allows for small signature envelopes, that are easy to transport and verify independently.

-

Additional hints in the protected header ensure cryptographic agility for the hashing & signing algorithms, and discoverability for the original content which could be prohibitively large to move over a network.

-
-
-

-1.1. Attached Payload -

-

COSE_sign1 envelope with an attached payload, providing for signature validation.

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      h'317cedc7...c494e772',       / Payload                       /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-

-1.2. Detached Payload -

-

COSE_sign1 envelope with a detached payload (nil), which is compact but the payload must be distributed out of band to validate the signature

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      nil,                          / Detached Payload              /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-

-1.3. Hashed Payload -

-

A hashed payload functions equivalently to an attached payload, with the benefits of being compact in size and providing the ability to validate the signature.

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      h'935b5a91...e18a588a',       / Payload                       /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-
-
-

-2. Header Parameters -

-

To represent a hash of a payload, the following headers are defined:

-
-
TBD_1:
-
-

the hash algorithm used to generate the hash of the payload

-
-
-
TBD_2:
-
-

the content type of the payload the hash represents

-
-
-
TBD_3:
-
-

an identifier enabling a verifier to retrieve the full payload preimage.

-
-
-
-
-
-

-2.1. Signed Hash Envelopes Example -

-
-
-Hash_Envelope_Protected_Header = {
-    ; Cryptographic algorithm to use
-    ? &(alg: 1) => int,
-
-    ; Type of the envelope
-    ? &(typ: 16) => int / tstr
-
-    ; Hash algorithm used to produce the payload from content
-    ; -16 for SHA-256,
-    ; See https://www.iana.org/assignments/cose/cose.xhtml
-    &(payload_hash_alg: TBD_1) => int
-
-    ; Content type of the preimage
-    ; (content to be hashed) of the payload
-    ; 50 for application/json,
-    ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3
-    &(payload_preimage_content_type: TBD_2) => int
-
-    ; Location the content of the hashed payload is stored
-    ; For example:
-    ; storage.example/244f...9c19
-    ? &(payload_location: TBD_3) => tstr
-
-    * int => any
-}
-
-Hash_Envelope_Unprotected_Header = {
-    * int => any
-}
-
-Hash_Envelope_as_COSE_Sign1 = [
-    protected : bstr .cbor Hash_Envelope_Protected_Header,
-    unprotected : Hash_Envelope_Unprotected_Header,
-    payload: bstr / nil,
-    signature : bstr
-]
-
-Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1)
-
-
-
-
-
-
-

-2.2. Protected Header -

-

16 (typ), TBD_1 (payload hash alg) and TBD_2 (content type of the preimage of the payload) MUST be present in the protected header and MUST NOT be present in the unprotected header. -TBD_3 (payload_location) MAY be added to the protected header and MUST NOT be presented in the unprotected header.

-

For example:

-
-
-{
-  / alg : ES384 / 1: -35,
-  / kid / 4: h'75726e3a...32636573',
-  / typ / 16: application/hashed+cose
-  / payload_hash_alg sha-256 / TBD_1: 1
-  / payload_preimage_content_type / TBD_2: application/jwk+json
-  / payload_location / TBD_3 : storage.example/244f...9c19
-}
-
-
-
-
-
-
-
-
-

-3. Encrypted Hashes -

-

Should we define this?

-
-
-
-
-

-4. Security Considerations -

-

TODO Security

-
-
-

-4.1. Choice of Hash Function -

-

It is RECOMMENDED to align the strength of the chosen hash function to the strength of the chosen signature algorithm. -For example, when signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the payload.

-
-
-
-
-
-
-

-5. IANA Considerations -

-
-
-

-5.1. Requirements Notation -

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", -"MAY", and "OPTIONAL" in this document are to be interpreted as -described in BCP 14 [RFC2119] [RFC8174] when, and only when, they -appear in all capitals, as shown here.

-
-
-
-
-

-5.2. COSE Header Algorithm Parameters -

-
    -
  • -

    Name: payload hash algorithm

    -
    • -
  • -

    Label: TBD_1

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: Hash algorithm used to produce the payload.

    -
    • -
-
-
-
-
-

-5.3. Named Information Hash Algorithm Registry -

-
    -
  • -

    Name: SHAKE256

    -
    • -
  • -

    Label: TBD_2

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: SHAKE256 a described in https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

    -
    • -
  • -

    Name: ASCON128

    -
    • -
  • -

    Label: TBD_3

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: ASCON128 a described in https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf

    -
    • -
-
-
-
-
-
-
-

-6. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC9052]
-
-Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
-
-
-
-
-
-
-

-Acknowledgments -

-

The following individuals provided input into the final form of the document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet.

-
-
-
-
-

-Authors' Addresses -

-
-
Orie Steele
-
Transmute
- -
-
-
Steve Lasker
-
DataTrails
- -
-
-
Henk Birkholz
-
Fraunhofer SIT
-
Rheinstrasse 75
-
-64295 Darmstadt -
-
Germany
- -
-
-
- - - diff --git a/draft-steele-cose-hash-envelope-01/draft-steele-cose-hash-envelope.txt b/draft-steele-cose-hash-envelope-01/draft-steele-cose-hash-envelope.txt deleted file mode 100644 index 7bad809..0000000 --- a/draft-steele-cose-hash-envelope-01/draft-steele-cose-hash-envelope.txt +++ /dev/null @@ -1,328 +0,0 @@ - - - - -Network Working Group O. Steele -Internet-Draft Transmute -Intended status: Standards Track S. Lasker -Expires: 9 January 2025 DataTrails - H. Birkholz - Fraunhofer SIT - 8 July 2024 - - - COSE Hash Envelope - draft-steele-cose-hash-envelope-latest - -Abstract - - This document defines new COSE header parameters for signaling a - payload as an output of a hash function. This mechanism enables - faster validation as access to the original payload is not required - for signature validation. Additionally, hints of the detached - payload's content format and availability are defined providing - references to optional discovery mechanisms that can help to find - original payload content. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at - https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele- - cose-hash-envelope.html. Status information for this document may be - found at https://datatracker.ietf.org/doc/draft-steele-cose-hash- - envelope/. - - Discussion of this document takes place on the CBOR Object Signing - and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/. - - Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 9 January 2025. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Attached Payload - 1.2. Detached Payload - 1.3. Hashed Payload - 2. Header Parameters - 2.1. Signed Hash Envelopes Example - 2.2. Protected Header - 3. Encrypted Hashes - 4. Security Considerations - 4.1. Choice of Hash Function - 5. IANA Considerations - 5.1. Requirements Notation - 5.2. COSE Header Algorithm Parameters - 5.3. Named Information Hash Algorithm Registry - 6. Normative References - Acknowledgments - Authors' Addresses - -1. Introduction - - COSE defined detached payloads in Section 2 of [RFC9052], using nil - as the payload. In order to verify a signature over a detached - payload, the verifier must have access to the payload content. - Storing a hash of the content allows for small signature envelopes, - that are easy to transport and verify independently. - - Additional hints in the protected header ensure cryptographic agility - for the hashing & signing algorithms, and discoverability for the - original content which could be prohibitively large to move over a - network. - -1.1. Attached Payload - - COSE_sign1 envelope with an attached payload, providing for signature - validation. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'317cedc7...c494e772', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.2. Detached Payload - - COSE_sign1 envelope with a detached payload (nil), which is compact - but the payload must be distributed out of band to validate the - signature - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - nil, / Detached Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.3. Hashed Payload - - A hashed payload functions equivalently to an attached payload, with - the benefits of being compact in size and providing the ability to - validate the signature. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'935b5a91...e18a588a', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -2. Header Parameters - - To represent a hash of a payload, the following headers are defined: - - TBD_1: the hash algorithm used to generate the hash of the payload - - TBD_2: the content type of the payload the hash represents - - TBD_3: an identifier enabling a verifier to retrieve the full - payload preimage. - -2.1. Signed Hash Envelopes Example - - Hash_Envelope_Protected_Header = { - ; Cryptographic algorithm to use - ? &(alg: 1) => int, - - ; Type of the envelope - ? &(typ: 16) => int / tstr - - ; Hash algorithm used to produce the payload from content - ; -16 for SHA-256, - ; See https://www.iana.org/assignments/cose/cose.xhtml - &(payload_hash_alg: TBD_1) => int - - ; Content type of the preimage - ; (content to be hashed) of the payload - ; 50 for application/json, - ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3 - &(payload_preimage_content_type: TBD_2) => int - - ; Location the content of the hashed payload is stored - ; For example: - ; storage.example/244f...9c19 - ? &(payload_location: TBD_3) => tstr - - * int => any - } - - Hash_Envelope_Unprotected_Header = { - * int => any - } - - Hash_Envelope_as_COSE_Sign1 = [ - protected : bstr .cbor Hash_Envelope_Protected_Header, - unprotected : Hash_Envelope_Unprotected_Header, - payload: bstr / nil, - signature : bstr - ] - - Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1) - -2.2. Protected Header - - 16 (typ), TBD_1 (payload hash alg) and TBD_2 (content type of the - preimage of the payload) MUST be present in the protected header and - MUST NOT be present in the unprotected header. TBD_3 - (payload_location) MAY be added to the protected header and MUST NOT - be presented in the unprotected header. - - For example: - - { - / alg : ES384 / 1: -35, - / kid / 4: h'75726e3a...32636573', - / typ / 16: application/hashed+cose - / payload_hash_alg sha-256 / TBD_1: 1 - / payload_preimage_content_type / TBD_2: application/jwk+json - / payload_location / TBD_3 : storage.example/244f...9c19 - } - -3. Encrypted Hashes - - Should we define this? - -4. Security Considerations - - TODO Security - -4.1. Choice of Hash Function - - It is RECOMMENDED to align the strength of the chosen hash function - to the strength of the chosen signature algorithm. For example, when - signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the - payload. - -5. IANA Considerations - -5.1. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -5.2. COSE Header Algorithm Parameters - - * Name: payload hash algorithm - - * Label: TBD_1 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: Hash algorithm used to produce the payload. - -5.3. Named Information Hash Algorithm Registry - - * Name: SHAKE256 - - * Label: TBD_2 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: SHAKE256 a described in - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf - - * Name: ASCON128 - - * Label: TBD_3 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: ASCON128 a described in - https://csrc.nist.gov/CSRC/media/Projects/lightweight- - cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): - Structures and Process", STD 96, RFC 9052, - DOI 10.17487/RFC9052, August 2022, - . - -Acknowledgments - - The following individuals provided input into the final form of the - document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, - Cedric Fournet. - -Authors' Addresses - - Orie Steele - Transmute - Email: orie@transmute.industries - - - Steve Lasker - DataTrails - Email: steve.lasker@datatrails.ai - - - Henk Birkholz - Fraunhofer SIT - Rheinstrasse 75 - 64295 Darmstadt - Germany - Email: henk.birkholz@ietf.contact diff --git a/draft-steele-cose-hash-envelope-01/index.html b/draft-steele-cose-hash-envelope-01/index.html deleted file mode 100644 index 62dbb01..0000000 --- a/draft-steele-cose-hash-envelope-01/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - OR13/draft-steele-cose-hash-envelope draft-steele-cose-hash-envelope-01 preview - - - - -

Editor's drafts for draft-steele-cose-hash-envelope-01 branch of OR13/draft-steele-cose-hash-envelope

- - - - - - -
COSE Hash Envelopeplain textsame as main
- - - diff --git a/index.html b/index.html index 50e9038..17b88b5 100644 --- a/index.html +++ b/index.html @@ -1,7 +1,7 @@ - OR13/draft-steele-cose-hash-envelope main preview + cose-wg/draft-ietf-cose-hash-envelope main preview -

Editor's drafts for main branch of OR13/draft-steele-cose-hash-envelope

-

View saved issues, or the latest GitHub issues and pull requests in the repo.

+

Editor's drafts for main branch of cose-wg/draft-ietf-cose-hash-envelope

+

View saved issues, or the latest GitHub issues and pull requests in the repo.

- - - - + + + +
COSE Hash Envelopeplain textdatatrackerdiff with last submissionCOSE Hash Envelopeplain textdatatrackerdiff with last submission
-

Preview for branch issue-15-opt-a

- - - - - - -
COSE Hash Envelopeplain textdiff with main

Preview for branch issue-16

- - - - -
COSE Hash Envelopeplain textdiff with main
-

Preview for branch steve

-

Preview for branch steve/streamline

- - - - - - -
COSE Hash Envelopeplain textdiff with main
-

Preview for branch steve/120-submission

- - - - - - -
COSE Hash Envelopeplain textdiff with main
-

Preview for branch steve/120-fixes

- - - - - + + +
COSE Hash Envelopeplain textdiff with mainplain textdiff with main

Preview for branch issue_15

- - - + + +
COSE Hash Envelopeplain textdiff with mainplain textdiff with main
-

Preview for branch draft-steele-cose-hash-envelope-01

- +

Preview for branch issue-15-opt-b

+
- - - + + +
COSE Hash Envelopeplain textdiff with mainplain textdiff with main
-

Preview for branch issue-15-opt-b

- +

Preview for branch issue-15-opt-a

+
- - - + + +
COSE Hash Envelopeplain textdiff with mainplain textdiff with main
- - diff --git a/steve/120-fixes/draft-steele-cose-hash-envelope.txt b/steve/120-fixes/draft-steele-cose-hash-envelope.txt deleted file mode 100644 index 7bad809..0000000 --- a/steve/120-fixes/draft-steele-cose-hash-envelope.txt +++ /dev/null @@ -1,328 +0,0 @@ - - - - -Network Working Group O. Steele -Internet-Draft Transmute -Intended status: Standards Track S. Lasker -Expires: 9 January 2025 DataTrails - H. Birkholz - Fraunhofer SIT - 8 July 2024 - - - COSE Hash Envelope - draft-steele-cose-hash-envelope-latest - -Abstract - - This document defines new COSE header parameters for signaling a - payload as an output of a hash function. This mechanism enables - faster validation as access to the original payload is not required - for signature validation. Additionally, hints of the detached - payload's content format and availability are defined providing - references to optional discovery mechanisms that can help to find - original payload content. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at - https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele- - cose-hash-envelope.html. Status information for this document may be - found at https://datatracker.ietf.org/doc/draft-steele-cose-hash- - envelope/. - - Discussion of this document takes place on the CBOR Object Signing - and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/. - - Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 9 January 2025. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Attached Payload - 1.2. Detached Payload - 1.3. Hashed Payload - 2. Header Parameters - 2.1. Signed Hash Envelopes Example - 2.2. Protected Header - 3. Encrypted Hashes - 4. Security Considerations - 4.1. Choice of Hash Function - 5. IANA Considerations - 5.1. Requirements Notation - 5.2. COSE Header Algorithm Parameters - 5.3. Named Information Hash Algorithm Registry - 6. Normative References - Acknowledgments - Authors' Addresses - -1. Introduction - - COSE defined detached payloads in Section 2 of [RFC9052], using nil - as the payload. In order to verify a signature over a detached - payload, the verifier must have access to the payload content. - Storing a hash of the content allows for small signature envelopes, - that are easy to transport and verify independently. - - Additional hints in the protected header ensure cryptographic agility - for the hashing & signing algorithms, and discoverability for the - original content which could be prohibitively large to move over a - network. - -1.1. Attached Payload - - COSE_sign1 envelope with an attached payload, providing for signature - validation. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'317cedc7...c494e772', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.2. Detached Payload - - COSE_sign1 envelope with a detached payload (nil), which is compact - but the payload must be distributed out of band to validate the - signature - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - nil, / Detached Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.3. Hashed Payload - - A hashed payload functions equivalently to an attached payload, with - the benefits of being compact in size and providing the ability to - validate the signature. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'935b5a91...e18a588a', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -2. Header Parameters - - To represent a hash of a payload, the following headers are defined: - - TBD_1: the hash algorithm used to generate the hash of the payload - - TBD_2: the content type of the payload the hash represents - - TBD_3: an identifier enabling a verifier to retrieve the full - payload preimage. - -2.1. Signed Hash Envelopes Example - - Hash_Envelope_Protected_Header = { - ; Cryptographic algorithm to use - ? &(alg: 1) => int, - - ; Type of the envelope - ? &(typ: 16) => int / tstr - - ; Hash algorithm used to produce the payload from content - ; -16 for SHA-256, - ; See https://www.iana.org/assignments/cose/cose.xhtml - &(payload_hash_alg: TBD_1) => int - - ; Content type of the preimage - ; (content to be hashed) of the payload - ; 50 for application/json, - ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3 - &(payload_preimage_content_type: TBD_2) => int - - ; Location the content of the hashed payload is stored - ; For example: - ; storage.example/244f...9c19 - ? &(payload_location: TBD_3) => tstr - - * int => any - } - - Hash_Envelope_Unprotected_Header = { - * int => any - } - - Hash_Envelope_as_COSE_Sign1 = [ - protected : bstr .cbor Hash_Envelope_Protected_Header, - unprotected : Hash_Envelope_Unprotected_Header, - payload: bstr / nil, - signature : bstr - ] - - Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1) - -2.2. Protected Header - - 16 (typ), TBD_1 (payload hash alg) and TBD_2 (content type of the - preimage of the payload) MUST be present in the protected header and - MUST NOT be present in the unprotected header. TBD_3 - (payload_location) MAY be added to the protected header and MUST NOT - be presented in the unprotected header. - - For example: - - { - / alg : ES384 / 1: -35, - / kid / 4: h'75726e3a...32636573', - / typ / 16: application/hashed+cose - / payload_hash_alg sha-256 / TBD_1: 1 - / payload_preimage_content_type / TBD_2: application/jwk+json - / payload_location / TBD_3 : storage.example/244f...9c19 - } - -3. Encrypted Hashes - - Should we define this? - -4. Security Considerations - - TODO Security - -4.1. Choice of Hash Function - - It is RECOMMENDED to align the strength of the chosen hash function - to the strength of the chosen signature algorithm. For example, when - signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the - payload. - -5. IANA Considerations - -5.1. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -5.2. COSE Header Algorithm Parameters - - * Name: payload hash algorithm - - * Label: TBD_1 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: Hash algorithm used to produce the payload. - -5.3. Named Information Hash Algorithm Registry - - * Name: SHAKE256 - - * Label: TBD_2 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: SHAKE256 a described in - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf - - * Name: ASCON128 - - * Label: TBD_3 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: ASCON128 a described in - https://csrc.nist.gov/CSRC/media/Projects/lightweight- - cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): - Structures and Process", STD 96, RFC 9052, - DOI 10.17487/RFC9052, August 2022, - . - -Acknowledgments - - The following individuals provided input into the final form of the - document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, - Cedric Fournet. - -Authors' Addresses - - Orie Steele - Transmute - Email: orie@transmute.industries - - - Steve Lasker - DataTrails - Email: steve.lasker@datatrails.ai - - - Henk Birkholz - Fraunhofer SIT - Rheinstrasse 75 - 64295 Darmstadt - Germany - Email: henk.birkholz@ietf.contact diff --git a/steve/120-fixes/index.html b/steve/120-fixes/index.html deleted file mode 100644 index 97bb3d5..0000000 --- a/steve/120-fixes/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - OR13/draft-steele-cose-hash-envelope steve/120-fixes preview - - - - -

Editor's drafts for steve/120-fixes branch of OR13/draft-steele-cose-hash-envelope

- - - - - - -
COSE Hash Envelopeplain textsame as main
- - - diff --git a/steve/120-submission/draft-steele-cose-hash-envelope.html b/steve/120-submission/draft-steele-cose-hash-envelope.html deleted file mode 100644 index f1a5b37..0000000 --- a/steve/120-submission/draft-steele-cose-hash-envelope.html +++ /dev/null @@ -1,1551 +0,0 @@ - - - - - - -COSE Hash Envelope - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftCOSE Hash EnvelopeJuly 2024
Steele, et al.Expires 9 January 2025[Page]
-
-
-
-
Workgroup:
-
Network Working Group
-
Internet-Draft:
-
draft-steele-cose-hash-envelope-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
O. Steele
-
Transmute
-
-
-
S. Lasker
-
DataTrails
-
-
-
H. Birkholz
-
Fraunhofer SIT
-
-
-
-
-

COSE Hash Envelope

-
-

Abstract

-

This document defines new COSE header parameters for signaling that a payload is the output of a hash function. -This mechanism enables faster validation as access to the original payload is not required for signature validation. -Additionally, hints of the detached payload's content format and availability are defined.

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- The latest revision of this draft can be found at https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele-cose-hash-envelope.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-cose-hash-envelope/.

-

- Discussion of this document takes place on the - CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/.

-

Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 9 January 2025.

-
-
- - -
-
-

-1. Introduction -

-

COSE defined detached payloads in Section 2 of [RFC9052], using nil as the payload.

-

In order to verify a signature over a detached payload, the verifier must have access to the payload content. Storing a hash of the content allows for small signature envelopes, that are easy to transport and verify independently.

-

Additional hints in the protected header ensure cryptographic agility for the hashing & signing algorithms, and discoverability for the original content which could be prohibitively large to move over a network.

-
-
-

-1.1. Requirements Notation -

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", -"MAY", and "OPTIONAL" in this document are to be interpreted as -described in BCP 14 [RFC2119] [RFC8174] when, and only when, they -appear in all capitals, as shown here.

-
-
-
-
-
-
-

-2. Header Parameters -

-

To represent a hash of a detached payload, the following headers are defined:

-
-
TBD 0:
-
-

will be assigned by [I-D.ietf-cose-typ-header-parameter], represents the content type of the code envelope, including the protected header and payload

-
-
-
TBD 1:
-
-

the hash algorithm used to generate the hash of the payload

-
-
-
TBD 2:
-
-

the content type of the payload the hash represents

-
-
-
TBD 3:
-
-

an identifier enabling a verifier to retrieve the full payload preimage.

-
-
-
-
-
-

-2.1. Signed Hash Envelopes Example -

-
-
-Hash_Envelope_Protected_Header = {
-    ; Cryptographic algorithm to use
-    ? &(alg: 1) => int,
-
-    ; Type of the envelope
-    ? &(typ: TBD_0) => int / tstr
-
-    ; Hash algorithm used to produce the payload from content
-    ; -16 for SHA-256,
-    ; See https://www.iana.org/assignments/cose/cose.xhtml
-    &(payload_hash_alg: TBD_1) => int
-
-    ; Content type of the preimage of the payload
-    ; 50 for application/json,
-    ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3
-    &(payload_preimage_content_type: TBD_2) => int
-
-    ; Identifier for an artifact repository
-    ; For example:
-    ; pkg:container...image@sha256:244f...9c?repo..._url=dev.example
-    ? &(artifact_repository: TBD) => tstr
-
-    ; Type of Verifiable Data Structure, e.g. RFC9162_SHA256
-    ; ? &(verifiable-data-structure: -111) => int,
-
-    ; additional parameters allows.
-
-}
-
-Verifiable_Data_Proofs = {
-  ? &(inclusion-proofs: -1) => [ bstr .cbor inclusion-proof ]
-  ? &(consistency-proofs: -2) => [ bstr .cbor consistency-proof ]
-  ; ... other proofs are allowed here.
-}
-
-Hash_Envelope_Unprotected_Header = {
-  ; ? &(verifiable-data-proofs: 222) => Verifiable_Data_Proofs
-  ; ... other unprotected header values are still allowed here.
-}
-
-Hash_Envelope_as_COSE_Sign1 = [
-    protected : bstr .cbor Hash_Envelope_Protected_Header,
-    unprotected : Hash_Envelope_Unprotected_Header,
-    payload: bstr / nil,
-    signature : bstr
-]
-
-Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1)
-
-
-
-
-
-
-

-2.2. Protected Header -

-

TBD 0 (typ), TBD 1 (payload hash alg) and TBD 2 (content type of the preimage of the payload) MUST be present in the protected header and MUST NOT be present in the unprotected header.

-

For example:

-
-
-{
-  / alg : ES384 / 1: -35,
-  / kid / 4: h'75726e3a...32636573',
-  / typ / TBD 0: application/hashed+cose
-  / payload_hash_alg sha-256 / TBD 1: 1
-  / payload_preimage_content_type / TBD 2: application/jwk+json
-  / artifact_repository / TBD 3 : \
-  pkg:container/image@sha256:244f...?repository_url=dev.example
-}
-
-
-

TBD 0 will be assigned by [I-D.ietf-cose-typ-header-parameter], it represents the content type of the code envelope, which includes the protected header and payload.

-

TBD 1 will be assigned by this draft. -TBD 2 will be assigned by this draft. -TBD 3 will be assigned by this draft.

-
-
-
-
-

-2.3. Attached Payload -

-

The payload MAY be attached.

-
-
-18(                                 / COSE Sign 1  /
-    [
-      h'a4013822...3a616263',       / Protected    /
-      {}                            / Unprotected  /
-      h'317cedc7...c494e772',       / Payload      /
-      h'15280897...93ef39e5'        / Signature    /
-    ]
-)
-
-
-
-
-
-
-

-2.4. Detached Payload -

-

The payload MAY be detached.

-
-
-18(                                 / COSE Sign 1      /
-    [
-      h'a4013822...3a616263',       / Protected        /
-      {}                            / Unprotected      /
-      nil,                          / Detached payload /
-      h'15280897...93ef39e5'        / Signature        /
-    ]
-)
-
-
-
-
-
-
-
-
-

-3. Encrypted Hashes -

-

Should we define this?

-
-
-
-
-

-4. Security Considerations -

-

TODO Security

-
-
-

-4.1. Choice of Hash Function -

-

It is RECOMMENDED to align the strength of the chosen hash function to the strength of the chosen signature algorithm. -For example, when signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the payload.

-
-
-
-
-
-
-

-5. IANA Considerations -

-
-
-

-5.1. COSE Header Algorithm Parameters -

-
    -
  • -

    Name: payload hash algorithm

    -
    • -
  • -

    Label: TBD_1

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: Hash algorithm used to produce the payload.

    -
    • -
-
-
-
-
-

-5.2. Named Information Hash Algorithm Registry -

-
    -
  • -

    Name: SHAKE256

    -
    • -
  • -

    Label: TBD_2

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: SHAKE256 a described in https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

    -
    • -
  • -

    Name: ASCON128

    -
    • -
  • -

    Label: TBD_3

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: ASCON128 a described in https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf

    -
    • -
-
-
-
-
-
-
-

-6. Normative References -

-
-
[I-D.ietf-cose-typ-header-parameter]
-
-Jones, M. B. and O. Steele, "COSE "typ" (type) Header Parameter", Work in Progress, Internet-Draft, draft-ietf-cose-typ-header-parameter-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-typ-header-parameter-05>.
-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC9052]
-
-Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
-
-
-
-
-
-
-

-Acknowledgments -

-

The following individuals provided input into the final form of the document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet.

-
-
-
-
-

-Authors' Addresses -

-
-
Orie Steele
-
Transmute
- -
-
-
Steve Lasker
-
DataTrails
- -
-
-
Henk Birkholz
-
Fraunhofer SIT
-
Rheinstrasse 75
-
-64295 Darmstadt -
-
Germany
- -
-
-
- - - diff --git a/steve/120-submission/draft-steele-cose-hash-envelope.txt b/steve/120-submission/draft-steele-cose-hash-envelope.txt deleted file mode 100644 index 8705c5d..0000000 --- a/steve/120-submission/draft-steele-cose-hash-envelope.txt +++ /dev/null @@ -1,337 +0,0 @@ - - - - -Network Working Group O. Steele -Internet-Draft Transmute -Intended status: Standards Track S. Lasker -Expires: 9 January 2025 DataTrails - H. Birkholz - Fraunhofer SIT - 8 July 2024 - - - COSE Hash Envelope - draft-steele-cose-hash-envelope-latest - -Abstract - - This document defines new COSE header parameters for signaling that a - payload is the output of a hash function. This mechanism enables - faster validation as access to the original payload is not required - for signature validation. Additionally, hints of the detached - payload's content format and availability are defined. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at - https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele- - cose-hash-envelope.html. Status information for this document may be - found at https://datatracker.ietf.org/doc/draft-steele-cose-hash- - envelope/. - - Discussion of this document takes place on the CBOR Object Signing - and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/. - - Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 9 January 2025. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Requirements Notation - 2. Header Parameters - 2.1. Signed Hash Envelopes Example - 2.2. Protected Header - 2.3. Attached Payload - 2.4. Detached Payload - 3. Encrypted Hashes - 4. Security Considerations - 4.1. Choice of Hash Function - 5. IANA Considerations - 5.1. COSE Header Algorithm Parameters - 5.2. Named Information Hash Algorithm Registry - 6. Normative References - Acknowledgments - Authors' Addresses - -1. Introduction - - COSE defined detached payloads in Section 2 of [RFC9052], using nil - as the payload. - - In order to verify a signature over a detached payload, the verifier - must have access to the payload content. Storing a hash of the - content allows for small signature envelopes, that are easy to - transport and verify independently. - - Additional hints in the protected header ensure cryptographic agility - for the hashing & signing algorithms, and discoverability for the - original content which could be prohibitively large to move over a - network. - -1.1. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -2. Header Parameters - - To represent a hash of a detached payload, the following headers are - defined: - - TBD 0: will be assigned by [I-D.ietf-cose-typ-header-parameter], - represents the content type of the code envelope, including the - protected header and payload - - TBD 1: the hash algorithm used to generate the hash of the payload - - TBD 2: the content type of the payload the hash represents - - TBD 3: an identifier enabling a verifier to retrieve the full - payload preimage. - -2.1. Signed Hash Envelopes Example - - Hash_Envelope_Protected_Header = { - ; Cryptographic algorithm to use - ? &(alg: 1) => int, - - ; Type of the envelope - ? &(typ: TBD_0) => int / tstr - - ; Hash algorithm used to produce the payload from content - ; -16 for SHA-256, - ; See https://www.iana.org/assignments/cose/cose.xhtml - &(payload_hash_alg: TBD_1) => int - - ; Content type of the preimage of the payload - ; 50 for application/json, - ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3 - &(payload_preimage_content_type: TBD_2) => int - - ; Identifier for an artifact repository - ; For example: - ; pkg:container...image@sha256:244f...9c?repo..._url=dev.example - ? &(artifact_repository: TBD) => tstr - - ; Type of Verifiable Data Structure, e.g. RFC9162_SHA256 - ; ? &(verifiable-data-structure: -111) => int, - - ; additional parameters allows. - - } - - Verifiable_Data_Proofs = { - ? &(inclusion-proofs: -1) => [ bstr .cbor inclusion-proof ] - ? &(consistency-proofs: -2) => [ bstr .cbor consistency-proof ] - ; ... other proofs are allowed here. - } - - Hash_Envelope_Unprotected_Header = { - ; ? &(verifiable-data-proofs: 222) => Verifiable_Data_Proofs - ; ... other unprotected header values are still allowed here. - } - - Hash_Envelope_as_COSE_Sign1 = [ - protected : bstr .cbor Hash_Envelope_Protected_Header, - unprotected : Hash_Envelope_Unprotected_Header, - payload: bstr / nil, - signature : bstr - ] - - Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1) - -2.2. Protected Header - - TBD 0 (typ), TBD 1 (payload hash alg) and TBD 2 (content type of the - preimage of the payload) MUST be present in the protected header and - MUST NOT be present in the unprotected header. - - For example: - - { - / alg : ES384 / 1: -35, - / kid / 4: h'75726e3a...32636573', - / typ / TBD 0: application/hashed+cose - / payload_hash_alg sha-256 / TBD 1: 1 - / payload_preimage_content_type / TBD 2: application/jwk+json - / artifact_repository / TBD 3 : \ - pkg:container/image@sha256:244f...?repository_url=dev.example - } - - TBD 0 will be assigned by [I-D.ietf-cose-typ-header-parameter], it - represents the content type of the code envelope, which includes the - protected header and payload. - - TBD 1 will be assigned by this draft. TBD 2 will be assigned by this - draft. TBD 3 will be assigned by this draft. - -2.3. Attached Payload - - The payload MAY be attached. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'317cedc7...c494e772', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -2.4. Detached Payload - - The payload MAY be detached. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - nil, / Detached payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -3. Encrypted Hashes - - Should we define this? - -4. Security Considerations - - TODO Security - -4.1. Choice of Hash Function - - It is RECOMMENDED to align the strength of the chosen hash function - to the strength of the chosen signature algorithm. For example, when - signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the - payload. - -5. IANA Considerations - -5.1. COSE Header Algorithm Parameters - - * Name: payload hash algorithm - - * Label: TBD_1 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: Hash algorithm used to produce the payload. - -5.2. Named Information Hash Algorithm Registry - - * Name: SHAKE256 - - * Label: TBD_2 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: SHAKE256 a described in - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf - - * Name: ASCON128 - - * Label: TBD_3 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: ASCON128 a described in - https://csrc.nist.gov/CSRC/media/Projects/lightweight- - cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf - -6. Normative References - - [I-D.ietf-cose-typ-header-parameter] - Jones, M. B. and O. Steele, "COSE "typ" (type) Header - Parameter", Work in Progress, Internet-Draft, draft-ietf- - cose-typ-header-parameter-05, 3 April 2024, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): - Structures and Process", STD 96, RFC 9052, - DOI 10.17487/RFC9052, August 2022, - . - -Acknowledgments - - The following individuals provided input into the final form of the - document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, - Cedric Fournet. - -Authors' Addresses - - Orie Steele - Transmute - Email: orie@transmute.industries - - - Steve Lasker - DataTrails - Email: steve.lasker@datatrails.ai - - - Henk Birkholz - Fraunhofer SIT - Rheinstrasse 75 - 64295 Darmstadt - Germany - Email: henk.birkholz@ietf.contact diff --git a/steve/120-submission/index.html b/steve/120-submission/index.html deleted file mode 100644 index 74790f6..0000000 --- a/steve/120-submission/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - OR13/draft-steele-cose-hash-envelope steve/120-submission preview - - - - -

Editor's drafts for steve/120-submission branch of OR13/draft-steele-cose-hash-envelope

- - - - - - -
COSE Hash Envelopeplain textsame as main
- - - diff --git a/steve/streamline/draft-steele-cose-hash-envelope.html b/steve/streamline/draft-steele-cose-hash-envelope.html deleted file mode 100644 index 3b56a02..0000000 --- a/steve/streamline/draft-steele-cose-hash-envelope.html +++ /dev/null @@ -1,1555 +0,0 @@ - - - - - - -COSE Hash Envelope - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftCOSE Hash EnvelopeJuly 2024
Steele, et al.Expires 7 January 2025[Page]
-
-
-
-
Workgroup:
-
Network Working Group
-
Internet-Draft:
-
draft-steele-cose-hash-envelope-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
O. Steele
-
Transmute
-
-
-
S. Lasker
-
DataTrails
-
-
-
H. Birkholz
-
Fraunhofer SIT
-
-
-
-
-

COSE Hash Envelope

-
-

Abstract

-

This document defines new COSE header parameters for signaling a payload as an output of a hash function. -This mechanism enables faster validation as access to the original payload is not required for signature validation. -Additionally, hints of the detached payload's content format and availability are defined providing references to optional discovery mechanisms that can help to find original payload content.

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- The latest revision of this draft can be found at https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele-cose-hash-envelope.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-cose-hash-envelope/.

-

- Discussion of this document takes place on the - CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/.

-

Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 7 January 2025.

-
-
- - -
-
-

-1. Introduction -

-

COSE defined detached payloads in Section 2 of [RFC9052], using nil as the payload. -In order to verify a signature over a detached payload, the verifier must have access to the payload content. -Storing a hash of the content allows for small signature envelopes, that are easy to transport and verify independently.

-

Additional hints in the protected header ensure cryptographic agility for the hashing & signing algorithms, and discoverability for the original content which could be prohibitively large to move over a network.

-
-
-

-1.1. Attached Payload -

-

COSE_sign1 envelope with an attached payload, providing for signature validation.

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      h'317cedc7...c494e772',       / Payload                       /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-

-1.2. Detached Payload -

-

COSE_sign1 envelope with a detached payload (nil), which is compact but the payload must be distributed out of band to validate the signature

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      nil,                          / Detached Payload              /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-

-1.3. Hashed Payload -

-

A hashed payload functions equivalently to an attached payload, with the benefits of being compact in size and providing the ability to validate the signature.

-
-
-18(                                 / COSE Sign 1                   /
-    [
-      h'a4013822...3a616263',       / Protected                     /
-      {}                            / Unprotected                   /
-      h'935b5a91...e18a588a',       / Payload                       /
-      h'15280897...93ef39e5'        / Signature                     /
-    ]
-)
-
-
-
-
-
-
-
-
-

-2. Header Parameters -

-

To represent a hash of a payload, the following headers are defined:

-
-
TBD_1:
-
-

the hash algorithm used to generate the hash of the payload

-
-
-
TBD_2:
-
-

the content type of the payload the hash represents

-
-
-
TBD_3:
-
-

an identifier enabling a verifier to retrieve the full payload preimage.

-
-
-
-
-
-

-2.1. Signed Hash Envelopes Example -

-
-
-Hash_Envelope_Protected_Header = {
-    ; Cryptographic algorithm to use
-    ? &(alg: 1) => int,
-
-    ; Type of the envelope
-    ? &(typ: 16) => int / tstr
-
-    ; Hash algorithm used to produce the payload from content
-    ; -16 for SHA-256,
-    ; See https://www.iana.org/assignments/cose/cose.xhtml
-    &(payload_hash_alg: TBD_1) => int
-
-    ; Content type of the preimage (content to be hashed) of the payload
-    ; 50 for application/json,
-    ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3
-    &(payload_preimage_content_type: TBD_2) => int
-
-    ; Location the content of the hashed payload is stored
-    ; For example:
-    ; storage.example/244f...9c19
-    ? &(payload_location: TBD_3) => tstr
-
-    * int => any
-}
-
-Hash_Envelope_Unprotected_Header = {
-    * int => any
-}
-
-Hash_Envelope_as_COSE_Sign1 = [
-    protected : bstr .cbor Hash_Envelope_Protected_Header,
-    unprotected : Hash_Envelope_Unprotected_Header,
-    payload: bstr / nil,
-    signature : bstr
-]
-
-Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1)
-
-
-
-
-
-
-

-2.2. Protected Header -

-

16 (typ), TBD_1 (payload hash alg) and TBD_2 (content type of the preimage of the payload) MUST be present in the protected header and MUST NOT be present in the unprotected header. -TBD_3 (payload_location) MAY be added to the protected header and MUST NOT be presented in the unprotected header.

-

For example:

-
-
-{
-  / alg : ES384 / 1: -35,
-  / kid / 4: h'75726e3a...32636573',
-  / typ / 16: application/hashed+cose
-  / payload_hash_alg sha-256 / TBD_1: 1
-  / payload_preimage_content_type / TBD_2: application/jwk+json
-  / payload_location / TBD_3 : storage.example/244f...9c19
-}
-
-
-
-
-
-
-
-
-

-3. Encrypted Hashes -

-

Should we define this?

-
-
-
-
-

-4. Security Considerations -

-

TODO Security

-
-
-

-4.1. Choice of Hash Function -

-

It is RECOMMENDED to align the strength of the chosen hash function to the strength of the chosen signature algorithm. -For example, when signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the payload.

-
-
-
-
-
-
-

-5. IANA Considerations -

-
-
-

-5.1. Requirements Notation -

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", -"MAY", and "OPTIONAL" in this document are to be interpreted as -described in BCP 14 [RFC2119] [RFC8174] when, and only when, they -appear in all capitals, as shown here.

-
-
-
-
-

-5.2. COSE Header Algorithm Parameters -

-
    -
  • -

    Name: payload hash algorithm

    -
    • -
  • -

    Label: TBD_1

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: Hash algorithm used to produce the payload.

    -
    • -
-
-
-
-
-

-5.3. Named Information Hash Algorithm Registry -

-
    -
  • -

    Name: SHAKE256

    -
    • -
  • -

    Label: TBD_2

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: SHAKE256 a described in https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

    -
    • -
  • -

    Name: ASCON128

    -
    • -
  • -

    Label: TBD_3

    -
    • -
  • -

    Value type: int

    -
    • -
  • -

    Value registry: https://www.iana.org/assignments/named-information/named-information.xhtml

    -
    • -
  • -

    Description: ASCON128 a described in https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf

    -
    • -
-
-
-
-
-
-
-

-6. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC9052]
-
-Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
-
-
[RFC9596]
-
-Jones, M.B. and O. Steele, "CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter", RFC 9596, DOI 10.17487/RFC9596, , <https://www.rfc-editor.org/rfc/rfc9596>.
-
-
-
-
-
-
-

-Acknowledgments -

-

The following individuals provided input into the final form of the document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet.

-
-
-
-
-

-Authors' Addresses -

-
-
Orie Steele
-
Transmute
- -
-
-
Steve Lasker
-
DataTrails
- -
-
-
Henk Birkholz
-
Fraunhofer SIT
-
Rheinstrasse 75
-
-64295 Darmstadt -
-
Germany
- -
-
-
- - - diff --git a/steve/streamline/draft-steele-cose-hash-envelope.txt b/steve/streamline/draft-steele-cose-hash-envelope.txt deleted file mode 100644 index ce4c8bb..0000000 --- a/steve/streamline/draft-steele-cose-hash-envelope.txt +++ /dev/null @@ -1,332 +0,0 @@ - - - - -Network Working Group O. Steele -Internet-Draft Transmute -Intended status: Standards Track S. Lasker -Expires: 7 January 2025 DataTrails - H. Birkholz - Fraunhofer SIT - 6 July 2024 - - - COSE Hash Envelope - draft-steele-cose-hash-envelope-latest - -Abstract - - This document defines new COSE header parameters for signaling a - payload as an output of a hash function. This mechanism enables - faster validation as access to the original payload is not required - for signature validation. Additionally, hints of the detached - payload's content format and availability are defined providing - references to optional discovery mechanisms that can help to find - original payload content. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at - https://OR13.github.io/draft-steele-cose-hash-envelope/draft-steele- - cose-hash-envelope.html. Status information for this document may be - found at https://datatracker.ietf.org/doc/draft-steele-cose-hash- - envelope/. - - Discussion of this document takes place on the CBOR Object Signing - and Encryption Working Group mailing list (mailto:cose@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/cose/. - Subscribe at https://www.ietf.org/mailman/listinfo/cose/. - - Source for this draft and an issue tracker can be found at - https://github.com/OR13/draft-steele-cose-hash-envelope. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 7 January 2025. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Attached Payload - 1.2. Detached Payload - 1.3. Hashed Payload - 2. Header Parameters - 2.1. Signed Hash Envelopes Example - 2.2. Protected Header - 3. Encrypted Hashes - 4. Security Considerations - 4.1. Choice of Hash Function - 5. IANA Considerations - 5.1. Requirements Notation - 5.2. COSE Header Algorithm Parameters - 5.3. Named Information Hash Algorithm Registry - 6. Normative References - Acknowledgments - Authors' Addresses - -1. Introduction - - COSE defined detached payloads in Section 2 of [RFC9052], using nil - as the payload. In order to verify a signature over a detached - payload, the verifier must have access to the payload content. - Storing a hash of the content allows for small signature envelopes, - that are easy to transport and verify independently. - - Additional hints in the protected header ensure cryptographic agility - for the hashing & signing algorithms, and discoverability for the - original content which could be prohibitively large to move over a - network. - -1.1. Attached Payload - - COSE_sign1 envelope with an attached payload, providing for signature - validation. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'317cedc7...c494e772', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.2. Detached Payload - - COSE_sign1 envelope with a detached payload (nil), which is compact - but the payload must be distributed out of band to validate the - signature - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - nil, / Detached Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -1.3. Hashed Payload - - A hashed payload functions equivalently to an attached payload, with - the benefits of being compact in size and providing the ability to - validate the signature. - - 18( / COSE Sign 1 / - [ - h'a4013822...3a616263', / Protected / - {} / Unprotected / - h'935b5a91...e18a588a', / Payload / - h'15280897...93ef39e5' / Signature / - ] - ) - -2. Header Parameters - - To represent a hash of a payload, the following headers are defined: - - TBD_1: the hash algorithm used to generate the hash of the payload - - TBD_2: the content type of the payload the hash represents - - TBD_3: an identifier enabling a verifier to retrieve the full - payload preimage. - -2.1. Signed Hash Envelopes Example - - Hash_Envelope_Protected_Header = { - ; Cryptographic algorithm to use - ? &(alg: 1) => int, - - ; Type of the envelope - ? &(typ: 16) => int / tstr - - ; Hash algorithm used to produce the payload from content - ; -16 for SHA-256, - ; See https://www.iana.org/assignments/cose/cose.xhtml - &(payload_hash_alg: TBD_1) => int - - ; Content type of the preimage (content to be hashed) of the payload - ; 50 for application/json, - ; See https://datatracker.ietf.org/doc/html/rfc7252#section-12.3 - &(payload_preimage_content_type: TBD_2) => int - - ; Location the content of the hashed payload is stored - ; For example: - ; storage.example/244f...9c19 - ? &(payload_location: TBD_3) => tstr - - * int => any - } - - Hash_Envelope_Unprotected_Header = { - * int => any - } - - Hash_Envelope_as_COSE_Sign1 = [ - protected : bstr .cbor Hash_Envelope_Protected_Header, - unprotected : Hash_Envelope_Unprotected_Header, - payload: bstr / nil, - signature : bstr - ] - - Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1) - -2.2. Protected Header - - 16 (typ), TBD_1 (payload hash alg) and TBD_2 (content type of the - preimage of the payload) MUST be present in the protected header and - MUST NOT be present in the unprotected header. TBD_3 - (payload_location) MAY be added to the protected header and MUST NOT - be presented in the unprotected header. - - For example: - - { - / alg : ES384 / 1: -35, - / kid / 4: h'75726e3a...32636573', - / typ / 16: application/hashed+cose - / payload_hash_alg sha-256 / TBD_1: 1 - / payload_preimage_content_type / TBD_2: application/jwk+json - / payload_location / TBD_3 : storage.example/244f...9c19 - } - -3. Encrypted Hashes - - Should we define this? - -4. Security Considerations - - TODO Security - -4.1. Choice of Hash Function - - It is RECOMMENDED to align the strength of the chosen hash function - to the strength of the chosen signature algorithm. For example, when - signing with ECDSA using P-256 and SHA-256, use SHA-256 to hash the - payload. - -5. IANA Considerations - -5.1. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -5.2. COSE Header Algorithm Parameters - - * Name: payload hash algorithm - - * Label: TBD_1 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: Hash algorithm used to produce the payload. - -5.3. Named Information Hash Algorithm Registry - - * Name: SHAKE256 - - * Label: TBD_2 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: SHAKE256 a described in - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf - - * Name: ASCON128 - - * Label: TBD_3 - - * Value type: int - - * Value registry: https://www.iana.org/assignments/named- - information/named-information.xhtml - - * Description: ASCON128 a described in - https://csrc.nist.gov/CSRC/media/Projects/lightweight- - cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): - Structures and Process", STD 96, RFC 9052, - DOI 10.17487/RFC9052, August 2022, - . - - [RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and - Encryption (COSE) "typ" (type) Header Parameter", - RFC 9596, DOI 10.17487/RFC9596, June 2024, - . - -Acknowledgments - - The following individuals provided input into the final form of the - document: Carsten Bormann, Henk Birkholz, Antoine Delignat-Lavaud, - Cedric Fournet. - -Authors' Addresses - - Orie Steele - Transmute - Email: orie@transmute.industries - - - Steve Lasker - DataTrails - Email: steve.lasker@datatrails.ai - - - Henk Birkholz - Fraunhofer SIT - Rheinstrasse 75 - 64295 Darmstadt - Germany - Email: henk.birkholz@ietf.contact diff --git a/steve/streamline/index.html b/steve/streamline/index.html deleted file mode 100644 index b5ed374..0000000 --- a/steve/streamline/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - OR13/draft-steele-cose-hash-envelope steve/streamline preview - - - - -

Editor's drafts for steve/streamline branch of OR13/draft-steele-cose-hash-envelope

- - - - - - -
COSE Hash Envelopeplain textsame as main
- - -