On 03/22/2011 02:23 AM, silent...@gmail.com wrote: > 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. 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). > 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. 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?) > 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 :) ). So Thunderbird does not support a standard way of marking a certificate as valid for a particular email address. You meantioned ldap, but that is an RFE, not something that's currently supported. > 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. The main hang up with using certificates without email addresses is designing and implementing a properly trusted way of binding a certificate to an email address. This would be an excellent way to contribute. I would certainly carve out some time to review such a proposal and but patch. > I think, being able to support encryption or having an option > that enables or disables verification of email addresses in > certificates would make sense. Patches are welcome;)... as long as they don't undermine the underlying security of the system. (You can't just use any random cert to encrypt, you need one that is authoritatively bound to that email address!). bob > Best regards, > Sergei Evdokimov > >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
