559243 - I can't decrypt a mail which is sent by Outlook 2010

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[yindj]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; CIBA; TheWorld)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

my friend is using office 2010,hi sent me a mail with encryption (RSA with SHA1)and signature,and this mail cann,t be decrypted by Thunderbird 3.0.3-3.0.4.
This mail is working fine when i use office 2003,foxmail.
plus, the certificates are also working fine when he use office 2003 and i use thunderbird 3.

Reproducible: Always

Steps to Reproduce:
1.use office 2010 sent a mail with signature and encryption.
2.
3.
Actual Results:  


Thunderbird 无法对此消息解密

发件人对此消息使用了您的某个数字证书进行了加密。但是 Thunderbird 无法找到该证书以及对应的私钥。
可能的解决方法：

    * 如果您有智能卡，请现在插入。
    * 如果您使用的是新计算机，或者您使用的是新的 Thunderbird 配置文件，您需要从您的备份数据恢复您的证书以及私钥。证书备份文件的后缀名一般为 ".p12"。

Comment 1

[Ludovic Hirlimann [:Usul]]

Gary can you translate the chinese error message ?

Comment 2

[Kaspar]

Attachment: Sample message generated by Outlook 2010 Beta (with broken RecipientIdentifier)

(In reply to comment #1)
> Gary can you translate the chinese error message ?

Ludovic: it's the standard error message when Thunderbird fails to find the private key:

> Thunderbird cannot decrypt this message
>
> The sender encrypted this message to you using one of your digital
> certificates, however Thunderbird was not able to find this certificate and
> corresponding private key.
> Possible solutions:
>
>    * If you have a smartcard, please insert it now.
>    * If you are using a new machine, or if you are using a new Thunderbird
>      profile, you will need to restore your certificate and private key from
>      a backup. Certificate backups usually end in ".p12".

The problem, however, in this case is definitely with Outlook 2010 (it should be noted that what is currently available is only a beta version, released in November last year):

First, as has recently been noted in a thread in mozilla.dev.tech.crypto (http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/c764ad2ce55a1ded), Outlook 2010 Beta will incorrectly reference a certificate by its key id even if that certificate does *not* have a SubjectKeyIdentifier extension (bug 1, this clearly goes against RFC 5652, section 6.2.1).

Second, as I found out in the meantime by playing with the beta version myself, Outlook 2010 Beta (v14.0.4536.1000) even fails to correctly encode the RecipientIdentifier, which is defined by the following ASN.1 syntax (from RFC 5652):

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

Looking at a message encrypted with Outlook 2010 Beta (see attachment), we find that it only implicitly encodes the subjectKeyIdentifier [0], instead of using an explicit encoding (bug 2 - explicit is mandatory since it's defined as an ASN.1 CHOICE):

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
    (PKCS #7)
  [0] {
    SEQUENCE {
      INTEGER 2
      SET {
        SEQUENCE {
          INTEGER 2
          [0]
            22 19 E5 04 D5 75 0B 37 D2 0C C9 30 B1 41 29 E1
            A2 E5 83 B1
          SEQUENCE {
            OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
              (PKCS #1)
            NULL
            }
[...]

It should look like this, however:

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
    (PKCS #7)
  [0] {
    SEQUENCE {
      INTEGER 2
      SET {
        SEQUENCE {
          INTEGER 2
          [0] {
            OCTET STRING
              22 19 E5 04 D5 75 0B 37 D2 0C C9 30 B1 41 29 E1
              A2 E5 83 B1
            }
          SEQUENCE {
            OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
              (PKCS #1)
            NULL
            }
[...]

Comment 3

[Ludovic Hirlimann [:Usul]]

Kaspar thanks a lot for the testcase and analysis. So based on your analysis this is invalid ?

Comment 4

[Ludovic Hirlimann [:Usul]]

kaspar ^^^ ?

Comment 5

[Kaspar]

Attachment: Certificate and private key for decrypting attachment 439548 (passphrase: empty)

This PKCS#12 file includes both the private key and the certificate which was used as the recipient when creating the message in attachment 439548 [details] with Outlook Beta 2010 (v14.0.4536.1000). An empty passphrase was used.

Comment 6

[Kaspar]

(In reply to comment #3)
> Kaspar thanks a lot for the testcase and analysis. So based on your analysis
> this is invalid ?

Yes, I was just about to do that...

Comment 7

[Duncan H]

I have confirmed that this issue persists in the RTM version of Outlook 2010 (14.0.4760.1000). Could we reopen this bug and consider whether there are any potential workarounds?

While I appreciate this is a flaw in Outlook, from the user's perspective the problem appears to be in Thunderbird since Outlook 2010 S/MIME messages open correctly in other clients. It wouldn't be the first time that a Mozilla product has worked around a non-standard Microsoft implementation.

Comment 8

[Kaspar]

(In reply to comment #7)
> I have confirmed that this issue persists in the RTM version of Outlook 2010
> (14.0.4760.1000).

Sigh. If 4760 is really the build number of the final release (I also saw references mentioning 14.0.4763.1000), can you use the certificate attached in comment 5 to create another sample message?

> Could we reopen this bug and consider whether there are any potential
> workarounds?

If the final release also has the two issues described in comment 2, then no: I would clearly refrain from trying to fix this at Mozilla's end (NSS), as Microsoft really screwed up in this case. They definitely fail to comply with the S/MIME specs in two specific aspects, and it would certainly hurt S/MIME interoperability in the long run if we tried to work around these implementation errors.

> While I appreciate this is a flaw in Outlook, from the user's perspective the
> problem appears to be in Thunderbird since Outlook 2010 S/MIME messages open
> correctly in other clients.

Those "other clients" are probably just the ones from Microsoft, right? I doubt that S/MIME implementations other than those from MS will handle this kind of broken messages.

Comment 9

[Duncan H]

I'm not sure how to create another sample encrypted message in .eml format.

I have a support contract with Microsoft and have opened a case for this issue. In the meantime, I have reverted to Outlook 2007. Kaspar, thanks for your thorough investigation; I will direct the Microsoft support engineer to this page.

I confirmed that S/MIME messages encrypted in Outlook 2010 open correctly in Outlook 2007 but not in Thunderbird. The original bug report said that they also worked in Outlook 2003 and Foxmail.

Comment 10

[Kaspar]

(In reply to comment #2)
> Second, as I found out in the meantime by playing with the beta version myself,
> Outlook 2010 Beta (v14.0.4536.1000) even fails to correctly encode the
> RecipientIdentifier

I was wrong here, sorry - that claim is not true. Quoting again from RFC 5652:

   CryptographicMessageSyntax2004
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

   DEFINITIONS IMPLICIT TAGS ::=

   [...]

   KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

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


Looking at these definitions, it's clear that an implicit tagging for the subjectKeyIdentifier is indeed correct (note to myself and others looking for the exact rules: see clause 31.2.7 in the 2008 edition of X.680 - the "SubjectKeyIdentifier" type itself is an OCTET STRING, and does not fall under case c, therefore).

Note that the second dump shown in comment 2, however, is actually what NSS does when it's told to reference a recipient cert by subject key ID (when encoding)... so it turns out that there's a bug in a template in libsmime, really. I'm will attach a patch next.

Comment 11

[Kaspar]

Attachment: Fix RecipientIdentifier template

As explained in the previous comment, the subject key ID must not be tagged explicitly (nor is it a constructed type). Bob, would you be willing to review?

Comment 12

[Kaspar]

Additional note: even if the encoding issue is fixed (by applying attachment 445586 [details] [diff] [review]), we're still left with the first bug mentioned in comment 2:

> Outlook 2010 Beta will incorrectly reference a certificate by its key id
> even if that certificate does *not* have a SubjectKeyIdentifier extension

I can confirm that this behavior is also present in the final release (14.0.4760.1000, in the meantime a trial version of that build is publicly available).

For this problem, I definitely think a fix on the Outlook side is needed (see also the conclusion of Blake Ramsdell, main author of the S/MIME v3 RFCs, in his message which is available at http://www.ietf.org/mail-archive/web/smime/current/msg18730.html).

Duncan, perhaps you could provide an update on the case you opened with Microsoft?

Comment 13

[Duncan H]

The Microsoft support engineer is still working to reproduce the issue. I will
update this bug once I hear back from him.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 445586 [details] [diff] [review]
Fix RecipientIdentifier template

I'm not yet convinced that NSS is wrong here.  I agree that it all comes down 
to the interpretation of X.680/2008 clause 31.2.7 (or equivalently, 
X.680/2002 clause 30.6).  We've had a lot of experience with that before.  
See bug 232693, bug 350200 and bug 436957.

So, I'm going to study this case a little more.
If I concur that it's a bug, I'll review this patch.

Comment 15

[Kaspar]

Attachment: Alternative version of certificate (+ private key) for decrypting attachment 439548

For the sake of completeness: here is an alternative version of the certificate provided in attachment 439549 [details]. It uses the same key, but differs from the first one in two aspects: it does have a subjectKeyIdentifier extension, and it has another serial number.

When this version is imported and the proposed fix for the RecipientIdentifier template is applied, then the message in attachment 439548 [details] can be successfully decrypted with NSS.

Comment 17

[jobr]

I found one more client which cannot decrypt this kind of e-mail - it's Entourage 2008 (Microsoft Office 2008).
On the contrary, MS Outlook 2007/2008 or Outlook Express have no problem with this.

Comment 18

[jobr]

(In reply to comment #17)
> I found one more client which cannot decrypt this kind of e-mail - it's
> Entourage 2008 (Microsoft Office 2008).
> On the contrary, MS Outlook 2007/2008 or Outlook Express have no problem with
> this.
Sorry, I meant MS Outlook 2007/2010

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

OK, I'm convinced that Kaspar's analysis in comment 10 is correct.
Now, the next questions in my mind are: 

- if we correct this template, will we make TB suddenly unable to decode 
emails that it has correctly decoded in the past?

- if we correct this template, will TB begin to encode new emails that 
cannot be decoded by older versions of TB?

IF the answers are: No and No, because TB never generates messages with that
form, and won't begin to do so, and prior to the advent of MS OL2010, neither
did anyone else, then the solution appears to be simple.  Otherwise ...

Comment 20

[Kaspar]

(In reply to comment #19)
> - if we correct this template, will we make TB suddenly unable to decode 
> emails that it has correctly decoded in the past?

Well, yes, because we're changing the template, and the template can only handle one form of the encoding, not both. But this "yes" isn't that relevant, actually:

> - if we correct this template, will TB begin to encode new emails that 
> cannot be decoded by older versions of TB?

No. PSM never used NSS_CMSRecipientInfo_CreateWithSubjKeyID for referencing keys, it only uses NSS_CMSRecipientInfo_Create:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsCMS.cpp&rev=1.27&mark=593#589

(neither does cmsutil, btw)

And NSS_CMSRecipientInfo_Create selects NSSCMSRecipientID_IssuerSN for referencing the key:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/smime/cmsrecinfo.c&rev=1.20&mark=307#304

> IF the answers are: No and No, because TB never generates messages with that
> form, and won't begin to do so, and prior to the advent of MS OL2010, neither
> did anyone else, then the solution appears to be simple.  Otherwise ...

I believe that the solution is simple, yes. I can't rule out the theoretical existence of other broken S/MIME implementations which incorrectly encoded the RecipientIdentifier in the past (in exactly the same way as NSS did), but I consider this quite unlikely. And note that for those users, there still remains the option of using an old version of Thunderbird for decrypting, if they should really have such messages...

Comment 21

[Duncan H]

I received the following response from Microsoft Support:

You are correct that Thunderbird and other email clients cannot open some encrypted emails sent from Outlook 2010. However, the issue lies with the receiving software and not the sending software. Microsoft received numerous requests for our client to be compliant with RFC3852. In a nutshell in order to be compliant with RFC3852, the client must support subjectKeyIdentifier or they cannot decrypt our message.

We have a work around for this issue but it requires setting a registry key:
HKCU\Software\microsoft\Office\14.0\outlook\security
DWORD: UseIssuerSerialNumber
Value: 1

This registry key allows Outlook 2010 to use the issuer and serial number so that other clients are able to decrypt email using the old, non-compliant method.

Comment 22

[Duncan H]

See also http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

That response completely side-steps the issue that they send messages 
identifying the recipient by subject key id, even when the recipient's cert 
has NO subject key ID.

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 12, 
Kaspar, 
Can you attach to this bug report:
- a message produced by the final release of Outlook 2010 that does 
"reference a certificate by its key id even if that certificate does 
*not* have a SubjectKeyIdentifier extension" and 
- the certificate thereby referenced?

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Pem file with email cert for nelson at bolyard dot me

Would someone with outlook 2010 final send me an encrypted email using 
this cert?  (This is a Verisign class 1 cert.)

Comment 26

[Kaspar]

Attachment: Another sample message, generated by Outlook 2010, final release

(In reply to comment #24)
> Can you attach to this bug report:
> - a message produced by the final release of Outlook 2010 that does 
> "reference a certificate by its key id even if that certificate does 
> *not* have a SubjectKeyIdentifier extension" and 

Here it is. This time it's not a draft message, but a complete one instead - i.e., it has two KeyTransRecipientInfo types, one for the cert in attachment 439549 [details] (which was configured as the sender's cert) and one for the cert in attachment 448229 [details]. Both certs do *not* have a SKID extension, but Outlook nevertheless references them by their (synthesized) subject key identifier.

> - the certificate thereby referenced?

See attachment 448229 [details] (as mentioned above). As you can see when looking at the envelopedData, the fe:f3:2e:b9:37:1f:07:0b:e7:15:6c:10:29:0d:fb:c4:46:9b:4d:c2 octet string is used to reference the cert with your public key (whose modulus starts with be:19:6d).

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

In http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38

Abdias Ruiz writes:

> As a workaround, you can use the following registry value to make Outlook 
> 2010 revert to the behavior found in earlier Outlook versions.
>
>    HKEY_CURRENT_USER\Software\microsoft\office\14.0\outlook\security
>    DWORD:  UseIssuerSerialNumber
>    Value:  1 

He asks that someone verify that this workaround solves both the problems of 
identifying the recipient's cert and the signer's cert by non-existent subject Key IDs, resulting in an email that can be successfully decrypted and shown to 
be signed by non-Outlook software.  

So, I ask that you try that, and attach the result here (as you did with 
attachment 448269 [details]) so we can see if that works.  (No, this is NOT in lieu 
of fixing the NSS bug!)

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 445586 [details] [diff] [review]
Fix RecipientIdentifier template

I tested out this patch three ways:

- once with the certificate from attachment 446200 [details] and 
the sample message given above in attachment 439548 [details].  
The message was satisfactorily deciphered with that cert.

- once with the certificate from attachment 439549 [details] and
the sample message given above in attachment 439548 [details].  
As expected, the patch did NOT make the message decipherable with that cert.
The patch did change the error code seen in that test from 
"security library: improperly formatted DER-encoded message." to
"Cannot decrypt: you are not a recipient, or matching certificate and private 
 key not found."

- a third time, with my own certificate (as in attachment 448229 [details])
and the sample message from attachment 448269 [details]. The result was similar to the
second test above.  Decoding was not successful, but the error code changed
from "invalid DER" to "you are not a recipient".

So, at best, I can say that this patch fixes *A* bug in NSS's libSMIME, 
but I cannot say that it fixes the complaint given in this bug, which is 
"I can't decrypt a mail which is sent by Outlook 2010" for the general case
where the recipient's cert has no subject key ID (SKID) extension.

We can either
a) mark this bug fixed when this patch is committed, and tell people that 
the test is Microsoft's bug, for which a workaround exists that requires
registry changes to the systems running OL2010, or 

b) we can try to implement a scheme wherein we attempt to enumerate the user's
local "user" certs, and compute a fictitious SKID for each one, as OL2010 does
(assuming we can divine how that is done), and then try to find the matching cert based on that fictitious SKID.  

Doing this would forever codify and bless MS's error, and remove any motivation for them to fix their bug.  So I'm inclined to wait and see if they fix the 
problem, now that it's been brought to their attention.  But if they do not,
or if they suggest that their users rely on the workaround in lieu of a real 
fix for the indefinite future, then we may need to reconsider. 

Thoughts?

Comment 29

[Kaspar]

Attachment: A third sample message, generated by Outlook 2010, final release, with UseIssuerSerialNumber=1

(In reply to comment #27)
> So, I ask that you try that, and attach the result here

As requested (I already tried that before submitting attachment 448269 [details]). Note for the interested reader: RecipientIdentifier and SignerIdentifier are *not* the same thing (although they have exactly the same ASN.1 syntax).

What you see in attachment 448269 [details] are two instances of *Recipient*Identifier; it's an unsigned message and doesn't therefore have any SignerIdentifier (that's why I was referring to "sender's cert", not "signer's cert"). But for bonus points, the attachment here is actually signed and encrypted - so once you decrypt it, you'll see signedData and the SignerIdentifier for the cert in attachment 439549 [details]. And just in case someone is wondering: Outlook 2010 (14.0.4760.1000, final release) unconditionally uses IssuerAndSerialNumber for the *Signer*Identifier, irrespective of the UseIssuerSerialNumber registry setting (what Abdias Ruiz writes in his message on 26 May is wrong).

Comment 30

[Nelson Bolyard (seldom reads bugmail)]

I should add that, unless MS releases a patched/fixed version of their product, or officially publishes and blesses the workaround as being a real solution 
(a "hot fix") for their bug, most corporate and governmental shops will never 
deploy it, and TB users will be excluded from those environments.

Comment 31

[Nelson Bolyard (seldom reads bugmail)]

Thanks Kaspar.  

> Outlook 2010 (14.0.4760.1000, final release) unconditionally uses 
> IssuerAndSerialNumber for the *Signer*Identifier, irrespective of the 
> UseIssuerSerialNumber registry setting (what Abdias Ruiz writes in his 
> message on 26 May is wrong).

Do you want to tell Abdias?  Or shall I?  I encourage you to join the fray.

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

Checking in nss/lib/smime/cmsasn1.c; new revision: 1.7; previous revision: 1.6

Comment 33

[Nelson Bolyard (seldom reads bugmail)]

Kaspar, 
Do you agree that, for those Outlook 2010 users who can and do utilize 
the registry entry shown in comment 27 above, that is 
a sufficient solution to this problem for them and their correspondents?

Comment 34

[Kaspar]

(In reply to comment #33)
> Do you agree that, for those Outlook 2010 users who can and do utilize 
> the registry entry shown in comment 27 above, that is 
> a sufficient solution to this problem for them and their correspondents?

Yes, I agree.

Comment 35

[yindj]

thanks a lot. The registry works great! It accelerate outlook 2010 startup and certificate find.


(In reply to comment #21)
> I received the following response from Microsoft Support:
> You are correct that Thunderbird and other email clients cannot open some
> encrypted emails sent from Outlook 2010. However, the issue lies with the
> receiving software and not the sending software. Microsoft received numerous
> requests for our client to be compliant with RFC3852. In a nutshell in order to
> be compliant with RFC3852, the client must support subjectKeyIdentifier or they
> cannot decrypt our message.
> We have a work around for this issue but it requires setting a registry key:
> HKCU\Software\microsoft\Office\14.0\outlook\security
> DWORD: UseIssuerSerialNumber
> Value: 1
> This registry key allows Outlook 2010 to use the issuer and serial number so
> that other clients are able to decrypt email using the old, non-compliant
> method.

Comment 37

[Steve]

this "bug" has been fixed/closed without a final explanation for the issue, that microsoft generates a synthetic subjectkeyidentifier.

See comment proposal by Nelson Bolyard

"b) we can try to implement a scheme wherein we attempt to enumerate the user's
local "user" certs, and compute a fictitious SKID for each one, as OL2010 does
(assuming we can divine how that is done), and then try to find the matching
cert based on that fictitious SKID."


As far as i now understand, you did not implement this - without applying the registry hack from Microsoft, Thunderbird will still be unable to decrypt messages encrypted to x509 certificates, which do not have a SKID - because nobody knows how to generate this SKID... Is this true?

Or do you actually try to decrypt a message with all available keys now?

Please add a final conclusion to this bug.

Comment 38

[Nelson Bolyard (seldom reads bugmail)]

The originally problem reported is the result of two bugs, one on which was 
in NSS, the other is in Outlook.  The NSS bug is fixed.  There is a 
workaround available from Microsoft for the Outlook bug.  We will not be 
introducing absurdly slow behavior into NSS to compensate for that bug.

Comment 39

[Steve]

>>We will not be introducing absurdly slow behavior into NSS to compensate for that bug.

I do support that decision, although i must say the reasoning is not really convincing when you know that most users have 1 x509 private key, there would be no "slow" behavior at all - even with 2 or 3 - its a mail client...not a server.

The reasoning should have been, "this time we will not do workarounds for an absurd rfc violation by microsoft"

Comment 40

[Bill Osler]

I cannot comment on this topic with any authority as either a developer or as somebody knowledgeable about cryptography or the relevant standards.  However, speaking as a user, I have grave concerns about the decision to wait on MS to fix their apparent non-compliance.  It's not like they have a great track record at that sort of thing.

I cannot control the email client(s) used by my correspondents, and so far as I know I do not exchange secure messages with ANY other Thunderbird users.  Virtually everybody I correspond with uses Outlook.  There are many users, including some of my correspondents, who have no business firing up Regedit for ANY reason, so I can't count on them to apply a registry edit to make their email client compatible with mine.  Furthermore, given Microsoft's past performance re:standards compliance I can't say I am confident that there will be a solution coming from that direction any time soon.

That leaves users like me in an awkward position.  However much I like Thunderbird I do not like switching back and forth between email clients based on whom I am messaging.  It is not a viable solution for me, and I suspect that there are other users in the same position.

What about an optional solution that allows users to choose to configure Thunderbird to accept messages encrypted using Microsoft's implementation of the RecipientIdentifier?

For my part, the number of email certificates is small, and many of my messages arrive without encryption.  I would not be bothered a bit by 'absurdly slow behavior' in NSS if that is what is required to make the email client work.

Comment 41

[Kaspar]

(In reply to comment #40)
> For my part, the number of email certificates is small, and many of my messages
> arrive without encryption.  I would not be bothered a bit by 'absurdly slow
> behavior' in NSS if that is what is required to make the email client work.

Bill: does your own certificate have a subjectKeyIdentifier extension? If so, it would just be a question of having the next Thunderbird 3.1.x release pick up the latest changes from http://hg.mozilla.org/releases/mozilla-1.9.2/... that branch was updated to NSS 3.12.7 a few days ago (bug 575620).

Comment 42

[Bill Osler]

Kaspar:
When I view my certificate in Thunderbird there is an entry labeled Certificate Subject Key ID with 20 bytes of binary data.  Outlook has an entry labeled Subject Key Identifier that contains the same 20 bytes.  I GUESS that this entry is the subjectKeyIdentifier extension that has been referenced in this thread.
I have not yet downloaded the latest build to test whether the fix applies.
Thanks,
Bill Osler

Comment 43

[Kaspar]

(In reply to comment #42)
> When I view my certificate in Thunderbird there is an entry labeled
> Certificate Subject Key ID with 20 bytes of binary data.

Yes, this sounds good ("Subject Key ID" is the term used by PSM, the GUI part of the crypto stuff in Mozilla).

> I have not yet downloaded the latest build to test whether the fix applies.

I suggest you try a recent "nightly" version from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/. You'll be pleased when looking at the messages encrypted by Outlook 2010, most likely :-)

Comment 44

[Simon Woods]

Not quite :-(

Just downloaded the version from the 16th Aug (zip) and have the same problem as before. My certificate contains a 20 byte "Certificate Subject Key ID" (smart card based).

Mail was sent encrypted by one of my Colleagues in Outlook 2010.

Am I doing something wrong or do you need additional information?

Comment 45

[Bill Osler]

The current build does seem to have fixed the problem I had with reading encrypted email from Outlook 2010.  I am not using a 'smart card' system.  I wonder if that makes a difference?
Also, if there is some ambiguity about whether the fix is working well, should the status still be listed as RESOLVED  FIXED?

Comment 46

[Ludovic Hirlimann [:Usul]]

(In reply to comment #44)
 
> Am I doing something wrong or do you need additional information?

File a new bug please.

Comment 47

[Nelson Bolyard (seldom reads bugmail)]

This bug is marked fixed because it is an NSS bug and the problem has been 
fixed in NSS.  Whether any particular version of Firefox or Thunderbird has
taken the new version of NSS is anybody's guess. 

What version do you see for the file smime3.dll in your firefox directory?
Check file properties, version tab, file version attribute.

Comment 48

[Simon Woods]

smime3.dll: 3.12.7.0 Basic ECC

Comment 49

[Kaspar]

(In reply to comment #44)
> My certificate contains a 20 byte "Certificate Subject Key ID"
> (smart card based).
> 
> Mail was sent encrypted by one of my Colleagues in Outlook 2010.
> 
> Am I doing something wrong or do you need additional information?

Could you add that message as an attachment (or send it to me via mail) and provide the value of the "Certificate Subject Key ID" field of your own certificate?

(I assume that your smartcard-based certificate is appearing in the "Your Certificates" tab in the Cert Manager window, is that correct? If not, then it's an issue of properly configuring Thunderbird to support your smartcard device and should be dealt with in a separate bug, as mentioned in comment 46.)

Comment 50

[Simon Woods]

Attachment: Another example of an encrypted mail from Outlook 2010 (using subjectKeyIdentifier format for the RecipientIdentifier)

The attachment is a test mail sent from Outlook 2010 using a chip card based encryption. I have setup a thunderbird Security Device to use the PKCS interface of the card software and can read and write encrypt mails using the smartcard (for the last 8 years :-))

My card appears in "Your Certificates" with Certificate Subject Key ID:
01 b2 fc 39 23 38 53 70 b5 1c 79 aa 79 f8 13 23 e9 e7 b1 58

Comment 51

[Kaspar]

Comment on attachment 467057 [details]
Another example of an encrypted mail from Outlook 2010 (using subjectKeyIdentifier format for the RecipientIdentifier)

(In reply to comment #50)
> The attachment is a test mail sent from Outlook 2010 using a chip card based
> encryption. I have setup a thunderbird Security Device to use the PKCS
> interface of the card software and can read and write encrypt mails using the
> smartcard (for the last 8 years :-))
> 
> My card appears in "Your Certificates" with Certificate Subject Key ID:
> 01 b2 fc 39 23 38 53 70 b5 1c 79 aa 79 f8 13 23 e9 e7 b1 58

Thanks. This message is encoded as expected, it includes a KeyTransRecipientInfo which references your cert by its subject key identifier:

    SEQUENCE {
      INTEGER 2
      SET {
        SEQUENCE {
          INTEGER 2
          [0]
            01 B2 FC 39 23 38 53 70 B5 1C 79 AA 79 F8 13 23
            E9 E7 B1 58
          SEQUENCE {
            OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
              (PKCS #1)
            NULL
            }
          OCTET STRING
            0D FC D4 A7 3E 0E 7E 72 62 EF D8 4A E6 5E C4 D1
            44 24 0C D7 F2 5D D5 2E E9 25 A7 ED 38 7D 07 D5
            39 AB E6 0F 7E 69 29 83 D9 E3 8B E8 04 B5 1C 45
            ...

I can't see any reason why libsmime in NSS 3.12.7 would fail to correctly parse this, and in fact, I have just successfully tested a nightly build of Thunderbird 3.1.3pre ("Lanikai") with a smartcard-based certificate I own myself, with a similarly encoded message. It works as expected, Lanikai prompted me for the smartcard PIN when I opened the encrypted message.

For your specific situation, I can think of the following possible reasons for a failure:

a) for some reason, when you were testing the version of Lanikai you mention in comment 44, it did not use the version of smime3.dll you identified in comment 47

b) it's a peculiarity of the PKCS#11 module for your smartcard (maybe its so-called "friendlyness", see "PublicCerts" at https://developer.mozilla.org/en/PKCS11_Module_Specs, or http://www.mail-archive.com/[e-mail]/msg08548.html)

c) it has to do with the way your certificate, public and/or private keys are stored on your smartcard (in particular, their CKA_ID attributes)

If you're willing to provide more information about your specific setup (smartcard and PKCS#11 module you're using, and possibly some debug logs), then please file a *separate* bug and Cc me.

Comment 52

[Simon Woods]

Thanks - will do by the end of next week after my vacation.

If you send me the necessary "debug" settings etc to produce the logs you need I can provide this in the new bug up front. I have a fairly major interest that this works for me also :-).

Comment 53

[Kaspar]

(In reply to comment #52)
> If you send me the necessary "debug" settings etc to produce the logs you need
> I can provide this in the new bug up front.

Collect a debug log of your PKCS#11 module when Thunderbird 3.1.3pre (Lanikai) tries to decrypt that message. See http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html for how to get such a log, and set NSPR_LOG_MODULES to nss_mod_log:4. (This might reveal information you consider sensitive, so be sure to check the contents of that log before uploading. If you sanitize [parts of] the log, then please clearly indicate where you did.)

Comment 54

[Kaspar]

Comment on attachment 467057 [details]
Another example of an encrypted mail from Outlook 2010 (using subjectKeyIdentifier format for the RecipientIdentifier)

The alleged failure with decrypting the message when using a smartcard-based certificate is now being tracked in bug 592489 (where this message is also attached), so I'm obsoleting the file in this bug.

Comment 55

[Kaspar]

This fix has now made its way into Thunderbird 3.1.3. For smartcard-based certificates, an additional issue has shown up, which is being addressed in bug 592489.

Finally, for certificates without a subjectKeyIdentifier extension, note that it's actually still Microsoft's job to fix the RecipientIdentifier encoder in their Outlook 2010 code (see also comment 12).