duplicate digest-algorithms in field value

[ioggstream]

I expect

To clarify usage of duplicate algorithms, eg. with different parameters

Instead

It is not specified

Note

RFC3230 does not forbid duplicate digest-algorithm in field value, because the receiver MAY ignore one or more representation-digest eg:

Digest: sha-256=bxxx.., sha-256=axxx...

multihash encodes the algorithm and its parameters inside the string, and this is a use-case for duplicate digest-algorithms. This behavior is not in line with S-F though.

Digest: mh=fafafaf, mh=fbfbfbf

In case of digest-algorithms with parameters, this is more complex. The following valid example shows a duplicate digest-algorithm bs with two different parameter values.

Digest: bs=axxx; p=1,    bs=bxxx; p=2

Do we need an example for that?
Which is a suitable way to define it using structured fields/headers?

@LPardue

[LPardue]

I think this is tightly coupled with the parameter discussion on #850.

[ioggstream]

Forbidding parameters would fix this.

[ioggstream]

@msporny do you see any drawback in this? PTAL :)

[msporny]

Multihash doesn't have any parameter use cases that I can think of since you're supposed to encode all of those parameters via the multihash header. That is, it's always one multibase encoded multihash-header plus value. Multihash specifically would be fine w/ forbidding parameters.

It does raise the question on what happens if multiple multihash values are expressed. They would probably all be valid... one is a sha-256, one is a blake2b-32, etc. So, there is a strong use case for multiple "duplicate" "mh" digest algorithms (without parameters).

I can't comment on other hash expression schemes as it's not an area with which I'm an expert.

Does that help, @ioggstream?

[ioggstream]

@msporny thanks for your feedback!

Multihash specifically would be fine w/ forbidding parameters.

Ok!

... if multiple multihash values are expressed. They would probably all be valid

That is fine with the current Digest definition, but does not fit with structured-fields where every token is an unique keyword.
Seems that a future transition to a S-F scheme has many points to tackle...

A solution could be the following (but I suggest you to get in touch with people working on SF):

• digest-algorithms that supports multiple digest-value should be declared;
• in that case, those algorithms can be serialized as an InnerList;
• mh digest-algorithm should be serialized as a sf-item or sf-itemlist
• we should extend the serialization of digest-algorithms to support double quotes or bytes...

example

Digest: sha-256="xxx", sha-512="yyy", mh=("zzz" "qqq")

[ioggstream]

As of now it's ok having duplicates, as that depends on the digest-algorithm. We could at most spend a couple of words on the subject in the security considerations (eg if one receives multiple values for sha-256, ..)