Quali proprietà di un certificato X.509 dovrebbero essere fondamentali e quali no?

Question

Quali proprietà di un certificato X.509 dovrebbero essere fondamentali e quali no?

#1 da (30 voti)

23

Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

ma non riesco a trovare informazioni (preferibilmente una breve lista) su che le estensioni dovrebbero (non) essere designate come critiche. Ho riscontrato che basicConstraints è critico, sia perché è di base, sia perché un certificato contrassegnato come CA:FALSE non dovrebbe ovviamente essere in grado di firmare certificati figlio (anche se penso di aver letto da qualche parte che pathlen per le CA ristrette sembra essere ignorato di tanto in tanto) - ma è anche una delle parti più basilari di un certificato, che è probabilmente il motivo per cui è spesso non designato come critico. keyUsage suona come un buon candidato per la critica, ma per quanto riguarda extendedKeyUsage e subjectAltName ?

C'è una breve panoramica che indica quali estensioni dovrebbero essere a) critiche b) non critiche c) non ha importanza?

public-key-infrastructure certificates x.509 restrictions

posta Tobias Kienzler 15.02.2013 - 18:01

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure certificates x.509 restrictions

Quali sono i vantaggi e gli svantaggi dei diversi tipi di sensori di movimento? Perché è falso il certificato SSL difficile?

score 30 · Accepted Answer

In "puro X.509", non importa se un'estensione è critica o meno, perché le implementazioni conformi devono onorare le estensioni che riconoscono, siano esse contrassegnate come critiche o meno. Il flag "critico" è per le estensioni che sono non standard: si rende critica tale estensione se è importante per la sicurezza (implementazioni che non comprendono l'estensione dovrebbe rifiutare il certificato) o non critica altrimenti (le implementazioni che non comprendono l'estensione possono quindi ignorarlo tranquillamente).

C'è una leggera eccezione a questa regola, con l'estensione CRL Distribution Points . Ha due scopi: documentare da dove può essere scaricato CRL e implementare la segmentazione dell'ambito . Quest'ultimo ruolo è attivo solo quando l'estensione è critica. Quando l'estensione è critica, si può ritenere che un CRL copra il certificato (ossia che sia in grado di dire qualcosa sul suo stato di revoca) solo se il CRL contiene un'estensione Issuing Distribution Point , con un "punto di distribuzione" che corrisponde a uno di quelli specificati nell'estensione CRL Distribution Point nel certificato. Quando l'estensione non è critica, l'estensione serve solo nel suo ruolo di documentazione.

In pratica , renderete le estensioni critiche o meno a seconda che possano essere ignorate senza perforare un buco troppo grande nell'intera sicurezza, e anche a seconda se rendere l'estensione critica indurrà implementazioni per rifiutare il certificato per mancanza di supporto. Ad esempio, se si utilizza un'estensione critica Name Constraints , si rischia il rifiuto incondizionato da OpenSSL (le versioni precedenti alla 1.0, che è piuttosto recente, non la supportano); ma se lo rendi non critico, allora lo stesso OpenSSL lo ignorerà . L'estensione Name Constraints è un caso tipico di un'estensione che non può essere ignorata in modo sicuro e pertanto dovrebbe sempre essere contrassegnata come critica (ma ne rendono problematico l'utilizzo).

RFC 5280 elenca, per ogni estensione di certificato, se una CA conforme deve rendere l'estensione critica o meno. Questi sono requisiti sulla CA e non sui validatori; un sistema che convalida un certificato non deve rifiutarlo sulla base del fatto che include un'estensione critica Subject Key Identifier , anche se la RFC 5280 dice (sezione 4.2.1.2):

Conforming CAs MUST mark this extension as non-critical.

Vedi la RFC per i dettagli su ogni estensione: queste sono le linee guida su come dovrebbe comportarsi la tua CA. Ad esempio, Key Usage è un "DOVREBBE essere critico", Basic Constraints è un "PU be essere critico", Name Constraints è un "DEVE essere critico", e così via ... Se segui queste regole, la tua sicurezza andrà bene (ma potrebbe essere necessario apportare alcune modifiche per l'interoperabilità).