Maybe I am missing something, but shouldn't https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ specify the encoding of ECDSA signatures? There are multiple methods to encode ECDSA signatures: raw binary encoding (IEEE P.1363 standard); ASN.1 SEQUENCE with two INTEGERs (r and s) encoded with DER; Encoding specified in RFC 3279 section 2.2.3 ECDSA Signature Algorithm; RFC 5480. Also related is RFC 5758 section 3.2
Section 3.2.3 states the client must encode the signature using base64 of signature result. When a client generates uses ECDSA signatures, it will have to decide how to encode the signature, i.e. raw binary, ASN1....
One option is the ECDSA signature encoding is decided out-of-band, i.e. the server documents the encoding it supports and the client must use that encoding. Alternatively, the server could try or detect all possible encodings, maybe ASN1 first, and then binary if ASN1 failed. There could be other implementation variants.
Providing guidelines will reduce interoperability issues.
I came upon this problem while working on an experimental HTTP signature implementation using a Python client that leverages the pycryptodome library (https://pycryptodome.readthedocs.io/en/latest/src/signature/dsa.html) and a server side implementation implemented in golang. The python library supports both binary and ASN1 encoding.
Maybe I am missing something, but shouldn't https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ specify the encoding of ECDSA signatures? There are multiple methods to encode ECDSA signatures: raw binary encoding (IEEE P.1363 standard); ASN.1 SEQUENCE with two INTEGERs (r and s) encoded with DER; Encoding specified in RFC 3279 section 2.2.3 ECDSA Signature Algorithm; RFC 5480. Also related is RFC 5758 section 3.2
Section 3.2.3 states the client must encode the signature using base64 of signature result. When a client generates uses ECDSA signatures, it will have to decide how to encode the signature, i.e. raw binary, ASN1....
One option is the ECDSA signature encoding is decided out-of-band, i.e. the server documents the encoding it supports and the client must use that encoding. Alternatively, the server could try or detect all possible encodings, maybe ASN1 first, and then binary if ASN1 failed. There could be other implementation variants. Providing guidelines will reduce interoperability issues.
I came upon this problem while working on an experimental HTTP signature implementation using a Python client that leverages the pycryptodome library (https://pycryptodome.readthedocs.io/en/latest/src/signature/dsa.html) and a server side implementation implemented in golang. The python library supports both binary and ASN1 encoding.
This is how the pycryptodome library encodes the signature: https://github.com/Legrandin/pycryptodome/blob/649d981b84eeb1c1a7edb96ba796aad079a0de31/lib/Crypto/Signature/DSS.py#L107