COSE Hash Envelope
draft-ietf-cose-hash-envelope-10

[Ballot comment]
Thanks for the work done in this document. I have some comments about

### Section 5.1

`the algorithm SHOULD be registered in the IANA COSE Algorithms registry, and should be distinguishable from non-pre hash variants that may also be present.`

Is there any reason why the first SHOULD is marked as BCP14 and not the second one ?

In which case can the first SHOULD be ignored ?

Please provide a URI for the "IANA COSE Algorithms registry"

[Ballot comment]
The example at https://www.ietf.org/archive/id/draft-ietf-cose-hash-envelope-08.html#section-4.1 appears to repeat at least one element, about the generation of the hash as an adjacent file. Is this file at all relevant to the example, despite being mentioned twice? It seems as if the only relevant piece is that this *is* the hash of the source file.

NIT: Section 5.3, "Verifiers that not have" => "Verifiers that do not have"

[Ballot comment]
Thanks to Yaron Sheffer for his secdir review.  I think many of his comments should be incorporated, I can't see that it has happened yet.

Section 5.1:  Currently you recommend that the strength of all the algorithm components is what I call 'matchy matchy', but that isn't always necessary.  I would change this to something like:  'The hash/signature algorithm combination is *RECOMMENDED to be equal or stronger than the payload hash algorithm.'  For example, if the payload is hashed with SHA 512, but the hash/signature algorithm is P256 w/ SHA 256, then the strength of the whole thing is basically equivalent to P256 w/ SHA 256, not ideal.

[Ballot comment]
Hi Orie, Steve, and Henk,

Thank you for the effort put into this document.

I have only very few nits that I submitted as a PR using the WG Github repo [1].

Cheers,
Med

[1] https://github.com/cose-wg/draft-ietf-cose-hash-envelope/pull/58/files

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cose-hash-envelope-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the COSE Header Parameters registry in the CBOR Object Signing and Encryption (COSE) registry group located at:

https://www.iana.org/assignments/cose/

three early registrations will have their references changed to [ RFC-to-be; Section 3 ] as follows:

Name: payload-hash-alg
Label: 258
Value Type: int
Value Registry: [COSE Algorithms] registry
Description: The hash algorithm used to produce the payload of a COSE_Sign1
Reference: [ RFC-to-be; Section 3 ]

Name: preimage-content-type
Label: 259
Value Type: uint / tstr
Value Registry: [CoAP Content-Formats] registry
Description: The content-format number or content-type (media-type name) of data that has been hashed to produce the payload of the COSE_Sign1
Reference: [ RFC-to-be; Section 3 ]

Name: payload-location
Label: 260
Value Type: tstr
Value Registry:
Description: The string or URI hint for the location of the data hashed to produce the payload of a COSE_Sign1
Reference: [ RFC-to-be; Section 3 ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-10-10):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-hash-envelope@ietf.org, jon.geater@gmail.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (COSE Hash Envelope) to Proposed Standard


The IESG has received a request from the CBOR Object Signing and Encryption
WG (cose) to consider the following document: - 'COSE Hash Envelope'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-10-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/

No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for [COSE Hash Envelope](https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/)

## Document History

### 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there?

No. Although it was discussed with members of the SCITT WG it was always seen
as appropriate for the more generally useful layer of COSE.

### 2. Was there controversy about particular points that caused the WG to not adopt the document?

No.

### 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

_If so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)_

No.

### 4. For protocol documents, are there existing implementations of the contents of the document?

_Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere, either
in the document itself (as RFC 7942 recommends) or elsewhere (where)?_

This is not a protocol document. However, I am aware that at least 2
implementations exist, from DataTrails and Microsoft.

## Additional Reviews

### 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations

_Would it therefore benefit from their review? Have those reviews occurred?
If yes, describe which reviews took place._

The document is foundational to certain use cases of SCITT, and I considered
that it might also be useful to RATS. I canvassed both WGs for feedback.

No particular feedback was given by RATS, but the SCITT WG expressed very
positive views.

### 6. Describe how the document meets any required formal expert review criteria

_Such as the MIB Doctor, YANG Doctor, media type, and URI type reviews._

The document contains a request for 3 COSE Header Parameters.

### 7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation?

The document does not contain a YANG module.

### 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language

I have taken the CDDL from the document (after the small change from v5 to v6) and successfully validated and generated examples using Hannes Kimara's CDDLC golang tooling.

## Document Shepherd Checks

### 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

The shepherd believes that the document is needed, clearly written, complete
and correctly designed. Subject to clarification of the CDDL issues it is
ready to be handed off to the responsible Area Director.

### 10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

The document has been presented and discussed at multiple IETF meetings
and had protracted discussions around hash algorithm selection and
operator ordering. I believe these have all been settled.

### 11. What type of RFC publication is being requested on the IETF stream

_Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?_

The intended type is Proposed Standard, because the document describes a data
format for the purpose of interoperability, and uses BCP14 language.
Implementations have moved past the experimental stage. The Datatracker does
reflect the correct RFC status.

### 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79?

_To the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable._

I have obtained confirmation by email from all authors that they have fulfilled
their IPR disclosure obligations, and also asked the WG list for more general
input. To the best of my knowledge, no disclosure is necessary for this
document.

### 13. Has each author, editor, and contributor shown their willingness to be listed as such?

Yes.

### 14. Document any remaining I-D nits in this document.

_Simply running the idnits tool is not enough; please review the
"Content Guidelines" on authors.ietf.org. (Also note that the current
idnits tool generates some incorrect warnings; a rewrite is underway.)_

`idnits` reports:
`Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).`

Both warnings appear to be erroneous.

One comment refers to an out-of-date reference which seems harmless.

From a content guidelines perspective the document is mostly good. It is
correctly named, structured, and contains the required content. I note one
deviation from the recommendations of the Content Guidelines, in that the
author contact emails are all work emails, which are not stable over time.
Indeed, for 2 of the 3 authors those addresses were correct at the time of
writing but no longer are.

### 15. Should any informative references be normative or vice-versa?

No.

### 16. List any normative references that are not freely available to anyone.

_Did the community have sufficient access to review any such normative
references?_

All normative references have been freely available for a long time.

### 17. Are there any normative downward references that are not already listed in the DOWNREF registry?

There are no normative downward references in this document.

### 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?

No.

### 19. Will publication of this document change the status of any existing RFCs?

_If so, does the Datatracker metadata correctly reflect this and are those
RFCs listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed._

The publication of this document will not change the status of any existing
RFCs.

### 20. Describe the document shepherd's review of the IANA considerations section

_Especially with regard to its consistency with the body of the document._

_Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126)._

The document clearly identifies its ask to IANA for new COSE Header Params.
The request is necessary and minimal, and does not establish a new registry.

### 21. List any new IANA registries that require Designated Expert Review for future allocations.

_Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate._

There are no new registries.

# Shepherd Writeup for [COSE Hash Envelope](https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/)

## Document History

### 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there?

No. Although it was discussed with members of the SCITT WG it was always seen
as appropriate for the more generally useful layer of COSE.

### 2. Was there controversy about particular points that caused the WG to not adopt the document?

No.

### 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

_If so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)_

No.

### 4. For protocol documents, are there existing implementations of the contents of the document?

_Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere, either
in the document itself (as RFC 7942 recommends) or elsewhere (where)?_

This is not a protocol document. However, I am aware that at least 2
implementations exist, from DataTrails and Microsoft.

## Additional Reviews

### 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations

_Would it therefore benefit from their review? Have those reviews occurred?
If yes, describe which reviews took place._

The document is foundational to certain use cases of SCITT, and I considered
that it might also be useful to RATS. I canvassed both WGs for feedback.

No particular feedback was given by RATS, but the SCITT WG expressed very
positive views.

### 6. Describe how the document meets any required formal expert review criteria

_Such as the MIB Doctor, YANG Doctor, media type, and URI type reviews._

The document contains a request for 3 COSE Header Parameters.

### 7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation?

The document does not contain a YANG module.

### 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language

I have taken the CDDL from the document (after the small change from v5 to v6) and successfully validated and generated examples using Hannes Kimara's CDDLC golang tooling.

## Document Shepherd Checks

### 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

The shepherd believes that the document is needed, clearly written, complete
and correctly designed. Subject to clarification of the CDDL issues it is
ready to be handed off to the responsible Area Director.

### 10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

The document has been presented and discussed at multiple IETF meetings
and had protracted discussions around hash algorithm selection and
operator ordering. I believe these have all been settled.

### 11. What type of RFC publication is being requested on the IETF stream

_Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?_

The intended type is Proposed Standard, because the document describes a data
format for the purpose of interoperability, and uses BCP14 language.
Implementations have moved past the experimental stage. The Datatracker does
reflect the correct RFC status.

### 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79?

_To the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable._

I have obtained confirmation by email from all authors that they have fulfilled
their IPR disclosure obligations, and also asked the WG list for more general
input. To the best of my knowledge, no disclosure is necessary for this
document.

### 13. Has each author, editor, and contributor shown their willingness to be listed as such?

Yes.

### 14. Document any remaining I-D nits in this document.

_Simply running the idnits tool is not enough; please review the
"Content Guidelines" on authors.ietf.org. (Also note that the current
idnits tool generates some incorrect warnings; a rewrite is underway.)_

`idnits` reports:
`Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).`

Both warnings appear to be erroneous.

One comment refers to an out-of-date reference which seems harmless.

From a content guidelines perspective the document is mostly good. It is
correctly named, structured, and contains the required content. I note one
deviation from the recommendations of the Content Guidelines, in that the
author contact emails are all work emails, which are not stable over time.
Indeed, for 2 of the 3 authors those addresses were correct at the time of
writing but no longer are.

### 15. Should any informative references be normative or vice-versa?

No.

### 16. List any normative references that are not freely available to anyone.

_Did the community have sufficient access to review any such normative
references?_

All normative references have been freely available for a long time.

### 17. Are there any normative downward references that are not already listed in the DOWNREF registry?

There are no normative downward references in this document.

### 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?

No.

### 19. Will publication of this document change the status of any existing RFCs?

_If so, does the Datatracker metadata correctly reflect this and are those
RFCs listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed._

The publication of this document will not change the status of any existing
RFCs.

### 20. Describe the document shepherd's review of the IANA considerations section

_Especially with regard to its consistency with the body of the document._

_Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126)._

The document clearly identifies its ask to IANA for new COSE Header Params.
The request is necessary and minimal, and does not establish a new registry.

### 21. List any new IANA registries that require Designated Expert Review for future allocations.

_Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate._

There are no new registries.

# Shepherd Writeup for [COSE Hash Envelope](https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/)

## Document History

### 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there?

No. Although it was discussed with members of the SCITT WG it was always seen
as appropriate for the more generally useful layer of COSE.

### 2. Was there controversy about particular points that caused the WG to not adopt the document?

No.

### 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

_If so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)_

No.

### 4. For protocol documents, are there existing implementations of the contents of the document?

_Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere, either
in the document itself (as RFC 7942 recommends) or elsewhere (where)?_

This is not a protocol document. However, I am aware that at least 2
implementations exist, from DataTrails and Microsoft.

## Additional Reviews

### 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations

_Would it therefore benefit from their review? Have those reviews occurred?
If yes, describe which reviews took place._

The document is foundational to certain use cases of SCITT, and I considered
that it might also be useful to RATS. I canvassed both WGs for feedback.

No particular feedback was given by RATS, but the SCITT WG expressed very
positive views.

### 6. Describe how the document meets any required formal expert review criteria

_Such as the MIB Doctor, YANG Doctor, media type, and URI type reviews._

The document contains a request for 3 COSE Header Parameters.

### 7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation?

The document does not contain a YANG module.

### 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language

I tried validating the CDDL with 2 tools:
  * Hannes Kimara's CDDLC golang tooling
  * Christian Bromann's CDDL javacript tooling

Both throw up significant errors. Given that there are at least 2 successful
implementations of this document that is confusing, but not unheard of.

I have reached out to the authors to see if I missed anything obvious.

## Document Shepherd Checks

### 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

The shepherd believes that the document is needed, clearly written, complete
and correctly designed. Subject to clarification of the CDDL issues it is
ready to be handed off to the responsible Area Director.

### 10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

The document has been presented and discussed at multiple IETF meetings
and had protracted discussions around hash algorithm selection and
operator ordering. I believe these have all been settled.

### 11. What type of RFC publication is being requested on the IETF stream

_Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?_

The intended type is Proposed Standard, because the document describes a data
format for the purpose of interoperability, and uses BCP14 language.
Implementations have moved past the experimental stage. The Datatracker does
reflect the correct RFC status.

### 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79?

_To the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable._

I have obtained confirmation by email from all authors that they have fulfilled
their IPR disclosure obligations, and also asked the WG list for more general
input. To the best of my knowledge, no disclosure is necessary for this
document.

### 13. Has each author, editor, and contributor shown their willingness to be listed as such?

Yes.

### 14. Document any remaining I-D nits in this document.

_Simply running the idnits tool is not enough; please review the
"Content Guidelines" on authors.ietf.org. (Also note that the current
idnits tool generates some incorrect warnings; a rewrite is underway.)_

`idnits` reports:
`Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).`

Both warnings appear to be erroneous.

One comment refers to an out-of-date reference which seems harmless.

From a content guidelines perspective the document is mostly good. It is
correctly named, structured, and contains the required content. I note one
deviation from the recommendations of the Content Guidelines, in that the
author contact emails are all work emails, which are not stable over time.
Indeed, for 2 of the 3 authors those addresses were correct at the time of
writing but no longer are.

### 15. Should any informative references be normative or vice-versa?

No.

### 16. List any normative references that are not freely available to anyone.

_Did the community have sufficient access to review any such normative
references?_

All normative references have been freely available for a long time.

### 17. Are there any normative downward references that are not already listed in the DOWNREF registry?

There are no normative downward references in this document.

### 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?

No.

### 19. Will publication of this document change the status of any existing RFCs?

_If so, does the Datatracker metadata correctly reflect this and are those
RFCs listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed._

The publication of this document will not change the status of any existing
RFCs.

### 20. Describe the document shepherd's review of the IANA considerations section

_Especially with regard to its consistency with the body of the document._

_Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126)._

The document clearly identifies its ask to IANA for new COSE Header Params.
The request is necessary and minimal, and does not establish a new registry.

### 21. List any new IANA registries that require Designated Expert Review for future allocations.

_Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate._

There are no new registries.