Re: [Multiformats] Multiformats Considered Harmful

st 6. 9. 2023 v 4:03 odesílatel Michael Jones <michael_b_jones@hotmail.com>
napsal:

> While I usually reserve my time and energy for advancing good ideas, I’m
> making an exception to publicly state the reasons why I believe “
> multiformats <https://github.com/msporny/charter-ietf-multiformats/>”
> should not be considered for standardization by the IETF.
>
> 1. Multiformats institutionalize the failure to make a choice, which is
> the opposite of what good standards do. Good standards make choices about
> representations of data structures resulting in interoperability, since
> every conforming implementation uses the same representation. In contrast,
> multiformats enable different implementations to use a multiplicity of
> different representations for the same data, harming interoperability.
> https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03#appendix-D.1 defines
> 23 equivalent and non-interoperable representations for the same data!
>
> 2. The stated purpose of “multibase
> <https://www.ietf.org/archive/id/draft-multiformats-multibase-08.html>”
> is “*Unfortunately, it’s not always clear what base encoding is used;
> that’s where this specification comes in. It answers the question: Given
> data ‘d’ encoded into text ‘s’, what base is it encoded with?*”, which is
> wholly unnecessary. Successful standards DEFINE what encoding is used
> where. For instance,
> https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2 defines that
> “x” is base64url encoded. No guesswork or prefixing is necessary or useful.
>
> 3. Standardization of multiformats would result in unnecessary and
> unhelpful duplication of functionality – especially of key representations.
> The primary use of multiformats is for “publicKeyMultibase” – a
> representation of public keys that are byte arrays. For instance, the only
> use of multiformats by the W3C DID spec <https://www.w3.org/TR/did-core/> is
> for publicKeyMultibase. The IETF already has several perfectly good key
> representations, including X.509, JSON Web Key (JWK), and COSE_Key. There’s
> not a compelling case for another one.
>
> 4. publicKeyMultibase can only represent a subset of the key types used in
> practice. Representing many kinds of keys requires multiple values – for
> instance, RSA keys require both an exponent and a modulus. By comparison,
> the X.509, JWK, and COSE_Key formats are flexible enough to represent all
> kinds of keys. It makes little to no sense to standardize a key format that
> limits implementations to only certain kinds of keys.
>
> 5. The “multihash
> <https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html>”
> specification relies on a non-standard representation of integers called
> “Dwarf”. Indeed, the referenced Dwarf document lists itself as being at
> http://dwarf.freestandards.org/ – a URL that no longer exists!
>
> 6. The “Multihash Identifier Registry” at
> https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html#mh-registry duplicates
> the functionality of the IANA “Named Information Hash Algorithm Registry”
> at
> https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg,
> in that both assign (different) numeric identifiers for hash functions. If
> multihash goes forward, it should use the existing registry.
>
> 7. It’s concerning that the draft charter
> <https://msporny.github.io/charter-ietf-multiformats/> states that “*Changing
> current Multiformat header assignments in a way that breaks backward
> compatibility with production deployments*” is out of scope. Normally
> IETF working groups are given free reign to make improvements during the
> standardization process.
>
> 8. Finally, as a member of the W3C DID and W3C Verifiable Credentials
> working groups, I will state that it is misleading for the draft charter to
> say that “*The outputs from this Working Group are currently being used
> by … the W3C Verifiable Credentials Working Group, W3C Decentralized
> Identifiers Working Group…*”. The documents produced by these working
> groups intentionally contain no normative references to multiformats or any
> data structures derived from them. Where they are referenced, it is
> explicitly stated that the references are non-normative.
>

+1 Appreciate the list, Mike.

I'd lean towards a spec that focused a bit more on current deployments,
rather than speculations of what might get deployed, in future.

>
>
>                                                 -- Mike
>
>
>
> P.S.  This was also posted at https://self-issued.info/?p=2408 and
> https://www.linkedin.com/posts/selfissued_github-mspornycharter-ietf-multiformats-activity-7105001423574077441-6tcS,
> referenced from https://twitter.com/selfissued/status/1699234431293370376,
> and filed as an issue at
> https://github.com/msporny/charter-ietf-multiformats/issues/2.
>
>
> --
> Multiformats mailing list
> Multiformats@ietf.org
> https://www.ietf.org/mailman/listinfo/multiformats
>