blake2b algorithm identifier

[pwinckles]

blake2b is listed in the digest algorithm table, but the output size is not specified. The notes say "full-length form only," which I assume means blake2b-512. For the sake of clarity and interpretability, I think it would be useful to use the complete identifier.

[pwinckles]

I haven't gotten around to making the pull request yet, but, in light of the inventory size concerns discussed in #367, perhaps multiple different blake2b output sizes should be supported?

[zimeon]

RFC7693 sec 4 "Standard Parameter Sets and Algorithm Identifiers" suggests identifiers id-blake2b512, id-blake2b256, and id-blake2b160. I don't like the id- prefix and am not really sure how standard its use it. However, I tend to agree with @pwinckles that we should use identifiers with an explicit length designation. Based on possible use cases with many versions where inventory size may be a concern (see #367) it may be worth including shorter versions, perhaps down to id-blake2b160 which has a digest of 20 bytes and hence 40 hex digits (rather than 128 digits for id-blake2b512 and sha512)

[jrochkind]

If multiple sizes were to be supported, would you expect the client reading blake2b digests would know which size were used simply by looking at the size of the output hex-encoded digest? Or would that be indicated by different values used to specify different sizes? That seems inadvisable.

Ref #371, I think the left column table of digests is meant to be a controlled vocabulary of digests, so if you wanted metadata to say what bytesize blake2b were used, I guess you'd need to list each allowed byte size in that table, with a string indicating it.

[eocarragain]

multihash may be relevant here, but perhaps too untested/niche for use in OCFL?

[ahankinson]

We looked into multihash, but felt that it introduced a dependency into the stack that detracted from the interoperability of using 'pure' hash algorithms. One of the design parameters for OCFL is that it should be usable in a default OS installation, with some built-in future-proofing (shasum is a common utility now, but it's likely that the blake CLI utilities will be more widely available soon. b2sum has been added as part of the GNU coreutils, but I don't think it's trickled down to all the distros yet).

[rosy1280]

refs #371