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 norme 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 suivantes de la norme RFC 5280.

Section RFC 5280	Clause lint
4.1.1.2	L'algorithme de signature dans le certificat DOIT contenir le même identifiant d'algorithme que le champ de signature dans 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'AC à chaque certificat.
4.1.2.2	Les AC conformes NE DOIVENT PAS utiliser de valeurs serialNumber de plus de 20 octets.
4.1.2.4	Le champ "Émetteur" DOIT contenir un nom distinctif (DN) non vide.
4.1.2.5	Les AC conformes à ce profil DOIVENT toujours encoder les dates de validité des certificats jusqu'à l'année 2049 au format UTCTime.
4.1.2.5	Pour indiquer qu'un certificat n'a pas de date d'expiration bien définie, la valeur notAfter DOIT être définie sur la valeur GeneralizedTime 99991231235959Z.
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 (Zulu).
4.1.2.5.2	GeneralizedTime DOIT inclure les secondes
4.1.2.5.2	Les valeurs GeneralizedTime ne DOIVENT PAS inclure de fractions de seconde.
4.1.2.6	Si le sujet est une AC (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 du sujet DOIT être renseigné avec un nom distinctif non vide correspondant au contenu du champ de l'émetteur (section 4.1.2.4) dans tous les certificats émis par l'AC du sujet.
4.1.2.8	Les champs d'identifiant unique NE DOIVENT apparaître que si la version est 2 ou 3.
4.1.2.8	Les AC 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 3.
4.2	Un certificat NE DOIT PAS inclure plusieurs instances d'une extension particulière.
4.2	Si l'AC émet des certificats avec une séquence vide pour le champ "subject" (sujet), elle DOIT prendre en charge l'extension "subject alternative name" (autre nom d'objet).
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 pour faciliter la construction du chemin de certification.
4.2.1.1	Les AC 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 incluant l'extension de contraintes de base (section 4.2.1.9) où la valeur de cA est TRUE.
4.2.1.2	Les AC conformes DOIVENT marquer l'extension d'identifiant de clé de sujet comme non critique.
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	Si le bit keyCertSign est défini, le bit cA de l'extension de contraintes de base (section 4.2.1.9) DOIT également être défini.
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.3	Lorsqu'elles sont présentes, les AC conformes DOIVENT marquer cette extension d'utilisation de clé comme critique.
4.2.1.4	Un OID de règle 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 règle spéciale anyPolicy, ils DOIVENT être limités aux qualificatifs identifiés dans cette section.
4.2.1.4	Les AC conformes NE DOIVENT PAS utiliser l'option noticeRef.
4.2.1.4	Les AC 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 selon la forme de normalisation Unicode C (NFC).
4.2.1.5	Les règles NE DOIVENT PAS être mappées vers ou depuis la valeur spéciale anyPolicy.
4.2.1.5	Chaque issuerDomainPolicy nommé dans l'extension de mappage des règles doit également être affirmé dans une extension de règles de certificat du même certificat.
4.2.1.5	Les AC conformes DOIVENT marquer cette extension de mappage de règles comme critique.
4.2.1.6	Chaque fois que de telles identités (tout élément d'un SAN) doivent être liées à un certificat, l'extension "subject alternative name" (ou "issuer alternative name") DOIT être utilisée ;
4.2.1.6	Si le champ "Subject" contient une séquence vide, l'AC é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 d'IP, comme spécifié dans [RFC 791], la chaîne d'octets DOIT contenir exactement quatre octets. Pour la version 6 d'IP, telle que spécifiée 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 le dNSName (une IA5String).
4.2.1.6	SAN : le dNSName DOIT respecter la "syntaxe du 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 l'uniformResourceIdentifier (un 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 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 AC conformes NE DOIVENT PAS émettre de certificats avec des subjectAltNames contenant des champs GeneralName vides.
4.2.1.6	Lorsqu'elles incluent l'extension subjectAltName dans un certificat dont le nom distinctif de sujet n'est pas vide, les AC conformes DOIVENT marquer l'extension subjectAltName comme non critique.
4.2.1.7	L'autre nom de l'émetteur DOIT être encodé comme dans la section 4.2.1.6.
4.2.1.7	Le cas échéant, les AC conformes DOIVENT marquer cette extension d'autre nom de l'émetteur comme non critique.
4.2.1.8	Attributs du répertoire de sujets : les AC conformes DOIVENT marquer cette extension comme non critique.
4.2.1.9	Le champ pathLenConstraint doit être supérieur ou égal à zéro, le cas échéant.
4.2.1.9	Les AC conformes DOIVENT inclure cette extension dans tous les certificats d'AC 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 AC NE DOIVENT PAS inclure le champ pathLenConstraint, sauf si le booléen cA est défini et que l'extension d'utilisation de la clé définit 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 suivants d'un chemin de certification DOIVENT se trouver.
4.2.1.10	Contraintes de nom : les AC 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. En d'autres termes, le champ "permittedSubtrees" ou "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, le minimum DOIT être zéro et le maximum DOIT être absent.
4.2.1.10	La syntaxe de iPAddress DOIT être celle décrite dans la section 4.2.1.6, avec les ajouts suivants spécifiques aux contraintes de nom : pour les adresses IPv4, le champ iPAddress de GeneralName DOIT contenir huit (8) octets, encodés dans 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.10	NE DOIT PAS imposer de contraintes de nom sur les formulaires de nom x400Address, ediPartyName ou registeredID.
4.2.1.11	Les autorités de certification conformes NE DOIVENT PAS émettre de certificats dont les contraintes de règles sont une séquence vide. En d'autres termes, le champ "inhibitPolicyMapping" ou le champ "requireExplicitPolicy" DOIVENT être présents.
4.2.1.11	Contraintes de règles : les AC conformes DOIVENT marquer cette extension comme critique.
4.2.1.12	Les AC conformes NE DOIVENT PAS marquer cette extension comme critique si le KeyPurposeId anyExtendedKeyUsage est présent.
4.2.1.13	Un élément DistributionPoint ne DOIT PAS se composer uniquement du champ "reasons". Les champs "distributionPoint" ou "cRLIssuer" DOIVENT être présents.
4.2.1.13	L'extension "Points de distribution de la CRL" 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 AC conformes NE DOIVENT PAS utiliser nameRelativeToCRLIssuer pour spécifier les noms des points de distribution.
4.2.1.14	Les AC conformes DOIVENT marquer cette extension Inhibit anyPolicy comme critique.
4.2.1.15	L'extension "Freshest CRL" DOIT être marquée comme non critique par les AC conformes.
4.2.2.1	Les AC conformes DOIVENT marquer cette extension d'accès aux informations de l'autorité comme non critique.
4.2.2.1	Lorsque la méthode accessMethod id-ad-caIssuers est utilisée, au moins une instance DOIT spécifier une accessLocation qui est un URI HTTP [RFC 2616] ou LDAP [RFC 4516].
4.2.2.2	Les AC conformes DOIVENT marquer cette extension d'accès aux informations sur le sujet comme non critique.
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.