Il valore di firma ECDSA (di una risposta OCSP) deve essere codificato DER

2

Nelle risposte OCSP di un certo PKI eIDAS I di tanto in tanto ottengono valori di firma che, quando decompressi dalla BIT STRING, contengono una firma ECDSA i cui componenti INTEGER hanno un byte 00 non necessario e, quindi, non sono codificati DER ad es.

 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.
         : . . . . . . . }
         : . . . . . . }

Qui l'utility dump ASN.1 afferma che questa codifica non DER è un errore, così come l'attuale versione di BouncyCastle (un controllo per la codifica DER è stato introdotto in un commit di ottobre 2016, sfortunatamente senza alcun problema o norma riferimento nel commento).

Vorrei sapere se BouncyCastle è troppo severo o il risponditore OCSP crea effettivamente risposte non valide. Purtroppo non ho ancora trovato alcuna norma (rilevante per PKI eIDAS) che indica chiaramente quale codifica può essere utilizzata lì.

RFC 6960 su OCSP dice

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 }

ma ciò richiede solo che BIT STRING signature sia codificato con DER, non tutti i dati incapsulati in esso.

TR-03111 (Linea guida tecnica sulla crittografia a curve ellittiche dell'Ufficio federale tedesco per la sicurezza delle informazioni) dice

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).

ma difficilmente l'Ufficio federale tedesco per la sicurezza delle informazioni è un requisito normativo per le PKI eIDAS in generale.

In X9.62 trovo solo

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.

    
posta mkl 16.02.2018 - 11:52
fonte

1 risposta

1

Secondo gli standard ISO / IEC 8825-1: gli INER codificati BER / DER dovrebbero essere:

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.

apparentemente dumpasn1 controlla esattamente questo:

    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;
            }
        }

Vedi: link

Quindi siccome la codifica dice è BER / DER codificato INTEGER, dovrebbe essere.

    
risposta data 16.02.2018 - 14:04
fonte

Leggi altre domande sui tag