Requisiti del programma - Microsoft Trusted Root Program

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.

2. Requisiti di programma continui

Requisiti di controllo

1. I partecipanti al programma devono fornire a Microsoft prove di una verifica qualificata (vedere https://aka.ms/auditreqs) per ogni CA radice, CA subordinata non vincolata e certificato con firma incrociata, prima di condurre operazioni commerciali e successivamente 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 state sottoposte ad audit e continueranno a essere sottoposte ad audit 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 al programma deve divulgare l'intera gerarchia PKI (CA subordinata non limitata, CA radice non iscritte, con firma incrociata, CA subordinate, EKUs, vincoli di certificato) a Microsoft su base annuale, inclusi i certificati emessi a CAs 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 controllata pubblicamente, deve essere limitata al dominio.

6. I partecipanti al programma devono comunicare a Microsoft via email almeno 120 giorni prima di trasferire la proprietà della CA principale o subordinata registrata, collegata 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 possano essere interessati in modo sostanziale dalla rimozione imminente di una CA radice dal programma.

Altri requisiti

9. Le CA commerciali potrebbero non registrare un'autorità di certificazione root nel programma destinata ad essere considerata attendibile principalmente all'interno di un'organizzazione (ad esempio, CA aziendali).

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 nel 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.

A. Requisiti di base

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. L'estensione dei 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, il bit digitalSignature DEVE essere impostato.
      • Le dimensioni della chiave radice devono soddisfare i requisiti descritti di seguito in "Requisiti di firma".
2. I certificati da aggiungere all'archivio dei certificati radici attendibili DEVONO essere certificati radice autofirmati.
3. Le CA Radice appena emesse devono essere valide per un minimo di otto anni e, al massimo, di 25 anni, dalla data di rilascio.
4. Le CA a livello radice partecipanti non devono rilasciare nuovi certificati RSA a 1024 bit dalle radici coperte da questi requisiti.
5. Tutti i certificati dell'Autorità di Certificazione emittente devono contenere un'estensione CDP con un CRL valido e/o un'estensione AIA verso un risponditore OCSP. Un certificato di entità finale può contenere un'estensione AIA con un URL OCSP valido e/o un'estensione CDP che punta a un endpoint HTTP valido contenente il CRL. Se non è inclusa un'estensione AIA con un URL OCSP valido, il file CRL risultante deve essere <10 MB.
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 del soggetto quando generano un nuovo certificato root 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 sono collegati a una CA radice partecipante deve separare l'autenticazione del server, S/MIME, la firma del codice e la marcatura temporale. 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 dei seguenti OID di politica nell'estensione della Politica del Certificato del certificato entità finale.
    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.
    6. Cassetta postale S/MIME convalidata legacy 2.23.140.1.5.1.1.
    7. Cassetta postale S/MIME convalidata multiuso 2.23.140.1.5.1.2.
    8. Casella di posta S/MIME validata Strict 2.23.140.1.5.1.3.
    9. S/MIME Organization Validated Legacy 2.23.140.1.5.2.1.
    10. S/MIME Organization Validated Multipurpose 2.23.140.1.5.2.2.
    11. S/MIME Validato dall'Organizzazione Strict 2.23.140.1.5.2.3.
    12. S/MIME Sponsor Validated Legacy 2.23.140.1.5.3.1.
    13. S/MIME Sponsor Validated Multipurpose 2.23.140.1.5.3.2.
    14. S/MIME Sponsor Validated Strict 2.23.140.1.5.3.3.
    15. S/MIME Individual Validated Legacy 2.23.140.1.5.4.1.
    16. S/MIME Individual Validated Multipurpose 2.23.140.1.5.4.2.
    17. S/MIME Individual Validated Strict 2.23.140.1.5.4.3.
11. A partire da agosto 2024, tutti gli OID personalizzati EV SSL gestiti dal Trusted Root Program e i relativi strumenti verranno rimossi e sostituiti con l'OID EV SSL conforme al CA/B Forum (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 OID applicati al loro 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 FALSE 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

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 di Microsoft raccomanda che i certificati ECC/ECDSA non dovrebbero essere rilasciati ai sottoscrittori a causa di questa nota incompatibilità e dei rischi correlati.
• La firma del codice non supporta ECC o chiavi > 4096

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. Requisiti del servizio di risposta OCSP: a. Validità minima di otto (8) ore; Validità massima di sette (7) giorni; e b. 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 il periodo di validità.

3. Raccomandazioni CRL quando OCSP non è presente: a. Deve contenere l'estensione specifica di Microsoft 1.3.6.1.4.1.311.21.4 (pubblicazione CRL successiva). b. Il nuovo CRL deve essere disponibile all'orario di pubblicazione successivo del CRL. c. Le dimensioni massime del file CRL (CRL completo o CRL partizionato) non devono superare 10M.

   Nota

   L'obiettivo della sezione 3.C.3- Raccomandazioni CRL quando OCSP non è presente è fornire copertura per gli utenti finali in casi di revoca di massa.

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 da parte del Programma entro 10 anni dalla data di distribuzione di un certificato radice sostitutivo in un processo di rollover 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, tutte le OID di firma del codice EV verranno rimosse dalle radici attuali nel "Microsoft Trusted Root Program" 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 tutti gli EKU assegnati 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. Marca temporale 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 usi 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 ulteriori informazioni, consultare il Partner Center for Windows Hardware.