On Mar 22, 11:34 pm, Robert Relyea <rrel...@redhat.com> 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 <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
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
