Cumplimiento de RFC

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

El Servicio de CA aplica los siguientes requisitos de RFC 5280.

Sección RFC 5280	Cláusula de lint
4.1.1.2	El signatureAlgorithm en el certificado DEBE contener el mismo identificador de algoritmo que el campo de firma 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 asignado por la AC a cada certificado.
4.1.2.2	Las AC que cumplen NO DEBEN usar valores de número de serie superiores a 20 octetos.
4.1.2.4	El campo del emisor DEBE tener un nombre distinguido (DN) que no esté vacío.
4.1.2.5	Las AC que cumplen con este perfil DEBEN codificar siempre las fechas de validez de los certificados hasta el año 2049 como UTCTime.
4.1.2.5.1	Los valores UTCTime se DEBEN expresar 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 segundos fraccionarios
4.1.2.6	Si el asunto es una AC (p.ej., si está presente la extensión de restricciones básicas, como se explica en la sección 4.2.1.9, y el valor de cA es TRUE), el campo del asunto DEBE propagarse con un nombre distinguido no vacío que coincida con el contenido del campo del emisor (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 DEBEN aparecer solo si la versión es 2 o 3.
4.1.2.8	Las AC que cumplen 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 la 3.
4.2	Un certificado NO DEBE incluir más de una instancia de una extensión en particular.
4.2	Si la AC emite certificados con una secuencia vacía para el campo del asunto, DEBE admitir la extensión de nombre alternativo del sujeto.
4.2.1.1	Para facilitar la construcción de la ruta de certificación, el campo keyIdentifier de la extensión AuthorityKeyIdentifier se DEBE incluir en todos los certificados generados por las AC compatibles.
4.2.1.1	Las AC que cumplan con las AC 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 la AC que cumplan con los requisitos, es decir, en todos los certificados, incluida la extensión de restricciones básicas (Sección 4.2.1.9) en los que el valor de cA es TRUE.
4.2.1.2	Las CA que cumplan con las AC DEBEN marcar la extensión de identificador de clave de sujeto como no crítica.
4.2.1.3	Si se confirma el bit keyCertSign, también DEBE confirmar el bit de 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.4	El OID de una política de certificados NO DEBE aparecer más de una vez en una extensión de políticas de certificados.
4.2.1.4	Cuando se utilizan calificadores con la política especial anyPolicy, se DEBEN limitar a los calificadores identificados en esta sección.
4.2.1.5	Las políticas NO DEBEN asignarse al valor especial anyPolicy.
4.2.1.6	Cuando esas identidades (cualquier elemento de una SAN) se deban vincular a un certificado, se DEBE usar la extensión de nombre alternativo del sujeto (o nombre alternativo de la entidad emisora).
4.2.1.6	Si el campo de asunto contiene una secuencia vacía, la AC emisora DEBE incluir una extensión subjectAltName que esté 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 IP 4, como se especifica en [RFC 791], la cadena del octeto DEBE contener exactamente cuatro octetos. Para la versión IP 6, como se especifica en [RFC 2460], la cadena del octeto 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 el dNSName (una IA5String).
4.2.1.6	SAN: El valor dNSName DEBE estar en la "sintaxis del nombre preferido"
4.2.1.6	NO se deben usar las extensiones subjectAltName con un dNSName de " "
4.2.1.6	NO DEBE usarse la representación de DNS para las direcciones de correo electrónico de Internet (suscriptor.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 (una IA5String).
4.2.1.6	URI de SAN: El nombre NO DEBE ser un URI relativo y DEBE seguir las reglas de codificación y sintaxis de URI que se especifican en [RFC 3986].
4.2.1.6	URI 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 completo 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 AC que cumplan con los requisitos NO DEBEN emitir certificados con subjectAltNames que contengan campos GeneralName vacíos.
4.2.1.7	El nombre alternativo de la entidad emisora DEBE codificado como en 4.2.1.6
4.2.1.8	Atributos del directorio del sujeto: Las AC que cumplan con las reglamentaciones 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 AC conformes DEBEN incluir esta extensión en todos los certificados de AC que contengan claves públicas utilizadas para validar firmas digitales en los 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 declare el valor booleano cA y la extensión de uso de la clave declare el bit keyCertSign.
4.2.1.10	La extensión de restricciones de nombre, que DEBE usarse solo en un certificado de AC, indica un espacio de nombres dentro del cual se DEBEN ubicar todos los nombres de asuntos de certificados posteriores en una ruta de certificación.
4.2.1.10	Limitaciones de nombres: Las AC que se ajusten a las AC DEBEN marcar esta extensión como crítica.
4.2.1.10	Las ACs que cumplen las AC NO DEBEN emitir certificados cuando las restricciones de nombres sean una secuencia vacía. Es decir, ya sea que el campo allowedSubtrees o los elementos excludedSubtrees DEBEN estar presentes.
4.2.1.10	En este perfil, los campos mínimo y máximo no se utilizan 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íficas para las restricciones de nombre: para las direcciones IPv4, el campo iPAddress de GeneralName DEBE contener ocho (8) octetos, codificados con 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 con una codificación similar.
4.2.1.11	Las AC conformes NO DEBEN emitir certificados cuando las restricciones de políticas sean una secuencia vacía. Es decir, el campo inhibitPolicyMapping o el campo requiredPolicyPolicy DEBEN estar presentes.
4.2.1.11	Restricciones de la política: Las AC que cumplan con las reglamentaciones DEBEN marcar esta extensión como crítica.
4.2.1.13	Un DistributionPoint NO DEBE incluir solo el campo de los motivos. Es decir, “distributionPoint” o “cRLIssuer” DEBEN estar presentes.
4.2.1.14	Las AC que cumplan con la política DEBEN marcar esta extensión Inhibit anyPolicy como crítica.
4.2.1.15	La extensión más reciente de CRL DEBE marcarse como no crítica según las CA que cumplan con los requisitos.
4.2.2.1	Las ACs que cumplan con los requisitos DEBEN marcar esta extensión de acceso a la información de la autoridad como no crítica.
4.2.2.2	Las CA que cumplan con las AC DEBEN marcar esta extensión de Acceso a la información del sujeto como no crítica.
4.1.2.5	Para indicar que un certificado no tiene una fecha de vencimiento bien definida, a notAfter SE DEBE asignar el valor GeneralizedTime de 99991231235959Z.
4.2.1.2	Para ayudar a las aplicaciones a identificar el certificado de entidad final apropiado, esta extensión DEBE incluir en todos los certificados de entidad final
4.2.1.3	Cuando están presentes, las CA compatibles DEBEN marcar esta extensión de uso de claves como crítica.
4.2.1.4	Las CA que cumplan con los requisitos NO DEBEN usar la opción notificationRef.
4.2.1.4	Las CA compatibles DEBEN usar la codificación UTF8String para explícitaText, pero PUEDE usar IA5String.
4.2.1.4	La cadena de explícitaText 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 utiliza la codificación UTF8String, todas las secuencias de caracteres SE DEBEN normalizar según el formato de normalización C (NFC) de Unicode
4.2.1.5	Cada emisorDomainPolicy que se nombra en la extensión de asignaciones de políticas también DEBE confirmarse en una extensión de políticas de certificado en el mismo certificado.
4.2.1.5	Las ACs deben marcar esta extensión de la asignación de políticas como crítica.
4.2.1.6	Cuando se incluye la extensión subjectAltName en un certificado que tiene un nombre distinguido de sujeto no vacío, las CA compatibles DEBEN marcar la extensión subjectAltName como no crítica.
4.2.1.7	Cuando estén presentes, las AC conformes DEBEN marcar esta extensión de Nombre alternativo del emisor como no crítica.
4.2.1.10	NO DEBES imponer restricciones de nombre en los formularios de nombre x400Address, ediPartyName o ID registrado.
4.2.1.12	Las CA que cumplan con las AC NO DEBEN marcar esta extensión como crítica si está presente anyExtendedKeyUsage Key comunesId.
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 de LDAP o HTTP.
4.2.1.13	Las AC que cumplan los requisitos NO DEBEN usar nameRelativeToCRLIssuer para especificar nombres de puntos de distribución.
4.2.2.1	Cuando se usa id-ad-caIssuers accessMethod, al menos una instancia DEBE especificar una accessLocation que sea un URI HTTP [RFC 2616] o LDAP [RFC 4516].
7.2	Para admitir nombres de dominio internacionalizados en la estructura actual, las implementaciones adecuadas DEBEN convertir los nombres de dominio internacionalizados al formato de codificación compatible con ASCII (ACE), como se especifica en la sección 4 de RFC 3490 antes de almacenarlos en el campo dNSName.