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, il servizio CA non applica tutti i requisiti RFC 5280 ed è possibile che una CA creata utilizzando il servizio CA emetta un certificato non conforme.

Certificate Authority Service applica i seguenti requisiti RFC 5280.

Sezione RFC 5280	Clausola Lint
4.1.1.2	Il campo signatureAlgorithm in Certificate DEVE contenere lo stesso identificatore di 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 (valore 2).
4.1.2.2	Il numero di serie DEVE essere un numero intero positivo assegnato dall'autorità di certificazione 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à del certificato fino all'anno 2049 come UTCTime
4.1.2.5.1	I valori UTCTime DEVONO essere espressi in ora del meridiano di Greenwich (Zulu)
4.1.2.5.1	I valori UTCTime DEVONO includere i secondi
4.1.2.5.2	I valori GeneralizedTime DEVONO essere espressi nel fuso orario di Greenwich (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 es. è presente l'estensione dei vincoli di base, come discusso nella Sezione 4.2.1.9, e il valore di cA è TRUE), il campo soggetto DEVE essere compilato con un nome distinto non vuoto che corrisponda ai contenuti del campo emittente (Sezione 4.1.2.4) in tutti i certificati emessi dalla CA soggetto.
4.1.2.8	I campi degli 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 dell'oggetto, DEVE supportare l'estensione del nome alternativo dell'oggetto
4.2.1.1	Il campo keyIdentifier dell'estensione authorityKeyIdentifier DEVE essere incluso in tutti i certificati generati da CA conformi per facilitare la costruzione 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 costruzione del percorso di certificazione, authorityKeyIdentifier DEVE essere presente in tutti i certificati CA conformi, ovvero in tutti i certificati che includono l'estensione dei vincoli di base (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 dell'oggetto come non critica.
4.2.1.3	Se il bit keyCertSign è attivato, deve essere attivato 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.4	Un OID delle norme del certificato NON DEVE comparire più di una volta in un'estensione delle norme del certificato.
4.2.1.4	Quando i qualificatori vengono utilizzati con la policy speciale anyPolicy, DEVONO essere limitati ai qualificatori identificati in questa sezione.
4.2.1.5	I criteri NON DEVONO essere mappati al valore speciale anyPolicy o da questo
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 dell'oggetto (o del nome alternativo dell'emittente).
4.2.1.6	Se il campo dell'oggetto contiene una sequenza vuota, l'autorità di certificazione che lo ha emesso DEVE includere un'estensione subjectAltName contrassegnata come critica.
4.2.1.6	Quando l'estensione subjectAltName contiene un indirizzo email 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 dell'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 (un'IA5String).
4.2.1.6	SAN: il valore dNSName DEVE essere nella "sintassi del nome preferito"
4.2.1.6	NON DEVONO essere utilizzate estensioni subjectAltName con un valore dNSName di " "
4.2.1.6	NON DEVE essere utilizzata la rappresentazione DNS per gli indirizzi email 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 (un'IA5String).
4.2.1.6	URI SAN: il nome NON DEVE essere un URI relativo e DEVE seguire la sintassi e le regole di codifica degli URI specificate in [RFC 3986].
4.2.1.6	URI SAN: il nome DEVE includere sia 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 è presente l'estensione subjectAltName, 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.7	Il nome alternativo dell'emittente DEVE essere codificato come in 4.2.1.6
4.2.1.8	Attributi della directory dei soggetti: le CA conformi DEVONO contrassegnare questa estensione come non critica.
4.2.1.9	Dove viene visualizzato, 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 degli oggetti nei certificati successivi in 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. In altre parole, il campo permittedSubtrees o il campo excludedSubtrees DEVE essere presente.
4.2.1.10	In questo profilo, i campi minimo e massimo non vengono utilizzati con nessuna forma 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 come descritto nella Sezione 4.2.1.6 con le seguenti aggiunte specifiche per i vincoli dei nomi: 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.11	Le CA conformi NON DEVONO emettere certificati in cui i vincoli delle norme sono una sequenza vuota. In altre parole, è necessario che sia presente il campo inhibitPolicyMapping o il campo requireExplicitPolicy.
4.2.1.11	Vincoli delle norme: le CA conformi DEVONO contrassegnare questa estensione come critica.
4.2.1.13	un DistributionPoint NON DEVE essere costituito solo dal campo reasons; devono essere presenti distributionPoint o cRLIssuer.
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 per l'accesso alle informazioni sull'autorità come non critica.
4.2.2.2	Le CA conformi DEVONO contrassegnare questa estensione di accesso alle informazioni sull'oggetto come non critica.
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.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 presente, le CA conformi DEVONO contrassegnare questa estensione di utilizzo della chiave come critica.
4.2.1.4	Le CA conformi NON DEVONO utilizzare l'opzione noticeRef.
4.2.1.4	Le CA conformi DOVREBBERO 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. U+0000 a U+001F e 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	Ogni issuerDomainPolicy denominato nell'estensione delle mappature dei criteri DEVE essere affermato anche in un'estensione dei criteri del certificato nello stesso certificato.
4.2.1.5	Le CA conformi DOVREBBERO contrassegnare questa estensione di mappatura dei criteri come critica.
4.2.1.6	Quando includi l'estensione subjectAltName in un certificato con un nome distinto dell'oggetto non vuoto, le CA conformi DEVONO contrassegnare l'estensione subjectAltName come non critica.
4.2.1.7	Ove presente, le CA conformi DEVONO contrassegnare questa estensione Nome alternativo emittente come non critica.
4.2.1.10	NON DEVE imporre vincoli sui nomi per i formati x400Address, ediPartyName o registeredID.
4.2.1.12	Le CA conformi NON DEVONO contrassegnare questa estensione come critica se è presente il KeyPurposeId anyExtendedKeyUsage.
4.2.1.13	L'estensione Punti di distribuzione CRL DEVE 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.2.1	Quando viene utilizzato il metodo di accesso id-ad-caIssuers, almeno un'istanza DEVE specificare un'accessLocation che sia un URI HTTP [RFC 2616] o LDAP [RFC 4516].
7.2	Per supportare i nomi di dominio internazionalizzati nella struttura attuale, le implementazioni conformi DEVONO convertire i nomi di dominio internazionalizzati nel formato ACE (ASCII Compatible Encoding) come specificato nella Sezione 4 del RFC 3490 prima di memorizzarli nel campo dNSName.