Ci sono dettagli enunciati in RFC 3850 . In pratica:
-
Si consiglia vivamente di includere il proprio indirizzo email nel certificato, in un'estensione Subject Alt Name
(o eventualmente come attributo extra in subjectDN
, ma questo è deprecato). Se il certificato non contiene l'indirizzo e-mail, i tuoi corrispondenti dovranno trovare un altro modo per associare il certificato al tuo indirizzo e-mail, e la maggior parte del software avrà dei problemi (è pensato per essere supportato, ma renderà le cose difficili altre persone).
-
Se l'utilizzo del certificato è limitato con un'estensione Key Usage
, allora digitalSignature
e / o nonRepudiation
devono essere consentiti esplicitamente in tale estensione.
-
Se il certificato contiene un'estensione Extended Key Usage
, allora deve contenere il id-kp-emailProtection
OID (1.3.6.1.5.5.7.3.4) o lo speciale% COID di tutti gli scopi OID (2.5. 29.37.0).
-
Se il certificato è un certificato di sola firma (contiene una chiave DSA o (EC) DSA o è limitato tramite anyExtendedKeyUsage
), allora l'e-mail crittografia sarà difficile. Esiste (era?) Un meccanismo in cui il tuo software genera una coppia di chiavi Diffie-Hellman e allega la chiave pubblica alle e-mail firmate che invii, consentendo ai destinatari di crittografare le loro risposte. Questo è, nel migliore dei casi, mal supportato in natura, e aggiunge alcuni problemi extra (come la memorizzazione della chiave privata DH extra). Pertanto è consigliabile utilizzare un certificato che sia in grado di crittografare (chiave RSA e non limitato da un'estensione Key Usage
).
-
In teoria potresti avere due certificati, uno per la crittografia e-mail e uno per le firme e-mail; questo sarebbe una buona idea . Ma il supporto potrebbe essere trovato un po 'carente in quella zona. Alcuni test sono richiesti.
C'erano alcune estensioni specifiche di Netscape nei vecchi tempi, che erano necessarie per un uso corretto da parte di Netscape Communicator, ma chi lo esegue al giorno d'oggi?