Consider using multiformats (multihash) for future proofing

ioggstream / draft-polli-resource-digests-http

THIS REPO WAS MOVED TO https://github.com/httpwg/http-extensions/

https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html

Other

0 stars 1 forks source link

Consider using multiformats (multihash) for future proofing #39

Open dlongley opened 5 years ago

dlongley commented 5 years ago

I think defining a parameter that allows the digest algorithm to be specified using a multihash. This would eliminate the need to maintain a separate registry for hash algorithms and could better future proof the spec. See: an ietf draft spec, multiformats, multihash.

There may also be some synergy here with hashlinks.

ioggstream commented 5 years ago

I read the I-D briefly. Could we just define a mhash digest-algorithm like the following and leave the mhash parser in charge of decoding?

Digest: mhash=0x132052eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4

dlongley commented 5 years ago

@ioggstream,

Could we just define a mhash digest-algorithm like the following and leave the mhash parser in charge of decoding?

Yeah, I think that's the way to go.

LPardue commented 5 years ago

I see this as out of scope for an update document because it adds a new feature. The digest-algorithm could be spaced in a separate document

dlongley commented 5 years ago

I see this as out of scope for an update document because it adds a new feature. The digest-algorithm could be spaced in a separate document

This update document registers new algorithm IDs for SHA-256 and SHA-512. Why would mhash be out of scope but those would not be?

ioggstream commented 5 years ago

@dlongley if I understand correctly @LPardue:

the goal for this spec is to obsolete and replace RFC3230;
we hope to go RFC in a very short time because RFC3230 is inconsistent with the current HTTP spec.;
to do this we should avoid to reference other I-D;
we added id-sha* to allow implementations that are not taking into account content-coding to acknowledge they mis-interpreted the concept of instance presented in rfc3230 without having to reimplement everything (they should just prefix their digest-algorithm with id-).

If the mhash solution I proposed above could work (we can discuss this in this thread too), I suggest that:

in multihash spec you register a new digest-algorithm in the IANA registry like we did in https://github.com/ioggstream/draft-polli-resource-digests-http/blob/master/draft-polli-resource-digests-http.md#the-id-sha-512-digest-algorithm-iana-id-sha-512

LPardue commented 5 years ago

Roberto explained my thoughts clearly. This isn't a judgement on multihash itself, it's just a separation of concerns.

The addition of id-sha-x is somewhat a clarification, and the security considerations for SHA are already well discussed. Multihash is a new thing and could tie up the process