From a1919dfbd9d98c4f5995eb91ab955c1cf9ca79f4 Mon Sep 17 00:00:00 2001 From: rxgrant <6995442+rxgrant@users.noreply.github.com> Date: Tue, 12 Oct 2021 04:08:34 +0000 Subject: [PATCH 1/3] Review of Security Considerations Remove several extremely contentious and void-for-vagueness paragraphs in order to improve the Security Considerations section. > Pay very close attention to the defense, cryptographic agility, > and political acceptability of any cryptography you rely on for > DID Method security. What is the defense of a cryptography? What is cryptographic agility? In which part of the world should I gauge political acceptability? Remove paragraph. > Competition, direct substitutability, interoperability, and mutual > feature support are key to reducing the barriers to adoption of, > and increasing confidence in, your DID Method. How does competition reduce the barriers to adoption of your DID Method? How does competition increase confidence in your DID Method? What is direct substitutability? How does direct substitutability reduce the barriers to adoption of your DID Method? How does direct substitutability increase confidence in your DID Method? What is interoperability? Does it mean that your DID Documents comply with the DID Core v1.0 spec? Does it mean that another app can get a DID Document when given a DID from your DID Method? That would mean someone included your library in their app, or they were able to read your DID Method spec and reimplement. And that could have been a well-known resolver, so that anyone can get the DID Document with a simple HTTP query. What is mutual feature support besides complying with the DID Core v1.0 spec in order to allow interoperability? There is already an entire section titled "Method Reuse is Encouraged". Remove paragraph, rename subsection. > Avoid hard coupling to specific networks, such as Bitcoin or > Hyperledger Fabric. Design your method such that it may be > adapted to support multiple ledger systems. The notion of "cross-chain" IDs is not compatible with updating and revocation. Supporting those - ahem, required features - would in turn require code (and storage) to actually follow transactions on every cross-chain VDR. If an app developer or browser maker had libraries for certain VDRs, then they might as well use the native DID Methods for those VDRs. As things exist now, minor DID Methods will see interoperability when supported via popular resolvers. Remove paragraph. > Avoid secp256k1, RSA, P-256, P-384 and P-521. No. Remove advisement. > Avoid relying on smart contracts for complex data management. If > you must use a smart contract, keep it simple and architect a > solution that supports data migration. What are smart contracts? Why should they not be relied on? What is data migration in a smart contract setting? What is a simple smart contract? Remove paragraph. --- index.html | 26 +------------------------- 1 file changed, 1 insertion(+), 25 deletions(-) diff --git a/index.html b/index.html index da417d1..585dde2 100644 --- a/index.html +++ b/index.html @@ -1282,12 +1282,6 @@

Security Considerations

characteristics of their software systems.

-

- Pay very close attention to the defense, cryptographic agility, and - political - acceptability of any cryptography you rely on for DID Method security. -

-

Avoid complex or slow signature formats, especially if they are poorly documented, or do not have an open standard with well documented test @@ -1307,24 +1301,13 @@

Security Considerations

-

Vendor Lock In

-

- Competition, direct substitutability, interoperability, and mutual - feature support are key to reducing the barriers to adoption of, and - increasing confidence in, your DID Method. -

+

Transparency

Avoid inventing "new features". Work with others to find a common way to express any new features that are not unique to your DID Method.

-

- Avoid hard coupling to specific networks, such as Bitcoin or - Hyperledger Fabric. Design your method such that it may be adapted - to support multiple ledger systems. -

-

Transparency and openness in approaches related to security not only lead to greater security, but promote interoprability and adoption. @@ -1350,13 +1333,6 @@

Digital Signatures

SP 800-56A Rev 3 when evalutating curves for use.

-

Avoid secp256k1, RSA, P-256, P-384 and P-521.

- -

- Avoid relying on smart contracts for complex data management. If you - must use a smart contract, keep it simple and architect a solution - that supports data migration. -

From da1305f297cecfd115039ee1632bb468f52eb7ca Mon Sep 17 00:00:00 2001 From: rxgrant <6995442+rxgrant@users.noreply.github.com> Date: Tue, 12 Oct 2021 18:44:16 +0000 Subject: [PATCH 2/3] Update Safecurves section with information about libsecp256k1. based on https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses/68316 --- index.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/index.html b/index.html index ffe9b40..8ac27fc 100644 --- a/index.html +++ b/index.html @@ -1331,6 +1331,12 @@

Digital Signatures

SP 800-56A Rev 3 when evalutating curves for use. + Safecurves does not take into account actual implementation work such as + for secp256k1 in + libsecp256k1, + and has been described as a resource "best considered marketing copy + rather than an earnest attempt at scholarship", in + reviews.

From b908e50c5507c3bf3fa234eee62b0ef460fae50e Mon Sep 17 00:00:00 2001 From: rxgrant <6995442+rxgrant@users.noreply.github.com> Date: Tue, 12 Oct 2021 20:39:43 +0000 Subject: [PATCH 3/3] restore some advice on cryptographic agility Thanks to Orie for pointers to discussion on this. --- index.html | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/index.html b/index.html index 8ac27fc..bd819e5 100644 --- a/index.html +++ b/index.html @@ -1282,6 +1282,24 @@

Security Considerations

characteristics of their software systems.

+

+ Some cryptographic functions are + not allowed on certain government networks, hence it is a + good idea to beware of that when designing a DID Method for use + on those networks. +

+ +

+ Some Working + Group wisdom is offered on the limits of cryptographic + agility. Cryptosuites exist so that people that know better + can pick an extremely limited set of options, rather than + enabling a kitchen sink approach. +

+

Avoid complex or slow signature formats, especially if they are poorly documented, or do not have an open standard with well documented test