On 03/22/2011 03:09 PM, silent...@gmail.com wrote: > Thank you for the reply! > > On Mar 22, 7:00 pm, Robert Relyea <rrel...@redhat.com> 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
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
