Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
- Subject: Re: [Fed-Talk] Re: Root Cert on MacBookPro Question
- From: "Timothy J. Miller" <email@hidden>
- Date: Wed, 30 Dec 2009 08:43:23 -0600
Paul Derby wrote:
They have these "split" certs one for signing, another for
encryption. OS X Mail app recognizes when a signing cert is present,
but aborts when the user tries to encrypt.
Again, this is *very* likely because of email address matching issues
with Mail.app. Because DoD does not have an enterprise email solution,
changes in assignment cause changes in the user's email addresses. DoD
components also have the unfortunate tendency to periodically change
their email address naming schemes, which doesn't help matters any.
Keeping user certificates in sync with these changes has proven
difficult, and is a small part of why the DoD PKI CRL has grown to
unreasonable size. Microsoft provides a capability where the email
address matching rules can be relaxed in Outlook (this is allowed by the
S/MIME RFCs), but Apple and Mozilla (and Lotus and pretty much everyone
else implementing S/MIME) do not.
The solution, however, is not in the PKI or in the mail client. The
solution is for DoD to get its collective act together and deploy an
enterprise email capability, even if it's only a big honkin' forwarder
and directory service. This is, I'm happy to say, well underway for
Army and Air Force, and starting to happen for the DoD as a whole.
That is really tough to
debug and the error message that gets generated is pretty worthless.
True. But this is true of many applications and systems for many
different things, not just PKI. Microsoft's quintessential "An error
has occured while creating an error report" (yes, 'occurred' is
misspelt) message comes to mind, but UNIX systems aren't immune to
useless error logging either.
In XP you can specify which cert you wish to use. In OS X you can't
without getting into terminal mode or messing around exporting and
importing to get the order "right" for OS X.
This only an issue at signing if you have more than one *valid*
certificate issued with the digital signature key usage bit set for the
same sender's email address, or when a recipient has more than one
*valid* certificate with the key encipherment or key agreement key usage
bits set for the same email address.
While this happens, it's very rare, and is usually the result of an
organization trying to use the same S/MIME identity with an
internal-only PKI *and* an external-only PKI (e.g., corporate certs for
internal use, and Verisign certs for external use, but the same email
address in both). This is basically a misunderstanding of the nature of
the S/MIME identity being asserted in an S/MIME certificate, and while I
grant you that the average user won't understand the difference, the
people who deployed such a frankentecture should have known better.
I wish Apple would put some energy into
getting cert support up to par with the rest of OS X.
I couldn't agree more.
I will say, however, that IMHO Apple got some PKI UI elements right.
The Keychain key storage model is relatively intuitive, and visual cues
between trust anchors and non-trust anchor certificates that are very
helpful.
Past these, however, security UIs in general are pretty awful, but
Apple's not alone here; Mozilla's PSM isn't any better, and Microsoft's
abortion of a key storage and handling UIs are better left undiscussed.
I continue to hope for programmers to take a page from the InfoCard UI
in Windows and apply the card metaphor to certificates, but so far this
has been in vain.
It will also be nice when certs are ubiquitous so that we can lock down
receiving email that isn't signed by a white listed sender. That would
eliminate most SPAM.
That would be no more effective than whitelisting senders without
signatures unless you're also willing to also manage a corresponding
whitelist of sender *keys*. The problem here is that keys inevitably
change, and lacking a global infrastructure of key management messaging
you're very unlikely to find out when that happens.
-- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden