CJL Posted March 11, 2010 Report Share Posted March 11, 2010 I've been doing some work with S/MIME (Digital ID) interoperability and have run into a problem.Apple's Mail.app does not include the S/MIME Capabilities signed attribute that RFC3851 instructs they SHOULD include. This should be corrected and I have done everything I know how to bring it to Apple's attention - starting over a year ago.This creates a problem on Windows. It seems that when Windows receives a new certificate for a contact in a signed message, it scans the message for S/MIME capabilities. If they are there, it is implemented. If they are not, the contact or certificate is marked as not being S/MIME V.3 capable and Windows insists on sending messages with 40-bit RC2 encryption instead of 3DES. Thankfully, the user is warned under the default security settings so he knows this is happening.My questions are:Where is this S/MIME capability information stored? Address Book? Windows Live Contacts? Registry? Somewhere else?Is there any way to change a contact and tell Windows, "Yes, this contact/digital id/certificate is 168-bit 3DES, S/MIME V3 encryption capable?"The only way I have been able to correct this is by deleting the contact/digital ID on Windows (Now in Address Book and Live Contacts??) and sending one signed message from the Apple user using Thunderbird. After that, Windows has the contact marked as 168-bit 3DES capable.My current testing platform is XP SP3 with current Windows Live Mail. No Windows Server or Active Directory - just plain-old clients. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.