On 2010-06-03 21:52 PDT, Kaspar Brand wrote: > On 03.06.2010 22:57, PDF3 SecureEmail wrote: >> 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,
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
