DIP-263 Use User Data for public keys

[wesbiggs]

Abstract

Public keys should be treated as User Data types rather than content announcements.

We remove the Public Key Announcement and replace with a User Data type for each key type, namely keyAgreement and assertionMethod. These formats will be defined in Avro schema (a single Avro type, PublicKey), and added to the User Data section of the spec. The Public Key Announcement will be moved to "Migrated Announcements".

Motivation

Public keys (for keyAgreement and assertionMethod key types, at least) are important for DSNP participants to be able to retrieve deterministically and quickly in order to accomplish tasks like graph encryption/decryption and credential verification.

If these are implemented as announcements (as is currently implied by the specification), the consumer must either rely on an outside content index, or an archive of state change events. The former is subject to man-in-the-middle attacks if not maintained directly by the querying party, and retrieval of the latter may be highly inefficient.

By defining these as User Data items, we guarantee that they can be accessed directly by DSNP Operations.

Specification Pull Request

Current change pull request: #276

Rationale

This proposal is informed by implementation choices made by the DSNP over Frequency implementation.

Backwards Compatibility

This is a declarative change only, so there should be no impact on current DSNP systems provided they are using a compatible storage strategy today.

Reference Implementation and/or Tests

DSNP over Frequency is proposed as a reference implementation.

Security Considerations

Treating keys as User Data should help avoid security challenges that might become a problem if content indexers were used:

1. Content indexers cannot be fully trusted to maintain data integrity as they sit outside the consensus system.
2. Content indexers could be subject to man-in-the-middle attacks.
3. Content indexers that are not fully in sync with the latest updates to keys could give the wrong answer to queries for a user's most recent key.

Dependencies

None.

References

DSNP spec:

• Public Key Announcement
• User Data

Copyright

Copyright and related rights waived via CC0.

[wesbiggs]

For discussion:

Should public keys include proof of ownership verifiable by consumers?

For assertionMethod keys, proof would consist of signing the DSNP User Id with the private key.

For keyAgreement keys, is this possible? (avoiding replay attacks)

[aramikm]

I think we are already doing that proof of ownership during writes for schemas that have SchemaSetting::SignatureRequired setting.

[wesbiggs]

Thanks @aramikm. (A) that's a Frequency-specific setting (not in DSNP spec, but possibly something we want to cover in this DIP), and (B) it's proof of ownership of the control key for the User Id, but not proof of ownership of the key being registered.

On the other hand, I'm trying to reason about whether it's actually a problem. If Bob "announces" the same public key as Alice, but doesn't control the corresponding private key, what are the attack vectors?

• Someone could send a message thinking Bob could decrypt it, but actually only Alice could decrypt it.
• Alice could sign something (a credential, say) and claim that it was Bob that signed it.

I think those are probably OK, if not really intended. A DSNP from of SignatureRequired would be useful though, to prevent a delegation target announcing an arbitrary key for Bob.

[aramikm]

You are correct, from frequency perspective we are storing each item as a byteArray and we don't care if the underlying data is a public key or not. I think we might be able to make it work with adding a new schema setting which will allow us to check the item as a public key against a signature.

[wilwade]

DSNP Spec Community Call Notes for 2024-05-02

• Does this or the PR mention anything about needing historical keys?
  • We generally think it needs to
• What about supporting or using Xed25519 (from Signal) for a multiuse single key?

[wesbiggs]

Historical keys: User Data is specified as a stream (ordered list) of the given Avro type (which also implicitly gives each key an index number), though the Replace User Data operation assumes that all data is being rewritten/replaced. Frequency adds the additional semantic of "append only", i.e. no previously existing records can be removed. I see three options. (1) We could enshrine "append only" in the DSNP spec, (2) leave it as an implementation choice (i.e. it is OK for an implementation to restrict which updates it allows), or (3) make keys a first class concept in DSNP, not subordinated to the User Data operations, and define specific key management operations.

Xed25519: A major purpose of the assertionMethod public keys is to enable usage with the W3C Verifiable Credential Data Integrity specification. While theoretically any type of signing key could be used for credential proofs, the current standards work is limited to ECDSA, EdDSA, and BBS schemes. This means a client application would need to be able to convert an Xed25519 key to an ed25519 form in order to apply the signing or verification algorithms for credentials. It could be done, but we would be out ahead of any library support for VCs. As an alternative, you could store as Xed25519 internally within Frequency, and translate and display as ed25519/x25519 when rendering a DID document or similar. From a principle of least privilege perspective, though, using the same key for multiple purposes might not be advised (but clearly this needs to be balanced with cost/storage requirements).

[wesbiggs]

Looking at this again, I think the confusion about historical keys stems from inconsistency in naming. We have publicFollows, privateFollows, and privateConnections all in plural form, but publicKey_foo for these types (and I've added the underscore to further confuse things).

I think we achieve better consistency and clarity if we go with:

• keyAgreementPublicKeys
• assertionMethodPublicKeys

Note that these have the same length as the ones with underscores. They are consistent with the previous names in that they begin with adjectives and end with plurals.

[wesbiggs]

These changes have been made for DSNP 1.3.