FEP-8b32: Object Integrity Proofs

Standards Fediverse Enhancement Proposals
, ,
1

source: fep/fep-8b32.md at main - fep - Codeberg.org

---
authors: @silverpill
status: DRAFT
dateReceived: 2022-11-12
discussionsTo: #29 - [TRACKING] FEP-8b32: Object Integrity Proofs - fep - Codeberg.org
---

FEP-8b32: Object Integrity Proofs

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying and nomadic identity.

History

Mastodon implemented embedded signatures according to Linked Data Signatures 1.0 specification, which is now obsolete.

Requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.

Integrity proofs

The proposed authentication mechanism is based on Data Integrity specification.

Proof generation

The proof MUST be created according to the Data Integrity specification, section 4.1 Generate Proof.

The process of proof generation consists of the following steps:

  • Canonicalization is a transformation of a JSON object into the form suitable for hashing, according to some deterministic algorithm.
  • Hashing is a process that calculates an identifier for the transformed data using a cryptographic hash function.
  • Signing is a process that calculates a value that protects the integrity of the input data from modification.

The resulting proof is added to the original JSON object under the key proof. Objects MAY contain multiple proofs.

Example of unsigned activity:

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Create",
    "actor": "https://example.com/users/alice",
    "object": {
        "type": "Note",
        "content": "Hello world"
    }
}

Example of activity with integrity proof:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/data-integrity/v1"
    ],
    "type": "Create",
    "actor": "https://example.com/users/alice",
    "object": {
        "type": "Note",
        "content": "Hello world"
    },
    "proof": {
        "type": "JcsRsaSignature2022",
        "created": "2022-11-12T00:00:00Z",
        "verificationMethod": "https://example.com/users/alice#main-key",
        "proofPurpose": "assertionMethod",
        "proofValue": "z2xZFiRJrr859BvmK22hS47448J..."
    }
}

The list of attributes used in integrity proof is defined in Data Integrity specification, section 2.1 Proofs. The value of verificationMethod attribute SHOULD be an URL of actor’s public key or a DID associated with an actor.

Proof verification

The recipient of activity SHOULD perform proof verification if it contains integrity proofs. Verification process MUST follow the Data Integrity specification, section 4.2 Verify Proof. It starts with the removal of a proof value from the JSON object. Then the object is canonicalized, hashed and signature verification is performed according to the parameters specified in the proof.

If both HTTP signature and integrity proof are used, the integrity proof MUST be given precedence over HTTP signature. The HTTP signature MAY be dismissed.

Algorithms

Implementors SHOULD pursue broad interoperability when choosing algorithms for integrity proofs. These algorithms are RECOMMENDED:

  • Canonicalization: JCS
  • Hashing: SHA-256
  • Signatures: RSASSA-PKCS1-v1_5

Implementations

TBD

References

Copyright

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.

1 Like
2

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs . Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addressed.

Summary
This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying and nomadic identity.

2 Likes
3

Here’s an interesting use case: integrity proofs can be used to implement client+relay model, where the signing key is stored on the client and activity signing is done by client as well. The relay (server) accepts signed activity via C2S and delivers it to the audience. The relay can refuse to deliver activity but it can not change the activity in any way, because that would invalidate the signature.

1 Like
4

Is there more on the client+relay model posted anywhere? I wonder if this helps support a model where private keys are held client-side.

5

This post was inspired by various discussions about Nostr protocol where identities are key-based and client+relay model is used. Client-side identity is possible in Fediverse too, and I even created a proof of concept, which makes use of FEP-8b32 and FEP-c390 extensions. I talked about this in Nomadic Identity thread:

I’m still not entirely convinced that client+relay model makes sense. But this is something we can explore – all building blocks already exist.

6

Made several small modifications to the proposal and added a link to implementation (it’s my own project Mitra):

2 Likes
7

Thanks, :+1: for this FEP being adopted.

Suggestions

Include test cases of activities that should be valid using various algorithm pairings. This would at least help me, if I wanted to implement this.
Specify behavior if Authentication is missing, e.g.

A server MAY require Authentication. In this case a request lacking authentication MUST be answered with HTTP 401.

Discuss behavior for AP S2S 7.1.2 Forwarding from Inbox, e.g.

A forwarded activity MAY be used without further verification, i.e. no GET is necessary from the original host.

Discuss public key caching. This probably goes beyond the scope of this FEP. So, one might one want add something like This section is non-normative. to it.

8

Only a small number of proof suites (methods) has been standardized so far: Verifiable Credentials Extension Registry. I’m mostly improvising and inventing my own suites. If you want to create an interoperable implementation, we can discuss it here or somewhere else, but I don’t want to include non-standard proof suites in the proposal (JcsRsaSignature2022 is used in the example but without it proposal would be incomplete).

Some servers may process activities in background and respond with 200/202 before authentication is performed.

Should this be a separate section in the proposal? Efficient forwarding is not the only use case of object integrity proofs, so if we talk about this we may as well mention other use cases.

That’s a good idea. This FEP can include recommendations for dealing with rotated/revoked keys: Reuse of Identity Channel Addresses & Revocation/Reissue of Keys

1 Like
9

I think a section on sample use cases would really help this proposal.

Another possible use case is to include the object being announced in an Announce activity. This would reduce the peak loads on servers, as only servers not having cached the public key, would need to fetch it.

An idea, I had is to use key expiration as a method to decide if content needs to be refetched. I’m not 100% sure if this is a good mechanism, but I thought it might be a good idea to put out there.

1 Like
10

One of the remaining issues here is a lack of clarity regarding proof type. When I read Data Integrity spec I get the impression that it recommends using DataIntegrityProof type along with cryptosuite property, but it is not clear how cryptosuites are registered.

Related issue:

How to use cryptographic suites · Issue #84 · w3c/vc-data-integrity · GitHub

1 Like
11

I think the Verificable Credential documentation’s state is described in Status of The Document as

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Given that it contains plenty of stuff marked ISSUE in red, I’m leaning towards: Give the authors another 6 months and then check back if it is usable. I’m not sure what I would do if waiting 6 months is not an option. The results of not waiting for a finalized draft can be witnessed in Mastodon’s Documentation on Linked Data Signatures.

I write the above in full appreciation that delaying proper integrity proofs due to unavailability of good credentials will delay a whole other bunch of stuff. However, the alternative currently seems to descent into a possible world of not understandable requirements due to updating definitions.

1 Like
12

Isn’t this also more or less the current state of HTTP signatures? Stuck on an obsoleted draft.

13

Integrity proofs are used in many examples throughout the Verifiable Credentials Data Model v1.1 document, which is already a W3C Recommendation. I doubt that Data Integrity spec will change substantially. Terminology and property names have been relatively stable for the past few years. The cryptosuite concept is new but it looks like it is designed to be backwards compatible.

I think the main challenge for FEP-8b32 implementors would be coming to agreement about which algorithms to use. Currently FEP recommends these:

  • Hashing: SHA-256. I guess this is non-controversial.

  • Signatures: RSASSA-PKCS1-v1_5. Everyone in Fediverse already uses it to create HTTP signatures. However, ECDSA and EdDSA have smaller key sizes, so if we’re ever going to migrate, FEP-8b32 is a good starting point.

  • Canonicalization: JCS. This is most difficult one because servers that already support LD signatures (e.g. Mastodon) use RDF canonicalization. If I understand corretly, RDF canonicalization is still a working draft, and it is much more complicated than JCS. I think there’s a good chance that some programming languages will never have a decent RDF library, although today JCS libraries are also hard to find (I haven’t found anything for Ruby and Elixir).

14

The RDF canonicalization algorithm is actually called URDNA2015. I searched for libraries implementing this algorithm and found Ruby, Python, Javascript, Go, Rust and PHP implementations. This covers all popular AP servers except Pleroma and Mobilizon (written in Elixir). There’s no JCS implementation in Ruby (for Mastodon). I think this is a bigger blocker, so URDNA2015 could be a better choice after all.

I found specification for eddsa-2022 cryptosuite: EdDSA Cryptosuite v2020.

15

Shouldn’t JCS be the clear favorite because it’s faster? I cannot find any analysis of the performance of the two algorithms, but it’s my expectation knowing roughly what they do.

Also if I understand Re: JSONWebSignature2020 vs JcsEd25519Signature2022 from Markus Sabadello on 2023-01-27 (public-vc-wg@w3.org from January 2023) correctly, it’s impossible to implement full URDNA without implementing JCS. So library support should favor JCS. (Or implementations are incomplete).

16

I prefer JCS, but if the goal is to replace Linked Data signatures, we need to get Mastodon on board. I finally found a Rust library that implements URDNA2015 so I’m going to support both algorithms.

It’s unlikely that JCS is part of URDNA2015 because JCS is relatively new standard (2020). They are different algorithms, or at least they appear to be.

17

I’ve been waiting for Data Integrity spec update, but this may take some more time, it seems. I think it would be better to change the example of signed activity right now, to reflect the recommendation given by @msporny in this comment:

DataIntegrityProof is what we’re hoping the communities using this technology will adopt as they move forward.
The reason for DataIntegrityProof is so that there is a single JSON-LD type for most Data Integrity Proofs instead of the path we were headed down, which would require an entirely new JSON-LD Context for every type of Data Integrity Proof AND would require the inclusion of that context whenever you did a signature of that type. Instead, what we’re trying to do is reduce the number of JSON-LD Contexts an implementation has to pull in, ideally to 1 base context (ActivityPub or Verifiable Credentials)

In summary, I’ll make the following changes:

  • Replace JcsRsaSignature2022 type with DataIntegrityProof
  • Add cryptosuite property with the value jcs-rsa-2022
  • Explain that jcs-rsa-2022 is non-standard and give a link to the spec for a similar cryptosuite, jcs-eddsa-2022: EdDSA Cryptosuite v2022
18

Hey @silverpill, thanks a ton for shifting towards the new DataIntegrityProof work! I noted above that you plan to create a suite for RSA. I’d strongly advise against doing that for the reasons included here:

New applications SHOULD NOT be using RSA unless there is a very good reason (like being compatible w/ broadly deployed systems in ways that makes it impossible to upgrade to more modern cryptography).

If FIPS HSM support isn’t an issue (and I don’t think it is for activitypub), then you should be using EdDSA ("cryptosuite": "jcs-eddsa-2022"). Also note that we might change the “jcs” name to something else.

1 Like
19

RSA was chosen to make implementation process easier for developers. Today the de-facto standard for server-to-server authentication in Fediverse is HTTP signatures with RSASSA-PKCS1-v1_5 algorithm. Every interoperating server already stores an RSA key for each user and knows how to verify those signatures. In order to implement FEP-8b32, developers only need to find some JCS library and adjust their activity construction and validation procedures. And while I understand that jcs-eddsa-2022 is preferable, implementing it would require more effort and that may discourage people. Of course, this is just a guess, and the recommendation will be revised based on a feedback from developers.

20

I would say: It’s better to encourage people to bite the bullet now then later. If the FediVerse is successful, there will be more projects to convince to make the switch than there are now. Furthermore, it should be a lot easier to find an ed25519 library than a jcs one.

1 Like