Proposes a new Public Key Announcement with initial support for a keyAgreement key type.
Motivation
DSNP Users need to be able to share public keys in order to secure and transmit private data. An initial use case for this is to allow users to encrypt and decrypt their private social graph, and to enable two users to generate a shared secret that can be used to pseudonymously identify a relationship.
Specification Pull Request
TBD
Rationale
We expect every DSNP user to need at least one public key, which will typically be created contemporaneously with the creation of their DSNP User Id. Announcements provide a DSNP-centric approach that ensures public keys will be propagated to interested applications without requiring a new interface.
The choice of the term keyAgreement and the use of publicKeyMultibase serialization for keys is based on the same terms in the W3C DID specification. These are rapidly evolving standards but appear to be aligned with usage in major decentralized projects including IPFS.
Backwards Compatibility
Not applicable.
Reference Implementation and/or Tests
None at this time.
Security Considerations
Unlike Control Keys, public keys in announcements do not need to uniquely identify a DSNP User. Therefore, there is no requirement to ensure that all public keys are different. It is therefore possible (though extremely improbable if keys are generated randomly) that two users will publish the same public key.
The revokedAsOf field proposed is intended to allow for post-hoc revocation of keys that have been compromised, as well as keys that users wish to explicitly ensure are not trusted after a certain point in time.
Abstract
Proposes a new Public Key Announcement with initial support for a
keyAgreementkey type.Motivation
DSNP Users need to be able to share public keys in order to secure and transmit private data. An initial use case for this is to allow users to encrypt and decrypt their private social graph, and to enable two users to generate a shared secret that can be used to pseudonymously identify a relationship.
Specification Pull Request
TBD
Rationale
We expect every DSNP user to need at least one public key, which will typically be created contemporaneously with the creation of their DSNP User Id. Announcements provide a DSNP-centric approach that ensures public keys will be propagated to interested applications without requiring a new interface.
The choice of the term
keyAgreementand the use ofpublicKeyMultibaseserialization for keys is based on the same terms in the W3C DID specification. These are rapidly evolving standards but appear to be aligned with usage in major decentralized projects including IPFS.Backwards Compatibility
Not applicable.
Reference Implementation and/or Tests
None at this time.
Security Considerations
Unlike Control Keys, public keys in announcements do not need to uniquely identify a DSNP User. Therefore, there is no requirement to ensure that all public keys are different. It is therefore possible (though extremely improbable if keys are generated randomly) that two users will publish the same public key.
The
revokedAsOffield proposed is intended to allow for post-hoc revocation of keys that have been compromised, as well as keys that users wish to explicitly ensure are not trusted after a certain point in time.Dependencies
None.
References
None at this time.
Copyright
Copyright and related rights waived via CC0.