Quando S / MIME richiede il certificato dell'altra parte e quando è sufficiente la chiave?

1

Cercando di capire l'implementazione S / MIME, vedo che a volte è necessario avere il certificato della controparte e talvolta è sufficiente avere solo la propria chiave pubblica. Sono confuso su quando hai bisogno di un certificato e quando la chiave è sufficiente. Qualcuno può chiarire?

(Sto cercando di capire gli interni qui, quindi la mia domanda è concettuale - so che praticamente, la maggior parte dei client di posta usa il certificato completo).

    
posta Frank 25.04.2014 - 21:53
fonte

1 risposta

1

S / MIME si basa su CMS (il nome standard per ciò che precedentemente era noto come "PKCS # 7"). Un'e-mail crittografata è in realtà un oggetto CMS enveloped-data . La maggior parte dei dati è crittografata simmetricamente, con una chiave derivata / scambiata utilizzando uno dei meccanismi di trasporto dettagliati nella sezione 6.2 :

  • KeyTransRecipientInfo è fondamentalmente una crittografia asimmetrica con la chiave pubblica del destinatario. Questo è ciò che viene utilizzato quando il destinatario ha una chiave RSA adatta per la crittografia (ad esempio, non una chiave RSA contrassegnata nel suo certificato come "solo firma").

  • KeyAgreeRecipientInfo è per algoritmi di scambio di chiavi che non sono crittografia asimmetrica. Lo userai se il destinatario ha una chiave Diffie-Hellman.

  • KEKRecipientInfo viene utilizzato quando è presente una chiave simmetrica condivisa (alta entropia) tra mittente e destinatario.

  • PasswordRecipientInfo viene utilizzato quando c'è una password condivisa tra mittente e destinatario ( che quindi richiede un ampio hashing della password per compensare la debolezza intrinseca della password).

  • OtherRecipientInfo è per tutti gli altri casi, che non rientrano nelle categorie sopra.

Il punto critico è che sia per KeyTransRecipientInfo che per KeyAgreeRecipientInfo, la chiave pubblica del destinatario (che si tratti di RSA, Diffie-Hellman ...) può essere identificata in due modi:

  RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

  KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

  RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

  SubjectKeyIdentifier ::= OCTET STRING

Quando la chiave pubblica proviene da un certificato, la chiave pubblica può essere identificata utilizzando "issuerAndSerialNumber" (una copia dei campi "issuerDN" e "serialNumber" del certificato) o con "identificatore chiave soggetto" . Quest'ultimo è un mucchio di byte che possono facoltativamente essere inclusi in un certificato (come Estensione identificatore chiave soggetto ). Qualsiasi informazione viene prontamente estratta dal certificato. Non hai mai bisogno del certificato completo, ma hai bisogno di parti di esso.

S / MIME supporta anche le chiavi pubbliche che sono non ottenute dai certificati, ma da "Preferenze S / MIME". L'idea è (o forse era? Non l'ho visto da molto tempo) che un utente possa avere solo un certificato di firma (ad esempio con una chiave DSA). In quel caso, quell'utente potrebbe generare la propria coppia di chiavi per la crittografia asimmetrica o lo scambio di chiavi, firmare la parte pubblica e includerla nei messaggi che invia. Le persone che vogliono rispondere possono quindi utilizzare quella chiave pubblica per il trasporto chiave o il contratto chiave. Poiché tale chiave non è contenuta in un certificato, non può essere identificata con i campi del certificato. Invece, verrà identificato con un "identificatore di chiave" simile all'identificatore di chiave soggetto ", cioè un gruppo di byte.

Riepilogo: tutta la crittografia utilizza solo la chiave , ma il formato del messaggio deve includere una designazione per la chiave utilizzata e tale design utilizzerà i campi estratti da il certificato del destinatario (se la chiave pubblica del destinatario proviene effettivamente da un certificato).

    
risposta data 25.04.2014 - 22:20
fonte