analizando la extensión id-ce-keyUsage en certificados X.509

Question

analizando la extensión id-ce-keyUsage en certificados X.509

#1 de Thomas Pornin (3 votos)

3

Estoy intentando decodificar un certificado X.509 y tengo una pregunta sobre la decodificación de las extensiones. En particular, la cadena de octetos correspondiente a id-ce-keyUsage (OID 2.5.29.15) es la siguiente:

03020106

03 es la etiqueta. Una cadena de bits. 02 es la longitud. El valor es 0106. Esto es lo que enlace dice acerca de la codificación de cadenas de bits:

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

Aquí está la definición de ASN.1 para esta BIT STRING en particular (de enlace ):

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

Mi pregunta es ... ¿por qué la cadena de bits final tiene un byte no utilizado? Mi expectativa sería que no tendría bits no utilizados ya que la definición ASN.1 define valores para los ocho bits.

cryptography tls certificates x.509

pregunta compcert 05.01.2012 - 14:47

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography tls certificates x.509

Shellcode que es más pequeño que 295 bytes que genera un shell [cerrado] Cómo informarme en metasploit cuando un usuario hace una shell inversa a mi computadora

score 3 · Accepted Answer

En ASN.1, hay dos tipos distintos que están designados por BIT STRING .

Si tienes esto:

Foo ::= BIT STRING

entonces Foo es un tipo para una cadena de bits genérica, con una longitud arbitraria y valores arbitrarios para cada bit.

Por otro lado, con esto:

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

entonces Bar es un tipo para un conjunto de indicadores , y las reglas de codificación DER indican que estos deben codificarse como si fuera un BIT STRING genérico, pero deteniéndose en el último no. bit cero. Por lo tanto, si desea codificar un valor de tipo Bar con los indicadores x y y establecidos, pero no z , entonces la codificación debe ser un BIT STRING de longitud exactamente dos bits, no tres o más. Eso es lo que DER ordena; Las reglas BER genéricas permiten agregar tantos bits extra de valor cero como desee. Tras la decodificación, se supone que las marcas que están más allá de la longitud del código codificado se borran.

Por lo tanto, para su BIT STRING : 03 02 01 06 se decodifica como tal:

03 : a BIT STRING .
02 : el valor consiste en los siguientes dos bytes.
01 : primer byte de valor; para un BIT STRING , significa que deberá ignorar exactamente 1 bit en el último byte de valor.
06 : los bits en sí mismos.

En binario, 06 es 00000110 , pero el primer byte de valor dice que ignoraremos el último bit, ya que los bytes realmente codifican una cadena de exactamente 7 bits: 0000011 .

El último bit de esa cadena es un 1, por lo que es compatible con las reglas DER. Cuando interpreta la cadena de bits como tantos indicadores individuales, los dos estados '1' indican que los indicadores numerados 5 y 6 se establecen (es decir, keyCertSign y cRLSign, respectivamente, que es típico de los certificados de CA), otras marcas se borran, incluso si su índice numérico es mayor que la cadena de bits codificada real.

BER le permitiría codificar ese valor de KeyUsage como, por ejemplo:

03 04 05 06 00 00

es decir, una cadena de 19 bits (tres bytes de valor con bits en ellos, pero los últimos 5 se ignoran). Esto aún indicaría que los indicadores keyCertSign y cRLSign están establecidos, por lo que la semántica sería idéntica. Sin embargo, el contenido del certificado debe seguir DER, que exige la codificación a la longitud mínima (se eliminan los ceros finales).

Esta particularidad de la codificación DER está pensada para la compatibilidad con versiones posteriores: la codificación DER de un conjunto de indicadores depende de qué indicadores se establecen realmente, no de qué indicadores podrían se han establecido, por lo tanto, una versión X.509 posterior podría agregar nuevos usos clave posibles, sin hacer certificados inválidos (es decir, que no sean DER) que usen la versión anterior.

Realmente, esto hubiera sido mucho más claro si la sintaxis ASN.1 no hubiera usado " BIT STRING " para dos propósitos distintos. El último uso (conjunto de indicadores) debería haber utilizado una palabra clave distinta explícita, por ejemplo, " FLAGS ".