Requisiti del programma - Programma radice attendibile Microsoft

1. Introduzione

Microsoft Root Certificate Program supporta la distribuzione dei certificati radice, consentendo ai clienti di considerare attendibili i prodotti Windows. Questa pagina descrive i requisiti generali e tecnici del programma.

Nota

• Per informazioni sugli aggiornamenti più recenti spediti, vedere https://aka.ms/rootupdates
• Aggiungere un segnalibro a questa pagina come segue: https://aka.ms/RootCert

2. Requisiti di programma continui

Requisiti di controllo

1. I partecipanti al programma devono fornire a Microsoft prove di un controllo qualificato (vedere https://aka.ms/auditreqs) per ogni CA radice, ca subordinata non vincolata, e certificato con firma incrociata, prima di eseguire operazioni commerciali e successive su base annuale.
2. I partecipanti al programma devono assumere la responsabilità di garantire che tutte le CA subordinate non vincolate e i certificati con firma incrociata soddisfino i requisiti di controllo del programma.
3. Le CA devono divulgare pubblicamente tutti i report di controllo per le CA subordinate non vincolate.
4. I provider ca devono assicurarsi che le CA radice abilitate per S/MIME e tutte le CA subordinate in grado di emettere certificati S/MIME siano stati controllati e continueranno a essere controllati sulla versione più recente di, almeno uno dei set di criteri seguenti. Questo controllo deve essere eseguito almeno una volta all'anno. Un periodo di controllo iniziale deve iniziare entro il 1° settembre 2023.
   
   • Principi e criteri WebTrust per le autorità di certificazione - S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP o NCP+
     

Requisiti di comunicazione e divulgazione

4. I partecipanti al programma devono fornire a Microsoft le identità di almeno due "agenti attendibili" per fungere da rappresentanti del programma e un alias di posta elettronica generale. I partecipanti al programma devono informare Microsoft dopo la rimozione o l'aggiunta di personale come agente attendibile. I partecipanti al programma accettano di ricevere notifiche tramite posta elettronica e devono fornire a Microsoft un indirizzo di posta elettronica per ricevere comunicazioni ufficiali. I partecipanti al programma devono accettare che l'avviso sia efficace quando Microsoft invia un messaggio di posta elettronica o una lettera ufficiale. Almeno uno dei contatti o gli alias forniti deve essere un canale di comunicazione monitorato 24/7 per le richieste di revoca o altre situazioni di gestione degli eventi imprevisti.

5. Il partecipante del programma deve divulgare la gerarchia PKI completa (CA subordinata non limitata, ca non registrate radice con firma incrociata, CA subordinate, EKU, vincoli di certificato) a Microsoft su base annuale, inclusi i certificati rilasciati a ca esterne gestite da terze parti esterne all'interno del CCADB. I partecipanti al programma devono mantenere queste informazioni accurate nel database CCADB quando si verificano modifiche. Se un'autorità di certificazione subordinata non viene divulgata o controllate pubblicamente, deve essere vincolata dal dominio.

6. I partecipanti al programma devono informare Microsoft tramite posta elettronica almeno 120 giorni prima di trasferire la proprietà della CA radice o subordinata registrata che si concatena a una radice registrata a un'altra entità o persona.

7. Il codice motivo deve essere incluso nelle revoche per i certificati intermedi. Le ca devono aggiornare il database CCADB quando revocano i certificati intermedi entro 30 giorni.

8. I partecipanti al programma accettano che Microsoft possa contattare i clienti che Microsoft ritiene che potrebbero essere interessati in modo sostanziale dalla rimozione in sospeso di una CA radice dal programma.

Altri requisiti

9. Le ca commerciali potrebbero non registrare una CA radice nel programma che deve essere considerata attendibile internamente all'interno di un'organizzazione (ad esempio CA enterprise).

10. Se un'autorità di certificazione usa un subappaltatore per gestire qualsiasi aspetto della propria attività, la CA assumerà la responsabilità per le operazioni aziendali del subappaltatore.

11. Se Microsoft, a sua esclusiva discrezione, identifica un certificato il cui utilizzo o attributi è determinato a essere contrario agli obiettivi del programma radice attendibile, Microsoft informerà la CA responsabile e richiederà di revocare il certificato. La CA deve revocare il certificato o richiedere un'eccezione a Microsoft entro 24 ore dalla ricezione dell'avviso di Microsoft. Microsoft esaminerà il materiale inviato e informerà la CA della decisione finale di concedere o negare l'eccezione a sua esclusiva discrezione. Nel caso in cui Microsoft non conceda l'eccezione, la CA deve revocare il certificato entro 24 ore dall'eccezione negata.

---

3. Requisiti tecnici del programma

Tutte le ca del programma devono essere conformi ai requisiti tecnici del programma. Se Microsoft determina che una CA non è conforme ai requisiti seguenti, Microsoft escluderà tale CA dal programma.

R. Requisiti radice

1. I certificati radice devono essere certificati x.509 v3.
   1. L'attributo CN deve identificare l'autore e deve essere univoco.
   2. L'attributo CN deve essere in una lingua appropriata per il mercato della CA e leggibile da un cliente tipico di tale mercato.
   3. Estensione vincoli di base: deve essere cA=true.
   4. L'estensione Key Usage DEVE essere presente e DEVE essere contrassegnata come critica. Le posizioni di bit per KeyCertSign e cRLSign DEVONO essere impostate. Se per firmare le risposte OCSP viene usata la chiave privata della CA radice, è necessario impostare il bit digitalSignature.
      • Le dimensioni della chiave radice devono soddisfare i requisiti descritti in "Requisiti chiave".
2. I certificati da aggiungere all'archivio radice attendibile DEVONO essere certificati radice autofirmati.
3. Le ca radice appena coniate devono essere valide per un minimo di otto anni, e un massimo di 25 anni, dalla data di invio.
4. Le ca radice partecipanti potrebbero non rilasciare nuovi certificati RSA a 1024 bit dalle radici coperte da questi requisiti.
5. Tutti i certificati di entità finale devono contenere un'estensione AIA con un URL OCSP valido. Questi certificati possono anche contenere un'estensione CDP che contiene un URL CRL valido. Tutti gli altri tipi di certificato devono contenere un'estensione AIA con un URL OCSP o un'estensione CDP con un URL CRL valido
6. Le chiavi private e i nomi dei soggetti devono essere univoci per ogni certificato radice; il riutilizzo di chiavi private o nomi di soggetto nei certificati radice successivi dalla stessa CA può causare problemi imprevisti di concatenamento dei certificati. Le ca devono generare una nuova chiave e applicare un nuovo nome soggetto durante la generazione di un nuovo certificato radice prima della distribuzione da parte di Microsoft.
7. Le autorità di certificazione governative devono limitare l'autenticazione server a domini di primo livello rilasciati dal governo e possono rilasciare solo altri certificati ai codici di paese ISO3166 su cui il paese ha il controllo sovrano (vedere https://aka.ms/auditreqs la sezione III per la definizione di una "CA per enti pubblici"). Questi TLD rilasciati dal governo sono indicati nel rispettivo contratto di ogni CA.
8. Il rilascio di certificati CA che concatenano a una CA radice partecipante deve separare l'autenticazione del server, S/MIME, la firma del codice e l'uso del timestamp. Ciò significa che una singola CA emittente non deve combinare l'autenticazione server con S/MIME, firma del codice o timestamp EKU. Per ogni caso d'uso deve essere usato un intermedio separato.
9. I certificati di entità finale devono soddisfare i requisiti per il tipo di algoritmo e le dimensioni della chiave per i certificati sottoscrittori elencati nell'Appendice A dei requisiti di base del forum CAB disponibili in https://cabforum.org/baseline-requirements-documents/.
10. Le ca devono dichiarare uno degli ID dei criteri seguenti nel certificato dell'estensione dell'entità finale dell'estensione dei criteri di certificato.
    1. DV 2.23.140.1.2.1.
    2. OV 2.23.140.1.2.2.
    3. EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3.
    5. Firma del codice non EV 2.23.140.1.4.1.
11. A partire da agosto 2024, tutti gli OID SSL EV personalizzati gestiti dal programma radice attendibile e i rispettivi strumenti verranno rimossi e sostituiti con l'OID SSL SSL conforme a CA/B (2.23.140.1.1). Il team di Microsoft Edge implementerà i controlli per EV SSL OID (2.23.140.1.1) nel browser, quindi altri OID SSL EV non verranno più accettati per allinearsi a Edge e per evitare incompatibilità.
12. Le CA potrebbero non avere più di 2 ID OID applicati al certificato radice.
13. I certificati di entità finale che includono un'estensione Vincoli di base in base a IETF RFC 5280 devono avere il campo cA impostato su FAL edizione Standard e il campo pathLenConstraint deve essere assente.
14. Una CA deve tecnicamente vincolare un risponditore OCSP in modo che l'unico EKU consentito sia la firma OCSP.
15. Una CA deve essere in grado di revocare un certificato a una data specifica come richiesto da Microsoft.

B. Requisiti per la firma

Algoritmo	Tutti gli usi tranne la firma del codice e il timestamp	Uso della firma del codice e del timestamp
Algoritmi digest	SHA2 (SHA256, SHA384, SHA512)	SHA2 (SHA256, SHA384, SHA512)
RSA	2048	4096 (solo nuove radici)
ECC/ECDSA	NIST P-256, P-384, P-521	NIST P-256, P-384, P-521

Nota: le firme che usano la crittografia a curva ellittica (ECC), ad esempio ECDSA, non sono supportate in Windows e nelle funzionalità di sicurezza di Windows più recenti. Gli utenti che usano questi algoritmi e certificati affronteranno diversi errori e potenziali rischi per la sicurezza. Il Programma radice attendibile Microsoft consiglia che i certificati ECC/ECDSA non devono essere rilasciati ai sottoscrittori a causa di questa incompatibilità e rischio noti.

C. Requisiti di revoca

1. Le ca devono avere un criterio di revoca documentato e devono avere la possibilità di revocare qualsiasi certificato che rilascia.
2. Le ca che rilasciano certificati di autenticazione server devono supportare entrambi i requisiti del risponditore OCSP seguenti:
   1. Validità minima di otto (8) ore; validità massima di sette (7) giorni.
   2. L'aggiornamento successivo deve essere disponibile almeno otto (8) ore prima della scadenza del periodo corrente. Se la validità è superiore a 16 ore, l'aggiornamento successivo deve essere disponibile al 1/2 del periodo di validità.
3. Tutti i certificati rilasciati da una CA radice devono supportare l'estensione del punto di distribuzione CRL e/o l'AIA contenente un URL del risponditore OCSP.
4. La CA non deve usare il certificato radice per rilasciare certificati di entità finale.
5. Se una CA rilascia certificati di firma del codice, deve usare un'autorità timestamp conforme a RFC 3161, "Internet X.509 Public Key Infrastructure TimeStamp Protocol (TSP)."

D. Requisiti del certificato radice per la firma del codice

1. I certificati radice che supportano l'uso della firma del codice possono essere rimossi dalla distribuzione entro 10 anni dalla data di distribuzione di un certificato radice di rollover sostitutivo o prima, se richiesto dalla CA.
2. I certificati radice che rimangono nella distribuzione per supportare solo l'uso della firma del codice oltre la durata della sicurezza degli algoritmi (ad esempio RSA 1024 = 2014, RSA 2048 = 2030) possono essere impostati su "disable" nel sistema operativo Windows 10.
3. A partire da febbraio 2024, Microsoft non accetterà più né riconoscerà i certificati di firma del codice EV e CCADB smetterà di accettare i controlli di firma del codice EV. A partire da agosto 2024, tutti gli ID di firma del codice EV verranno rimossi dalle radici esistenti nel programma radice attendibile Microsoft e tutti i certificati di firma del codice verranno trattati allo stesso modo.

E. Requisiti EKU

1. Le ca devono fornire una giustificazione aziendale per tutte le EKU assegnate al certificato radice. La giustificazione può essere sotto forma di prove pubbliche di un'attività corrente di rilascio di certificati di un tipo o di tipi o di un piano aziendale che dimostra un'intenzione di rilasciare tali certificati a breve termine (entro un anno di distribuzione del certificato radice dal programma).

2. Microsoft abiliterà solo le EKU seguenti:

   1. Autenticazione server =1.3.6.1.5.5.7.3.1
   2. Autenticazione client =1.3.6.1.5.5.7.3.2
   3. Posta elettronica sicura EKU=1.3.6.1.5.5.7.3.4
   4. Timestamp EKU=1.3.6.1.5.5.7.3.8
   5. Firma del documento EKU=1.3.6.1.4.1.311.10.3.12
   • Questo EKU viene usato per firmare documenti all'interno di Office. Non è necessario per altri utilizzi di firma del documento.

F. Requisiti per la firma del codice in modalità kernel (KMCS) di Windows 10

Windows 10 ha requisiti elevati per convalidare i driver in modalità kernel. I driver devono essere firmati sia da Microsoft che da un partner del programma usando i requisiti di convalida estesa. Tutti gli sviluppatori che desiderano avere i driver in modalità kernel inclusi in Windows devono seguire le procedure descritte dal team di sviluppo hardware Microsoft. Per altre informazioni, vedere il Centro per i partner per l'hardware Windows.