# Signature in ECDSA-signed X.509 certificates

I wonder if there is a standard way of encoding the ECDSA-signature in the signature field of an X.509 certificate.

As far as I understand, the signature is a tuple of two integers r and s. If the signature uses the prime256v1 curve, each integer will be 32 bytes long. There seems to be a most common way of presenting these integers, which is as an ASN.1 DER encoded sequence.

0x30 0x44 0x02 0x20 [r-value] 0x02 0x20 [s-value]

Is there a standard saying how you may represent the ECDSA-signature in X.509? I have not found anything yet saying how they can or should be represented...

• Remember for P256 each of R and S will about half the time need an extra octet thus changing L for that component to 0x21 and L for the SEQUENCE to 0x45 or 0x46. And similarly for most other standard Fp curves, whose sizes were chosen as multiples of 8. – dave_thompson_085 Apr 14 '17 at 4:59
• Oh, I did not know that, thanks for pointing it out. Will R and S always have the same size, or can one have 33 bytes while the other have 32? – flipje Apr 14 '17 at 13:12
• r and s for ECDSA are effectively independent random variables uniform over [1,n-1] where n is the group order; the standard Fp curves have cofactor 1 so the group order is very near p which is chosen to be near 2^bits. Thus for P256 each of r and s, independently, has nearly 0.5 chance of being in [2^255,n-1] and needing length 33. A similar effect occurs for integer-DSA except there the subgroup order q is usually itself random in [(2^N)/2,(2^N)-1] for N in 160,224,256 thus biasing the probability of r,s needing the extra octet. – dave_thompson_085 Apr 15 '17 at 1:16
• Just because r or s is in [2^255,n-1] shouldn't mean they need 33 bytes, as n-1 should be 2^256-1 which is 32 bytes of ones. After reading a bit more, I understand that this is still somewhat true, but it is because the ASN.1 structure uses signed integers, while r and s are unsigned. So the most significant bit must be 0, which it is not if they are bigger than 2^255. Therefore an extra 0x00 byte is added if msb is 1. Is that correct? – flipje Apr 16 '17 at 6:41
• n for P256 is NOT 2^256, and for cryptographic (DLP-hard) elliptic curves in general it is NOT 2^bits. As I said it is near 2^bits; for the exact value see SECG 2, FIPS 186, or any handy implementation sourcecode. Yes it's because ASN.1 integers are signed values in [2^255,2^256-1], which includes [2^255,n-1] as a proper subset, need an extra octet of 0x00 to be represented correctly. – dave_thompson_085 Apr 17 '17 at 2:09

``````ECDSA-Sig-Value ::= SEQUENCE {