Bootstrapping di certificati SMIME doppi per la firma e la crittografia?

Question

Bootstrapping di certificati SMIME doppi per la firma e la crittografia?

#1 da (1 voti)

1

Per mantenere la proprietà di non disconoscimento della firma pur avendo ancora escrow per la chiave di crittografia, si consiglia di avere certificati separati (e chiavi pub-priv) per la firma (ad esempio CertSign ) e crittografia (ad esempio CertEnc ).

Supponendo una certa Alice con Alice-CertSign e Alice-CertEnc , da un punto di vista pratico (client di posta moderni), come vengono distribuiti questi due certificati a Bob, Charlie, David ecc in modo che possano verificare i messaggi da Alice e inviarli crittografati messaggi?

Se Alice invia un messaggio vuoto alla gente, il suo client di posta elettronica invierà un concat di Alice-CertSign e Alice-CertEnc come allegato? Qualunque standard de-facto o de-jure su questo problema di bootstrap?

Guidare questa curiosità è un esperimento con un solo certificato che ho appena fatto tramite Comodo's certificati SMIME gratuiti. Firma e crittografia in un singolo certificato con il bit di non ripudio NON impostato (incerto se mantengono una copia ... "dietro"). Su iOS6 che invia quel singolo certificato e una firma interna come allegato smime.p7s (che non potevo eseguire attraverso openssl cms... - openssl pkcs7 ... solo dumps certs).

email smime public-key-infrastructure

posta DeepSpace101 21.08.2013 - 21:16

fonte

1 risposta

Leggi altre domande sui tag email smime public-key-infrastructure

Bancomat / Carta di debito Sicurezza [chiuso] Fuzzing API Android

score 1 · Answer 1

Lo standard de jure è RFC 5751 . In particolare, vedi sezione 2.5.3 : tra gli attributi che possono essere allegati a una firma ( a SignerInfo ) è uno chiamato "SMIMEEncryptionKeyPreference" che identifica il certificato che il mittente vorrebbe che le persone usassero quando gli inviano risposte crittografate. Il certificato stesso dovrebbe essere incluso nella CertificateSet associata all'oggetto SignedData .

Al di là del gergo ASN.1, ciò significa che il bootstrap funziona così: l'utente A invia all'utente B una email firmata ; la firma non solo autentica l'email stessa, ma include un set di attributi che forniscono a B informazioni sufficienti per inviare una risposta crittografata ad A, in particolare il certificato di crittografia di A e una designazione univoca del certificato specifico da utilizzare per la crittografia, nel caso in cui i contenuti del certificato non siano sufficienti (ad esempio, se l'utente A ha un certificato con un'estensione Key Usage che lo contrassegna come "solo firma" e un altro certificato contrassegnato come "solo crittografia", quindi non c'è quasi nessuna ambiguità).

Se questo funzionerà bene con il software MUA esistente è un'altra domanda, alla quale è possibile rispondere solo tramite test.