Conformidade com RFC

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

O serviço de autoridade certificadora impõe os seguintes requisitos do RFC 5280.

Seção do RFC 5280	Cláusula lint
4.1.1.2	O signatureAlgorithm no certificado PRECISA conter o mesmo identificador de algoritmo que o campo de assinatura na sequência tbsCertificate (seção 4.1.2.3).
4.1.2.1	Quando as extensões são usadas, como esperado neste perfil, a versão PRECISA ser 3 (o valor é 2).
4.1.2.2	O número de série PRECISA ser um número inteiro positivo atribuído pela AC a cada certificado.
4.1.2.2	As ACs em conformidade PRECISAM usar valores de serialNumber maiores que 20 octetos.
4.1.2.4	O campo do emissor PRECISA conter um nome distinto (DN) não vazio.
4.1.2.5	As ACs que atendem a esse perfil PRECISAM sempre codificar as datas de validade do certificado até o ano de 2049 como UTCTime
4.1.2.5.1	Os valores de UTCTime precisam ser expressos no horário médio de Greenwich (Zulu).
4.1.2.5.1	Os valores de UTCTime precisam incluir segundos.
4.1.2.5.2	Os valores de GeneralizedTime precisam ser expressos no Horário de Greenwich (Zulu)
4.1.2.5.2	GeneralizedTime PRECISA incluir segundos.
4.1.2.5.2	Os valores de GeneralizedTime NÃO devem incluir segundos fracionários.
4.1.2.6	Se o assunto for uma AC (por exemplo, a extensão de restrições básica, conforme discutido na seção 4.2.1.9, estiver presente e o valor de cA for VERDADEIRO), o campo de assunto PRECISA ser preenchido com um nome distinto não vazio que corresponda ao conteúdo do campo emissor (seção 4.1.2.4) em todos os certificados emitidos pela AC do 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 que estiverem em conformidade com esse perfil NÃO PODEM gerar certificados com identificadores exclusivos.
4.1.2.9	O campo "Extensions" só vai aparecer se a versão for 3.
4.2	Um certificado NÃO pode incluir mais de uma instância de uma extensão específica.
4.2	Se a AC emitir certificados com uma sequência vazia para o campo de assunto, ela PRECISA oferecer suporte à extensão de nome alternativo do assunto.
4.2.1.1	O campo keyIdentifier da extensão authorityKeyIdentifier PRECISA ser incluído em todos os certificados gerados por ACs conformes para facilitar a construção do caminho de certificação.
4.2.1.1	As ACs em conformidade PRECISAM marcar a extensão authorityKeyIdentifier como não crítica.
4.2.1.2	Para facilitar a construção do caminho de certificação, o authorityKeyIdentifier PRECISA aparecer em todos os certificados de ACs em conformidade, ou seja, todos os certificados que incluem a extensão de restrições básicas (seção 4.2.1.9), em que o valor de cA é VERDADEIRO.
4.2.1.2	As ACs em conformidade PRECISAM marcar a extensão do identificador de chave do sujeito como não crítica.
4.2.1.3	Se o bit keyCertSign for ativado, o bit cA na extensão de restrições básicas (seção 4.2.1.9) também PRECISA ser ativado.
4.2.1.3	Quando a extensão keyUsage aparece em um certificado, pelo menos um dos bits PRECISA ser definido como 1.
4.2.1.4	Um OID de política de certificado NÃO PODE aparecer mais de uma vez em uma extensão de políticas de certificado.
4.2.1.4	Quando os qualificadores são usados com a política especial anyPolicy, eles precisam ser limitados aos qualificadores identificados nesta seção.
4.2.1.5	As políticas NÃO podem ser mapeadas para ou a partir do valor especial anyPolicy.
4.2.1.6	Sempre que essas identidades (qualquer coisa em um SAN) forem vinculadas a um certificado, a extensão do nome alternativo do assunto (ou do emissor) PRECISA ser usada.
4.2.1.6	Se o campo de assunto contiver uma sequência vazia, a AC emissora PRECISA incluir uma extensão subjectAltName marcada como crítica.
4.2.1.6	Quando a extensão subjectAltName contém um endereço de e-mail da Internet, o endereço PRECISA ser armazenado no rfc822Name.
4.2.1.6	Para a versão 4 do IP, conforme especificado no [RFC 791], a string de octetos PRECISA conter exatamente quatro octetos. Para a versão 6 do IP, conforme especificado no [RFC 2460], a string de octeto PRECISA conter exatamente 16 octetos.
4.2.1.6	Quando a extensão subjectAltName contém um rótulo do sistema de nomes de domínio, o nome de domínio PRECISA ser armazenado no dNSName (uma IA5String).
4.2.1.6	SANs: o dNSName PRECISA estar na "sintaxe de nome preferido".
4.2.1.6	As extensões subjectAltName com um dNSName de " " NÃO devem ser usadas
4.2.1.6	O uso da representação DNS para endereços de e-mail da Internet (subscriber.example.com em vez de [e-mail]) NÃO PODE ser usado
4.2.1.6	Quando a extensão subjectAltName contém um URI, o nome PRECISA ser armazenado no uniformResourceIdentifier (um IA5String).
4.2.1.6	URIs SAN: o nome NÃO PODE ser um URI relativo e PRECISA seguir a sintaxe e as regras de codificação de URI especificadas em [RFC 3986].
4.2.1.6	URIs SAN: o nome PRECISA 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], seção 3.2) PRECISAM incluir um nome de domínio ou endereço IP totalmente qualificado como host.
4.2.1.6	Se a extensão subjectAltName estiver presente, a sequência PRECISA conter pelo menos uma entrada.
4.2.1.6	As ACs conformes NÃO PODEM emitir certificados com subjectAltNames que contenham campos GeneralName vazios.
4.2.1.7	O nome alternativo do emissor PRECISA ser codificado conforme 4.2.1.6.
4.2.1.8	Atributos do diretório de assunto: as ACs em conformidade PRECISAM marcar essa extensão como não crítica.
4.2.1.9	Onde ele aparece, o campo pathLenConstraint PRECISA ser maior ou igual a zero.
4.2.1.9	As ACs em conformidade PRECISAM incluir essa extensão em todos os certificados de AC que contêm chaves públicas usadas para validar assinaturas digitais em certificados e PRECISAM marcar a extensão como crítica nesses certificados.
4.2.1.9	As ACs PRECISAM APENAS incluir o campo pathLenConstraint, a menos que o booleano cA seja atribuído e a extensão de uso da chave atribua o bit keyCertSign.
4.2.1.10	A extensão de restrições de nome, que PRECISA ser usada apenas em um certificado de AC, indica um espaço de nomes em que TODOS os nomes de sujeitos em certificados subsequentes em um caminho de certificação PRECISAM estar localizados.
4.2.1.10	Restrições de nome: as ACs em conformidade PRECISAM marcar essa extensão como crítica
4.2.1.10	As ACs em conformidade NÃO PODEM emitir certificados em que as restrições de nome sejam uma sequência vazia. Ou seja, o campo permittedSubtrees ou excludedSubtrees PRECISA estar presente.
4.2.1.10	Nesse perfil, os campos mínimo e máximo não são usados com nenhum formulário de nome. Portanto, o mínimo PRECISA ser zero, e o máximo PRECISA estar ausente.
4.2.1.10	A sintaxe de iPAddress PRECISA ser conforme descrito na seção 4.2.1.6 com as seguintes adições especificamente para restrições de nome: para endereços IPv4, o campo iPAddress de GeneralName PRECISA conter oito (8) octetos, codificados no estilo de RFC 4632 (CIDR) para representar um intervalo de endereços [RFC 4632]. Para endereços IPv6, o campo iPAddress PRECISA conter 32 octetos codificados da mesma forma.
4.2.1.11	As ACs em conformidade NÃO PODEM emitir certificados em que as restrições de política sejam uma sequência vazia. Ou seja, o campo inhibitPolicyMapping ou o campo requireExplicitPolicy PRECISA estar presente.
4.2.1.11	Restrições de política: as ACs em conformidade PRECISAM marcar essa extensão como crítica.
4.2.1.13	O DistributionPoint NÃO pode consistir apenas do campo de motivos. O distributionPoint ou o cRLIssuer precisa estar presente.
4.2.1.14	As ACs em conformidade PRECISAM marcar essa extensão Inhibit anyPolicy como crítica.
4.2.1.15	A extensão CRL mais recente PRECISA ser marcada como não crítica pelas ACs em conformidade.
4.2.2.1	As ACs em conformidade PRECISAM marcar essa extensão de acesso a informações de autoridade como não crítica.
4.2.2.2	As ACs em conformidade PRECISAM marcar essa extensão de acesso às informações do sujeito 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 de GeneralizedTime 99991231235959Z DEVE ser atribuído a notAfter.
4.2.1.2	Para ajudar os aplicativos a identificar o certificado de entidade final adequado, essa extensão PRECISA ser incluída em todos os certificados de entidade final.
4.2.1.3	Quando presentes, as ACs em conformidade DEVEM marcar essa extensão de uso 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 PRECISAM usar a codificação UTF8String para explicitText, mas PODEM usar IA5String.
4.2.1.4	A string explicitText NÃO deve incluir caracteres de controle (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 caracteres precisam ser normalizadas de acordo com o formulário C (NFC) de normalização Unicode.
4.2.1.5	Cada issuerDomainPolicy nomeado na extensão de mapeamento de políticas PRECISA ser atribuído em uma extensão de políticas de certificado no mesmo certificado.
4.2.1.5	As ACs em conformidade DEVEM marcar essa extensão de mapeamento de políticas como crítica.
4.2.1.6	Ao incluir a extensão subjectAltName em um certificado que tenha um nome distinto de assunto não vazio, as ACs em conformidade DEVEM marcar a extensão subjectAltName como não crítica.
4.2.1.7	Quando presentes, as ACs em conformidade DEVEM marcar essa extensão de nome alternativo do emissor como não crítica.
4.2.1.10	NÃO DEVE impor restrições de nome nos formulários de nome x400Address, ediPartyName ou registeredID.
4.2.1.12	As ACs em conformidade NÃO devem marcar essa extensão como crítica se o KeyPurposeId de anyExtendedKeyUsage estiver presente.
4.2.1.13	A extensão dos pontos de distribuição de CRL não deve ser essencial
4.2.1.13	Quando presente, o 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 precisa especificar um accessLocation que seja um URI HTTP [RFC 2616] ou LDAP [RFC 4516].
7,2	Para acomodar nomes de domínio internacionalizados na estrutura atual, as implementações em conformidade PRECISAM converter nomes de domínio internacionalizados para o formato de codificação compatível com ASCII (ACE, na sigla em inglês), conforme especificado na seção 4 do RFC 3490, antes do armazenamento no campo dNSName.