S/MIME в Microsoft

Продолжая криптографическую тему хочется отметить некорректности вот этой статьи (Outlook S/MIME certificate selection):
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx

Достаточно много народа на нее ссылались, поэтому тема ее неточностей - актуальна.

"When sending an encrypted eMail, Outlook actually requires two certificates. One certificate is owned by the recipient and one is owned by the sender. The recipient’s certificate is used by the sender for encrypting the eMail which is sent out. The sender’s certificate is used by the sender to encrypt the eMail that is stored in the Sent Items folder in Outlook"

Из абзаца может показаться, то письмо шифруется дважды: на ключе отправителя и кладется в Отправленные, и на ключе получателя - и отправляется.

На самом деле это не так: письмо шифруется один раз на ключах всех получателей и на ключе отправителя. Цитата из RFC3851, раздел 3.3:

"Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6)."

Из сего факта есть интересно следствие, что, будучи получателем письма, я могу залезть в ящик к отправителю и прочитать отправленное мне письмо своим ключом. Это может повторить любой из получателей, причем, применительно и к отправителю и к любому из получателей.

Далее,
"To find a valid certificate owned by the recipient, Outlook verifies if any certificates are stored in the userSMimeCertificate attribute in Active Directory. If so, Outlook examines the PKCS#7 blobs to find out if Outlook is the one that published them. In that case, there is an extra signed attribute that indicates which is the default certificate. If the certificate marked as default is found in the userSMimeCertificate attribute, it is chosen. If the default certificate is not found, the first valid certificate in the store is selected. In case the userSMimeCertificate attribute stores no certificates, Outlook queries the userCertificate attribute in Active Directory"

Может сложиться впечатление, то Outlook берет сертификат непосредственно из AD, и, увидев сертификат в AD, можно долго удивляться почему же Outlook его никак не находит при попытке написать письмо.

На самом деле все не так. Может пройти аж до 48 часов с момента выпуска пользователю сертификата до момента появления возможности отправки ему шифрованного письма.

Очень понятно и подробно об этом написано в KB#841273 - Administering the offline address book in Outlook. Очень рекомендую это внимательно почитать. В двух словах - сертификат берется не из АД, а из локальной копии автономной адресной книги, которая на сервере Exchange генерится не часто (по умолчанию - раз в день), и также нечасто забирается Outlook-ом для автономной работы (если включено кеширование, которое включено по умолчанию).

Еще важно отметить, что по умолчанию Outlook всегда хочет проверять CRL как для сертификатов получателей, так и для сертификата отправителя. Тут может быть масса проблем, начиная с недоступности указанных в сертификате CDP, заканчивая банальными настройками прокси, когда локальный CRL не скачивается по HTTP через настроенный прокси. Не хочу говорить, что я бы рекомендовал отключение проверки CDP, но думать об этом надо.

Вообще, полезно почитать перечень криптопараметров Outlook и решить что как подкрутить в соответствии с потребностями (Plan for e-mail messaging cryptography in Outlook 2010):
http://technet.microsoft.com/en-us/library/cc179061.aspx