Comments (2)
Thanks for the review @Wind4Greg! Attempts at answers below:
- Key Formats section 2.1. In the EdDSA specification this is "Verification Methods". Do we want to support the general "MultiKey" approach?
Yes.
Do we need to support "EcdsaSecp256r1VerificationKey2019" and "EcdsaSecp384r1VerificationKey2019" specific types?
In EdDSA we had a legacy requirement for the "Ed25519VerificationKey2020" key type. Is that the case here?
No, I don't think we want to support that unless there is a large and sustained deployment of that particular signature suite?
Note that there are multicodec codes for P-256 and P-384 compressed public keys and these are used in the DID:key spec. The did:key draft gives some of these values.
We are probably going to drop support for P-384, both in ecdsa-2019
and possibly in did:key
. The argument for P-384 over P-256 is just not very strong (energy required to break P-256 already exhausts entire planetary energy output for hundreds of years, presuming exponential increases in computing power and energy output).
- Note that FIPS PUB 186-4 doesn't defined the compressed key format. NIST SP 800-186 discusses point compression but not the most commonly used encoding. This is defined in RFC5480 section 2.2: "The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 and the compressed form is indicated by either 0x02 or 0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if any other value is included in the first octet." This encoding is used after further processing with X.509 certificates and hence is widely supported and should be explicitly cited in this or reference document.
+1 for citing the proper reference.
- Similarly in section 2.2 on "Signature Formats" can we use the general "DataIntegrityProof" type from the data integrity spec along with a
cryptosuite
designation rather than two new signature types "EcdsaSecp256r1Signature2019" and "EcdsaSecp384r1Signature2019". Possible cryptosuite names could be: "ecdsa-secp256r1-2019" and "ecdsa-secp384r1-2019"
We only want to support P-256 for 2019. So, only one choice, which means we can reduce to: ecdsa-2019
- Section 3 on "Algorithms" is incomplete. It seems like we would want to use a procedure such as in the EdDSA draft which is explicit on the steps to construction signature that involved both the unsigned document, and proof options, canonicalization, hashing, hash combination, and signing.
+1
- FIPS PUB 186-4: Digital Signature Standard (DSS) cited in the draft is deprecated and should be replaced with FIPS 186-5 (2023) and NIST SP 800-186 (2023).
+1, agreed.
- RFC 9053 CBOR Object Signing and Encryption (COSE): Initial Algorithms. States: " Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]." Should this document make a similar statement since this has been such a common source of security issues. Many libraries conform to RFC6979.
+1, yes, I believe so. /cc @dlongley
The only thing that gives me pause is that I remember reading something about EdDSA determinism causing problems and now they're looking at non-deterministic EdDSA (though, don't know how much traction that has really gotten).
- The example below uses "DataIntegrityProof" type, was created with an algorithmic approach of the EdDSA draft, and a deterministic P-256r1 signing algorithm (that was verified against RFC6979 test vectors). The public key included in the verification method is a multicodec encoded compressed P-256 key.
Great! Thank you!
from vc-di-ecdsa.
Thanks! I agree with @msporny's comments. As for using the deterministic version of ECDSA, I think it's fine to say it "SHOULD" be used, however, we may want to note that the should is there enable more implementations such as those provided by Web browsers via the Web Crypto API. It would be a significant problem if that became a "MUST".
My understanding is that deterministic vs. non-deterministic signatures is a trade off, but one that should almost always be made in favor of deterministic signatures. Non-deterministic signatures are vulnerable to any problem with the random number generator used -- for essentially any use case. Deterministic signatures may be vulnerable to fault attacks but this is really only a consideration for embedded device / smart card use cases. My understanding is that there are mitigations for this (if needed), including sometimes simple ones like just adding random nonces to what is signed (building on the existing primitive without having to change it).
from vc-di-ecdsa.
Related Issues (20)
- Clarifying `publicKeyMultibase` encoding: `did:key` style with multicodec code, or not? HOT 3
- Add normative guidance that Deterministic signatures SHOULD be used HOT 2
- Point Privacy and Security Considerations section back to Data Integrity HOT 2
- Ensure to pass SHA-384 param and fetch verification method early to get key size HOT 2
- Add definition for secretKeyMultibase serialization HOT 1
- Remove references to MULTIBASE and MULTICODEC HOT 3
- Ensure `created` proof option is optional HOT 5
- Ensure additional custom proof options provided via `proof` are included in the proof configuration HOT 3
- "Section 4: Retrieving Cryptographic Material" => "Section 4: Retrieve Verification Method" HOT 1
- Tell implementers to use major type 2 encoding (not tag 64 -- Uint8Array) for CBOR HOT 9
- Update contexts in examples HOT 3
- Update DataIntegrityProof proofValue admissible encodings HOT 1
- Recommended HMAC key length for ecdsa-sd-2023? HOT 4
- Unify Error Handling Language HOT 2
- ecdsa-rdfc-2019 Transformation passes wrong type to "Deserialize JSON-LD" HOT 1
- Editorial (respec?) issue in the proof configuration section HOT 2
- [Editorial] Making the RCH hash function reference more explicit HOT 4
- Different hashing functions in ECDSA and their relations to RDF-CANON HOT 4
- Transformation should refer to canonical n-quads HOT 9
- DRY principle for multikeys? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vc-di-ecdsa.