Quando è composta una catena di certificati X.509 X1, X2 ... Xn e Xn sono root CA, Un certificato di livello inferiore può avere una validità più lunga periodo rispetto ai suoi genitori? Penso che il livello più basso dovrebbe essere la corretta sottogamma di alto livello almeno nella pratica.
Anche se non riesco a trovare alcun obbligo del genere in RFC2459, posso contare su questa ipotesi?
Qualsiasi commento è molto apprezzato.
Questo è un punto storicamente contestato.
Nell' algoritmo di convalida di RFC 5280 (che sostituisce RFC 2459 , a proposito), non è richiesto il nidificazione dell'intervallo di validità. Tuttavia, alcune implementazioni storiche hanno insistito su di esso; vedi ad esempio la guida in stile X.509 di Peter Gutmann:
Although this isn't specified in any standard, some software requires validity period nesting, in which the subject validity period lies inside the issuer validity period. Most software however performs simple pointwise checking in which it checks whether a cert chain is valid at a certain point in time (typically the current time). Maintaining the validity nesting requires that a certain amount of care be used in designing overlapping validity periods between successive generations of certificates in a hierarchy. Further complications arise when an existing CA is re-rooted or re-parented (for example a divisional CA is subordinated to a corporate CA).
Microsoft PKI ("ADCS", ovvero Servizi certificati Active Directory ) impone l'annidamento del periodo di validità, in quanto, quando emette un certificato, non consente la data di fine validità di quel certificato per superare quello dell'attuale certificato CA (in effetti, troncando il periodo di validità richiesto dal modello se portasse a tale situazione).
Anche se, durante il rinnovo di un certificato CA, è possibile mantenere lo stesso nome CA e la stessa chiave CA, nel qual caso sia i certificati CA vecchi sia quelli nuovi possono essere usato in modo intercambiabile finché non è scaduto nessuno, su certificati EE emessi sia prima che dopo il rinnovo. Cioè, se il vecchio certificato CA è CA1, il nuovo è CA2, il certificato EE1 è stato emesso prima del rinnovo e del certificato EE2 è stato emesso dopo, quindi CA1- > EE1, CA1- > EE2, CA2- > EE1 e CA2- > EE2 dovrebbe tutti essere convalidati; questo è molto conveniente per garantire transizioni fluide. Mentre la nidificazione del periodo di validità implica che CA1- > EE1 e CA2- > EE2 si annidano, CA1- > EE2 e CA2- > EE1 potrebbero non essere nidificati - e questo va bene.
Riepilogo: non puoi fare affidamento sull'annidamento del periodo di validità e non dovresti cercare di applicare il nidificazione durante la convalida dei certificati.
Hmm, sono d'accordo che mi sarei aspettato di trovare queste informazioni in RFC 5280 4.1.2.5. Validità . (A proposito, RFC 5280 obsoleto RFC 3280, che obsoleto RFC 2459, quindi non dovresti più guardare al 2459).
Detto questo, puoi calcolarlo logicamente (almeno per un'impostazione standard simile a TLS): quando un utente finale convalida un certificato, deve seguire la catena fino alla radice, assicurando che ogni certificato lungo la via è valida Diciamo che X2 scade prima di X1 (e supponiamo che X2 fosse l'emittente per X1). Una volta che X2 scade, X1 è buono quanto inutile poiché non c'è modo di costruire una catena di convalida da X1 a Xn.
Ecco un caso in cui una CA potrebbe emettere certificazioni con una durata maggiore rispetto alla radice: i requisiti affermano che A) Tutti i certificati foglia devono avere una durata di 3 anni (diciamo che stanno entrando in dispositivi embedded) B) Tutti i fogli i certificati devono essere emessi dalla stessa radice (diciamo che hai solo spazio per appuntare una radice). Ora, il certificato CA scadrà tra 2 anni e in quel momento si pianifica di emettere un nuovo certificato CA per la stessa chiave CA. In tal caso, non c'è problema nel rilasciare una certificazione fogliare di 3 anni su una radice di 2 anni.
La domanda che stai ponendo è un po 'vaga sul fatto che tu stia cercando la CA / emittente per applicare la regola della "nidificazione della validità" o che il client / verificatore la applichi.
Se sei CA / Emittente: : dipende da te. Esistono molte CA che non emetteranno un certificato con una durata maggiore rispetto a se stessi. Detto questo, posso immaginare scenari in cui potrebbe voler fare questo.
Se sei il cliente / verificatore: non penso che ti guadagni qualcosa per essere severi su questo. Stai provocando intenzionalmente problemi di compatibilità tra il tuo client e le CA che non seguono "l'annidamento della validità" ... per quale guadagno? _ (supponendo che tutti i certificati della catena debbano essere nel loro periodo di validità al momento della convalida, suppongo che questo sia ciò che chiami "convalida standard" nel tuo commento).
Leggi altre domande sui tag tls certificates x.509