Does the ECDSA signature value (of an OCSP response) need to be DER encoded

Question

In OCSP responses by a certain eIDAS PKI I every once in a while get signature values which, when unpacked from their BIT STRING, contain an ECDSA signature whose INTEGER constituents have an unnecessary leading 00 byte and, therefore, are not DER encoded, e.g.

 376   10: . . . . . SEQUENCE {
 378    8: . . . . . . OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
         : . . . . . . . (ANSI X9.62 ECDSA algorithm with SHA256)
         : . . . . . . }
 388   71: . . . . . BIT STRING, encapsulates {
 391   68: . . . . . . SEQUENCE {
 393   32: . . . . . . . INTEGER    
         : . . . . . . . . 6D 7F 95 D5 8E 9B E1 18    m.......
         : . . . . . . . . 60 DC A6 D6 91 37 0D B4    `....7..
         : . . . . . . . . AF D5 C9 A0 E8 21 40 4A    .....!@J
         : . . . . . . . . 94 8B 9F AA 6C DC F2 8C                            
 427   32: . . . . . . . INTEGER    
         : . . . . . . . . 00 1B FD 92 CB 1E E2 A8    ........
         : . . . . . . . . 2B 18 FC 37 ED 42 D0 66    +..7.B.f
         : . . . . . . . . E6 52 63 88 47 88 EE 00    .Rc.G...
         : . . . . . . . . FF 37 CF 20 8F F8 3C C1                            
         : . . . . . . . . Error: Integer has non-DER encoding.
         : . . . . . . . }
         : . . . . . . }

Here already the ASN.1 dump utility claims that this non-DER encoding is an error, and so does the current BouncyCastle version (a check for DER encoding has been introduced in a October 2016 commit, unfortunately without any issue or norm reference in the comment).

I would like to know whether BouncyCastle is too strict or the OCSP responder indeed creates invalid responses. Unfortunately I have not yet found any norm (relevant for eIDAS PKIs) which clearly indicates which encoding may be used there.

RFC 6960 on OCSP says

The value for response SHALL be the DER encoding of BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

but this only requires the BIT STRING signature to be DER encoded, not any data encapsulated in it.

TR-03111 (Technical Guideline on Elliptic Curve Cryptography by the German Federal Office for Information Security) says

In X9.62 format the ECDSA-signature (r; s) is encoded as ASN.1 structure with the following syntax:
ECDSA-Sig-Value ::= SEQUENCE {
  r INTEGER,
  s INTEGER
}
To embed the signature in a BIT STRING the DER encoded ECDSA-Sig-Value SHALL be the value of the bit string (including tag and length eld).

but a requirement by the German Federal Office for Information Security hardly is normative for eIDAS PKIs in general.

In X9.62 I only find

While it is likely that these ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used.

Bitcoin had a kerfuffle over this issue a few years back (before it was _really_ famous): https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki . Although I don't know what was generating the 'bad' signatures. — dave_thompson_085, Feb 17 '18 at 02:52
Some backgrounds appear to be in here: https://en.bitcoin.it/wiki/Transaction_malleability — mkl, Feb 17 '18 at 07:38

score 1 · Accepted Answer · answered Feb 16 '18 at 13:04

According to ISO/IEC 8825-1:2003 BER/DER encoded Integers should be:

8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets.

apparently dumpasn1 does check exactly this:

    if( i == 0 )
        {
        if( ( value == 0x00 ) && ( ( ch & 0x80 ) == 0x00 ) )
            warnNonDER = TRUE;
        if( ( value == 0xFF ) && ( ( ch & 0x80 ) == 0x80 ) )
            warnNonDER = TRUE;
        if( warnNonDER )
            {
            intBuffer[ 0 ] = ( int ) value;
            intBuffer[ 1 ] = ch;
            }
        }

See: https://github.com/clibs/dumpasn1/blob/master/dumpasn1.c#L1398

So since the encoding says it is BER/DER encoded INTEGER, it should be.

Ah! So it's not a question of DER vs. BER but instead of correct BER/DER vs. incorrect BER/DER. So while this does not answer my question as I formulated it ("Does the ECDSA signature value need to be DER encoded?"), this is exactly what I need to know for the issue at hand! — mkl, Feb 16 '18 at 14:08

Does the ECDSA signature value (of an OCSP response) need to be DER encoded

1 Answers1