I believe is caused by the freshest intermediate scenario. A couple months ago the freshest path would have been to "DST ACES X6", but recently the Certipath PIV-I bridge was updated. As to what introduced it to the system, that could be done various
ways, but as you described, its via SMIME chain hints from a sender building an undesired path and the email client basically infecting your PKI store as a courtesy… be sure to thank it ;)
From my experience none of the PKI implementations in operating systems, browsers, mail clients (NSS) out there handles mesh PKI environments like the FPKI properly. We are working with some vendors to investigate issuance policy OID weighting or someway
to indicate super roots so when multiple paths exists, a preferred path is determined by a more calculated method other than freshness of the certificate.
With Microsoft there is a way to mitigate by putting undesired certificates in the disallowed store, this corrals the choice of paths to the preferred path, but it is a bit of a game of wack-a-mole as newly issued cross certificate will then get picked.
It does work though. For OS X, as most many DoD people very experienced in this issue have previously explained, the mitigation most are doing is explicit trust of an intermediate or root, as far as you can get before either strange paths occur or there are
certificates that are marked improperly as invalid because OS X's implementation of PKI is extremely out of date as far as critical extension interpretation and the like. This falls past best practices to mitigations needed to make something work; it is not
really a good situation in my opinion.
So my guess is that there are a few issues you are seeing:
- Lack of desired chain building method on multiple operating systems
- The effect of certificate hints propagated via SMIME [or TLS/SSL in some PKI stacks]
- OS X lack of capability with critical extensions and other odd behavior
In OS X I have seen even worse stuff, like chain building with expired certificates when paths with non-expired certificates exist and other PKI horors. If anyone else has better methods of mitigation besides explicit trusts, please share them.
-Ridley
-----Original Message-----
From: fed-talk-bounces+ridley.disiena=email@hidden [
mailto:fed-talk-bounces+ridley.disiena=email@hidden] On Behalf Of Levine, Jason (NIH/NCI) [E]
Sent: Wednesday, December 05, 2012 11:29 AM
To: NIH Apple Sys Admin Contacts; email@hidden
Subject: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
Does anyone here know how OS X chooses which intermediate certificate it uses when it's validating a certificate chain? Specifically, if a cert has issuer "SuperSecure CA", and my keychain contains two different certs with the CN "SuperSecure CA", what
is OS X's methodology for choosing which of these two certs is the proper issuer?
Briefly: my OS X 10.8 keychain contains multiple certs with the CN "Federal Common Policy" -- and due to Mail.app's behavior of auto-importing any certs it finds in an email, and a sender which once included a signature cert chain which has a "bad" Federal
Common Policy cert in it, I keep getting this other cert added to my keychain. This "bad" cert isn't self-signed like the current Federal Common Policy cert, but rather was issued by "Federal Bridge CA" and leads up to a CertiPath cert that has an "unrecognized
critical extension" and thus is untrusted by OS X. Once this "bad" Federal Common Policy is added to my keychain, OS X immediately chooses it as the issuer up the chain for ALL Federal PKI certs -- meaning most of the SSL certs at the NIH, all the certs on
PIV cards, etc. -- and stops trusting all of these. Each time, I have to go into the keychain, delete this rogue Federal Common Policy cert, and then be OK until the next time Mail.app caches the email that has that "bad" cert.
What makes OS X choose this bad Federal Common Policy cert over the good one that's in System Roots (and system and login -- I have three copies of the good one, all with custom trust settings saying Always Trust)?
(Of note, I'm happy to share the "bad" one with anyone who's interested -- it's interesting, in addition to the issuer difference described above, it has an expiration date in 2014 rather than the 2030 date of the current good one.)
Jason
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription: