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 AC no aplica todos los requisitos de RFC 5280 y es posible que una AC creada con el servicio de AC emita un certificado que no cumpla con los requisitos.

El servicio de AC aplica los siguientes requisitos de RFC 5280.

Sección de la RFC 5280 Cláusula 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 que la AC asigne a cada certificado.
4.1.2.2 Las AC que cumplan con los requisitos NO DEBEN usar valores de serialNumber superiores a 20 octetos.
4.1.2.4 El campo del emisor DEBE contener un nombre distinguido (DN) que no esté vacío.
4.1.2.5 Las AC que cumplan con este perfil DEBEN codificar las fechas de validez de los certificados hasta el año 2049 como UTCTime
4.1.2.5.1 Los valores de UTCTime DEBEN expresarse en la hora del meridiano de Greenwich (Zulu).
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 (Zulu).
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 el artículo 4.2.1.9, está presente y el valor de cA es VERDADERO), el campo de asunto DEBE propagarse con un nombre distinguido no vacío que coincida con el contenido del campo del emisor (artículo 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 Extensions DEBE aparecer solo 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 AC emite certificados con una secuencia vacía para el campo de asunto, la AC DEBE admitir la extensión de nombre alternativo de entidad.
4.2.1.1 El campo keyIdentifier de la extensión authorityKeyIdentifier DEBE incluirse en todos los certificados que generen las AC que cumplan con los requisitos para facilitar la construcción de la cadena de certificación.
4.2.1.1 Las AC que cumplan con los requisitos DEBEN marcar la extensión authorityKeyIdentifier como no crítica.
4.2.1.2 Para facilitar la construcción de la cadena de certificación, authorityKeyIdentifier DEBE aparecer en todos los certificados de AC que cumplan con los requisitos, es decir, 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 VERDADERO.
4.2.1.2 Las AC que cumplan con los requisitos DEBEN marcar la extensión del identificador de clave del sujeto como no esencial.
4.2.1.3 Si se confirma el bit keyCertSign, también SE DEBE confirmar 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.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.5 Las políticas NO DEBEN asignarse al valor especial anyPolicy ni desde él.
4.2.1.6 Siempre que esas identidades (cualquier elemento de un SAN) se vinculen 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 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 4 de IP, como se especifica en [RFC 791], la cadena de octetos DEBE contener exactamente cuatro octetos. En el caso de la versión 6 de 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 DEBEN usarse extensiones subjectAltName con un dNSName de “”.
4.2.1.6 NO SE DEBE usar la representación DNS para las direcciones de correo electrónico de Internet (subscriber.example.com en lugar de subscriber@example.com).
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 URIs 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 AC que cumplan con los requisitos NO DEBEN emitir certificados con nombres alternativos de sujeto que contengan campos GeneralName vacíos.
4.2.1.7 El nombre alternativo del emisor DEBE codificarse como se indica en 4.2.1.6.
4.2.1.8 Atributos del directorio de sujetos: Las AC que cumplan con la norma 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 que cumplan con la norma DEBEN incluir esta extensión en todos los certificados de AC que contengan claves públicas que se usen para validar las firmas digitales en los certificados y DEBEN marcar la extensión como fundamental en esos certificados.
4.2.1.9 Las AC NO DEBEN incluir el campo pathLenConstraint, a menos que se confirme el valor booleano cA y la extensión de uso de la clave confirme el bit keyCertSign.
4.2.1.10 La extensión de restricciones de nombres, que DEBE usarse solo en un certificado de AC, indica un espacio de nombres dentro del cual DEBEN ubicarse todos los nombres de sujeto en los certificados posteriores de una ruta de certificación.
4.2.1.10 Restricciones de nombres: Las AC que cumplan con los requisitos DEBEN marcar esta extensión como fundamental.
4.2.1.10 Las AC que cumplan con los requisitos NO DEBEN emitir certificados en los que las restricciones de nombres sean una secuencia vacía. Es decir, el campo permittedSubtrees o el campo excludedSubtrees DEBEN estar presentes.
4.2.1.10 Dentro de este perfil, los campos mínimo y máximo no se usan con ningún formulario 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 como se describe en el artículo 4.2.1.6 con las siguientes incorporaciones específicas para las restricciones de nombres: Para las direcciones IPv4, el campo iPAddress de GeneralName DEBE contener ocho (8) octetos, codificados al 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.11 Las AC que cumplen con los requisitos NO DEBEN emitir certificados en los que las restricciones de políticas sean una secuencia vacía. Es decir, el campo inhibitPolicyMapping o el campo requireExplicitPolicy DEBEN estar presentes.
4.2.1.11 Restricciones de políticas: Las AC que cumplan con los requisitos DEBEN marcar esta extensión como fundamental.
4.2.1.13 Un DistributionPoint NO DEBE consistir solo en el campo de motivos. Deben estar presentes distributionPoint o cRLIssuer.
4.2.1.14 Las AC que cumplan con la política DEBEN marcar esta extensión de 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 AC 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 AC que cumplan con los requisitos DEBEN marcar esta extensión de acceso a la información del sujeto como no esencial.
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.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 Cuando esté presente, las AC que cumplan con los requisitos DEBEN marcar esta extensión de uso de la clave como fundamental.
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 DEBEN normalizarse de acuerdo con el formulario de normalización C (NFC) de Unicode.
4.2.1.5 Cada issuerDomainPolicy nombrado en la extensión de asignaciones de políticas también DEBE afirmarse en una extensión de políticas de certificados en el mismo certificado.
4.2.1.5 Las AC que cumplan con la política DEBEN marcar esta extensión de asignaciones de políticas como fundamental.
4.2.1.6 Cuando se incluye la extensión subjectAltName en un certificado que tiene un nombre distinguido del sujeto no vacío, las AC que cumplen con el estándar DEBEN marcar la extensión subjectAltName como no esencial.
4.2.1.7 Cuando esté presente, las AC que cumplan con los requisitos DEBEN marcar esta extensión de nombre alternativo del emisor como no esencial.
4.2.1.10 NO DEBE imponer restricciones de nombres en los formularios de nombres x400Address, ediPartyName o registeredID.
4.2.1.12 Las AC que cumplan con los requisitos NO DEBEN marcar esta extensión como fundamental si está presente el KeyPurposeId anyExtendedKeyUsage.
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 AC que cumplen con los requisitos NO DEBEN usar nameRelativeToCRLIssuer para especificar los nombres de los puntos de distribución.
4.2.2.1 Cuando se usa el accessMethod id-ad-caIssuers, 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 conformes DEBEN convertir los nombres de dominio internacionalizados al formato de codificación compatible con ASCII (ACE), como se especifica en el artículo 4 de la RFC 3490, antes de almacenarlos en el campo dNSName.