Ron,
Response inline below...
On Mar 8, 2009, at 10:14 PM, Ron Broersma wrote:
Shawn,
I also found the certificate selection situation somewhat non-intuitive and confusing. I suspect that Paul's issue is that he didn't "Show Expired Certificates", and that's why he can't find them. I've run into the same thing a number of times before.
Your example of the "security" command is good, but I would recommend adding the "-a" option, to show ALL certificates, and not just the first match. Since the first match is often NOT the one that you want, it can be confusing, because it will often give you an expired cert even though there are valid certs in the keychain. It would be a lot less confusing if it returned "best match" instead of "first match", so a valid cert would have precedence over an expired or otherwise invalid cert.
Sure, showing all certificates would be great in many cases. I understand and appreciate your attempt at trying to simplify the process, but actually it is difficult to determine which is a "Best Match". I believe many would have alternate definitions of which they feel is a "Best Match". You can have multiple certificates (identities actually) which are valid at any given time. Some issue new _replacement_ Identities prior to the expiration of the previous one. Also, many have multiple valid identities issued by different CAs --- e.g. DoD, VeriSign, Thawte, Entrust, etc. Which of those would be the "Best Match" now becomes an even much more difficult one -- depends on the context of the Sender's intent at that moment.
You can have multiple (personal) Keychains with multiple Identities all valid at any given time.
The address book has the same problem.
Currently, Address Book, unfortunately displays the first certificate found by searching ('security find-certificate -e <EmailAddress>') with the email address defined in the address field and not the first one which is currently valid.
It is just as bad as the "security" command, in that it always seems to prefer invalid certs over ones that are valid.
Keep in mind that it is not the case that Certs (Identities) are of no value after they _expire_. It is frequently the case that folks need to re-read encrypted email which was encrypted with a Certificate that is _now_ expired, but was not at the time. If you delete an expired identity, you would not be able to read those older encrypted messages.
The _security_ command is not _bad_ when it gives you exactly what you are looking for from your current Keychains -- as defined in the current keychain list. What is challenging is the results may not have been what you were looking for without performing the appropriate search.
In order for Address Book to display the correct cert for a given email address, you have to rummage around all your keychains and delete all expired certs that match that email address. That really seems backwards. Why is this manual keychain maintenance required in order to get the right certs to display in Address Book?
As noted earlier, Address Book unfortunately displays the first certificate found by searching with
'security find-certificate -e <EmailAddress>'
I would love to see the behavior better reflect a valid email Identity. Right now, it will show the _check mark_ indicating a certificate is present in the system which also has the corresponding email address in it. Note that right now that would mean that even your MobileMe (@mac.com -or @me.com) email address has a _check mark_ next to it even though MobileMe does not provide a Certificate with the Extended Key Usage for Digital Signature.
I had submitted a RADAR on that and am tracking it.
Also, can you explain the relationship between what Apple Mail chooses for a certificate, vs. what Address Book displays?
Apple Mail will use the first _OS Validated_ certificate corresponding with the email address (RFC822Name) used for the account you are sending from as well as the recipient you are sending to.
Address Book (as noted earlier) is displaying the first certificate corresponding with the email address (RFC822Name) found across all your keychains.
Is there any correlation?
Frequently not with all of the Identities that we all have now a days.
Paul's email implies that a user would intuitively assume that the cert used in signing an email would be the one displayed in the Address Book. Is there really any relationship, or do these separate applications have independent logic in how they choose which cert to use?
As noted multiple times now in this email message (hopefully the replication will help reinforce this point), Mail will use the first _OS Validated_ certificate corresponding with the email address (RFC822Name) used for the account you are sending from as well as the recipient you are sending to.
If Apple Mail is "never allowed (by the OS) to utilize any certificate / identity that does not successfully pass the various tests", why wouldn't you make Address Book operate the same way, so that a user trying to diagnose problems like this won't be confused by the different results of these apps? It would be nice if Address Book displayed the same cert that Apple Mail would choose for digital signature or encryption for a given email address.
I Agree with that if you have ONLY One identity valid for Digital Signature. Remember that you can have multiple certificates (identities actually) which are valid at any given time. Some issue new _replacement_ Identities prior to the expiration of the previous one. Also, many have multiple valid identities issued by different CAs --- e.g. DoD, VeriSign, Thawte, Entrust, etc. Which of those would be the "Best Match" now becomes an even much more difficult one -- depends on the context of the Sender's intent at that moment.
Forcing use of a specific Certificate
If you absolutely want Mail to use One Valid Cert over another, then you can create an Identity Preference for the mapping of email address to which certificate you prefer to use (assuming it passes all of the tests for being valid). Note that when you initiate the New Identity Preference... dialog, it notes the first entry is "Location or Email Address" -- 'Enter the location (URL) or email address for which a certificate is required.'