Esta página foi traduzida pela API Cloud Translation.

Conformidade com o RFC

O serviço de autoridade de certificação usa a ferramenta ZLint para garantir que os certificados X.509 são válidos de acordo com as regras da RFC 5280. No entanto, o CA Service não aplica todos os requisitos da RFC 5280 e é possível que uma AC criada através do CA Service emita um certificado não compatível.

O serviço de AC aplica os seguintes requisitos da RFC 5280.

Secção RFC 5280	Cláusula de lint
4.1.1.2	O signatureAlgorithm no certificado TEM de conter o mesmo identificador de algoritmo que o campo de assinatura na sequência tbsCertificate (secção 4.1.2.3).
4.1.2.1	Quando são usadas extensões, como esperado neste perfil, a versão TEM de ser 3 (o valor é 2).
4.1.2.2	O número de série TEM de ser um número inteiro positivo atribuído pela CA a cada certificado.
4.1.2.2	As ACs em conformidade NÃO DEVEM usar valores serialNumber com mais de 20 octetos.
4.1.2.4	O campo issuer TEM de conter um nome distinto (DN) não vazio.
4.1.2.5	As ACs em conformidade com este perfil TÊM SEMPRE de codificar as datas de validade dos certificados até ao ano 2049 como UTCTime
4.1.2.5.1	Os valores UTCTime TÊM de ser expressos na Hora do Meridiano de Greenwich (Zulu)
4.1.2.5.1	Os valores de UTCTime TÊM de incluir segundos
4.1.2.5.2	Os valores GeneralizedTime têm de ser expressos na Hora do Meridiano de Greenwich (Zulu)
4.1.2.5.2	GeneralizedTime TEM de incluir segundos
4.1.2.5.2	Os valores GeneralizedTime NÃO DEVEM incluir frações de segundos
4.1.2.6	Se o assunto for uma AC (por exemplo, a extensão de restrições básicas, conforme abordado na secção 4.2.1.9, estiver presente e o valor de cA for TRUE), o campo de assunto TEM de ser preenchido com um nome distinto não vazio que corresponda ao conteúdo do campo de emissor (secção 4.1.2.4) em todos os certificados emitidos pela AC de assunto.
4.1.2.8	Os campos de identificador exclusivo SÓ podem aparecer se a versão for 2 ou 3
4.1.2.8	As ACs em conformidade com este perfil NÃO DEVEM gerar certificados com identificadores únicos.
4.1.2.9	O campo Extensions SÓ pode aparecer se a versão for 3
4.2	Um certificado NÃO PODE incluir mais do que uma instância de uma extensão específica.
4.2	Se a AC emitir certificados com uma sequência vazia para o campo do assunto, a AC TEM de suportar a extensão do nome alternativo do assunto
4.2.1.1	O campo keyIdentifier da extensão authorityKeyIdentifier TEM de ser incluído em todos os certificados gerados por ACs em conformidade para facilitar a construção do caminho de certificação.
4.2.1.1	As ACs em conformidade TÊM de marcar a extensão authorityKeyIdentifier como não crítica.
4.2.1.2	Para facilitar a criação do caminho de certificação, o authorityKeyIdentifier TEM de aparecer em todos os certificados da AC em conformidade, ou seja, todos os certificados que incluem a extensão de restrições básicas (secção 4.2.1.9) em que o valor de cA é TRUE.
4.2.1.2	As ACs em conformidade TÊM de marcar a extensão do identificador de chave do sujeito como não crítica.
4.2.1.3	Se o bit keyCertSign for afirmado, o bit cA na extensão de restrições básicas (secção 4.2.1.9) TAMBÉM tem de ser afirmado.
4.2.1.3	Quando a extensão keyUsage aparece num certificado,, pelo menos, um dos bits TEM de estar definido como 1.
4.2.1.4	Um OID de política de certificado NÃO PODE aparecer mais do que uma vez numa extensão de políticas de certificado.
4.2.1.4	Quando os qualificadores são usados com a política especial anyPolicy, TÊM de se limitar aos qualificadores identificados nesta secção.
4.2.1.5	As políticas NÃO DEVEM ser mapeadas para nem a partir do valor especial anyPolicy
4.2.1.6	Sempre que essas identidades (qualquer coisa num SAN) tiverem de ser associadas a um certificado, tem de ser usada a extensão do nome alternativo do assunto (ou do emissor);
4.2.1.6	Se o campo do assunto contiver uma sequência vazia, a AC emissora TEM de incluir uma extensão subjectAltName marcada como crítica.
4.2.1.6	Quando a extensão subjectAltName contém um endereço de email da Internet, o endereço TEM de ser armazenado no `rfc822Name`.
4.2.1.6	Para a versão 4 do IP, conforme especificado em [RFC 791], a string de octetos TEM de conter exatamente quatro octetos. Para a versão 6 do IP, conforme especificado na [RFC 2460], a string de octetos TEM de conter exatamente dezasseis octetos.
4.2.1.6	Quando a extensão subjectAltName contém uma etiqueta do sistema de nomes de domínio, o nome de domínio TEM de ser armazenado no dNSName (um IA5String).
4.2.1.6	SANs: o dNSName TEM de estar na "sintaxe de nome preferencial"
4.2.1.6	As extensões subjectAltName com um dNSName de " " NÃO DEVEM ser usadas
4.2.1.6	A representação DNS para endereços de correio eletrónico da Internet (subscriber.example.com em vez de subscriber@example.com) NÃO DEVE ser usada
4.2.1.6	Quando a extensão subjectAltName contém um URI, o nome TEM de ser armazenado no uniformResourceIdentifier (um IA5String).
4.2.1.6	URIs SAN: o nome NÃO PODE ser um URI relativo e TEM de seguir a sintaxe de URI e as regras de codificação especificadas em [RFC 3986].
4.2.1.6	URIs SAN: o nome TEM de incluir um esquema (por exemplo, "http" ou "ftp") e uma parte específica do esquema.
4.2.1.6	Os URIs SAN que incluem uma autoridade ([RFC 3986], Section 3.2) TÊM de incluir um nome de domínio totalmente qualificado ou um endereço IP como anfitrião.
4.2.1.6	Se a extensão subjectAltName estiver presente, a sequência TEM de conter, pelo menos, uma entrada.
4.2.1.6	As ACs em conformidade NÃO DEVEM emitir certificados com subjectAltNames que contenham campos GeneralName vazios.
4.2.1.7	O nome alternativo do emissor TEM de ser codificado como em 4.2.1.6
4.2.1.8	Atributos do diretório do proprietário: as ACs em conformidade TÊM de marcar esta extensão como não crítica.
4.2.1.9	Quando aparece, o campo pathLenConstraint TEM de ser igual ou superior a zero.
4.2.1.9	As ACs em conformidade TÊM de incluir esta extensão em todos os certificados de AC que contenham chaves públicas usadas para validar assinaturas digitais em certificados e TÊM de marcar a extensão como crítica nesses certificados.
4.2.1.9	As ACs NÃO DEVEM incluir o campo pathLenConstraint, a menos que o booleano cA seja afirmado e a extensão de utilização da chave afirme o bit keyCertSign.
4.2.1.10	A extensão de restrições de nomes, que TEM de ser usada apenas num certificado de AC, indica um espaço de nomes no qual todos os nomes de assuntos nos certificados subsequentes num caminho de certificação TÊM de estar localizados.
4.2.1.10	Restrições de nomes: as ACs em conformidade TÊM de marcar esta extensão como crítica
4.2.1.10	As ACs em conformidade NÃO DEVEM emitir certificados em que as restrições de nomes sejam uma sequência vazia. Ou seja, o campo permittedSubtrees ou o campo excludedSubtrees TEM de estar presente.
4.2.1.10	Neste perfil, os campos mínimo e máximo não são usados com nenhuma forma de nome. Por isso, o mínimo TEM de ser zero e o máximo TEM de estar ausente.
4.2.1.10	A sintaxe de iPAddress TEM de ser conforme descrito na secção 4.2.1.6 com as seguintes adições especificamente para restrições de nomes: para endereços IPv4, o campo iPAddress de GeneralName TEM de conter oito (8) octetos, codificados no estilo da RFC 4632 (CIDR) para representar um intervalo de endereços [RFC 4632]. Para endereços IPv6, o campo iPAddress TEM de conter 32 octetos codificados de forma semelhante.
4.2.1.11	As ACs em conformidade NÃO DEVEM emitir certificados em que as restrições de políticas sejam uma sequência vazia. Ou seja, o campo inhibitPolicyMapping ou o campo requireExplicitPolicy TEM de estar presente.
4.2.1.11	Restrições de políticas: as ACs em conformidade TÊM de marcar esta extensão como crítica.
4.2.1.13	Um DistributionPoint NÃO PODE consistir apenas no campo reasons; tem de estar presente distributionPoint ou cRLIssuer.
4.2.1.14	As ACs em conformidade TÊM de marcar esta extensão Inhibit anyPolicy como crítica.
4.2.1.15	A extensão CRL mais recente TEM de ser marcada como não crítica pelas ACs em conformidade.
4.2.2.1	As ACs em conformidade TÊM de marcar esta extensão de acesso às informações da autoridade como não crítica.
4.2.2.2	As ACs em conformidade TÊM de marcar esta extensão de acesso às informações do proprietário como não crítica.
4.1.2.5	Para indicar que um certificado não tem uma data de validade bem definida, o valor notAfter DEVE ser atribuído ao valor GeneralizedTime de 99991231235959Z.
4.2.1.2	Para ajudar as aplicações a identificar o certificado de entidade final adequado, esta extensão DEVE ser incluída em todos os certificados de entidade final
4.2.1.3	Quando presente, as ACs em conformidade DEVEM marcar esta extensão de utilização da chave como crítica.
4.2.1.4	As ACs em conformidade NÃO DEVEM usar a opção noticeRef.
4.2.1.4	As ACs em conformidade DEVEM usar a codificação UTF8String para explicitText, mas PODEM usar IA5String.
4.2.1.4	A string explicitText NÃO DEVE incluir carateres de controlo (por exemplo, U+0000 a U+001F e U+007F a U+009F).
4.2.1.4	Quando a codificação UTF8String é usada, todas as sequências de carateres DEVEM ser normalizadas de acordo com a forma de normalização C (NFC) do Unicode
4.2.1.5	Cada issuerDomainPolicy nomeado na extensão de mapeamentos de políticas TAMBÉM DEVE ser afirmado numa extensão de políticas de certificados no mesmo certificado.
4.2.1.5	As ACs em conformidade DEVEM marcar esta extensão de mapeamentos de políticas como crítica.
4.2.1.6	Quando incluem a extensão subjectAltName num certificado que tem um nome distinto do assunto não vazio, as ACs em conformidade DEVEM marcar a extensão subjectAltName como não crítica.
4.2.1.7	Quando presente, as ACs em conformidade DEVEM marcar esta extensão do nome alternativo do emissor como não crítica.
4.2.1.10	NÃO DEVE impor restrições de nomes nos formulários de nomes x400Address, ediPartyName ou registeredID.
4.2.1.12	As ACs em conformidade NÃO DEVEM marcar esta extensão como crítica se o KeyPurposeId anyExtendedKeyUsage estiver presente.
4.2.1.13	A extensão de pontos de distribuição da CRL DEVE não ser crítica
4.2.1.13	Quando presente, DistributionPointName DEVE incluir, pelo menos, um URI LDAP ou HTTP.
4.2.1.13	As ACs em conformidade NÃO DEVEM usar nameRelativeToCRLIssuer para especificar nomes de pontos de distribuição.
4.2.2.1	Quando o accessMethod id-ad-caIssuers é usado, pelo menos uma instância DEVE especificar uma accessLocation que seja um URI HTTP [RFC 2616] ou LDAP [RFC 4516].
7.2	Para acomodar nomes de domínios internacionalizados na estrutura atual, as implementações em conformidade TÊM de converter nomes de domínios internacionalizados para o formato de codificação compatível com ASCII (ACE), conforme especificado na secção 4 da RFC 3490, antes do armazenamento no campo dNSName.