Esta página se ha traducido con Cloud Translation API.

Cumplimiento de RFC

Certificate Authority Service usa la herramienta ZLint para asegurarse de que los certificados X.509 sean válidos según las reglas de RFC 5280. Sin embargo, el Servicio de Autoridades de Certificación no aplica todos los requisitos de RFC 5280, por lo que es posible que una CA creada con este servicio emita un certificado no conforme.

En el Servicio de Autoridades de Certificación se aplican los siguientes requisitos de RFC 5280.

Sección RFC 5280	Cláusula de lint
4.1.1.2	El campo signatureAlgorithm de Certificate DEBE contener el mismo identificador de algoritmo que el campo signature de 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 ACs conformes NO DEBEN usar valores de serialNumber de más de 20 octetos.
4.1.2.4	El campo de emisor DEBE contener un nombre distintivo (DN) no vacío.
4.1.2.5	Las CAs que cumplan 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 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 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 GeneralizedTime NO DEBEN incluir fracciones de segundo
4.1.2.6	Si el sujeto es una AC (por ejemplo, si la extensión de restricciones básicas, tal como se describe en la sección 4.2.1.9, está presente y el valor de cA es TRUE), el campo de sujeto DEBE rellenarse con un nombre distintivo no vacío que coincida con el contenido del campo de 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 SOLO deben aparecer si la versión es 2 o 3
4.1.2.8	Las ACs que cumplan este perfil NO DEBEN generar certificados con identificadores únicos.
4.1.2.9	El campo Extensions 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 concreta.
4.2	Si la AC emite certificados con una secuencia vacía para el campo de asunto, DEBE admitir la extensión de nombre alternativo de la entidad.
4.2.1.1	El campo keyIdentifier de la extensión authorityKeyIdentifier DEBE incluirse en todos los certificados generados por las ACs conformes para facilitar la creación de la ruta de certificación.
4.2.1.1	Las CAs conformes DEBEN marcar la extensión authorityKeyIdentifier como no crítica.
4.2.1.2	Para facilitar la creación de la ruta de certificación, authorityKeyIdentifier DEBE aparecer en todos los certificados de AC conformes, es decir, en todos los certificados que incluyan la extensión basicConstraints (sección 4.2.1.9) donde el valor de cA sea TRUE.
4.2.1.2	Las ACs conformes DEBEN marcar la extensión del identificador de clave de asunto como no crítica.
4.2.1.3	Si se afirma el bit keyCertSign, también DEBE afirmarse 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 tener el valor 1.
4.2.1.4	Un OID de 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 usan cualificadores con la política especial anyPolicy, DEBEN limitarse a los cualificadores 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 se vayan a vincular dichas identidades (cualquier elemento de un SAN) a un certificado, DEBE utilizarse 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 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 de Internet, la dirección DEBE almacenarse en `rfc822Name`.
4.2.1.6	En el caso de la versión 4 de IP, tal 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, tal 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	SANs: el dNSName debe tener la "sintaxis de nombre preferida"
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 DNS de las direcciones de correo 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 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 SAN: el nombre DEBE incluir un esquema (por ejemplo, "http" o "ftp") y una parte específica del esquema.
4.2.1.6	Los URIs 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 ACs conformes NO DEBEN emitir certificados con subjectAltNames que contengan campos GeneralName vacíos.
4.2.1.7	El nombre alternativo del emisor DEBE codificarse como en 4.2.1.6.
4.2.1.8	Atributos del directorio de asunto: las autoridades de certificación conformes 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 conformes DEBEN incluir esta extensión en todos los certificados de AC que contengan claves públicas usadas para validar firmas digitales en certificados y DEBEN marcar la extensión como crítica en dichos certificados.
4.2.1.9	Las autoridades de certificación NO DEBEN incluir el campo pathLenConstraint a menos que se haya confirmado el valor booleano cA y la extensión de uso de claves haya confirmado el bit keyCertSign.
4.2.1.10	La extensión de restricciones de nombres, que SOLO se debe usar en un certificado de autoridad de certificación, indica un espacio de nombres en el que se deben encontrar todos los nombres de sujeto de los certificados posteriores de una ruta de certificación.
4.2.1.10	Restricciones de nombres: las autoridades de certificación conformes DEBEN marcar esta extensión como crítica.
4.2.1.10	Las autoridades de certificación conformes 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	En 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 la que se describe en la sección 4.2.1.6, con las siguientes adiciones específicas para las restricciones de nombre: en el caso de 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 intervalo de direcciones [RFC 4632]. En el caso de las direcciones IPv6, el campo iPAddress DEBE contener 32 octetos codificados de forma similar.
4.2.1.11	Las CAs conformes NO DEBEN emitir certificados en los que las restricciones de la política sean una secuencia vacía. Es decir, se debe incluir el campo inhibitPolicyMapping o el campo requireExplicitPolicy.
4.2.1.11	Restricciones de la política: las ACs conformes DEBEN marcar esta extensión como crítica.
4.2.1.13	Un DistributionPoint NO DEBE constar únicamente del campo reasons; debe estar presente distributionPoint o cRLIssuer.
4.2.1.14	Las ACs conformes DEBEN marcar esta extensión Inhibit anyPolicy como crítica.
4.2.1.15	Las ACs conformes DEBEN marcar la extensión CRL más reciente como no crítica.
4.2.2.1	Las autoridades de certificación conformes DEBEN marcar esta extensión de acceso a información de la autoridad como no crítica.
4.2.2.2	Las ACs conformes DEBEN marcar esta extensión de acceso a 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, se DEBE asignar a notAfter el valor GeneralizedTime 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 ACs conformes DEBEN marcar esta extensión de uso de clave como crítica.
4.2.1.4	Las ACs conformes NO DEBEN usar la opción noticeRef.
4.2.1.4	Las autoridades de certificación conformes 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 (por ejemplo, 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 según la forma de normalización C (NFC) de Unicode.
4.2.1.5	Cada issuerDomainPolicy nombrado en la extensión policy mappings también DEBE declararse en una extensión certificate policies del mismo certificado.
4.2.1.5	Las ACs conformes DEBEN marcar esta extensión de asignación de políticas como crítica.
4.2.1.6	Cuando se incluya la extensión subjectAltName en un certificado que tenga un nombre completo de la entidad no vacío, las CAs conformes DEBEN marcar la extensión subjectAltName como no crítica.
4.2.1.7	Cuando esté presente, las ACs conformes DEBERÍAN marcar esta extensión de nombre alternativo del emisor como no crítica.
4.2.1.10	NO DEBE imponer restricciones de nombre en los formularios de nombre x400Address, ediPartyName o registeredID.
4.2.1.12	Las ACs conformes NO DEBEN marcar esta extensión como crítica si está presente el KeyPurposeId anyExtendedKeyUsage.
4.2.1.13	La extensión Puntos de distribución de listas de revocación de certificados (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 ACs conformes NO DEBEN usar nameRelativeToCRLIssuer para especificar nombres de puntos de distribución.
4.2.2.1	Cuando se usa el método de acceso id-ad-caIssuers, al menos una instancia DEBE especificar un 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), tal como se especifica en la sección 4 del RFC 3490, antes de almacenarlos en el campo dNSName.