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
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
_______________________________________________
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