Support for ECDSA signatures on curve secp256r1

SPECIFICATIONS.md

@@ -165,7 +165,7 @@ The logic language is described by the following EBNF grammar:
 ```
 <origin_clause> ::= <sp>? "trusting " <origin_element> <sp>? ("," <sp>? <origin_element> <sp>?)*
 <origin_element> ::= "authority" | "previous" | <signature_alg>  "/" <bytes>
-<signature_alg> ::= "ed25519"
+<signature_alg> ::= "ed25519" | "secp256r1"
 
 <block> ::= (<origin_clause> ";" <sp>?)? (<block_element> | <comment> )*
 <block_element> ::= <sp>? ( <check> | <fact> | <rule> ) <sp>? ";" <sp>?
@@ -614,6 +614,7 @@ message PublicKey {
 
   enum Algorithm {
     Ed25519 = 0;
+    SECP256R1 = 1;
   }
 
   required bytes key = 2;
@@ -683,16 +684,58 @@ is a Biscuit token, that base 64 string should be prefixed with `biscuit:`.
 
 ### Cryptography
 
-Biscuit tokens are based on public key cryptography, with a chain of Ed25519
+Biscuit tokens are based on public key cryptography, with a chain of
 signatures. Each block contains the serialized Datalog, the next public key,
 and the signature by the previous key. The token also contains the private key
 corresponding to the last public key, to sign a new block and attenuate the
 token, or a signature of the last block by the last private key, to seal the
 token.
 
+#### Algorithms
+
+Biscuit supports multiple signature algorithms for it blocks, that can change
+between blocks in one token. The algorithm kind is defined in the `Algorithm`
+enum of the protobuf serialization of the public key. The `nextSecret` field
+in the proof section of the token uses the same algorithm as the `nextKey`
+of the last block.
+
+The following algorithms are supported:
+
+##### Ed25519
+
+The default signature algorithm is Ed25519 as introduced in [Bernstein, Daniel J.;
+Duif, Niels; Lange, Tanja; Schwabe, Peter; Bo-Yin Yang (2012). "High-speed
+high-security signatures" (PDF). Journal of Cryptographic Engineering](https://ed25519.cr.yp.to/ed25519-20110926.pdf)
+and specified in [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032).
+
+The protobuf encoding is defined as follows:
+- `key` field of the `Publickey` message: [compressed Edwards Y format](https://www.rfc-editor.org/rfc/rfc8032#section-5.1.2)
+- `nextSecret` in the `Proof` message: [32 bytes of cryptographically secure random data in little-endian](https://www.rfc-editor.org/rfc/rfc8032#section-5.1.5)
+- `signature` field in `Signature` and `ExternalSignature` messages: [concatenation of R and S values](https://www.rfc-editor.org/rfc/rfc8032#section-5.1.6)
+
+##### ECDSA
+
+Biscuit supports the ECDSA algorithm over the secp256r1 curve as defined in
+[SEC2v1](https://www.secg.org/sec1-v2.pdf), using the SHA-256 hashing
+algorithm. It is recommended to use a deterministic signature algorithm
+version like the one defined in [RFC 6979](https://datatracker.ietf.org/doc/html/rfc6979).
+
+
+The protobuf encoding is defined as follows:
+- `key` field of the `Publickey` message: [SEC1 format, defined in section 2.3.3](https://www.secg.org/sec1-v2.pdf). Allowed prefixes: `02`, `03`, `04`
+- `nextSecret` in the `Proof` message: big endian representation of the secret scalar
+- `signature` field in `Signature` and `ExternalSignature` messages: [SEC1 ASN.1 format, defined in section C5](https://www.secg.org/sec1-v2.pdf), only using the `r` and `s` parameters
+
+```
+ECDSA-Sig-Value ::= SEQUENCE {
+  r  INTEGER,
+  s  INTEGER
+}
+```
+
 #### Signature (one block)
 
-- `(pk_0, sk_0)` the root public and private Ed25519 keys
+- `(pk_0, sk_0)` the root public and private keys
 - `data_0` the serialized Datalog
 - `(pk_1, sk_1)` the next key pair, generated at random
 - `alg_1` the little endian representation of the signature algorithm fr `pk1, sk1` (see protobuf schema)
@@ -753,7 +796,7 @@ Token {
 ##### Optional external signature
 
 Blocks generated by a trusted third party can carry an *extra* signature to provide a proof of their
-origin. Same as regular signatures, they rely on Ed25519.
+origin. Same as regular signatures, they rely on public key cryptography.
 
 The external signature for block `n+1`, with `(external_pk, external_sk)` is `external_sig_n+1 = sign(external_sk, data_n+1 + alg_n+1 + pk_n+1)`.
 It's quite similar to the regular signature, with a crucial difference: the public key appended to the block payload is the one _carried_ by block `n` (and which is used to verify block `n+1`).

schema.proto

@@ -26,6 +26,7 @@ message PublicKey {
 
   enum Algorithm {
     Ed25519 = 0;
+    SECP256R1 = 1;
   }
 
   required bytes key = 2;