S/MIME interop issue with Outlook 2010 beta
Michael Ströder
Someone sent me an encrypted S/MIME message which I could not decrypt in
Mozilla's Seamonkey. It was generated by Outlook 2010 beta.
It seems it's a CMS structure and recipientInfos contains subject key ids
instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
that. Is it supported by the underlying libs?
Ciao, Michael.
Kaspar Brand
> It seems it's a CMS structure and recipientInfos contains subject key ids
> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
> that. Is it supported by the underlying libs?
I believe so, see
That's the code which is used by nsCMSMessage
(http://mxr.mozilla.org/comm-central/ident?i=nsCMSMessage), and
therefore also by Seamonkey.
Did you verify that the key id in the recipientInfo indeed matches the
one from your cert? Otherwise libsmime might simply fail to find the
correct private key.
Another reason for a failure could be the encryption algorithm - which
one did Outlook pick in this case?
Kaspar
Michael Ströder
> On 31.03.2010 07:49, Michael Ströder wrote:
>> It seems it's a CMS structure and recipientInfos contains subject key ids
>> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
>> that. Is it supported by the underlying libs?
>
> I believe so, see
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/smime/cmsreclist.c&mark=89-91#85
>
> That's the code which is used by nsCMSMessage
> (http://mxr.mozilla.org/comm-central/ident?i=nsCMSMessage), and
> therefore also by Seamonkey.
>
> Did you verify that the key id in the recipientInfo indeed matches the
> one from your cert? Otherwise libsmime might simply fail to find the
> correct private key.
Strange because my e-mail cert does not have subjectKeyIdentifier at all.
Hmm, in theory a S/MIME MUA could calculate it on-the-fly even if the cert
does not have one and build a lookup table. Maybe it's worth to look what RFC
5750 says about it...
Ciao, Michael.
--
Michael Ströder
E-Mail: mic...@stroeder.com
http://www.stroeder.com
Kaspar Brand
> Strange because my e-mail cert does not have subjectKeyIdentifier at all.
>
> Hmm, in theory a S/MIME MUA could calculate it on-the-fly even if the cert
> does not have one and build a lookup table. Maybe it's worth to look what RFC
> 5750 says about it...
That aspect is covered by the CMS spec, actually. From RFC 5652, section
6.2.1:
When an X.509
certificate is referenced, the key identifier matches the X.509
subjectKeyIdentifier extension value.
IOW, Outlook shouldn't use this format for referring to this particular
cert. Also, noted that RFC 5280 only mentions "two common methods for
generating key identifiers", there is no single standardized way for
calculating the key id.
Kaspar
Michael Ströder
If you read the whole section you've cited an excerpt from it's getting
blurry. I took this to the ietf-smime mailing list for clarification. Are you
subscribed there too?
Ciao, Michael.
--
Michael Str�der
E-Mail: mic...@stroeder.com
http://www.stroeder.com
Kaspar Brand
>> That aspect is covered by the CMS spec, actually. From RFC 5652, section
>> 6.2.1:
>>
>> When an X.509
>> certificate is referenced, the key identifier matches the X.509
>> subjectKeyIdentifier extension value.
>>
>> IOW, Outlook shouldn't use this format for referring to this particular
>> cert. Also, noted that RFC 5280 only mentions "two common methods for
>> generating key identifiers", there is no single standardized way for
>> calculating the key id.
>
> If you read the whole section you've cited an excerpt from it's getting
> blurry. I took this to the ietf-smime mailing list for clarification. Are you
> subscribed there too?
No, I'm not subscribed to that, but I don't see what you mean by "it's
getting blurry" after the sentence quoted above. If there's no SKID
extension, then there's no extension value, so Outlook's way of
referencing the cert is pretty broken, IMO (see also Blake's conclusion
in http://www.ietf.org/mail-archive/web/smime/current/msg18730.html).
Kaspar
Jean-Marc Desperrier
> On 31.03.2010 07:49, Michael Ströder wrote:
>> It seems it's a CMS structure and recipientInfos contains subject key ids
>> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
>> that. Is it supported by the underlying libs?
>
> I believe so, see
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/smime/cmsreclist.c&mark=89-91#85
>
> That's the code which is used by nsCMSMessage
> (http://mxr.mozilla.org/comm-central/ident?i=nsCMSMessage), and
> therefore also by Seamonkey.
Are you certain ? Previously we found out real ugly SMIME code that
hardcodes the use of SHA-1 :
http://groups.google.fr/group/mozilla.dev.tech.crypto/msg/7a15dafef963fe20
and here directly for the code
https://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp#496
When I checked, I concluded that code reimplements everything on top on
low level pkcs#7 (nss/lib/pkcs7/) and makes no use of nss/lib/smime.
I need to check the code you digg out here. It seems very confusing.
PDF3 SecureEmail
> On 31/03/201017:11, Kaspar Brand wrote:
>
> > On 31.03.201007:49, Michael Ströder wrote:
> >> It seems it's a CMS structure and recipientInfos contains subject key ids
> >> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
> >> that. Is it supported by the underlying libs?
>
> > I believe so, see
>
>
> > That's the code which is used by nsCMSMessage
> > (http://mxr.mozilla.org/comm-central/ident?i=nsCMSMessage), and
> > therefore also by Seamonkey.
>
> Are you certain ? Previously we found out real ugly SMIME code that
> and here directly for the codehttps://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime...
>
> When I checked, I concluded that code reimplements everything on top on
> low level pkcs#7 (nss/lib/pkcs7/) and makes no use of nss/lib/smime.
>
> I need to check the code you digg out here. It seems very confusing.
According to the link at
http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38
Outlook 2010 is OL2010 is using “sender key ID” instead of “issuer
name and serial number” – as per an SMIME standard, but can be
reverted to an older style using a registry key. I suspect that NSS
is not supporting "sender key ID" yet/properly. I think Thunderbird
needs this fixed...
Nelson B Bolyard
> According to the link at
> http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38
> Outlook 2010 is OL2010 is using “sender key ID” instead of “issuer
> name and serial number” – as per an SMIME standard, but can be
> reverted to an older style using a registry key. I suspect that NSS
> is not supporting "sender key ID" yet/properly. I think Thunderbird
> needs this fixed...
I suggest you read the relevant SMIME standards. The current version
allows SMIME clients to use either of the two formats. Older versions
of the standard only allowed the "issuer name and serial number" form.
The newer versions allow either one to be used.
However, the KeyID form identifies a certificate by a KeyID attribute
which is an optional extension in the certificate itself. It is
appropriate to use this form ONLY when the certificate thus identified
actually has that extension present. When that extension is not
present, the proper way to identify it is by its issuer name and serial
number, since all certificates have that, and only some have the
optional keyID.
TB can identify certificates by their keyID *WHEN THEY HAVE A KEYID*.
But when OL2010 says "the desired cert has this KeyID", and in fact the
desired cert has NO KeyID at all, TB is correct to say "no cert with
that KeyID can be identified".
Kaspar Brand
> I suspect that NSS is not supporting "sender key ID" yet/properly.
If you replace "sender key ID" by RecipientIdentifier, then that
statement is true, yes. (Note, however that the MSFT moderator mixes up
SignerIdentifier and RecipientIdentifier in his posts at
social.technet.microsoft.com, and also misrepresents facts about
Outlook's behavior when it comes to encoding the SignerIdentifier - it
always uses the "old" format for the *Signer*Identifier, and the
registry setting will only have an effect for the encoding of the
*Recipient*Identifier.)
> I think Thunderbird needs this fixed...
Yes, this is actually what
https://bugzilla.mozilla.org/show_bug.cgi?id=559243 is about. Once that
patch lands, NSS (and somewhen in the future also Thunderbird) will be
able to successfully decrypt messages which reference the recipient's
cert by their key ID, *as long as* the respective cert really has a
subjectKeyIdentifier extension.
Kaspar
Nelson B Bolyard
> On 03.06.2010 22:57, PDF3 SecureEmail wrote:
>
> statement is true, yes. (Note, however that the MSFT moderator mixes up
> SignerIdentifier and RecipientIdentifier in his posts at
> social.technet.microsoft.com, and also misrepresents facts about
> Outlook's behavior when it comes to encoding the SignerIdentifier - it
> always uses the "old" format for the *Signer*Identifier,
Kaspar, would you care to clarify what you mean by "old" format there?
It appears to me that it always uses the KeyID format for the
SignerIdentifier. I'd call the KeyID format the "new" format.
Maybe you mean "old" as in the Outlook 2010 default format used before a
registry entry has been added in an attempt to change it. yes?
> and the registry setting will only have an effect for the encoding of
> the *Recipient*Identifier.)
>
>> I think Thunderbird needs this fixed...
>
> Yes, this is actually what
> https://bugzilla.mozilla.org/show_bug.cgi?id=559243 is about. Once that
> patch lands, NSS (and somewhen in the future also Thunderbird) will be
> able to successfully decrypt messages which reference the recipient's
> cert by their key ID, *as long as* the respective cert really has a
> subjectKeyIdentifier extension.
To successfully decrypt, yes. And to successfully identify the signer's
cert *as long as* the signer's cert really has a subjectKeyID extension.
Otherwise, it will not be able to find the signer's cert, and hence will
not store it in the cert store. This may make it difficult (or impossible)
to send an encrypted reply to the mail.
>
> Kaspar
Regards,
/Nelson
Kaspar Brand
> Kaspar, would you care to clarify what you mean by "old" format there?
> It appears to me that it always uses the KeyID format for the
> SignerIdentifier. I'd call the KeyID format the "new" format.
>
> Maybe you mean "old" as in the Outlook 2010 default format used before a
> registry entry has been added in an attempt to change it. yes?
No. What I was referring to is:
"old" -> issuerAndSerialNumber
"new" -> subjectKeyIdentifier
(Note that I just used "old" in the previous post because the OP was
stating that the format "can be reverted to an older style using a
registry key". I don't think we should treat this as a question of "new"
vs. "old" - as the issue at hand shows the two forms can't be used
interchangeably in all circumstances.)
>> and the registry setting will only have an effect for the encoding of
>> the *Recipient*Identifier.)
Hopefully the following mini-table will make things clearer. It shows
what format for the RecipientIdentifier and the SignerIdentifier Outlook
2010 uses depending on the registry setting [1]:
UseIssuerSerialNumber set to...
0 [=default] 1
RecipientIdentifier subjectKeyIdentifier issuerAndSerialNumber
SignerIdentifier issuerAndSerialNumber issuerAndSerialNumber
And to reiterate the issue which needs to be fixed in Outlook: when a
recipient certificate does not have a subjectKeyIdentifier extension,
then it must not use the subjectKeyIdentifier format when referring to
this cert (irrespective of the registry setting, of course).
> And to successfully identify the signer's
> cert *as long as* the signer's cert really has a subjectKeyID extension.
> Otherwise, it will not be able to find the signer's cert, and hence will
> not store it in the cert store. This may make it difficult (or impossible)
> to send an encrypted reply to the mail.
As seen from the table above, this is currently a non-issue (Outlook
will always encode SignerIdentifier with issuer name + serial). But I
agree that the Outlook developers should pay attention to this as well
when they are touching the code to fix the RecipientIdentifier stuff.
Kaspar
[1] Complete registry path:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Security\UseIssuerSerialNumber
Kaspar Brand
> will always encode SignerIdentifier with issuer name + serial). But
> I agree that the Outlook developers should pay attention to this as
> well when they are touching the code to fix the RecipientIdentifier
> stuff.
Sigh. I just came across this:
http://support.microsoft.com/kb/2142236
Non-Outlook email clients unable to decrypt email sent from Outlook 2010
which states under "Cause":
> Outlook 2010 now more fully implements the Cryptographic Message
> Syntax (CMS) as documented in RFC3852. Outlook 2010 now uses
> subjectKeyIdentifier as the SignerIdentifier, whereas earlier
> versions used issuerAndSerialNumber. It seems that some clients may
> not yet support using subjectKeyIdentifier as the SignerIdentifier,
> as defined per the RFC. This results in it being unable to decrypt
> the message.
The statement about the SignerIdentifier is definitely incorrect. It
seems that Microsoft does not yet fully understand the issue - does
anyone here have straight contact to the Outlook dev team, or know
people who have? I'd be happy to help (i.e., explain the problem with
all the gory details), but would prefer to speak to someone who is also
able to fix the code, afterwards.
Kaspar
Nelson B Bolyard
> Sigh. I just came across this:
>
> http://support.microsoft.com/kb/2142236
> Non-Outlook email clients unable to decrypt email sent from Outlook 2010
>
> which states under "Cause":
>
>> Outlook 2010 now more fully implements the Cryptographic Message
>> Syntax (CMS) as documented in RFC3852. Outlook 2010 now uses
>> subjectKeyIdentifier as the SignerIdentifier, whereas earlier
>> versions used issuerAndSerialNumber. It seems that some clients may
>> not yet support using subjectKeyIdentifier as the SignerIdentifier,
>> as defined per the RFC. This results in it being unable to decrypt
>> the message.
That's a quote directly from
http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38
or vice versa.
> The statement about the SignerIdentifier is definitely incorrect. It
> seems that Microsoft does not yet fully understand the issue - does
> anyone here have straight contact to the Outlook dev team, or know
> people who have? I'd be happy to help (i.e., explain the problem with
> all the gory details), but would prefer to speak to someone who is also
> able to fix the code, afterwards.
I followed up on this with several posts in the forum page cited above. The
moderator of that forum expressed interest in personally following up on the
issue, but required that someone open a Microsoft support "case" which costs
USD $99 (minimum) unless one subscribes to their support service.
Marsh Ray
>
> The statement about the SignerIdentifier is definitely incorrect. It
> seems that Microsoft does not yet fully understand the issue - does
> anyone here have straight contact to the Outlook dev team, or know
> people who have? I'd be happy to help (i.e., explain the problem
> with all the gory details), but would prefer to speak to someone who
> is also able to fix the code, afterwards.
On 6/12/2010 12:53 PM, Nelson B Bolyard wrote:
>
> I followed up on this with several posts in the forum page cited
> above. The moderator of that forum expressed interest in personally
> following up on the issue, but required that someone open a Microsoft
> support "case" which costs USD $99 (minimum) unless one subscribes to
> their support service.
I have a couple of names of folks at MS who might know someone with code
in that area (and are consistently helpful and friendly). I'll try
shaking the tree a bit and perhaps someone will fall out.
- Marsh
Michael Ströder
After my initial inquiry on ietf-smime about this interop issue a MS employee
contacted me off-list. I think the MS developers now have found the concrete
issue. He sent me details about the cause which seem plausible to me. Last
information he wrote that he internally wants to open a premier support case
for this leading to a hotfix to be released (instead of waiting for the next
big service pack).
So no need for you to open the support case yourself. I'd also think Mozilla
should not change its implementation.
I can't say what the MS forum moderator knows or understand.
Ciao, Michael.