divergence between implementations serializing ed25519 public keys

There is some ambiguity in the spec regarding how to encode ed25519’s public portion of the keyval:

The 'ed25519' format is:

  { "keytype" : "ed25519",
    "scheme" : "ed25519",
    "keyval" : {"public" : PUBLIC}
  }

where PUBLIC is a 32-byte string.

While the ed25519 public key is a 32-byte string, I could find no implementation that’s serializing the public key to JSON as an array of integers. Instead, implementations are serializing it into a JSON string, but there is a fork in how this is implemented:

• python-tuf and go-tuf hex encode the public key
• rust-tuf encodes with base64url to encode the public key.
• notary, and hackage base64 standard encode the public key.

Can you provide any guidance on what serialization format we should be using?

edit: turns out rust-tuf uses base64url instead of base64standard for encoding.

[erickt]

I just submitted #47 to update the spec to reflect hex encoding the ed25519 public key, and target file hashes.

[JustinCappos]

I don’t see this as TAP worthy. It’s just a clarification / fix.

On Wed, Apr 10, 2019 at 8:49 PM Erick Tryzelaar [e-mail] wrote:

It looks like there’s also divergence on how implementations are encoding the snapshot/timestamp/ targets role hashes, both in the metadata and for the hash-prefixed files:

• python-tuf https://github.com/secure-systems-lab/securesystemslib/blob/509a1860a54019cb82ec374dc1cd1487c34517ba/securesystemslib/util.py#L393 and go-tuf https://github.com/flynn/go-tuf/blob/master/data/types.go#L108, hackage https://github.com/haskell/hackage-security/blob/21a385c1a3c6222d4a7b6b8ecaff23431999d130/hackage-security/src/Hackage/Security/TUF/FileInfo.hs#L68 (as best as I can tell) uses hex encoding for metadata and files.
• rust-tuf https://github.com/heartsucker/rust-tuf/blob/develop/src/crypto.rs#L763 uses base64url for metadata and files.
• notary uses base64standard for its metadata https://github.com/theupdateframework/notary/blob/ce99e3cc568549b10ced3eb49cbb7e2941924eb4/tuf/data/types.go#L174, and hex for target URLs https://github.com/theupdateframework/notary/blob/ce99e3cc568549b10ced3eb49cbb7e2941924eb4/tuf/utils/utils.go#L115 .

Also, if we were changing ed25519 metadata to use base64, should the spec also change the keyid and path_hash_prefixes to be base64? The spec specifically calls out that they are hex encoded.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/42#issuecomment-481923769, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD1kwxi-jI5bUgV_xjIIzhmqwyWUjks5vfoa2gaJpZM4ck62t .