FEP-8b32: Object Integrity Proofs

Standards Fediverse Enhancement Proposals
, ,
81

JCS context injection PR has been merged, test vectors have been updated as well. I will update my implementation in two stages, according to the plan:

Two remaining unresolved issues are context injection when object doesn’t have @context and proving integrity of nested objects.

2 Likes
82

I’m having trouble reproducing the test vector for FEP-8b32. (Is it okay to ask this here?) Is the private key z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq in the test vector equivalent to the following JWK?

{
  "kty": "OKP",
  "crv": "Ed25519",
  "d": "yW756hDF5BTEcXI6_53nLDX6W3D66X6IMuysfS4rjtY",
  "x": "sA2Nk45_dz1RVlqtNqYj9TRPf10ZYPnPPo4SYg6igQ8"
}
83

I’m not familiar with JWKs, but according to RFC-8037 the “d” parameter is a base64url encoded private key. I tried to decode it, and the value I get is different from the multibase-encoded one.

84

I thought the private key is c96ef9ea10c5e414c471723aff9de72c35fa5b70fae97e8832ecac7d2e2b8ed6 in hexadecimal bytes, was I wrong?

85

This is the private key, you are right. I get that value after decoding z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq

86

I have a question about the following statement in section 3.3.4 Hashing (eddsa-jcs-2022) of the Data Integrity EdDSA Cryptosuites v1.0 specification.

  1. Let hashData be the result of joining proofConfigHash (the first hash) with transformedDocumentHash (the second hash).

In the above specification, does “joining” mean concatenation, i.e., does the hashData total 64 bytes in size?

87

Yes, it’s a concatenation and the hashData will be 64 bytes in size.

88

Like the test vectors in the Data Integrity EdDSA Cryptosuites v1.0 specification, it would be nice if the test vectors for FEP-8b32 included an intermediate step to compute the proof:

  • Canonical object
  • Object hash (hex)
  • Canonical proof config
  • Proof config hash (hex)
  • Combination of two hashes (hex)
  • Signature of combined hashes (hex)
  • Signature (base58-btc)

Would this be possible?

2 Likes
89

Yes, I’ll add that in the next revision.

2 Likes
90

I found that the test vector in FEP-8b32 (and Mitra’s implementation) is inconsistent with the algorithm described in the Data Integrity EdDSA Cryptosuites v1.0 specification.

Looking at section 3.3.1 Create Proof (eddsa-jcs-2022) of the specification, it states:

  1. Set proof.@context to unsecuredDocument.@context.

The test vector, on the other hand, is the result of skipping this step. Mitra’s implementation also omits this step.

Is this test vector in FEP-8b32 intended or is it a bug in the specification?

91

I wrote about this a couple of days ago:

New algorithms are implemented but I haven’t pushed changes to Codeberg yet. During the transitional period, consider FEP-8b32 test vectors to be “correct” ones (i.e. don’t add @context to your proofs).

3 Likes
92

Okay, got it! Thanks for your kind response.

1 Like
93

Thanks to @silverpill, Fedify is now FEP-8b32 compliant. I haven’t made a stable release yet, but the tests are passing in the latest main branch.

Thanks again! :pray:

2 Likes
94

This is great news! I’ll add Fedify to implementation list

1 Like
95

IMHO, it would be better if the FEP-8b32 specification includes these use cases as well!

2 Likes
96

Done! #338 - FEP-8b32: Update proposal - fediverse/fep - Codeberg.org

I also added Fedify to implementation list, updated examples and test vectors, and made a normative reference to FEP-521a.

2 Likes
97

Now Fedify also has followed up the change in eddsa-jcs-2022 spec!

1 Like
98

I was told that securing nested objects with eddsa-jcs-2022 is acceptable: eddsa-jcs-2022 and nested documents · Issue #81 · w3c/vc-di-eddsa · GitHub (that question was originally raised by @helge in Use cases of fep-8b32: Object Integrity Proofs - #11 by silverpill).

Not sure what to make of it, I guess it’s time to remove warnings about nested objects from the FEP.

cc @stevebate @arcanicanis