¿Por qué el RFC 5280 dicta que las CA no emitan certificados con números de serie negativos?

3

He intentado emitir un certificado que comienza con 8 a F pero he encontrado que es imposible, principalmente debido a la RFC:

  

El número de serie DEBE ser un número entero positivo asignado por la CA para   cada certificado DEBE ser único para cada certificado emitido por un   CA dada (es decir, el nombre del emisor y el número de serie identifican un único   certificado). Las CA DEBEN forzar el número de serie para que no sea negativo   entero .

¿Entonces me gustaría saber si hay alguna razón real para no hacerlo más allá de la "implementación ASN.1 con errores"?

    
pregunta kiBytes 18.02.2014 - 17:06
fuente

3 respuestas

5

Respuesta corta: porque RFC 3280 , su predecesor, lo dice.

Respuesta más larga: porque históricamente los codificadores / decodificadores ASN.1 han tenido problemas con la codificación y decodificación de los enteros correctamente.

X.509 utiliza DER ASN.1 codificado , que entre otras cosas significa que los datos debe estar codificado en su forma mínima (la más corta). Como los enteros se almacenan en una forma de dos complementos de longitud variable, para codificar correctamente un entero no negativo que tiene su bit de inicio (MSB) establecido, se debe rellenar con un cero inicial, que en otras circunstancias no está permitido . La redacción de X.690 ( enlace ) es tal que los 9 bits iniciales de un entero deben inspeccionarse para verificar la forma mínima, permitiendo así que los enteros positivos tengan 0 bytes iniciales.

A cita a Peter Gutmann

  

Hay un segundo pero: Históricamente, muchos codificadores han obtenido la firma de   enteros incorrectos, lo que significa que (a) si obtienes un número negativo (al menos en   el área de criptografía, con la que estoy más familiarizado) siempre es una codificación   error y nunca un uso deliberado de un valor negativo, y (b) debido a la   el uso generalizado de codificadores incorrectos, muchos decodificadores tratan todos los valores enteros   como sin firmar Entonces, si bien puedes usar valores negativos en teoría, no es una buena idea.   Idea en la práctica.

La determinación correcta de los números de serie es crítica cuando se trata de verificaciones de revocación. La ambigüedad es un enemigo.

Me parece que esto es exactamente el problema que tiene su codificador ...

    
respondido por el mr.spuratic 18.02.2014 - 22:44
fuente
2

ASN.1 define el OID número de serie de 2.5.4.5 como una PrintableString. No se define como un atributo numérico, por lo tanto, se permiten los caracteres imprimibles y no se requiere ni se interpreta ningún signo.

enlace

serialNumber ATTRIBUTE ::= {
  WITH SYNTAX               PrintableString(SIZE (1..MAX))
  EQUALITY MATCHING RULE    caseIgnoreMatch
  SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
  LDAP-SYNTAX               printableString.&id
  LDAP-NAME                 {"serialNumber"}
  ID                        id-at-serialNumber
}

Sin embargo, RFC 2459 define a CertificateSerialNumber como un INTEGER.

enlace

Califica los números de serie de esta manera:

4.1.2.2  Serial number

The serial number is an integer assigned by the CA to each
certificate.  It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate).

Por lo tanto, la restricción proviene de los RFC, no de ASN.1

    
respondido por el John Deters 18.02.2014 - 19:43
fuente
0

Porque un número de serie está diseñado para ser un número incremental no negativo.

Básicamente es un código de control de inventario para una CA, y son números incrementales no negativos en la mayoría de los sistemas de inventario.

    
respondido por el Steve 18.02.2014 - 18:22
fuente

Lea otras preguntas en las etiquetas