Cumplimiento de RFC

Certificate Authority Service usa la herramienta ZLint para garantizar que los certificados X.509 sean válidos según las reglas de la RFC 5280. Sin embargo, el servicio de CA no aplica todos los requisitos de la RFC 5280, y es posible que una CA creada con el servicio de CA emita un certificado que no cumpla con los requisitos.

El servicio de CA aplica los siguientes requisitos de la RFC 5280.

Sección del RFC 5280	Cláusula de lint
4.1.1.2	El parámetro signatureAlgorithm en Certificate DEBE contener el mismo identificador de algoritmo que el campo signature en la secuencia tbsCertificate (sección 4.1.2.3).
4.1.2.1	Cuando se usan extensiones, como se espera en este perfil, la versión DEBE ser 3 (el valor es 2).
4.1.2.2	El número de serie DEBE ser un número entero positivo que la CA asigne a cada certificado.
4.1.2.2	Las CA que cumplen con los requisitos NO DEBEN usar valores de serialNumber que superen los 20 octetos.
4.1.2.4	El campo del emisor DEBE contener un nombre distintivo (DN) no vacío.
4.1.2.5	Las AC que cumplan con este perfil DEBEN codificar siempre las fechas de validez del certificado hasta el año 2049 como UTCTime.
4.1.2.5	Para indicar que un certificado no tiene una fecha de vencimiento bien definida, se DEBE asignar a notAfter el valor GeneralizedTime de 99991231235959Z.
4.1.2.5.1	Los valores de UTCTime DEBEN expresarse en la hora del meridiano de Greenwich (zulú).
4.1.2.5.1	Los valores de UTCTime DEBEN incluir segundos.
4.1.2.5.2	Los valores de GeneralizedTime DEBEN expresarse en la hora del meridiano de Greenwich (zulú).
4.1.2.5.2	GeneralizedTime DEBE incluir segundos
4.1.2.5.2	Los valores de GeneralizedTime NO DEBEN incluir fracciones de segundo.
4.1.2.6	Si el sujeto es una AC (p.ej., la extensión de restricciones básicas, como se explica en la sección 4.2.1.9, está presente y el valor de cA es TRUE), el campo del sujeto DEBE completarse con un nombre distintivo no vacío que coincida con el contenido del campo de la entidad emisora (sección 4.1.2.4) en todos los certificados emitidos por la AC del sujeto.
4.1.2.8	Los campos de identificador único SOLO deben aparecer si la versión es 2 o 3.
4.1.2.8	Las AC que cumplan con este perfil NO DEBEN generar certificados con identificadores únicos.
4.1.2.9	El campo de extensiones SOLO DEBE aparecer si la versión es 3
4.2	Un certificado NO DEBE incluir más de una instancia de una extensión en particular.
4.2	Si la CA emite certificados con una secuencia vacía para el campo de asunto, la CA DEBE admitir la extensión de nombre alternativo del asunto.
4.2.1.1	El campo keyIdentifier de la extensión authorityKeyIdentifier DEBE incluirse en todos los certificados generados por las CA que cumplan con los requisitos para facilitar la construcción de la ruta de certificación.
4.2.1.1	Las ACs que cumplen con los requisitos DEBEN marcar la extensión authorityKeyIdentifier como no crítica.
4.2.1.2	Para facilitar la construcción de la ruta de certificación, authorityKeyIdentifier DEBE aparecer en todos los certificados de CA que cumplan con los requisitos, es decir, en todos los certificados que incluyan la extensión de restricciones básicas (sección 4.2.1.9) en la que el valor de cA sea TRUE.
4.2.1.2	Las ACs que cumplen con los requisitos DEBEN marcar la extensión del identificador de clave del sujeto como no crítica.
4.2.1.2	Para ayudar a las aplicaciones a identificar el certificado de entidad final adecuado, esta extensión DEBE incluirse en todos los certificados de entidad final.
4.2.1.3	Si se establece el bit keyCertSign, también SE DEBE establecer el bit cA en la extensión de restricciones básicas (sección 4.2.1.9).
4.2.1.3	Cuando la extensión keyUsage aparece en un certificado, al menos uno de los bits DEBE establecerse en 1.
4.2.1.3	Cuando esté presente, las CA que cumplan con los requisitos DEBEN marcar esta extensión de Uso de la clave como crítica.
4.2.1.4	Un OID de política de certificado NO DEBE aparecer más de una vez en una extensión de políticas de certificado.
4.2.1.4	Cuando se usan calificadores con la política especial anyPolicy, DEBEN limitarse a los calificadores identificados en esta sección.
4.2.1.4	Las AC que cumplen con los requisitos NO DEBEN usar la opción noticeRef.
4.2.1.4	Las AC que cumplen con los requisitos DEBEN usar la codificación UTF8String para explicitText, pero PUEDEN usar IA5String.
4.2.1.4	La cadena explicitText NO DEBE incluir ningún carácter de control (p.ej., U+0000 a U+001F y U+007F a U+009F).
4.2.1.4	Cuando se usa la codificación UTF8String, todas las secuencias de caracteres SE DEBEN normalizar según la forma de normalización C (NFC) de Unicode.
4.2.1.5	Las políticas NO DEBEN asignarse al valor especial anyPolicy ni desde él.
4.2.1.5	Cada issuerDomainPolicy que se mencione en la extensión de asignaciones de políticas TAMBIÉN se debe confirmar en una extensión de políticas de certificados en el mismo certificado.
4.2.1.5	Las CA que cumplan con los requisitos DEBEN marcar esta extensión de asignaciones de políticas como crítica.
4.2.1.6	Siempre que se deban vincular dichas identidades (cualquier elemento en un SAN) a un certificado, se DEBE usar la extensión de nombre alternativo del sujeto (o nombre alternativo del emisor).
4.2.1.6	Si el campo del sujeto contiene una secuencia vacía, la CA emisora DEBE incluir una extensión subjectAltName marcada como crítica.
4.2.1.6	Cuando la extensión subjectAltName contiene una dirección de correo electrónico de Internet, la dirección DEBE almacenarse en rfc822Name.
4.2.1.6	Para la versión 4 del IP, como se especifica en [RFC 791], la cadena de octetos DEBE contener exactamente cuatro octetos. En el caso de la versión 6 del IP, como se especifica en [RFC 2460], la cadena de octetos DEBE contener exactamente dieciséis octetos.
4.2.1.6	Cuando la extensión subjectAltName contiene una etiqueta del sistema de nombres de dominio, el nombre de dominio DEBE almacenarse en dNSName (un IA5String).
4.2.1.6	SAN: El dNSName DEBE estar en la "sintaxis de nombre preferido".
4.2.1.6	NO se deben usar extensiones subjectAltName con un dNSName de " ".
4.2.1.6	NO se debe usar la representación de DNS para las direcciones de correo electrónico de Internet (subscriber.example.com en lugar de [e-mail]).
4.2.1.6	Cuando la extensión subjectAltName contiene un URI, el nombre DEBE almacenarse en uniformResourceIdentifier (un IA5String).
4.2.1.6	URIs de SAN: El nombre NO DEBE ser un URI relativo y DEBE seguir la sintaxis de URI y las reglas de codificación especificadas en [RFC 3986].
4.2.1.6	URIs de SAN: El nombre DEBE incluir un esquema (p.ej., "http" o "ftp") y una parte específica del esquema.
4.2.1.6	Los URI de SAN que incluyen una autoridad ([RFC 3986], sección 3.2) DEBEN incluir un nombre de dominio completamente calificado o una dirección IP como host.
4.2.1.6	Si la extensión subjectAltName está presente, la secuencia DEBE contener al menos una entrada.
4.2.1.6	Las ACs que cumplan con los requisitos NO DEBEN emitir certificados con subjectAltNames que contengan campos GeneralName vacíos.
4.2.1.6	Cuando se incluye la extensión subjectAltName en un certificado que tiene un nombre distintivo del sujeto no vacío, las ACs que cumplen con los requisitos DEBEN marcar la extensión subjectAltName como no crítica.
4.2.1.7	El nombre alternativo del emisor DEBE codificarse como en 4.2.1.6
4.2.1.7	Cuando esté presente, las CA que cumplan con los requisitos DEBEN marcar esta extensión de nombre alternativo de la entidad emisora como no crítica.
4.2.1.8	Atributos del directorio de asunto: Las ACs que cumplan con los requisitos DEBEN marcar esta extensión como no crítica.
4.2.1.9	Cuando aparece, el campo pathLenConstraint DEBE ser mayor o igual que cero.
4.2.1.9	Las ACs que cumplan con los requisitos DEBEN incluir esta extensión en todos los certificados de AC que contengan claves públicas que se usen para validar firmas digitales en certificados y DEBEN marcar la extensión como crítica en dichos certificados.
4.2.1.9	Las AC NO DEBEN incluir el campo pathLenConstraint, a menos que se confirme el valor booleano de cA y la extensión de uso de la clave confirme el bit de keyCertSign.
4.2.1.10	La extensión de restricciones de nombres, que SOLO se debe usar en un certificado de CA, indica un espacio de nombres dentro del cual se deben ubicar todos los nombres del asunto en los certificados posteriores de una ruta de certificación.
4.2.1.10	Restricciones de nombres: Las ACs que cumplan con los requisitos DEBEN marcar esta extensión como fundamental
4.2.1.10	Las AC que cumplen con los requisitos NO DEBEN emitir certificados en los que las restricciones de nombres sean una secuencia vacía. Es decir, debe estar presente el campo permittedSubtrees o el campo excludedSubtrees.
4.2.1.10	Dentro de este perfil, los campos mínimo y máximo no se usan con ninguna forma de nombre, por lo que el mínimo DEBE ser cero y el máximo DEBE estar ausente.
4.2.1.10	La sintaxis de iPAddress DEBE ser la que se describe en la sección 4.2.1.6 con las siguientes adiciones específicamente para las restricciones de nombres: Para las direcciones IPv4, el campo iPAddress de GeneralName DEBE contener ocho (8) octetos, codificados según el estilo de RFC 4632 (CIDR) para representar un rango de direcciones [RFC 4632]. Para las direcciones IPv6, el campo iPAddress DEBE contener 32 octetos codificados de manera similar.
4.2.1.10	NO DEBE imponer restricciones de nombres en los formularios de nombres x400Address, ediPartyName o registeredID.
4.2.1.11	Las CA que cumplen con los requisitos NO DEBEN emitir certificados en los que las restricciones de política sean una secuencia vacía. Es decir, DEBE estar presente el campo inhibitPolicyMapping o el campo requireExplicitPolicy.
4.2.1.11	Restricciones de la política: Las CA que cumplan con los requisitos DEBEN marcar esta extensión como crítica.
4.2.1.12	Las CA que cumplen con los requisitos NO DEBEN marcar esta extensión como crítica si está presente el KeyPurposeId anyExtendedKeyUsage.
4.2.1.13	Un DistributionPoint NO DEBE constar solo del campo reasons; debe estar presente distributionPoint o cRLIssuer.
4.2.1.13	La extensión de puntos de distribución de la CRL DEBE ser no crítica
4.2.1.13	Cuando está presente, DistributionPointName DEBE incluir al menos un URI LDAP o HTTP.
4.2.1.13	Las entidades de certificación que cumplen con los requisitos NO DEBEN usar nameRelativeToCRLIssuer para especificar los nombres de los puntos de distribución.
4.2.1.14	Las CA que cumplen con los requisitos DEBEN marcar esta extensión Inhibit anyPolicy como crítica.
4.2.1.15	Las AC que cumplan con los requisitos DEBEN marcar la extensión de CRL más reciente como no crítica.
4.2.2.1	Las CA que cumplen con los requisitos DEBEN marcar esta extensión de acceso a la información de la autoridad como no crítica.
4.2.2.1	Cuando se usa el método de acceso id-ad-caIssuers, al menos una instancia DEBE especificar una accessLocation que sea un URI HTTP [RFC 2616] o LDAP [RFC 4516].
4.2.2.2	Las CA que cumplen con los requisitos DEBEN marcar esta extensión de Subject Information Access como no crítica.
7.2	Para admitir nombres de dominio internacionalizados en la estructura actual, las implementaciones que cumplan con los requisitos DEBEN convertir los nombres de dominio internacionalizados al formato de codificación compatible con ASCII (ACE) según se especifica en la sección 4 del RFC 3490 antes de almacenarlos en el campo dNSName.