Is there a best practice in handling key rotation? It seems to be common that all keys are identified as the actor ID + “#main-key” (or something similar to that), and that probably needs to change.
Given that actors are objects, I was wondering sending an Update/Actor activity would be enough to hint that followers and federation peers should update their internal caches and references to that actor, including new keys.
Also, because signed objects will still live on, keys can’t really be removed, but instead should be flagged as not the current/primary key.
Yeah, both of those present some interesting challenges.
With signed key rotation flows, if the old key is compromised, then it doesn’t really make sense to sign a new key with the old key. I understand that this is for the “happy path” where there aren’t bad actors at play, but it is something to consider.
The blind key rotation makes validating old content practically impossible. If a ld+json signed payload is being referenced and relayed as federated content, if the key is rotated but the new key not identified differently than the old key, validation is going to repeatedly break.
Either way, it would be great if other developers implemented unique key ids. Using a checksum, like the classic md5 of key bytes, or timestamp would a lot of this a non-issue.
[2020-03-10 00:57:43+0000] Nick Gerakines via SocialHub:
Yeah, both of those present some interesting challenges.
With signed key rotation flows, if the old key is compromised, then it doesn’t really make sense to sign a new key with the old key. I understand that this is for the “happy path” where there aren’t bad actors at play, but it is something to consider.
The blind key rotation makes validating old content practically impossible. If a ld+json signed payload is being referenced and relayed as federated content, if the key is rotated but the new key not identified differently than the old key, validation is going to repeatedly break.
Blind key rotation allows a bunch of privacy features, including plausible deniability. It’s true that from a cryptonerd point of view it makes no sense but on actual usage you need to be able to have past data be non-veriable (it was already verified when it mattered anyway).
It also allows to just trash most of your instance/user and start from scratch.
Either way, it would be great if other developers implemented unique key ids. Using a checksum, like the classic md5 of key bytes, or timestamp would a lot of this a non-issue.
Blind key rotation does allow for some privacy features, sure, but key rotation is a normal thing. Consider the fact that the most commonly encryption systems on the web (TLS certificates, GPG, etc.) make expiration, rotation, and revocation central to how they work. I think it can and will be a normal thing to rotate keys periodically without having to trash all old content because the signatures are no longer verifiable.
Keys are treated as different from all other objects, which seems really weird. Each object has a unique ID, so why not give keys unique IDs?
Actor foo with key #mainkey creates note-1234
Actor foo rotates key #mainkey
Downstream server receives note-1234, attempts to verify it but cannot
Also, the spec is a little vague about key fetching. If I recall correctly, it says that key ids should be an endpoint that returns the key with a HTTP GET request, but it doesn’t say if the response should be the key body or the ld+json structure that contains the key data.
Practically, if the expected behavior is that instance, particularly large ones, are expected to trash instance and user data, that’s going to damage the ecosystem and hurt adoption. Not being able to rotate (expire, revoke, notify, etc.) makes it more difficult for users to own their data, instance operators deal with security problems, and deal with bad actors on the federation network.
It is also worth noting that blind rotation and having unique key identifiers aren’t in opposition to eachother. As an instance operator, I can still rotate a user’s key and not notify anyone, but still have a unique identifier for the newly created key.
[2020-03-10 14:52:51+0000] Nick Gerakines via SocialHub:
Blind key rotation does allow for some privacy features, sure, but key rotation is a normal thing. Consider the fact that the most commonly encryption systems on the web (TLS certificates, GPG, etc.) make expiration, rotation, and revocation central to how they work. I think it can and will be a normal thing to rotate keys periodically without having to trash all old content because the signatures are no longer verifiable.
Why would you trash old content? IIRC the only usage of the keys is for HTTP Signatures and JSON-LD Signatures (which are only used in public posts in Mastodon and never in Pleroma/Honk/…).
In both cases it doesn’t matter, it’s just like TLS certificates in 99% of cases (only one I know is with key-pinning), you can change the key and no one will care.
It is also worth noting that blind rotation and having unique key identifiers aren’t in opposition to eachother. As an instance operator, I can still rotate a user’s key and not notify anyone, but still have a unique identifier for the newly created key.
They’re not but they potentially harm plausible deniability as it makes it very easy to just have a backup of all the keys and have proof that at any point Allysa P. Hacker had posted a content that for example is now illegal in her country.
I don’t think that is the case. Signatures are also included in the JSON payloads during inbox posts as a mechanism to allow activities to be relayed with their content still verified. There is another thread, Making sense of RsaSignature2017, that I think you’re participating in.
It isn’t true or accurate to say that it doesn’t matter when certificates change. Certificates are actively checked against revocation lists. Not only is there the OSCP system built into certificate infrastructure, but there are revocation list systems actively developed by Google, Mozilla, Apple, and others for the purpose of actively checking certificate revocation.
It is also worth pointing out that Apple, a member of the CA/Browser Forum, is also mandating 13 month expiration times for all certificates starting in September. Any certificates that have an expiration time of longer than 13 months will be considered invalid in Safari and the underlying components using Safari in macOS, iOS, etc. Google attempted to introduce a similar measure at a CAB meeting last summer, but it didn’t pass.
Not that everyone should do what Google and Apple does, but it is generally accepted as a bad practice to have keys that don’t expire. ActivityPub, and the systems that build upon it, should support key expiration and rotation in a way that supports the longevity of the community and it’s users. Not having unique key identifiers makes that more difficult.
I was just quoting you? I may have misunderstood what you meant.