Victor Probo wrote:
> Robert; > Let me start with two sentences in your answer: > "Unfortunately the one to one mapping of email address to > certificate is > built into our database format. Getting basic S/MIME working is the > immediate goal." > And in a year or so it will be " We can't make it more flexible, too > much code > depends upon this API and structure." Actually the expressed design goal of the new code is to remove the restriction so that we simply need to change the database. Today the problem is 1) the database format only supports one-to-one, 2) the archictecture of the code only supports one-to-one, and 3) the API's only support one-to-one. What we are doing in NSS 3.4 is fixing 2 and 3 and isolating #1. The upshot is we may still be stuck with one-to-on mapping in the first release, but we will know how to fix the problem in future releases (or even update 'existing' releases. It's important to loose sight of 2 and 3, which is way I stated them as goals. It's also important not to let these goes stand in the way of release the already too long delayed S/MIME implementation. > > The reason I bring this up is that while standards and RFC' s are great > (so many to > choose from) it is the early implementations that define the 'practice'. > And > 'practice' takes pecedence over 'policy'! The X.509 allowes multiple > subjetAltName > extensions, which means multiple e-mail addresses, Why not the address > book? This is hardly the first implementation of S/MIME. We will already face the problem that older versions don't even understand subjectAltName, yet alone handle a multiple email address to single cert mapping. Existing versions of Communicator will downright choke on Certs presented as email certs without the email address in the SubjectName. (BTW it's not the address book that stores the mapping, it's the certificate store, which is only relevant to this discussion because it is possible to dynamically replace the certificate store with your own in NSS 3.4, which means we have a prayer of back fitting old versions > Is it the marketing push , "Get it to market now, make it work later"? Really it's a marketting pull "we have a functioning version of S/MIME today, before I go to Netscape 6". There is already a functioning, happy infrastructure out there that is using S/MIME. > But I flame.... > > Anyway, on to the specifics.... > > Robert Relyea wrote: > > > > > > > Victor Probo wrote: > > > >> I am asking what Mozilla will consider as a valid signature, and > how it will > >> respond. (please ignore spelling errors, we all know why) Start > with the > >> assumption that you have a validly structured X.509v3 certificate > signed by > >> an acceptable CA. > > > > > > > > Here's what communicator 4.x does today (for reference): > > > > If the email check fails, the signature is labelled invalid. The > email address in > > the cert must match the from line of the e-mail. > > Unfortunatly this is spoofable, but probably nothing better. > > > e-mail addresses and certificates match one for one. That is one > certificate > > (actually one set of certificates matched by subject) match > ? 'subject' = CN or DN? > All certs in a set must have same email? > > > one for one to email address. Communicator can not handle more than > one certificate > > (subject)* per email address, nor can it handle multiple email > addresses for > > pointing to the same certificate (subject) > . > This means that Bob Lord's addressbook entry cannot contain email > certs for > '[EMAIL PROTECTED]' as well as '[EMAIL PROTECTED]'? > > *certificate (subject) means a collection of certificates which make > of a single > > personality all sharing the same subject DN. 90 % of the time it > means a > > single cert. > > DN uniqueness is not required across CAs. I could have exactly the same > DN on Verisign and Baltimore certificates, and they could have > different emails. > Uniqueness is only within a single signing authority. > > > > ---------------------------------------------------------------- > > What our goals for mozilla are: > > > > If the email check fails, the signature is labelled invalid. One of > the email > > And as such, is the user consulted to see if they wish to store it > anyway? > Is it possible the user wants that cert stored anyway? > > > addresses in the cert, if any exist must match the from line of the > email > > sender. If no email addresses exist, a mapping of cert to email > addresses from > ^ in cert? > > some trusted source (directory/database) is attempted. If none exist > at all > ^ specified how? from the bad cert? from user? > > > match fails? In any case the displayed sender line gets replaces > with the CN > > from the certificate. > > > > There are two basic reasons for checking the email address: 1) The > signeature is > > only meaningful if you know how actually signed the email. A signed > email > > which says "get off moz crypto and get back to work" signed by Bob > Lord would > > have a different affect on me than the same signed message sent by > > [EMAIL PROTECTED] 2) The certificate with an embedded email > address is an > > authenticated way of getting the public key for a potential > recipient. That is > > Did you see the announcement this week that the DoD just shipped the > first > 600,000 (out of 6 million?) Smart cards to be used as the military > Common Access Card. And from the "X.509 Certificate Policy for the > United Stated Department of Defense" (version 5.2), section 6.1.7 we > find: > > "Public keys that are bound into certificates which assert the > CLASS 2, > CLASS 3, or CLASS 4 assurance policies shall be certified for use in > signing or encrypting, but not both,..." > Looks like they issue 2 different certs, the one you sign with cannot > do encryption. > > > why we need a trusted source to map email address to certificate if > we can't > > match email addr in the certificate. > > > > Note I said these are the goals for mozilla. Unfortunately the one > to one > > mapping of email address to certificate is built into our database > format. > > Getting basic S/MIME working is the immediate goal. > > > > > >> > >> 1) Must the email address in the cert match the the from line of > the e-mail? 2) > >> Must the email address in the cert match some address in the > Recieved lines? 3) > >> Must there be an email address in the cert at all? The signature > is for the > >> signer entity, not necessarily it's email address. 4) What if there are > >> multiple emails in multiple subjectAltName extensions? 5) Is the cert > >> considered valid if it's use is signature but not encryption? > > > > > > > > For signatures, the cert must be valid for signing. In order to > respond with an > > encrypted email, the encryption cert must also be available and > valid. S/MIME > > typically carries both certificates in a signed message. > > > > > >> > >> Is there any Mozilla ConOp for these circumstances? > >> > >> > >> Victor Probo > >> > > > Victor >
