Conformité avec les normes RFC

Certificate Authority Service utilise l'outil ZLint pour s'assurer que les certificats X.509 sont valides conformément aux règles RFC 5280. Cependant, CA Service n'applique pas toutes les exigences RFC 5280, et il est possible qu'une autorité de certification créée à l'aide de CA Service délivre un certificat non conforme.

CA Service applique les exigences RFC 5280 suivantes.

Section RFC 5280	Clause lint
4.1.1.2	L'algorithme signatureAlgorithm du certificat DOIT contenir le même identifiant d'algorithme que le champ de signature de la séquence tbsCertificate (section 4.1.2.3).
4.1.2.1	Lorsque des extensions sont utilisées, comme prévu dans ce profil, la version DOIT être 3 (la valeur est 2).
4.1.2.2	Le numéro de série DOIT être un entier positif attribué par l'autorité de certification à chaque certificat.
4.1.2.2	Les autorités de certification conformes NE DOIVENT PAS utiliser de valeurs serialNumber de plus de 20 octets.
4.1.2.4	Le champ d'émetteur DOIT contenir un nom distinctif (DN).
4.1.2.5	Les autorités de certification conformes à ce profil DOIVENT toujours encoder les dates de validité du certificat jusqu'à l'année 2049 au format UTCTime
4.1.2.5.1	Les valeurs UTCTime DOIVENT être exprimées en heure moyenne de Greenwich (Zoulou)
4.1.2.5.1	Les valeurs UTCTime DOIVENT inclure les secondes
4.1.2.5.2	Les valeurs GeneralizedTime DOIVENT être exprimées en heure moyenne de Greenwich (Zoulou)
4.1.2.5.2	GeneralizedTime DOIT inclure des secondes
4.1.2.5.2	Les valeurs GeneralizedTime NE DOIVENT PAS inclure de secondes fractionnaires
4.1.2.6	Si l'objet est une autorité de certification (par exemple, l'extension de contraintes de base, comme indiqué dans la section 4.2.1.9, est présente et la valeur de cA est TRUE), le champ d'objet DOIT être renseigné avec un nom distinctif non vide correspondant au contenu du champ d'émetteur (section 4.1.2.4) dans tous les certificats émis par l'autorité de certification concernée.
4.1.2.8	Les champs d'identifiant unique DOIVENT apparaître uniquement si la version est 2 ou 3.
4.1.2.8	Les autorités de certification conformes à ce profil NE DOIVENT PAS générer de certificats avec des identifiants uniques.
4.1.2.9	Le champ "Extensions" DOIT apparaître uniquement si la version est 3.
4.2	Un certificat NE DOIT PAS inclure plus d'une instance d'une extension particulière.
4.2	Si l'autorité de certification émet des certificats avec une séquence vide pour le champ "Objet", elle DOIT prendre en charge l'extension de nom d'objet de remplacement.
4.2.1.1	Le champ keyIdentifier de l'extension AuthorityKeyIdentifier DOIT être inclus dans tous les certificats générés par les autorités de certification conformes afin de faciliter la construction du chemin de certification.
4.2.1.1	Les autorités de certification conformes DOIVENT marquer l'extension authorityKeyIdentifier comme non critique.
4.2.1.2	Pour faciliter la construction du chemin de certification, AuthorityKeyIdentifier DOIT apparaître dans tous les certificats CA conformes, c'est-à-dire tous les certificats, y compris l'extension des contraintes de base (section 4.2.1.9), où la valeur de cA est TRUE.
4.2.1.2	Les autorités de certification conformes DOIVENT marquer l'extension de l'identifiant de la clé d'objet comme non critique.
4.2.1.3	Si le bit keyCertSign est revendiqué, le bit cA de l'extension de contraintes de base (section 4.2.1.9) DOIT également être revendiqué.
4.2.1.3	Lorsque l'extension keyUsage apparaît dans un certificat, au moins l'un des bits DOIT être défini sur 1.
4.2.1.4	Un OID de stratégie de certificat NE DOIT PAS apparaître plus d'une fois dans une extension de règles de certificat.
4.2.1.4	Lorsque des qualificatifs sont utilisés avec la stratégie spéciale "anyPolicy", ils DOIVENT être limités aux qualificatifs identifiés dans cette section.
4.2.1.5	Les règles NE DOIVENT PAS être mappées vers ou depuis la valeur spéciale anyPolicy
4.2.1.6	Chaque fois que de telles identités (qui se trouvent dans un SAN) doivent être liées à un certificat, l'extension du nom alternatif de l'objet (ou du nom alternatif de l'émetteur) DOIT être utilisée.
4.2.1.6	Si le champ "subject" contient une séquence vide, l'autorité de certification émettrice DOIT inclure une extension subjectAltName marquée comme critique.
4.2.1.6	Lorsque l'extension subjectAltName contient une adresse e-mail Internet, l'adresse DOIT être stockée dans le rfc822Name.
4.2.1.6	Pour l'adresse IP version 4, comme spécifié dans la norme [RFC 791], la chaîne d'octets DOIT contenir exactement quatre octets. Pour l'adresse IP version 6, comme spécifié dans le document [RFC 2460], la chaîne d'octets DOIT contenir exactement 16 octets.
4.2.1.6	Lorsque l'extension subjectAltName contient un libellé de système de noms de domaine, le nom de domaine DOIT être stocké dans le dNSName (une chaîne IA5String).
4.2.1.6	SAN: le dNSName DOIT être dans la "syntaxe de nom préférée"
4.2.1.6	Les extensions subjectAltName dont le dNSName est " " NE DOIVENT PAS être utilisées
4.2.1.6	l'utilisation de la représentation DNS pour les adresses de messagerie Internet (subscriber.example.com au lieu de abonné@example.com) NE DOIT PAS être utilisée.
4.2.1.6	Lorsque l'extension subjectAltName contient un URI, le nom DOIT être stocké dans uniformResourceIdentifier (une chaîne IA5String).
4.2.1.6	URI SAN: le nom NE DOIT PAS être un URI relatif. Il DOIT respecter la syntaxe de l'URI et les règles d'encodage spécifiées dans le document [RFC 3986].
4.2.1.6	URI SAN: le nom DOIT inclure les deux schémas (par exemple, "http" ou "ftp") et une partie spécifique au schéma.
4.2.1.6	Les URI SAN incluant une autorité ([RFC 3986], section 3.2) DOIVENT inclure un nom de domaine complet ou une adresse IP en tant qu'hôte.
4.2.1.6	Si l'extension subjectAltName est présente, la séquence DOIT contenir au moins une entrée.
4.2.1.6	les autorités de certification conformes NE DOIVENT PAS émettre de certificats avec des subjectAltNames contenant des champs GeneralName vides.
4.2.1.7	Le nom alternatif de l'émetteur DOIT être encodé comme indiqué dans la norme 4.2.1.6
4.2.1.8	Attributs du répertoire des sujets: les autorités de certification conformes DOIVENT marquer cette extension comme non critique.
4.2.1.9	Le cas échéant, le champ "pathLenConstraint" DOIT être supérieur ou égal à zéro.
4.2.1.9	Les autorités de certification conformes DOIVENT inclure cette extension dans tous les certificats CA contenant des clés publiques utilisées pour valider les signatures numériques des certificats, et DOIVENT la marquer comme critique dans ces certificats.
4.2.1.9	Les autorités de certification NE DOIVENT PAS inclure le champ "pathLenConstraint", sauf si la valeur booléenne cA est déclarée et que l'extension d'utilisation de la clé revendique le bit keyCertSign.
4.2.1.10	L'extension de contraintes de nom, qui DOIT être utilisée uniquement dans un certificat CA, indique un espace de noms dans lequel tous les noms d'objet des certificats suivants d'un chemin de certification DOIVENT être situés.
4.2.1.10	Contraintes de nom: les autorités de certification conformes DOIVENT marquer cette extension comme critique
4.2.1.10	Les autorités de certification conformes NE DOIVENT PAS émettre de certificats lorsque les contraintes de nom correspondent à une séquence vide. En d'autres termes, le champ allowedSubtrees ou le champ excludedSubtrees DOIT être présent.
4.2.1.10	Dans ce profil, les champs minimal et maximal ne sont pas utilisés dans les formulaires de nom. Par conséquent, la valeur minimale et la valeur maximale DOIVENT être absentes.
4.2.1.10	La syntaxe d'iPAddress DOIT être décrite dans la section 4.2.1.6, avec les ajouts suivants spécifiquement pour les contraintes de nom: pour les adresses IPv4, le champ iPAddress de GeneralName DOIT contenir huit (8) octets, encodés dans le style de RFC 4632 (CIDR) pour représenter une plage d'adresses [RFC 4632]. Pour les adresses IPv6, le champ iPAddress DOIT contenir 32 octets encodés de la même manière.
4.2.1.11	Les autorités de certification conformes NE DOIVENT PAS émettre de certificats lorsque les contraintes liées aux règles correspondent à une séquence vide. En d'autres termes, le champ "inhibitPolicyMapping" ou le champ "requiredexplicitPolicy" DOIT être présents.
4.2.1.11	Contraintes liées aux règles: les autorités de certification conformes DOIVENT marquer cette extension comme critique.
4.2.1.13	un DistributionPoint NE DOIT PAS contenir uniquement le champ de motifs. distributionPoint ou cRLIssuer DOIT être présent.
4.2.1.14	Les autorités de certification conformes DOIVENT marquer cette extension "Inhibit anyPolicy" comme critique.
4.2.1.15	L'extension LRC la plus récente DOIT être marquée comme non critique par les autorités de certification conformes.
4.2.2.1	Les autorités de certification conformes DOIVENT marquer cette extension d'accès aux informations d'autorité comme non critique.
4.2.2.2	Les autorités de certification conformes DOIVENT marquer cette extension d'accès aux informations sur l'objet comme non critique.
4.1.2.5	Pour indiquer qu'un certificat n'a pas de date d'expiration bien définie, notAfter DOIT être affecté à la valeur GeneralizedTime de 99991231235959Z.
4.2.1.2	Pour aider les applications à identifier le certificat d'entité finale approprié, cette extension DOIT être incluse dans tous les certificats d'entité finale
4.2.1.3	Lorsqu'elle est présente, les autorités de certification conformes DOIVENT marquer cette extension d'utilisation de clé comme critique.
4.2.1.4	Les autorités de certification conformes NE DOIVENT PAS utiliser l'option "noticeRef".
4.2.1.4	Les autorités de certification conformes DOIVENT utiliser l'encodage UTF8String pour explicitesText, mais PEUVENT utiliser IA5String.
4.2.1.4	La chaîne expliciteText NE DOIT PAS inclure de caractères de contrôle (par exemple, U+0000 à U+001F et U+007F à U+009F).
4.2.1.4	Lorsque vous utilisez l'encodage UTF8String, toutes les séquences de caractères DOIVENT être normalisées conformément au formulaire de normalisation Unicode C (NFC)
4.2.1.5	Chaque émetteurDomainPolicy nommé dans l'extension de mappage de règles DOIT également être revendiqué dans une extension de règles de certificat du même certificat.
4.2.1.5	Les autorités de certification conformes DOIVENT marquer cette extension de mappage des règles comme critique.
4.2.1.6	Lorsque vous incluez l'extension subjectAltName dans un certificat dont le nom distinctif d'objet n'est pas vide, les autorités de certification conformes DOIVENT marquer l'extension subjectAltName comme non critique.
4.2.1.7	Le cas échéant, les autorités de certification conformes DOIVENT marquer cette extension de nom alternatif de l'émetteur comme non critique.
4.2.1.10	NE DOIT PAS imposer de contraintes de nom dans les formulaires de nom x400Address, ediPartyName ou RegisterID.
4.2.1.12	Les autorités de certification conformes NE DOIVENT PAS marquer cette extension comme critique si l'identifiant anyExtendedKeyUsage KeyPurposeId est présent.
4.2.1.13	L'extension des points de distribution LRC DOIT être non critique
4.2.1.13	Lorsqu'il est présent, DistributionPointName DOIT inclure au moins un URI LDAP ou HTTP.
4.2.1.13	Les autorités de certification conformes NE DOIVENT PAS utiliser nameRelativeToCRLIssuer pour spécifier les noms des points de distribution.
4.2.2.1	Lorsque la méthode "id-ad-caIssuers accessMethod" est utilisée, au moins une instance DOIT spécifier un accessLocation qui est un URI HTTP [RFC 2616] ou LDAP [RFC 4516].
7.2	Pour tenir compte des noms de domaine internationalisés dans la structure actuelle, les implémentations conformes DOIVENT convertir les noms de domaine internationalisés au format ASCII Compatible Encoding (ACE), tel que spécifié dans la Section 4 du document RFC 3490, avant de les stocker dans le champ dNSName.