Initial Review, Suggestions, Test Vectors...

Hi all, I agree that this suite of signatures is important for compatibility. In addition due to the current work on VC Data Integrity and the EdDSA crypto suite 2020 we should be able to quickly update this document, complete the algorithm details and furnish test vectors. Below are some questions/comments prior to generating any pull requests.

Key Formats section 2.1. In the EdDSA specification this is "Verification Methods". Do we want to support the general "MultiKey" approach? 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? 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.
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.
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"
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.
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).
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.
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.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "name": "Alumni Credential",
  "description": "An minimum viable example of an Alumni Credential.",
  "issuer": "https://vc.example/issuers/5678",
  "validFrom": "2023-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:abcdefgh",
    "alumniOf": "The School of Examples"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-secp256r1-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z33SWiBLC2FAc1rAJbWU39PoHbTe7zcrVnDBqk94cVf2UDs54XxMuwaa1rMhafE8xn47Hdu7nqETWhks4VanNe46g"
  }
}

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.

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!

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).

w3c / vc-di-ecdsa

Initial Review, Suggestions, Test Vectors... #4