Back to Codeberg

feat(federation): mulitple actor public keys #81

forgejo-contrib-federation-issues-81.md

latest6.5 KB
Original Source

forgejo-contrib/federation

Watch21

Star82

Fork

You've already forked federation

6

CodeIssues 16Pull requests 8Projects 2ActivityActions

feat(federation): mulitple actor public keys #81

New issue

Open

opened 2025-12-08 17:10:15 +01:00 by 0xllx0 · 1 comment

0xllx0 commented 2025-12-08 17:10:15 +01:00

Collaborator

Copy link

A comment from @silverpill 0xllx0/federation#1 (comment) brings up the ability for ActivityPub actors to have multiple keys.

With ForgeFed and ActivityPub supporting this, as well as RFC 9421 (implemented by Mastodon), there is the future possibility
for actors having a public key for each supported signing algorithm.

Currently, only RSA v1.5 (RSA_SHA256) is supported by Mastodon and GoToSocial, so it is not an immediate priority.

However, to future-proof our implementation, I think it would be good to consider our architecture for an actor having multiple key records.

We could take multiple approaches to support multiple actor keys (non-exhaustive):

  • add owner ID + type to the federation_public_key table

    • OWNER_ID: table ID of the owning actor
    • OWNER_TYPE: owning actor type, e.g. (FederationHost, User, Repository, TicketTracker, etc)
    • SIGNATURE_TYPE: signature algorithm for the keypair
  • serialize a list of the {ID, SIGNATURE_TYPE} information into each actors PublicKeyIDs field

  • wait until we are fully on PostgreSQL, and store public key IDs as an integer array in actor records

  • write custom ORM polyfill to implement array operations on all currently used DBs

  • something else?

Related:

A comment from @silverpill https://codeberg.org/0xllx0/federation/pulls/1#issuecomment-8780175 brings up the ability for ActivityPub actors to have multiple keys. With ForgeFed and ActivityPub supporting this, as well as RFC 9421 (implemented by Mastodon), there is the future possibility for actors having a public key for each supported signing algorithm. Currently, only RSA v1.5 (RSA_SHA256) is supported by Mastodon and GoToSocial, so it is not an immediate priority. However, to future-proof our implementation, I think it would be good to consider our architecture for an actor having multiple key records. We could take multiple approaches to support multiple actor keys (non-exhaustive): - add owner ID + type to the federation_public_key table - OWNER_ID: table ID of the owning actor - OWNER_TYPE: owning actor type, e.g. (FederationHost, User, Repository, TicketTracker, etc) - SIGNATURE_TYPE: signature algorithm for the keypair - serialize a list of the {ID, SIGNATURE_TYPE} information into each actors PublicKeyIDs field - wait until we are fully on PostgreSQL, and store public key IDs as an integer array in actor records - write custom ORM polyfill to implement array operations on all currently used DBs - something else? Related: - https://codeberg.org/forgejo/forgejo/pulls/10074 - https://codeberg.org/forgejo/forgejo/pulls/10206 - https://codeberg.org/forgejo-contrib/federation/pulls/73

👍 1

0xllx0 referenced this issue from 0xllx0/federation 2025-12-08 18:47:03 +01:00 thoughts-on-normalization-and-signature-actor-validation #1

silverpill commented 2025-12-09 00:03:09 +01:00

Copy link

All FEP-8b32 implementations already generate two keys for actors, RSA and Ed25519, because that FEP recommends EdDSA signatures.

All FEP-8b32 implementations already generate two keys for actors, RSA and Ed25519, because that FEP recommends EdDSA signatures.

👀 1

Sign in to join this conversation.

No Branch/Tag specified

BranchesTags

main

feat/add-generated-threat-analysis

n0toose/admin-panel

n0toose/readme-forgefed-mention

n0toose/ap-username-changes

ap-username-changes-for-pr-9254

adr-signing-and-encryption

No results found.

Labels Clear labels No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

forgejo-contrib/federation#81

WritePreview

Loading…

Add table

| Rows | | | Columns | |

CancelOK

Add a link

Url Description Hint: With a URL in your clipboard, you can paste directly into the editor to create a link.

CancelOK

CancelSave

Reference in a new issue

Repository

forgejo-contrib/federation

Title

Body

Create issue

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

No Yes