id-ce-cRLDistributionPoints ASN.1 / DER encoding question

0

Ho un file - test.pem - con i seguenti contenuti:

-----BEGIN CERTIFICATE-----
MBIwEKAOoAwwCqMIMAZhBEFCQ0Q=
-----END CERTIFICATE-----

openssl asn1parse -inform PEM -in test.pem -i restituisce quanto segue:

    0:d=0  hl=2 l=  18 cons: SEQUENCE
    2:d=1  hl=2 l=  16 cons:  SEQUENCE
    4:d=2  hl=2 l=  14 cons:   cont [ 0 ]
    6:d=3  hl=2 l=  12 cons:    cont [ 0 ]
    8:d=4  hl=2 l=  10 cons:     SEQUENCE
   10:d=5  hl=2 l=   8 cons:      cont [ 3 ]
   12:d=6  hl=2 l=   6 cons:       SEQUENCE
   14:d=7  hl=2 l=   4 cons:        appl [ 1 ]
Error in encoding
19480:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:142:

Ecco a cosa corrisponde in hex:

00000000  30:10:30:0e:a0:0c:a0:0a:30:08:a3:06:30:04:61:02  0.0.....0...0.a.
00000010  58:58                                            XX

Decodifica a mano ho capito:

SEQUENCE {
  SEQUENCE {
    [0] {
      [0] {
        SEQUENCE {
          [3] {
            SEQUENCE {
              [APPLICATION 1] XX
            }
          }
        }
      }
    }
  }
}

Quindi sembra funzionare per me. Perché non piace così tanto? Ecco il mapping ASN.1 che corrisponde a:

link

    
posta compcert 14.02.2012 - 14:08
fonte

1 risposta

2

Le definizioni pubblicate qui tramite il collegamento sono incomplete, ma dopo aver fornito le definizioni per tutti i tipi indefiniti, ottengo un messaggio di errore simile dall'utilità OSS Nokalva ASN.1 Studio. L'ultimo byte visualizzato qui è una lunghezza (58 esadecimale decimale 88), ma in base al secondo byte (esadecimale 10, dec 16) la lunghezza totale della codifica è 16, quindi 88 byte in più non possono essere trovati nel buffer basato su quella lunghezza esterna, quindi il messaggio di errore sull'incontro di quella lunghezza di 88.

Paul

    
risposta data 15.02.2012 - 21:47
fonte

Leggi altre domande sui tag