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 de la RFC 5280. Toutefois, CA Service n'applique pas toutes les exigences de la RFC 5280. Il est donc possible qu'une autorité de certification créée à l'aide de CA Service émette un certificat non conforme.

Certificate Authority Service applique les exigences RFC 5280 suivantes.

Section de la RFC 5280	Clause lint
4.1.1.2	Le champ signatureAlgorithm du certificat DOIT contenir le même identifiant d'algorithme que le champ 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 la version 3 (valeur 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 de serialNumber supérieures à 20 octets.
4.1.2.4	Le champ "Émetteur" DOIT contenir un nom distinctif (DN) non vide.
4.1.2.5	Les autorités de certification conformes à ce profil DOIVENT toujours encoder les dates de validité des certificats jusqu'en 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 des secondes
4.1.2.5.2	Les valeurs GeneralizedTime DOIVENT être exprimées en heure moyenne de Greenwich (Zulu).
4.1.2.5.2	GeneralizedTime DOIT inclure des secondes
4.1.2.5.2	Les valeurs GeneralizedTime NE DOIVENT PAS inclure de fractions de seconde.
4.1.2.6	Si l'objet est une autorité de certification (par exemple, si l'extension de contraintes de base, comme indiqué dans la section 4.2.1.9, est présente et que la valeur de cA est "TRUE"), le champ "Subject" DOIT être renseigné avec un nom distinctif non vide correspondant au contenu du champ "Issuer" (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" ne doit apparaître que si la version est la 3.
4.2	Un certificat NE DOIT PAS inclure plusieurs instances d'une extension particulière.
4.2	Si l'autorité de certification délivre des certificats avec une séquence vide pour le champ d'objet, elle DOIT prendre en charge l'extension subjectAlternativeName.
4.2.1.1	Le champ keyIdentifier de l'extension authorityKeyIdentifier DOIT être inclus dans tous les certificats générés par des autorités de certification conformes afin de faciliter la création 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 d'autorité de certification conformes, c'est-à-dire tous les certificats incluant l'extension de 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 clé de l'entité comme non critique.
4.2.1.3	Si le bit keyCertSign est activé, le bit cA de l'extension de contraintes de base (section 4.2.1.9) DOIT également être activé.
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 certification NE DOIT PAS apparaître plus d'une fois dans une extension de stratégie de certification.
4.2.1.4	Lorsque des qualificatifs sont utilisés avec la règle 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 à partir ou vers la valeur spéciale "anyPolicy".
4.2.1.6	Chaque fois que ces identités (tout élément d'un SAN) doivent être liées à un certificat, l'extension subjectAltName (ou issuerAltName) DOIT être utilisée.
4.2.1.6	Si le champ d'objet 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 rfc822Name.
4.2.1.6	Pour la version 4 de l'IP, comme spécifié dans la RFC 791, la chaîne d'octets DOIT contenir exactement quatre octets. Pour la version 6 de l'IP, comme spécifié dans [RFC 2460], la chaîne d'octets DOIT contenir exactement seize 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 dNSName (une IA5String).
4.2.1.6	SAN: le dNSName DOIT être au format "syntaxe de nom préféré"
4.2.1.6	Les extensions subjectAltName avec un dNSName de " " NE DOIVENT PAS être utilisées
4.2.1.6	L'utilisation de la représentation DNS pour les adresses e-mail Internet (subscriber.example.com au lieu de [e-mail]) 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 IA5String).
4.2.1.6	URI SAN: le nom NE DOIT PAS être un URI relatif et DOIT respecter la syntaxe et les règles d'encodage des URI spécifiées dans [RFC 3986].
4.2.1.6	URI SAN: le nom DOIT inclure à la fois un schéma (par exemple, "http" ou "ftp") et une partie spécifique au schéma.
4.2.1.6	Les URI SAN qui incluent 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 noms d'objet alternatifs contenant des champs GeneralName vides.
4.2.1.7	L'autre nom de l'émetteur DOIT être encodé comme indiqué dans la section 4.2.1.6.
4.2.1.8	Attributs de répertoire d'objet: les autorités de certification conformes DOIVENT marquer cette extension comme non critique.
4.2.1.9	Lorsqu'il apparaît, 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 d'autorité de certification contenant des clés publiques utilisées pour valider les signatures numériques sur les certificats et DOIVENT marquer l'extension 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 affirmée et que l'extension d'utilisation de la clé affirme le bit "keyCertSign".
4.2.1.10	L'extension de contraintes de nom, qui DOIT être utilisée uniquement dans un certificat d'autorité de certification, indique un espace de noms dans lequel tous les noms d'objet des certificats ultérieurs d'un chemin de certification DOIVENT se trouver.
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 dont les contraintes de nom sont une séquence vide. Autrement dit, le champ permittedSubtrees ou le champ excludedSubtrees DOIT être présent.
4.2.1.10	Dans ce profil, les champs "Minimum" et "Maximum" ne sont utilisés avec aucune forme de nom. Par conséquent, la valeur minimale DOIT être nulle et la valeur maximale DOIT être absente.
4.2.1.10	La syntaxe de iPAddress DOIT être conforme à 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 selon le style de la 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 de règles sont une séquence vide. Autrement dit, le champ inhibitPolicyMapping ou le champ requireExplicitPolicy DOIVENT être présents.
4.2.1.11	Contraintes de règles: les autorités de certification conformes DOIVENT marquer cette extension comme critique.
4.2.1.13	Un DistributionPoint NE DOIT PAS se composer uniquement du champ "reasons". Le champ "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 de la 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 de l'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, la valeur GeneralizedTime de 99991231235959Z DOIT être attribuée à l'attribut notAfter.
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 la 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 explicitText, mais PEUVENT utiliser IA5String.
4.2.1.4	La chaîne explicitText 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 l'encodage UTF8String est utilisé, toutes les séquences de caractères DOIVENT être normalisées conformément à la forme de normalisation C (NFC) d'Unicode.
4.2.1.5	Chaque issuerDomainPolicy nommé dans l'extension de mappage de stratégies DOIT également être affirmé dans une extension de stratégie de certificat du même certificat.
4.2.1.5	Les autorités de certification conformes DOIVENT marquer cette extension de mappage de règles comme critique.
4.2.1.6	Lorsqu'elles incluent l'extension subjectAltName dans un certificat dont le nom distinctif de l'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 aux formats de nom x400Address, ediPartyName ou registeredID.
4.2.1.12	Les autorités de certification conformes NE DOIVENT PAS marquer cette extension comme critique si le KeyPurposeId anyExtendedKeyUsage est présent.
4.2.1.13	L'extension "Points de distribution de LRC" DOIT être non critique.
4.2.1.13	Le champ 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 d'accès id-ad-caIssuers est utilisée, au moins une instance DOIT spécifier un emplacement d'accès qui est un URI HTTP [RFC 2616] ou LDAP [RFC 4516].
7.2	Pour prendre en charge les noms de domaine internationalisés dans la structure actuelle, les implémentations conformes DOIVENT convertir les noms de domaine internationalisés au format ACE (ASCII Compatible Encoding), comme spécifié dans la section 4 de la RFC 3490, avant de les stocker dans le champ dNSName.