FEP-521a: Representing actor's public keys

Standards Fediverse Enhancement Proposals
, ,
21

Update: #289 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

Adding this paragraph:

Actor object MUST be used as a controller document, as described in section 2.3 Controller Documents of Data Integrity specification.

This is merely a clarification, and doesn’t require changing existing implementations.

In other news, Hubzilla now supports FEP-521a

1 Like
FEP-8b32: Object Integrity Proofs
22

Update: #324 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

Clarifying how invalid items in assertionMethod array should be processed, adding @fedify to implementations.

1 Like
23

Just as an FYI, the other representation is what’s standard in OAuth WG at IETF, and is how did:jwk encodes keys-- this later provides [backwards-compatible] interop with most contemporary (and older-but-still-supported) OIDC middleware, so MAY be useful for people down the road that are trying to implement AP on top of existing software with lots of users that use OIDC for everything (i.e. Log In With Google buttons).

But base58btc can be implemented in a few lines and is probably what I would pick until people start asking for the other. We can always write an extension-FEP making this multi-key-expression later, of course!

2 Likes
24

This FEP has been updated: #482 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

25

Controlled Identifiers is a W3C Recommendation now: Controlled Identifiers v1.0
I’ve made several minor changes in #603 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org, and I think it is done. Please submit your final comments!

26

Different public keys of the same actor MUST be identified using different fragment IDs.

This statement could be confusing in scenarios where fragment key IDs are not being used. For example, an actor could have multiple public keys where none of them use fragment ids or they might use a mix of fragment and non-fragment ids. The statement implies all keys MUST have a fragment id which isn’t consistent with the SHOULD recommendation for using fragment key ids in the previous sentence.

I think it would also be useful to provide a rationale for strongly recommending that the key id is based on the actor URI with a fragment. I understand this is the common pattern in the Mastoverse, but there are valid scenarios where this is not desirable (external key storage, for example).

1 Like
27

Is there a recommended method for adding a PGP public key to an actor?

1 Like
28

@stevebate What do you think about the following text:

Identifiers SHOULD be generated by appending a fragment identifier to the actor ID. That allows consumers to retrieve a public key and an associated actor object with a single HTTP request. If keys are identified using fragment identifiers, each key MUST have a unique fragment identifier.

Is it better?

1 Like
29

It depends on the purpose of a key:

  • If it is supposed to be used by a server to generate HTTP signatures or data integrity proofs, then I’d recommend to use the method described in this FEP. No multicodecs for PGP keys have been registered yet, but we can attempt to register one.
  • If it is supposed to be controlled by a user, but with a machine-readable cryptographic link to the actor, then FEP-c390: Identity Proofs might be used. In that case we would also need to register a multicodec, and create a cryptosuite specification (could be published in a FEP format).
  • If it is supposed to be controlled by a user, but a cryptographic link is not necessary, then it could be added to the actor document as a regular PropertyValue attachment, or a FEP-fb2a metadata entry.
30

@stevebate I added the text we discussed to the FEP several days ago: #605 - FEP-521a: Rephrase recommendations for constructing key IDs - fediverse/fep - Codeberg.org

Adding new requirements today: #606 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

31

@bashrc I opened an issue about registering a codec for PGP public keys: PGP public keys · Issue #381 · multiformats/multicodec · GitHub

32

I want to remove the statement about the expires property because it is not currently used in Fediverse (as far as I know): #621 - FEP-521a: Remove `expires` property - fediverse/fep - Codeberg.org
If something like this is desirable, it can be defined in a separate FEP.

33

This FEP is now FINAL!

2 Likes
34

Following the discussion in issue #710, I added “Security considerations” section to FEP-521a: #731 - FEP-521a: Add "Security considerations" section - fediverse/fep - Codeberg.org

It describes the best practices for handling secret keys.

35

FYI. In his latest article @Soatok emphasizes the importance that fediverse implementations implement FEP-521a to make E2EE for the fediverse a well-adopted reality:

With this out of the way, two things need to happen immediately:

  1. RFC 9421 libraries need to be updated to support the ml-dsa-44 signature algorithm.
  2. More Fediverse software needs to adopt FEP-521a to support multiple signing keys per Fediverse actor.

The article that is very well written is a highly recommended read that ties everything together in a clear and understandable way:

2 Likes
36

Would it be possible to add a table that maps RFC 9421 Signature Algorithms to Multicodec prefixes? I am having trouble mapping them.

Something like this:

| Signature Algorithm Name | Signature Algorithm Description | Multicodec Name | Multicodec Prefix | 
| ------------------- | ---------------------------------- | --------------- | ---------------- |
| rsa-pss-sha512      | RSASSA-PSS using SHA-512           | ?????? | ??????? |
| rsa-v1\_5-sha256     | RSASSA-PCKS1-v1\_5 using SHA-256    | ?????? | ??????? |
| hmac-sha256         | HMAC using SHA-256                 | ????sha256a???? | ????0x7012??? |
| ecdsa-p256-sha256   | ECDSA using curve P-256 DSS and SHA-256 | ??? p256-pub ????? | ??? 0x1200 ??? |
| ecdsa-p384-sha384   | ECDSA using curve P-384 DSS and SHA-384 | ??? p384-pub??? | ??? 0x1201 ??? |
| ed25519             | EdDSA using curve edwards25519     | ed25519-pub | 0xed    |
| ??????              | ?????????????????????              | mldsa-44-pub | 0x1210  |

Or document them here in that way?

1 Like
37
Signature Algorithm Name Signature Algorithm Description Multicodec Name Multicodec Prefix
rsa-pss-sha512 RSASSA-PSS using SHA-512 rsa-pub 0x1205
rsa-v1_5-sha256 RSASSA-PCKS1-v1_5 using SHA-256 rsa-pub 0x1205
hmac-sha256 HMAC using SHA-256 signing key is not published -
ecdsa-p256-sha256 ECDSA using curve P-256 DSS and SHA-256 p256-pub 0x1200
ecdsa-p384-sha384 ECDSA using curve P-384 DSS and SHA-384 p384-pub 0x1201
ed25519 EdDSA using curve edwards25519 ed25519-pub 0xed
ml-dsa-44 https://c2sp.org/httpsig-pq@v1.0.0#ml-dsa-44 mldsa-44-pub 0x1210

I am not 100% sure about these though.

1 Like
38

As far as I know, only rsa-v1_5-sha256, ed25519 and ml-dsa-44 are used in fediverse

1 Like
39

Thank you, silverpill!

That’s what I thought for rsa-pub, but it wasn’t clear if PSS and PCKS1 should share the same multicodec. That does mean there’s no way to distinguish the two without a lot of code to inspect the keys themselves, especially since PSS has a different hashing algorithm.

I know that not many people use RSA PSS on the Fediverse for RFC 9421 so it’s probably okay.

1 Like