Conformità alla normativa RFC

Certificate Authority Service utilizza lo strumento ZLint per garantire che i certificati X.509 siano validi in base alle regole RFC 5280. Tuttavia, CA Service non applica tutti i requisiti RFC 5280 ed è possibile che una CA creata utilizzando CA Service emetta un certificato non conforme.

Certificate Authority Service applica i seguenti requisiti RFC 5280.

Sezione RFC 5280	Clausola di analisi tramite lint
4.1.1.2	signatureAlgorithm in Certificate DEVE contenere lo stesso identificatore dell'algoritmo del campo signature nella sequenza tbsCertificate (sezione 4.1.2.3).
4.1.2.1	Quando vengono utilizzate le estensioni, come previsto in questo profilo, la versione DEVE essere 3 (il valore è 2).
4.1.2.2	Il numero di serie DEVE essere un numero intero positivo assegnato dalla CA a ogni certificato.
4.1.2.2	Le CA conformi NON DEVONO utilizzare valori serialNumber più lunghi di 20 ottetti.
4.1.2.4	Il campo emittente DEVE contenere un nome distinto (DN) non vuoto.
4.1.2.5	Le CA conformi a questo profilo DEVONO sempre codificare le date di validità dei certificati fino all'anno 2049 come UTCTime
4.1.2.5	Per indicare che un certificato non ha una data di scadenza ben definita, a notAfter DEVE essere assegnato il valore GeneralizedTime 99991231235959Z.
4.1.2.5.1	I valori UTCTime DEVONO essere espressi in Greenwich Mean Time (Zulu)
4.1.2.5.1	I valori UTCTime DEVONO includere i secondi
4.1.2.5.2	I valori GeneralizedTime DEVONO essere espressi in Greenwich Mean Time (Zulu)
4.1.2.5.2	GeneralizedTime DEVE includere i secondi
4.1.2.5.2	I valori GeneralizedTime NON DEVONO includere frazioni di secondo
4.1.2.6	Se il soggetto è una CA (ad esempio, l'estensione dei vincoli di base, come descritto nella sezione 4.2.1.9, è presente e il valore di cA è TRUE), il campo del soggetto DEVE essere compilato con un nome distinto non vuoto che corrisponda ai contenuti del campo dell'emittente (sezione 4.1.2.4) in tutti i certificati emessi dalla CA del soggetto.
4.1.2.8	I campi identificatori univoci DEVONO essere visualizzati solo se la versione è 2 o 3
4.1.2.8	Le CA conformi a questo profilo NON DEVONO generare certificati con identificatori univoci.
4.1.2.9	Il campo Estensioni DEVE essere visualizzato solo se la versione è 3
4.2	Un certificato NON DEVE includere più di un'istanza di una determinata estensione.
4.2	Se l'autorità di certificazione emette certificati con una sequenza vuota per il campo soggetto, DEVE supportare l'estensione del nome alternativo del soggetto
4.2.1.1	Il campo keyIdentifier dell'estensione authorityKeyIdentifier DEVE essere incluso in tutti i certificati generati dalle CA conformi per facilitare la creazione del percorso di certificazione.
4.2.1.1	Le CA conformi DEVONO contrassegnare l'estensione authorityKeyIdentifier come non critica.
4.2.1.2	Per facilitare la creazione del percorso di certificazione, authorityKeyIdentifier DEVE essere presente in tutti i certificati CA conformi, ovvero in tutti i certificati che includono l'estensione basicConstraints (sezione 4.2.1.9) in cui il valore di cA è TRUE.
4.2.1.2	Le CA conformi DEVONO contrassegnare l'estensione dell'identificatore della chiave del soggetto come non critica.
4.2.1.2	Per aiutare le applicazioni a identificare il certificato dell'entità finale appropriato, questa estensione DEVE essere inclusa in tutti i certificati dell'entità finale
4.2.1.3	Se il bit keyCertSign è impostato, deve essere impostato anche il bit cA nell'estensione Limitazioni di base (sezione 4.2.1.9).
4.2.1.3	Quando l'estensione keyUsage viene visualizzata in un certificato, almeno uno dei bit DEVE essere impostato su 1.
4.2.1.3	Se presente, le CA conformi DEVONO contrassegnare questa estensione di utilizzo della chiave come critica.
4.2.1.4	Un OID della policy del certificato NON DEVE comparire più di una volta in un'estensione delle policy del certificato.
4.2.1.4	Quando i qualificatori vengono utilizzati con la norma speciale anyPolicy, DEVONO essere limitati ai qualificatori identificati in questa sezione.
4.2.1.4	Le CA conformi NON DEVONO utilizzare l'opzione noticeRef.
4.2.1.4	Le CA conformi DEVONO utilizzare la codifica UTF8String per explicitText, ma POSSONO utilizzare IA5String.
4.2.1.4	La stringa explicitText NON DEVE includere caratteri di controllo (ad es. da U+0000 a U+001F e da U+007F a U+009F.
4.2.1.4	Quando viene utilizzata la codifica UTF8String, tutte le sequenze di caratteri DEVONO essere normalizzate in base alla forma di normalizzazione Unicode C (NFC)
4.2.1.5	Le policy NON DEVONO essere mappate al valore speciale anyPolicy o da questo valore.
4.2.1.5	Ogni issuerDomainPolicy denominata nell'estensione dei mapping delle policy DEVE essere dichiarata anche in un'estensione delle policy dei certificati nello stesso certificato.
4.2.1.5	Le CA conformi DEVONO contrassegnare questa estensione Policy Mappings come critica.
4.2.1.6	Ogni volta che queste identità (qualsiasi elemento in un SAN) devono essere associate a un certificato, DEVE essere utilizzata l'estensione del nome alternativo del soggetto (o del nome alternativo dell'emittente);
4.2.1.6	Se il campo dell'oggetto contiene una sequenza vuota, la CA emittente DEVE includere un'estensione subjectAltName contrassegnata come critica.
4.2.1.6	Quando l'estensione subjectAltName contiene un indirizzo di posta internet, l'indirizzo DEVE essere memorizzato in rfc822Name.
4.2.1.6	Per la versione 4 dell'IP, come specificato in [RFC 791], la stringa di ottetti DEVE contenere esattamente quattro ottetti. Per la versione 6 di IP, come specificato in [RFC 2460], la stringa di ottetti DEVE contenere esattamente sedici ottetti.
4.2.1.6	Quando l'estensione subjectAltName contiene un'etichetta del sistema dei nomi di dominio, il nome di dominio DEVE essere memorizzato in dNSName (una stringa IA5).
4.2.1.6	SAN: dNSName DEVE essere nella "sintassi del nome preferito"
4.2.1.6	Le estensioni subjectAltName con un dNSName di " " NON DEVONO essere utilizzate
4.2.1.6	non deve essere utilizzata la rappresentazione DNS per gli indirizzi di posta internet (subscriber.example.com anziché [e-mail])
4.2.1.6	Quando l'estensione subjectAltName contiene un URI, il nome DEVE essere memorizzato in uniformResourceIdentifier (una stringa IA5).
4.2.1.6	URI SAN: il nome NON DEVE essere un URI relativo e DEVE seguire le regole di sintassi e codifica degli URI specificate in [RFC 3986].
4.2.1.6	URI SAN: il nome DEVE includere uno schema (ad es. "http" o "ftp") e una parte specifica dello schema.
4.2.1.6	Gli URI SAN che includono un'autorità ([RFC 3986], sezione 3.2) DEVONO includere un nome di dominio completo o un indirizzo IP come host.
4.2.1.6	Se l'estensione subjectAltName è presente, la sequenza DEVE contenere almeno una voce.
4.2.1.6	Le CA conformi NON DEVONO emettere certificati con subjectAltNames contenenti campi GeneralName vuoti.
4.2.1.6	Quando includono l'estensione subjectAltName in un certificato con un nome distinto del soggetto non vuoto, le CA conformi DEVONO contrassegnare l'estensione subjectAltName come non critica.
4.2.1.7	Il nome alternativo dell'emittente DEVE essere codificato come in 4.2.1.6
4.2.1.7	Se presente, le CA conformi DEVONO contrassegnare questa estensione del nome alternativo dell'emittente come non critica.
4.2.1.8	Attributi della directory dei soggetti: le CA conformi DEVONO contrassegnare questa estensione come non critica.
4.2.1.9	Se presente, il campo pathLenConstraint DEVE essere maggiore o uguale a zero.
4.2.1.9	Le CA conformi DEVONO includere questa estensione in tutti i certificati CA che contengono chiavi pubbliche utilizzate per convalidare le firme digitali sui certificati e DEVONO contrassegnare l'estensione come critica in questi certificati.
4.2.1.9	Le CA NON DEVONO includere il campo pathLenConstraint a meno che il valore booleano cA non sia affermato e l'estensione Utilizzo chiave non affermi il bit keyCertSign.
4.2.1.10	L'estensione dei vincoli relativi ai nomi, che DEVE essere utilizzata solo in un certificato CA, indica uno spazio dei nomi all'interno del quale devono trovarsi tutti i nomi oggetto nei certificati successivi di un percorso di certificazione.
4.2.1.10	Vincoli relativi ai nomi: le CA conformi DEVONO contrassegnare questa estensione come critica
4.2.1.10	Le CA conformi NON DEVONO emettere certificati in cui i vincoli relativi ai nomi sono una sequenza vuota. ovvero deve essere presente il campo permittedSubtrees o excludedSubtrees.
4.2.1.10	All'interno di questo profilo, i campi minimo e massimo non vengono utilizzati con alcun modulo di nome, pertanto il valore minimo DEVE essere zero e il valore massimo DEVE essere assente.
4.2.1.10	La sintassi di iPAddress DEVE essere quella descritta nella sezione 4.2.1.6 con le seguenti aggiunte specifiche per i vincoli del nome: per gli indirizzi IPv4, il campo iPAddress di GeneralName DEVE contenere otto (8) ottetti, codificati nello stile di RFC 4632 (CIDR) per rappresentare un intervallo di indirizzi [RFC 4632]. Per gli indirizzi IPv6, il campo iPAddress DEVE contenere 32 ottetti codificati in modo simile.
4.2.1.10	NON DEVE imporre vincoli di nome ai moduli di nome x400Address, ediPartyName o registeredID.
4.2.1.11	Le CA conformi NON DEVONO emettere certificati in cui i vincoli delle norme sono una sequenza vuota. ovvero deve essere presente il campo inhibitPolicyMapping o il campo requireExplicitPolicy.
4.2.1.11	Vincoli dei criteri: le CA conformi DEVONO contrassegnare questa estensione come critica.
4.2.1.12	Le CA conformi NON DEVONO contrassegnare questa estensione come critica se è presente un KeyPurposeId anyExtendedKeyUsage.
4.2.1.13	Un DistributionPoint NON DEVE essere costituito solo dal campo reasons; devono essere presenti distributionPoint o cRLIssuer.
4.2.1.13	L'estensione Punti di distribuzione CRL DOVREBBE essere non critica
4.2.1.13	Se presente, DistributionPointName DEVE includere almeno un URI LDAP o HTTP.
4.2.1.13	Le CA conformi NON DEVONO utilizzare nameRelativeToCRLIssuer per specificare i nomi dei punti di distribuzione.
4.2.1.14	Le CA conformi DEVONO contrassegnare questa estensione Inhibit anyPolicy come critica.
4.2.1.15	L'estensione CRL più recente DEVE essere contrassegnata come non critica dalle CA conformi.
4.2.2.1	Le CA conformi DEVONO contrassegnare questa estensione di accesso alle informazioni sull'autorità come non critica.
4.2.2.1	Quando viene utilizzato il metodo di accesso id-ad-caIssuers, almeno un'istanza DEVE specificare una accessLocation che sia un URI HTTP [RFC 2616] o LDAP [RFC 4516].
4.2.2.2	Le CA conformi DEVONO contrassegnare questa estensione di accesso alle informazioni del soggetto come non critica.
7.2	Per adattare i nomi di dominio internazionalizzati alla struttura attuale, le implementazioni conformi DEVONO convertire i nomi di dominio internazionalizzati nel formato ASCII Compatible Encoding (ACE) come specificato nella sezione 4 di RFC 3490 prima dell'archiviazione nel campo dNSName.