Respuesta corta: El RFC (1422) mencionado por Wikipedia no es correcto. No solo se menciona el formato en un RFC anterior (1114), sino que RFC hace referencia correctamente al documento de la UIT que tiene la descripción original: la versión 11/1988 del X.509, disponible aquí . En la sección 8.7 (c) de ese documento, se afirma que "si el valor de un tipo es su valor predeterminado, estará ausente". Por lo tanto, un certificado de la versión 1 es la versión predeterminada y no debe incluirse en el certificado firmado.
Respuesta más larga, con un poco de explicación:
La especificación X.509 más reciente (que no está en un RFC, pero el documento de la UIT no está disponible gratuitamente) que se relaciona con los certificados de clave pública se documenta más recientemente en RFC 5280. Aquí hay una parte de la sección 4.1, que cubre la Codificación ASN.1:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
Dos partes de esta notación que se refieren explícitamente al control de versiones son la etiqueta de la versión en sí misma y las secciones issuerUniqueID, subjectUniqueID y extensiones. La etiqueta de versión dice que el valor predeterminado es v1, y la especificación original dice que los valores predeterminados deben estar ausentes. Cuando las revisiones posteriores de X.509 agregaron versiones, esas nuevas versiones dejaron de ser predeterminadas y aparecieron en el certificado firmado.
Aunque puede utilizar esta especificación más reciente para generar un certificado de clave de pub versión 1, realmente no hay necesidad. Puede etiquetar un nuevo certificado con la etiqueta de la versión 3 (usando el número entero 2), y simplemente elegir no usar ninguna de las nuevas secciones.
La nueva especificación es compatible hacia atrás con el original. ASN.1 se utiliza para la codificación en todas estas revisiones de certificados. La ASN.1 es muy compacta, y se basa principalmente en el formato definido de una estructura para determinar qué significa cualquier campo dado. Es decir, lo que ve con toda la sintaxis "::=" es una definición que sigue cuando analiza el blob de datos que obtiene. El primer campo listado en la secuencia de TBSCertificate es la versión, que es un número entero. El siguiente campo es el número de serie, que también es un número entero. Si falta el campo de versión, que puede ser si el certificado es una versión 1, puede ser realmente difícil saber que el número de serie no es la versión. (Es posible, y es probable, con los certificados CA) que el número de serie sea un número de un solo dígito. La forma de evitar esto, que se utiliza en la especificación que se muestra aquí, es usar el etiquetado DER. Si la etiqueta de la versión está presente, se etiqueta utilizando la etiqueta DER "[0]". El número de serie no está etiquetado, por lo que si encuentra un número entero sin una etiqueta DER, sabrá que es probablemente un certificado de la versión 1. (También es posible que tenga un certificado con formato incorrecto; mire suficientes certificados y encontrará todo tipo de errores de formato ASN.1).
Los certificados de la versión 1 no tienen ninguna de las otras secciones marcadas con etiquetas DER, pero los certificados de la versión 3 (la versión que encontrará con más frecuencia en Internet) tampoco tienen que incluir ninguna o todas esas secciones. Para saber cuál de las secciones, si las hay, están presentes, mire las etiquetas DER. La mayoría de los certificados de la versión 3 tendrán extensiones, pero no issuerUniqueID o subjectUniqueID. En esos certificados, verá la etiqueta [0] para la versión, 1 y [2] para IDs únicos de sujeto y emisor, y etiqueta [3] para extensiones. Muchos de los certificados de versión 3 que encuentra no tienen secciones de ID únicos, por lo que la etiqueta [3] que sigue inmediatamente a subjectPublicKeyInfo es la indicación de que las extensiones están junto a las que se analizarán.
No encontrarás muchos certificados de la versión 2. Debido a que X.509 y ASN.1 no son lo suficientemente confusos, existe una especificación X.509 para los certificados de "atributo", un tipo diferente de certificado que no contiene una clave pública y sigue un formato diferente (con campos similares en un orden diferente) - que siempre están etiquetados como versión 2 por definición. Consulte RFC 5755 para obtener más información y el formato para certificados de atributos.