This section defines algorithm encodings and representations enabling the Standards for Efficient Cryptography Group (SECG) elliptic curve secp256k1 [
SEC2] to be used for JOSE [
RFC 7515] and COSE [
RFC 8152] messages.
The SECG elliptic curve secp256k1 [
SEC2] is represented in a JSON Web Key (JWK) [
RFC 7517] using these values:
plus the values needed to represent the curve point, as defined in
Section 6.2.1 of
RFC 7518. As a compressed point encoding representation is not defined for JWK elliptic curve points, the uncompressed point encoding defined there
MUST be used. The
x and
y values represented
MUST both be exactly 256 bits, with any leading zeros preserved. Other optional values such as
alg MAY also be present.
It is represented in a COSE_Key [
RFC 8152] using these values:

kty (1): EC2 (2)

crv (1): secp256k1 (8)
plus the values needed to represent the curve point, as defined in
Section 13.1.1 of
RFC 8152. Either the uncompressed or compressed point encoding representations defined there can be used. The
x value represented
MUST be exactly 256 bits, with any leading zeros preserved. If the uncompressed representation is used, the
y value represented
MUST likewise be exactly 256 bits, with any leading zeros preserved; if the compressed representation is used, the
y value is a boolean value, as specified in
Section 13.1.1 of
RFC 8152. Other optional values such as
alg (3)
MAY also be present.
The ECDSA signature algorithm is defined in [
DSS]. This specification defines the
ES256K algorithm identifier, which is used to specify the use of ECDSA with the secp256k1 curve and the SHA256 [
DSS] cryptographic hash function. Implementations need to check that the key type is
EC for JOSE or
EC2 (2) for COSE and that the curve of the key is secp256k1 when creating or verifying a signature.
The ECDSA secp256k1 SHA256 digital signature is generated as follows:

Generate a digital signature of the JWS Signing Input or the COSE Sig_structure using ECDSA secp256k1 SHA256 with the desired private key. The output will be the pair (R, S), where R and S are 256bit unsigned integers.

Turn R and S into octet sequences in bigendian order, with each array being 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values.

Concatenate the two octet sequences in the order R and then S. (Note that many ECDSA implementations will directly produce this concatenation as their output.)

The resulting 64octet sequence is the JWS Signature or COSE signature value.
Implementations
SHOULD use a deterministic algorithm to generate the ECDSA nonce, k, such as the algorithm defined in [
RFC 6979]. However, in situations where devices are vulnerable to physical attacks, deterministic ECDSA has been shown to be susceptible to fault injection attacks [
KUDELSKI17] [
EUROSP18]. Where this is a possibility, implementations
SHOULD implement appropriate countermeasures. Where there are specific certification requirements (such as FIPS approval), implementors should check whether deterministic ECDSA is an approved nonce generation method.
The ECDSA secp256k1 SHA256 algorithm specified in this document uses these identifiers:
Name 
Value 
Description 
Recommended 
ES256K 
47 
ECDSA using secp256k1 curve and SHA256 
No 
Table 2: ECDSA Algorithm Values
When using a JWK or COSE_Key for this algorithm, the following checks are made:

The kty field MUST be present, and it MUST be EC for JOSE or EC2 for COSE.

The crv field MUST be present, and it MUST represent the secp256k1 elliptic curve.

If the alg field is present, it MUST represent the ES256K algorithm.

If the key_ops field is present, it MUST include sign when creating an ECDSA signature.

If the key_ops field is present, it MUST include verify when verifying an ECDSA signature.

If the JWK use field is present, its value MUST be sig.
This specification defines how to use the secp256k1 curve for ECDSA signatures for both JOSE and COSE implementations. While in theory the curve could also be used for ECDHES key agreement, it is beyond the scope of this specification to state whether this is or is not advisable. Thus, whether or not to recommend its use with ECDHES is left for experts to decide in future specifications.
When used for ECDSA, the secp256k1 curve
MUST be used only with the
ES256K algorithm identifier and not any others, including not with the COSE
ES256 identifier. Note that the
ES256K algorithm identifier needed to be introduced for JOSE to sign with the secp256k1 curve because the JOSE
ES256 algorithm is defined to be used only with the P256 curve. The COSE treatment of how to sign with secp256k1 is intentionally parallel to that for JOSE, where the secp256k1 curve
MUST be used with the
ES256K algorithm identifier.