analizzando l'estensione id-ce-keyUsage nei certificati X.509

Question

analizzando l'estensione id-ce-keyUsage nei certificati X.509

#1 da (3 voti)

3

Sto provando a decodificare un certificato X.509 e ho una domanda riguardante la decodifica delle estensioni. In particolare, la stringa di ottetto corrispondente a id-ce-keyUsage (OID 2.5.29.15) è la seguente:

03020106

03 è il tag. UNA BIT STRING. 02 è la lunghezza. Il valore è 0106. Ecco cosa dice link sulla codifica di bitstring:

"The initial octet shall encode, as an unsigned binary integer with bit 1 as the least significant bit, the number of
unused bits in the final subsequent octet. The number shall be in the range zero to seven."

Ecco la definizione ASN.1 per questo particolare BIT STRING (dal link ):

-- key usage extension OID and syntax

id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

KeyUsage ::= BIT STRING {
     digitalSignature        (0),
     nonRepudiation          (1),  -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
     keyEncipherment         (2),
     dataEncipherment        (3),
     keyAgreement            (4),
     keyCertSign             (5),
     cRLSign                 (6),
     encipherOnly            (7),
     decipherOnly            (8) }

La mia domanda è ... perché il bitstring finale ha un byte inutilizzato? La mia aspettativa sarebbe che non avrebbe bit inutilizzati poiché la definizione ASN.1 definisce i valori per tutti gli otto bit.

cryptography tls certificates x.509

posta compcert 05.01.2012 - 14:47

fonte

1 risposta

Leggi altre domande sui tag cryptography tls certificates x.509

Come contrastare o correggere la vulnerabilità del banner che afferra Perché compare "Impossibile trovare il limite della funzione corrente" quando sovrascrivo l'indirizzo ret di un programma vulnerabile?

score 3 · Accepted Answer

In ASN.1, ci sono due tipi distinti designati da BIT STRING .

Se hai questo:

Foo ::= BIT STRING

then Foo è un tipo per una stringa di bit generica, con una lunghezza arbitraria e valori arbitrari per ogni bit.

D'altra parte, con questo:

Bar ::= BIT STRING {
    x  (0),
    y  (1),
    z  (2)
}

allora Bar è un tipo per un gruppo di flag e le regole di codifica DER affermano che questi dovrebbero essere codificati come se fosse un generico BIT STRING , ma fermandosi all'ultimo non- zero bit. Quindi, se vuoi codificare un valore di tipo Bar con i flag x e y set, ma non z , allora la codifica deve essere un BIT STRING di lunghezza esattamente due bit, non tre o più. Questo è ciò che DER ha mandato; le regole generiche del BER consentono di aggiungere quanti più bit di valore zero si desidera. Dopo la decodifica, si presume che i flag che superano la lunghezza codificata del codice siano cancellati.

Quindi, per il tuo BIT STRING : 03 02 01 06 decodifica come tale:

03 : a BIT STRING .
02 : il valore consiste nei due byte successivi.
01 : primo byte di valore; per BIT STRING , significa che devi ignorare esattamente 1 bit nell'ultimo byte di valore.
06 : i bit stessi.

In binario, 06 è 00000110 , ma il primo byte di valore dice che dovremo ignorare l'ultimo bit, i byte codificano davvero una stringa di esattamente 7 bit: 0000011 .

L'ultimo bit di quella stringa è un 1, quindi è compatibile con le regole DER. Quando interpretano la stringa di bit come tanti singoli flag, i due stati '1' che i flag numerati 5 e 6 sono impostati (cioè keyCertSign e cRLSign, che è tipico dei certificati CA), mentre tutti altri flag vengono cancellati, anche se il loro indice numerico è più grande della vera stringa di bit codificata.

BER ti consentirebbe di codificare il valore KeyUsage come, ad esempio:

03 04 05 06 00 00

vale a dire. una stringa di 19 bit (tre byte di valore con bit in essi, ma gli ultimi 5 sono ignorati). Ciò significherebbe ancora che i flag keyCertSign e cRLSign sono impostati, quindi la semantica sarebbe identica. Tuttavia, il contenuto del certificato dovrebbe seguire DER, che impone la codifica alla lunghezza minima (gli zero finali vengono rimossi).

Questa particolarità della codifica DER è intesa per la compatibilità con le versioni successive: la codifica DER di una serie di flag dipende da quali flag sono effettivamente impostati, non da quali flag potrebbero essere stati impostati - quindi, una versione successiva di X.509 potrebbe aggiungere nuovi possibili utilizzi chiave, senza rendere non validi (cioè non DER) i certificati che utilizzano la versione precedente.

In realtà, sarebbe stato molto più chiaro se la sintassi ASN.1 non avesse usato " BIT STRING " per due scopi distinti. L'ultimo utilizzo (set di flag) avrebbe dovuto utilizzare una parola chiave distinta esplicita, ad es. " FLAGS ".