commit e640c523910712f072a4c385b1e812874d2063c3
parent 3e59a17156c285c889071ae0217bb17de728300c
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 22 Aug 2022 13:56:39 +0200
text
Diffstat:
1 file changed, 89 insertions(+), 5 deletions(-)
diff --git a/draft-schanzen-didgns.xml b/draft-schanzen-didgns.xml
@@ -58,11 +58,11 @@
<section>
<name>Introduction</name>
<t>
- GNS is a naming system that is decentralized and secure.
- Users can register zones and resolve the names of other users.
- Zones can be registered by anyone, users do not need permission to do so.
- Zones are not human-rememberable.
- The name of a zone is the public key of the ego controlling it.
+ GNS is a decentralized, censorship-resistant name system <xref target="I-D.draft-schanzen-gns"/>.
+ It allows users to register zones and resolve the names of other users
+ in a petname-like manner.
+ GNS is a suitable mechanism for a DID Document registry and DID method
+ identifier due to it's inherent suitability as a public-key infrastructure.
</t>
<section numbered="true" toc="default">
<name>Requirements Notation</name>
@@ -170,6 +170,90 @@ did:gns:000G057G3NM5FCGEDF35DBE6Y1R7QEFF7GJA9KXVK9KMT336XWKBY1M2XC
</t>
</section>
</section>
+ <section anchor="security">
+ <name>Security and Privacy Considerations</name>
+ <!-- The Security Considerations section MUST document the following forms of attack for the DID
+operations defined in the DID method specification: eavesdropping, replay, message insertion,
+deletion, modification, denial of service, amplification, and man-in-the-middle. Other known
+forms of attack SHOULD also be documented.-->
+ <t>
+ Record data in GNS is encrypted and signed using the private key which
+ corresponds to the public key in the DID.
+ This ensures that no message insertion or modification is possible and
+ authenticity of the DID Documents is ensured.
+ Only compromised private key material is a threat to the integrity
+ and authenticity of the DID.
+ Denial of service attacks are difficult due to the common use of
+ distributed hash tables as part of GNS implementations.
+ </t>
+ <!-- The Security Considerations section MUST discuss residual risks, such as the risks from compromise
+in a related protocol, incorrect implementation, or cipher after threat mitigation was deployed. -->
+ <t>
+ An incorrect implementation of the digital signature algorithm in GNS
+ could make it possible for an attacker to impersonate any other ego, and
+ create or delete DID Documents.
+ GNS itself provides crypto-agility and the possibility of extending the
+ protocol with new cryptographic schemes should the need arise.
+ In such cases, existing identities will need to be revoked and new DIDs
+ created.
+ </t>
+ <!--The Security Considerations section MUST discuss the policy mechanism by which DIDs are proven to
+be uniquely assigned. -->
+ <t>
+ The DIDs are statistically unique because they consist of a public key
+ corresponding to a GNS zone.
+ The chance for two users to generate the same private key and derive the
+ same public key is negligible.
+ </t>
+ <!--If a protocol incorporates cryptographic protection mechanisms, the DID method specification MUST
+clearly indicate which portions of the data are protected and by what protections, and it SHOULD
+give an indication of the sorts of attacks to which the cryptographic protection is susceptible.
+Some examples are integrity only, and endpoint authentication.-->
+ <t>
+ The GNS DID method uses digital signatures.
+ The security of the DID method depends on the assumption that a user can
+ keep the private zone key secret.
+ Any records containing DID Documents published in GNS are signed using
+ a private key derived from the zone private key and encrypted using a
+ derived symmetric key as defined in Section 5.1 of <xref target="I-D.draft-schanzen-gns"/>.
+ </t>
+ <!-- Data which is to be held secret (keying material, random seeds, and so on) should be clearly labeled.-->
+ <t>
+ The GND DID method never exposes the private zone key.
+ The user can however use and display the DIDs private key locally.
+ </t>
+ <!-- DID method specifications should explain and specify the implementation of signatures on DID documents,
+if applicable. -->
+ <t>
+ DID documents are not signed directly but instead stored in the apex of
+ GNS zones.
+ Every record in a GNS zone is signed by the zone owner's private key.
+ </t>
+ <!-- Where DID methods use peer-to-peer computing resources, such as with all known DLTs, the expected
+burdens of those resources SHOULD be discussed in relation to denial of service. -->
+ <t>
+ The underlying storage layer used by the DID method is the GNS.
+ A Distributed Ledger Technology is not used.
+ GNS does need resources such as for relaying messages and storing records.
+ However, a given peer is not required to provide these resources.
+ A peer may use more resources than it provides.
+ </t>
+ <!-- Privacy-->
+ <t>
+ Any given set of two GNS DIDs cannot be correlated.
+ Every DID uses a distinct private-public key pair.
+ The identity's privacy may be compromised if the user decides to use a
+ custom unique DID Document which contains compromising metadata.
+ The user can not be identified through a DID as the DID doesn't contain
+ any identifying information.
+ The user cannot prevent others to share a DID and DID Document as they
+ are essentialy public records.
+ The GNS DID method does not reveal any information that could harm the
+ users reputation.
+ Users only reveal their DID document. However, the user has no control
+ over how others handle that data.
+ </t>
+ </section>
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
<t>
