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 e una CA creata utilizzando CA Service può emettere un certificato non conforme.

CA Service applica i seguenti requisiti RFC 5280.

Sezione RFC 5280	Clausola Lint
4.1.1.2	Il signatureAlgorithm in Certificate DEVE contenere lo stesso algoritmo di identificatore del campo di firma 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 dell'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 nel fuso orario di Greenwich (Zulu)
4.1.2.5.1	I valori UTCTime DEVONO includere i secondi
4.1.2.5.2	I valori del tempo GeneralizedTime DEVONO essere espressi nel fuso orario di Greenwich (Zulu)
4.1.2.5.2	GeneralizedTime DEVE includere secondi
4.1.2.5.2	I valori GeneralizedTime NON DEVONO includere i secondi frazionari
4.1.2.6	Se l'oggetto è una CA (ad esempio, è presente l'estensione dei vincoli di base, come discusso nella Sezione 4.2.1.9, e il valore di cA è TRUE), il campo dell'oggetto DEVE essere compilato con un nome distinto non vuoto corrispondente al contenuto del campo dell'emittente (Sezione 4.1.2.4) in tutti i certificati emessi dall'oggetto CA.
4.1.2.8	I campi di identificatori univoci DEVONO essere visualizzati solo se la versione è la 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 delle 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 la CA 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 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 apparire in tutti i certificati CA conformi, ovvero in tutti i certificati, inclusa 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 è affermato, allora il bit cA nei vincoli di base estensione (Sezione 4.2.1.9) DEVE anche essere asserito.
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 del criterio del certificato NON DEVE apparire più di una volta in un'estensione dei criteri dei certificati.
4.2.1.4	Quando vengono utilizzati con il criterio speciale anyPolicy, i qualificatori DEVONO essere limitati ai qualificatori identificati in questa sezione.
4.2.1.5	I criteri NON DEVONO essere mappati al valore speciale anyPolicy
4.2.1.6	Ogni volta che tali identità (qualsiasi elemento in una 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 email Internet, l'indirizzo DEVE essere archiviato nel rfc822Name.
4.2.1.6	Per la versione IP 4, come specificato in [RFC 791], la stringa ottetto DEVE contenere esattamente quattro ottetti. Per la versione IP 6, come specificato in [RFC 2460], la stringa ottetto DEVE contenere esattamente sedici ottetti.
4.2.1.6	Quando l'estensione subjectAltName contiene un'etichetta del sistema dei nomi di dominio, il nome del dominio DEVE essere memorizzato nel campo dNSName (una stringa IA5).
4.2.1.6	SAN: il dNSName DEVE essere nella "sintassi del nome preferito"
4.2.1.6	Le estensioni subjectAltName con un valore dNSName pari a " " NON DEVONO essere utilizzate
4.2.1.6	l'utilizzo della rappresentazione DNS per gli indirizzi di posta Internet (subscriber.example.com anziché [e-mail]) NON DEVE essere utilizzato
4.2.1.6	Quando l'estensione subjectAltName contiene un URI, il nome DEVE essere archiviato in uniformResourceIdentifier (una stringa IA5String).
4.2.1.6	SAN URI: Il nome non DEVE essere un URI relativo, e DEVE seguire la sintassi URI e la codifica delle regole specificate in [RFC 3986].
4.2.1.6	URI SAN: il nome DEVE includere entrambi 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 come host un nome di dominio completo o un indirizzo IP.
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 subjectAltName 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 directory soggetto: 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 non venga indicato il valore booleano cA e l'estensione di utilizzo della chiave asserzioni il bit keyCertSign.
4.2.1.10	L'estensione di limitazioni dei 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 quando i vincoli relativi ai nomi sono una sequenza vuota. Ciò significa che il campo allowedSubtrees o il campo excludedSubtrees DEVONO essere presente.
4.2.1.10	All'interno di questo profilo, i campi minimo e massimo non vengono utilizzati con alcun tipo 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 specificamente per i vincoli di nome: Per gli indirizzi IPv4, il campo iPAddress di GeneralName DEVE contenere otto (8) ottetti, codificato 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 con codifica simile.
4.2.1.11	Le CA conformi NON DEVONO emettere certificati quando i vincoli dei criteri sono una sequenza vuota. In altre parole, il campo inhibitPolicyMapping o il campo request energetici DEVONO essere presente.
4.2.1.11	Vincoli relativi ai criteri: le CA conformi DEVONO contrassegnare questa estensione come critica.
4.2.1.13	un DistributionPoint NON DEVE essere costituito solo dal campo motivi; DEVE essere presente distribuzionePoint 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 mediante 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 del soggetto come non critica.
4.1.2.5	Per indicare che un certificato non ha una data di scadenza ben definita, al valore notAfter DOVREBBE essere assegnato il valore GeneralizedTime di 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 presenti, le CA conformi DEVONO contrassegnare questa estensione per l'utilizzo delle chiavi come critica.
4.2.1.4	Le CA conformi NON DEVONO utilizzare l'opzione notificationRef.
4.2.1.4	Le CA conformi DEVONO utilizzare la codifica UTF8String per expressText, ma POTREBBE utilizzare IA5String.
4.2.1.4	La stringa esplicitiText 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 DOVREBBERO essere normalizzate secondo la normalizzazione Unicode modulo C (NFC)
4.2.1.5	Ogni syndicationDomainPolicy denominato nell'estensione di mapping dei criteri DEVE essere asserito anche in un'estensione delle norme del certificato nello stesso certificato.
4.2.1.5	Le CA conformi DEVONO 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 oggetto non vuoto, le CA conformi DEVONO contrassegnare l'estensione subjectAltName come non critica.
4.2.1.7	Se presente, le CA conformi DEVONO contrassegnare questa estensione del nome alternativo dell'emittente come non critica.
4.2.1.10	NON DEVE imporre vincoli per i nomi ai moduli dei nomi x400Address, ediPartyName oggerID.
4.2.1.12	Le CA conformi NON DEVONO contrassegnare questa estensione come critica se è presente anyExtendedKeyUsage KeyPurposeId.
4.2.1.13	L'estensione dei punti di distribuzione dei 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 il id-ad-caIssuers accessMethod viene utilizzato, almeno un'istanza DOVREBBE specificare un accessLocation che è un HTTP [RFC 2616] o LDAP [RFC 4516] URI.
7.2	Per ospitare nomi di dominio internazionalizzati nella struttura attuale, implementazioni conformi DEVONO convertire i nomi di dominio internazionalizzati nel formato di codifica compatibile ASCII (ACE), come specificato nella sezione 4 di RFC 3490 prima dell'archiviazione nel campo dNSName.