S/MIME Encryption Certificate without email address
It seems that Thunderbird refuses to use X.509 certificates for S/MIME encryption when these certificates do not contain email address of the subject. We want to use S/MIME with keys stored on smart cards and certificates distributed via LDAP. For obvious reasons we cannot attach certificates to fixed email addresses. The RFC 3850 describing certificate handling in S/MIME 3.1 (or 2632 for version 3) states that "Receiving agents MUST recognize and accept certificates that contain no email address". And indeed, Thunderbird is able to verify a signature or decrypt an email if certificates with no email addresses were used (though it gives a warning when verifying a signature). It can also use a certificate without an email address for signing emails. However, it fails when I'm trying to encrypt an email. The encryption certificates without an email address can neither be explicitly imported via Certificate Manager nor loaded from the LDAP. Microsoft Outlook has similar issues, but after some registry tweaking it can be enabled to use such certificates (http:// support.microsoft.com/kb/276597). Is there is a way to make Thunderbird accept such certificates too? Best regards, Sergei Evdokimov -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME Encryption Certificate without email address
Well, the reasons are at least obvious to us :) - the card is supposed to be in use for least 5 years. Card owners (Health Care Providers in our case) should be able to use various email providers for exchanging medical reports. The email providers will be not gmail or yahoo, of course, but still the requirement is to allow having more than one as well to provide possibility to register or switch the email provider AFTER the card was issued. And in general, as electronic IDs are spreading (at least in Europe) this becoming quite a relevant scenario. Concerning compliance with S/MIME 3.0 and 3.1 - the sentence "Receiving agents MUST recognize and accept certificates that contain no email address" resides in versions 3.0, 3.1 and 3.2 of S/MIME Certificate Handling RFCs. Thunderbird is compliant with all of them - it recognizes certificates without an email address when decrypting an email or validating its signature. It even allows signing using such a certificate (though gives a warning when email address is missing in the signing certificate, what already poses a problem for us - doctors are easy to scare :) ). But as I said, encrypting emails with such a certificates is not working. I've checked the NSS code - as you say, the retrieval of certificates from the certificate database is based on the email address. That seems to me as an inconsistent behavior - signature verification and decryption are working and only encryption is not. I think, being able to support encryption or having an option that enables or disables verification of email addresses in certificates would make sense. Best regards, Sergei Evdokimov On Mar 21, 5:54 am, Nelson B Bolyard wrote: > On 2011/03/17 02:41 PDT, silent...@gmail.com wrote: > > > It seems that Thunderbird refuses to use X.509 certificates for S/MIME > > encryption when these certificates do not contain email address of the > > subject. We want to use S/MIME with keys stored on smart cards and > > certificates distributed via LDAP. For obvious reasons we cannot > > attach certificates to fixed email addresses. > > Obvious? Not at all. Why not? > > > The RFC 3850 describing certificate handling in S/MIME 3.1 (or 2632 > > for version 3) states that "Receiving agents MUST recognize and accept > > certificates that contain no email address". And indeed, Thunderbird > > is able to verify a signature or decrypt an email if certificates with > > no email addresses were used (though it gives a warning when verifying > > a signature). It can also use a certificate without an email address > > for signing emails. However, it fails when I'm trying to encrypt an > > email. The encryption certificates without an email address can > > neither be explicitly imported via Certificate Manager nor loaded from > > the LDAP. > > NSS does not claim compliance with S/MIME 3.1, but only with 3.0. > > > Microsoft Outlook has similar issues, but after some registry tweaking > > it can be enabled to use such certificates (http:// > > support.microsoft.com/kb/276597). Is there is a way to make > > Thunderbird accept such certificates too? > > NSS's cert database is capable of storing email encryption certs that lack > any email address, indexed by en email address not found in the cert itself. > Thunderbird does not use that facility to enter certs into that DB. You can > do it manually using NSS's (not Microsoft's) command line tool "certutil". > But this is probably not the answer you seek. > > > > > Best regards, > > Sergei Evdokimov > > -- > 123456789012345678901234567890123456789012345678901234567890123456789012345 > 67890 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME Encryption Certificate without email address
Thank you for the reply! On Mar 22, 7:00 pm, Robert Relyea wrote: > Unless there is an authoritative way to bind the cert to a given email > address, there is no way to use those certs for email. If you want email > certs to interoperate with people from outside of the infrastructure, > the only way is to put the email address in the certificate. Otherwise > you are completely loosing any value for signed and encrypted email. > > Within an infrastructure, it's fine to use some other means to mind cert > to email (like ldap). Well, actually, using LDAP is exactly our plan, so having email as a unique ID for a certificate is not critical at all. Besides, I wouldn't say that not having an email in the certificate makes them useless for people from the outside of the infrastructure. What concerns encryption - the message is already encrypted using the public key of the recipient, so having an email in the certificate does not add anything. Signature verification is, of course, problematic - if a certificate does not contain an email address, the message can be changed the certificate swapped and the client will still state that the message is correctly signed. But nevertheless, the signature that is not binded to the certificate can point to the identity and affiliation of the sender - in our case the CA performs identity verification (or from whom the certificate was stolen, if later it appears that the message was forged). We are aware of the risks that usage of such certificates introduces, but since the attachment (sensitive medical data) will be signed with a qualified signature, S/MIME signature will not be the only way for ensuring integrity and authenticity. But what is critical for us is the confidentiality protection agains the email provider, and we can't use it in Thunderbird with our certificates :( > Validating signature? I'm pretty sure if we can't bind the cert to the > sender's email address, we mark the signature as invalid. If that isn't > happening it's a bug! (It may be that you have explicitly marked this > cert as trusted for this email address?) I've checked it several times and certificates without email address can be used for signing messages. Thunderbird (as well as outlook and outlook express) give a warning that states that the signature is valid but email addresses in the certificate and in the message are different. As I've already mentioned, the relevant RFCs require that such certificates should be accepted, so I am not sure if it is a bug. So, to cut a long story short, I understand your argument, but I also think that in some scenarios it can make sense to allow usage of certificates that do not contain email addresses. It could be a switch in the settings, a setup option or something else (e.g., Outlook allows it after a minor change in the registry). Best regards, Sergei Evdokimov -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME Encryption Certificate without email address
On Mar 22, 11:34 pm, Robert Relyea wrote: > On 03/22/2011 03:09 PM, silent...@gmail.com wrote: > > > > > > > > > Thank you for the reply! > > > On Mar 22, 7:00 pm, Robert Relyea wrote: > >> Unless there is an authoritative way to bind the cert to a given email > >> address, there is no way to use those certs for email. If you want email > >> certs to interoperate with people from outside of the infrastructure, > >> the only way is to put the email address in the certificate. Otherwise > >> you are completely loosing any value for signed and encrypted email. > > >> Within an infrastructure, it's fine to use some other means to mind cert > >> to email (like ldap). > > Well, actually, using LDAP is exactly our plan, so having email as a > > unique ID for a certificate is not critical at all. Besides, I > > wouldn't say that not having an email in the certificate makes them > > useless for people from the outside of the infrastructure. What > > concerns encryption - the message is already encrypted using the > > public key of the recipient, so having an email in the certificate > > does not add anything. Signature verification is, of course, > > problematic - if a certificate does not contain an email address, the > > message can be changed the certificate swapped and the client will > > still state that the message is correctly signed. But nevertheless, > > the signature that is not binded to the certificate can point to the > > identity and affiliation of the sender - in our case the CA performs > > identity verification (or from whom the certificate was stolen, if > > later it appears that the message was forged). We are aware of the > > risks that usage of such certificates introduces, but since the > > attachment (sensitive medical data) will be signed with a qualified > > signature, S/MIME signature will not be the only way for ensuring > > integrity and authenticity. But what is critical for us is the > > confidentiality protection agains the email provider, and we can't use > > it in Thunderbird with our certificates :( > > There is not such thing as confidentiality if you don't have > authentication of the person you are sending the message to. Any plan > would have to take that into account. > > If you are willing to make a proposal with some code to do this right > (find the cert in a secure ldap by email address, for instance, and > allow that to be the authoritative binding), then I'll be happy to > review your proposal and code. > > bob>> Validating signature? I'm pretty sure if we can't bind the cert to the > >> sender's email address, we mark the signature as invalid. If that isn't > >> happening it's a bug! (It may be that you have explicitly marked this > >> cert as trusted for this email address?) > > I've checked it several times and certificates without email address > > can be used for signing messages. Thunderbird (as well as outlook and > > outlook express) give a warning that states that the signature is > > valid but email addresses in the certificate and in the message are > > different. > > Yes, and thunderbird shows a broken signature for that. > > > As I've already mentioned, the relevant RFCs require that > > such certificates should be accepted, so I am not sure if it is a bug. > > So, to cut a long story short, I understand your argument, but I also > > think that in some scenarios it can make sense to allow usage of > > certificates that do not contain email addresses. > > I'm okay with some of those scenarios, and if you are willing to do the > work to make them work, I'm willing to review the code. > > bob Great! I'll see what I can do. Sergei -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
