這個(gè)問(wèn)題是2006年2月28日提出來(lái)的:因?yàn)闆](méi)有使用S/MIME建立安全關(guān)聯(lián)，如果收件人不支持發(fā)件人使用的信息文摘算法會(huì)發(fā)生什么事情呢?

答:安全關(guān)聯(lián)式兩個(gè)或者兩個(gè)以上實(shí)體之間的關(guān)系，說(shuō)明他們?nèi)绾问褂冒踩?wù)安全地通信。例如，一個(gè)安全關(guān)聯(lián)是在聯(lián)絡(luò)期間的SSL會(huì)話過(guò)程中建立起來(lái)的。當(dāng)一個(gè)用戶希望建立一個(gè)SSL通信的時(shí)候，用戶要發(fā)送一個(gè)包含他希望使用的或者支持的加密系統(tǒng)的“客戶問(wèn)候”消息。服務(wù)器也將使用“客戶問(wèn)候”回答，并且也包含它支持的加密系統(tǒng)的信息。然后，這個(gè)客戶就負(fù)責(zé)選擇它將與服務(wù)器共享的加密系統(tǒng)以建立安全關(guān)聯(lián)。當(dāng)你對(duì)電子郵件進(jìn)行數(shù)字簽名的時(shí)候，你當(dāng)然不知道收件人使用什么電子郵件客戶端軟件以及這個(gè)軟件支持的加密系統(tǒng)，因此，就不能建立安全關(guān)聯(lián)。正如你的問(wèn)題暗示的那樣，這可能導(dǎo)致收件人的電子郵件客戶端軟件不支持創(chuàng)建這封郵件信息的算法或者散列值。

一般來(lái)說(shuō)，當(dāng)收到一封數(shù)字簽名的信息時(shí)，電子郵件客戶端軟件將計(jì)算自己的這個(gè)信息的散列值并且使用公共密鑰解密包含在郵件信息中的這個(gè)散列值，并且對(duì)比這兩個(gè)值。如果這兩個(gè)值相匹配，簽名信息的收件人就能夠保證這個(gè)信息沒(méi)有被篡改并且是由這個(gè)專用密鑰的擁有者簽署的。如果收件人的電子郵件客戶端軟件由于不支持發(fā)件人的算法而不能計(jì)算出這個(gè)報(bào)文摘要，收件人的電子郵件客戶端軟件就不能驗(yàn)證發(fā)件人的身份或者這封電子郵件的完整性。

S/MIME協(xié)議解決了這個(gè)問(wèn)題。大多數(shù)電子郵件客戶端軟件都支持的第三版S/MIME協(xié)議由幾個(gè)RFC組成。其中RFC 3370可識(shí)別S/MIME第三版軟件必須支持的算法。這些算法包括:安全散列算法-1(SHA-1)和計(jì)算散列值的報(bào)文摘要-5(MD5);數(shù)字簽名算法和用于簽名的RSA加密算法;RC2和用于報(bào)文加密的三次數(shù)據(jù)加密標(biāo)準(zhǔn)(3DES)。這將確保全部采用S/MIME協(xié)議的軟件達(dá)到基本兼容的水平。但是，電子郵件客戶端軟件如果正確識(shí)別出具體電子郵件使用的算法也可以增加額外的算法。實(shí)際上，報(bào)文摘要算法用于簽署一個(gè)報(bào)文，這個(gè)算法存儲(chǔ)在包含“SignerInfo digestAlgorithms”(簽名者報(bào)文摘要算法)字段的“SignedData”(簽名數(shù)據(jù))值中。據(jù)這個(gè)RFC稱，如果一個(gè)電子郵件客戶端軟件不能夠識(shí)別或者支持這個(gè)算法，它必須通知用戶這個(gè)客戶端軟件不能正確地驗(yàn)證這個(gè)郵件報(bào)文。

然而，如果發(fā)件人已經(jīng)從以前的報(bào)文中獲得了收件人的公共密鑰和數(shù)字證書(shū)，X.509數(shù)字證書(shū)可以使用簽名算法識(shí)別器，這樣，發(fā)件人的電子郵件客戶端軟件就可以使用那個(gè)信息選擇一種適當(dāng)?shù)乃惴?。這就意味著安全關(guān)聯(lián)能夠在電子郵件發(fā)送和接收之前就可以建立。***，請(qǐng)記住，在電子郵件交換過(guò)程中使用的加密功能還可以根據(jù)包括隱私協(xié)議、用戶偏愛(ài)和法律限制等外部信息建立。

【編輯推薦】

1. 信息安全防護(hù) 從保證電子郵件安全開(kāi)始
2. 攜手打造安全網(wǎng)絡(luò)和電子郵件解決方案
3. 保證電子郵件安全的五個(gè)小竅門