Ed, thanks for the comments. My replies are inline.
Edward A. Feustel wrote: > The document looks like a good start for common S/MIME tasks. Some areas > have not been discussed that could be improved for the user. > > 1. Retrieval of certificates > For the first time user, it would be desirable to have the get > certificate > button labeled: Get New Personal Certificate, or something like that. Agreed. > I would also like to have a button that can be pushed that says > something > like: Get Correspondent's Certificate that gets a correspondent's > certificate > from an LDAP enabled directory and offers a choice of certificates if > more than > one is available, including expired ones (that might have been used for > signing > during its period of validity). This button should enable retrieval > regardless of > what format the certificate is maintained in the directory! There will be a preference to get certs from a directory server. The client will perform that lookup automatically if you have the preference configured correctly. The current UI shows a pref which only allows the user to select one LDAP server and it sounds from your comments below that you anticipate having a large number of users who will need to select several LDAP servers. Regarding the need to select among multiple encryption certs: I anticipate a pref which is basically the same as the SSL client-auth pref: manual select vs. auto select. You and I might want to select manual select to resolve ambiguity. Other people may want to have the client automatically select a cert. Regarding selecting expired certs: do you anticipate such a need? When might it be appropriate to use an expired cert? > Speaking of format, we need a way to import/export certificates in any > of the > commonly acceptable formats!!! It would also be handy to be able to do > the same > with key pairs. Which formats should we support? We currently support PKCS#12. > 2. Certificates by account: > > This would be problematic for me when I do cross-management-domain > mailing since > I may have a different signing certificate for each intended > correspondent. I may also > have given a different public key certificate to each correspondent for > encryption purposes. > I hope the current spec includes the ability to search through ALL > certificates that > could have been used for encryption of messages to me to get the one > actually used and > to decrypt the message. > > If I have more than one signing/encryption certificate, I would rather > have a display of my signing/encryption certificates and choose which > one I want to use. It sounds like you'd like to have overrides for the basic prefs on a per-message basis. How common do you think this configuration would be? In other words, what percentage of users would want to have more than one cert per email address/account? > The same applies to my use of LDAP-enabled directories. I would rather > have a sequence of > directories that are explored than a single one. Perhaps the order would > be different for > each account. I tend to agree that having more than one LDAP server in the loop would help many deployments. > 3. Archival storage of messages: > > Left out of your discussion is the issue of storage of the messages and > review of them. > Since I keep a long term file of old messages, what happens when I > review a message and > the signing and encryption keys have expired? Just like in Communicator, emails verify based on the time they were sent, not the current time. If the cert was valid when sent, it will show up as valid. There are some kinks around this notion regarding CRLs and OCSP, but in general that's the idea. > I might like an interface which offers me the choice of storing the > message in plain text > or enciphered. I might like an interface which offers me an internal > indication that > at the time I received the message the signature was valid. This flag > could not be > changed if I copied the archive from one machine to another. > > Archiving of certificates: > > I need a way of dealing with certificates that have expired or been > invalidated. > For example, if a certificate has been revoked, I don't want to throw it > away since > I may wish to be able to validate a signature or decrypt a message sent > prior to the > action of revocation. On the other hand I may need a way to delete these > certificates. Check out the Cert Manager in N6.2 or the corresponding Mozilla build. Some old pics are here: http://people.netscape.com/lord/psm/n61/ Does that meet your needs? > Multiple signatures on a document: > > It would be a great advantage for workflow if the S/MIME tool would > permit multiple people > to sign a message, one after another. What kind of UI would permit one > to "validate all > signatures" and see which ones were not validatable? Any proposals you have would be helpful. I don't have an answer off the top of my head. > Forwarding of encrypted documents: > > Here I receive a document in encrypted form and wish to forward it to a > colleague. Unless > I have a "group" or "role" certificate and possession of its private key > for doing encryption > which we all share (I'd like this for a mail list) I have to send the > decrypted version re-encrypted. This kind of certificate/key would > require an additional page in the > certificate management section of security. It sounds like you want secure mailing lists, right? Does this RFC cover your needs? http://www.ietf.org/rfc/rfc2634.txt > Messages to the user on the use of certificates: > > I hope the messages indicating why I should supply my password to the > keystroke are improved!!! > Right now I key in the password and hope that I have not been > bamboozled! Ditto messages > about using my private key. I don't quite follow. Are you worried that another application will impersonate the Mozilla client and steal your key database password? > Time stamping messages: > > It would be nice to have a button called time stamp which either > consults a time stamp authority > and gets the message time stamped (Especially handy in an academic > environment). I'll add time stamping to the project list (coming soon), but we won't have time to get to it in the first cut of S/MIME. > Programmatic interface: > > One of the ways of doing workflow is via e-mail. I would hope that > EVERYTHING that can > be done by a Mozilla e-mail client can be scripted so that an > appropriate mailagent > can automate ANY process that a user might want. This is a very good idea. I'll add that to the project list. > Thanks for listening to these requests. I realize you will not be able > to put them all in. > But who knows ... If you don't ask you'll never know. :-) Thanks for the great feedback. I look forward to hearing more ideas as we get further along. -Bob > > > > Ed Feustel > > Jennifer Glick wrote: > >>Draft spec now posted here: >>http://www.mozilla.org/mailnews/specs/security/ >> >>Please post comments to the mail-news and crypto newsgroups. >> > -- Bob Lord Director, Security Engineering Netscape Communications Corp. http://www.mozilla.org/projects/security/pki/
