gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0005] branch master updated: text


From: gnunet
Subject: [lsd0005] branch master updated: text
Date: Mon, 22 Aug 2022 13:56:43 +0200

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0005.

The following commit(s) were added to refs/heads/master by this push:
     new e640c52  text
e640c52 is described below

commit e640c523910712f072a4c385b1e812874d2063c3
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Aug 22 13:56:39 2022 +0200

    text
---
 draft-schanzen-didgns.xml | 94 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 89 insertions(+), 5 deletions(-)

diff --git a/draft-schanzen-didgns.xml b/draft-schanzen-didgns.xml
index 9a958ab..22a8532 100644
--- 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>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]