Formatting and spec clarity updates

[SteveLasker]

Adding a bit more formatting and clarity to the spec

[OR13]

I think the intro still needs some work

[SteveLasker]

Yeah, this was a rough update that I wanted to save before wrapping up for the day.
I'll have more time tomorrow

[SteveLasker]

I changed the date to fix some kramdown warnings. Your call to revert, keep, change
PR is now ready and passes kramdown tests.

Ultimately, we need to decide how we want to handle "Too long lines..." for CDDL.

[JeromySt]

Is there a reason that special COSE headers and specification are warranted rather than simply following the guidance from RFC9054? One could use the COSE_Hash_V structure easily enough within the embedded payload of a COSE message. The arguments put forth in RFC9054 still hold true.

Another question that comes to mind is that hashing of content to represent and indirect immutable key for the original content isn't a unique COSE issue. As such might it be possible to consider a content-type extension approach in which the content-type can be augmented with something such as +hash_sha256 to represent the .Content is in-fact a hash of the original content/type without needing any new headers? Of course, this means we lose some of the application specific fields such as location and others proposed here, but we're left with a generic answer to a generic problem verse a COSE specific implementation.

[OR13]

COSE_Hash_V = (
    1 : int / tstr, # Algorithm identifier
    2 : bstr, # Hash value
    ? 3 : tstr, # Location of object that was hashed
    ? 4 : any   # object containing other details and things
    )

• https://www.rfc-editor.org/rfc/rfc9054.html#section-2.1

Is there a reason that special COSE headers and specification are warranted rather than simply following the guidance from RFC9054?

The main reasons is integrity protection, and being able to swap detached payload of hash of content for detached payload of content, in protocol messages that require COSE Sign 1.

If ? 4 : any # object containing other details and things can be any object, then its totally possible we could simply put a cose sign 1 with detached payload there, but the structure of the signed statement would then become an OR type of special kinds of COSE_Hash_V and special kinds of COSE Sign 1.

I do think its awkward that we can't directly use COSE_Hash_V in COSE sign 1 headers, perhaps registering a single header that is a COSE_Hash_V or set of COSE_Hash_V is a better approach?

[OR13]

As such might it be possible to consider a content-type extension approach in which the content-type can be augmented with something such as +hash_sha256

This would mean registering a new structured suffix for every hash algorithm?

I think if we can, we should avoid creating new media types.

We might be able to encode content type of the preimage in:

? 3 : tstr, # Location of object that was hashed
? 4 : any   # object containing other details and things