[auth48] Re: Final review in markdown: RFC-to-be 9995 draft-ietf-cose-hash-envelope for your review

[Orie <[e-mail]>]

Hi,

Thank you for the work on this document!
Inline for the rest:


On Tue, May 26, 2026 at 11:56 AM Megan Ferguson <
[e-mail]> wrote:

> Just resending to add Steve’s preferred email to the thread.
>
> > On May 20, 2026, at 8:39 PM, [e-mail] wrote:
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the source file.
> >
> > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
> >
> >
> > 2) <!--[rfced] Please review and confirm this suggested update maintains
> > your intended meaning:
> >
> > Original:
> > COSE defined detached payloads in Section 2 of [RFC9052], using nil as
> > the payload.
> >
> > Perhaps:
> > Section 2 of [RFC9052] defines detached payloads for COSE, using nil
> > as the payload.  -->
> >


I prefer your edit to the original here.


>
> >
> > 3) <!--[rfced] Please review our update to add a comma at the end of a
> line in the CDDL:
> >
> > Original:
> > &(payload_hash_alg: 258) => int
> >
> > Current:
> > &(payload_hash_alg: 258) => int,
> >
> > -->
> >


I prefer the comma, though I will admit I have lost track of CDDL best
practices for this... @Henk Birkholz <[e-mail]> ?


>
> >
> > 4) <!--[rfced] Please review our updates to the following text to ensure
> > we have maintained your intended meaning:
> >
> > Original:
> >   For example, when the actual content is a bstr, a Verifier appraising
> >   a content-type bstr has to decide if that bstr describes the digest
> >   bytes or the preimage bytes.  Setting preimage-content-type to bstr,
> >   makes it clear that the preimage bytes themselves were a bstr.
> >
> > Current:
> >   For example, when the actual content is a byte string (bstr), a
> >   verifier appraising the payload has to decide whether that bstr
> >   represents the digest bytes or the preimage bytes.  Setting
> >   payload_preimage_content_type to bstr makes it clear that the
> >   preimage bytes themselves were a bstr.
> >


Current looks good to me.


>
> > -->
> >
> >
> > 5) <!-- [rfced] We updated the URL for application/spdx+json as shown
> below, as the original was 404. Please review and let us know if any
> corrections are needed.
> >
> > Original: https://www.iana.org/assignments/media-types/application/spdx+
> > current:
> https://www.iana.org/assignments/media-types/application/spdx+json
> > -->
> >


Thanks for correcting!


>
> >
> > 6) <!--[rfced] Using "the" before manifest.spdx.json makes it feel like a
> > label is missing.  Please review.
> >
> > Original:
> >   The payload of this COSE_Sign1 is the SHA256 hash of the
> >   manifest.spdx.json.
> >
> > -->
> >


"the" could be removed here I think.


>
> >
> > 7) <!--[rfced] Please review if internet should be Internet here:
> >
> > Original:
> >   Verifiers that do not have access to the internet and obtain the
> >   preimage via other means will not be able to perform that check, nor
> >   to derive utility from it.
> > -->
>

I think it can remain lower case here.


> >
> >
> > 8) <!-- [rfced] We updated the "Value Registry" column of table 1 to
> include references to "CoAP Content-Formats" and "COSE Algorithms".  Please
> review and let us know any concerns.  The references have been added as
> informative references.
> >
> > Because we added a reference to the COSE Algorithms registry, we also
> replaced the URL below with an in text citation.  Please review.
> >
> > Original:
> >   Note that when using a pre-hash
> >   algorithm, the algorithm MUST be registered in the IANA COSE
>
> >   Algorithms registry (https://www.iana.org/assignments/cose/
>
> >   cose.xhtml#algorithms), and MUST be distinguishable from non-pre hash
>
> >   variants that may also be present.
> >
> > Current:
> >   Note that, when using a pre-hash algorithm,
> >   the algorithm MUST be registered in the IANA "COSE Algorithms"
> >   registry [COSE-Algorithms] and MUST be distinguishable from non-pre-
> >   hash variants that may also be present.
> > -->
>

Looks good to me.


> >
> >
> > 9) <!--[rfced] Please review the following possible inconsistencies with
> regard to terminology:
> >
> > COSE_MAC vs. COSE_Mac
> > SHA-256 vs. SHA256
> > SHA-384 vs. SHA384
> > -->
>

It must be "COSE_Mac" and  "SHA-256".

>
> >
> > 10) <!--[rfced] We had the following questions related to abbreviation
> use in the document:
> >
> > a) Please note that we have expanded abbreviations on first use.
> > Please review for accuracy.
> >
> > b) Would you like to expand SPDX as "System Package Data Exchange" on
> > first use?  -->
> >


No, but expanded as "Software Package Data Exchange" seems like a good
idea: https://en.wikipedia.org/wiki/Software_Package_Data_Exchange


> >
> > 11) <!--[rfced] In the response to our intake form, we saw:
> >
> > We only use ` ... I suspect we might be better off using " for a few
> > values instead of `, and reserve ` for highlighting code points and
> > not examples.
> >
> > Please let us know if/how updates should be made using Old/New and/or
> > by updating the edited file directly. -->
> >


Lets address this at the end, to avoid chatter, I'm not attached to making
any changes here, just called it out during intake.


>
> >
> > Thank you.
> > Megan Ferguson and Sandy Ginoza
> > RFC Production Center
> >
> >
> >
> >
> > On May 20, 2026, at 4:20 PM, [e-mail] wrote:
> >
> > RFC Author(s):
> >
> > Your document is now ready for Final Review (previously AUTH48).
> >
> > The document was edited in kramdown-rfc as part of the RPC pilot test
> (see
> > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc)
>
> >
> > Please review the procedures for your review using kramdown-rfc:
> >
> >
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
> >
> > Once the review is complete, it will be published as an RFC.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >  https://www.rfc-editor.org/authors/rfc9995.md
> >  https://www.rfc-editor.org/authors/rfc9995.html
> >  https://www.rfc-editor.org/authors/rfc9995.pdf
> >  https://www.rfc-editor.org/authors/rfc9995.txt
> >
> > Diff file of the text:
> >  https://www.rfc-editor.org/authors/rfc9995-diff.html
> >  https://www.rfc-editor.org/authors/rfc9995-rfcdiff.html (side by side)
> >
> > Diff of the kramdown:
> >  https://www.rfc-editor.org/authors/rfc9995-md-diff.html
> >  https://www.rfc-editor.org/authors/rfc9995-md-rfcdiff.html (side by
> side)
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> > https://www.rfc-editor.org/auth48/rfc9995
> >
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC 9995 (draft-ietf-cose-hash-envelope)
> >
> > Title            : COSE Hash Envelope
> > Author(s)        : O. Steele,
> >                  S. Lasker,
> >                  H. Birkholz
> > WG Chair(s)      : Ivaylo Petrov, Michael Jones
> > Area Director(s) : Deb Cooley, Christopher Inacio
> >
>
>