* Eisenacher, Patrick wrote on Tue, Feb 23, 2010 at 12:30 +0100: [...] > "The selection of a trust anchor is a matter of policy: it > could be the top CA in a hierarchical PKI, the CA that > issued the verifier's own certificate(s), or any other CA in > a network PKI." > > And no, I don't need a separate truststore for subordinate-CAs. > I have one truststore into which I put those certs that I > trust. I only have to build up and verify a path up to a cert > in my truststore. After all, a trust anchor is just that: an > anchor of trust. I don't need to verify further, when I trust > that entity.
I think using a sub-CA as trust anchor might even seem stronger, because base-security is bound to cryptographic keys instead on some subject's string content. When relying on some subject's string content, let's say evaluating whether O=MyOrg, legally ascertained contracts with all(!) super-CA's might be required to ensure that none else never ever will also get O=MyOrg - even if in some special closed group in a country on the other side of the globe has a special sub-CA, this must never ever issue O=MyOrg. I think this comes close to requiring that all sub-CAs must be trusted. Knowing that there are sometimes lower-security-level sub-CAs for personal mail certificates or alike, this might seem weak. Writing complex string matching rules seem to be complex and thus error prone. Am I wrong? Corrections appreciated! In practice someone might not use the sub-CAs `ordinary' certificate but might want to use a `root' certificate (self-signed by the sub-CA). For the use case that only certificates by this sub-CA shall be accepted, I think it is OK to make this to be the `local root CA'. > Things get differently of course, if you do revocation > checking, in which case you always have to build up the whole > path from ee to root-ca. But I stated that before and we both > agree on that. I think this also might depend on policy. If I would buy a sub CA certificate MyOrg from ACME-CA and later have a special context where I have reject all non-MyOrg certified chains and having MyOrg as trust anchor, I might not be allowed according to the policy to give ACME-CA the theoretic possibility to revoke the MyOrg trust anchor (because it is the anchor and by definition the root of any [all] trust). Is this correct or fails it elsewhere? Also I could imagine that MyOrg is (cross-) certified by many super-CAs, maybe because it also issues web server certificates and a root CA known by default in major browsers might be desired. I would not trust any ordinary end-user CA enough that they never ever will generate a MyOrg certificate if for example a valid business company has the correct valid official name MyOrg. Also, when having multiple root-CAs as trust anchors, how to ensure that none of the root-CAs never ever certifies MyOrg for someone else... So best here probably is to use a self-signed MyOrg certificate, but I think when doing this confusing and trouble could occure when in one chain MyOrg is self-signed but in the peer chain it is not or other conditions? > > Yes, it is probably a limitation to OpenSSL that it doesn't > > really have a > > "Trust Anchor only" store, but if you take a look at most major > > implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then > > they pretty much > > always use self signed "root" certs as the trust anchor. > > openssl has a truststore. It just doesn't allow to trust > subordinate-cas that I intentionally put in there to be > trusted. And that's what I consider a limitation. Yes, even if sub-CAs are locally avialable (trusted), they are not trusted. I felt this confusing. > So suppose, verisign has 2 subordinate-cas, one for securely > registered ees, and one for not so securely registered ees, > both subordinate-cas have a common verisign root-ca, and both > have the same policy identifier or none at all in their certs. I guess you cannot get a written contract (without paying heaps of money at least :)) from verisign guaranteeing that they never ever will make a third sub-CA with some property clashing with the implemented path-verification/policy algorithm. > How would I achieve my goal to only accept ees certified by the > secure registration ca? This should be a common scenario after > all. I've read a few specifications requiring that an official public CA shall be used to obtain certificates but not requiring to perform any subject content checking, which, if really someone would implement it this way, would allow anyone to obtain a certificate by this public CA. By this, he is authenticated but not neccesarily authorized, but often it seems both are not separated strongly enough (in terms of high security, i.e. as secured as the certificate itself is). oki, Steffen -- --[ end of message ]----------------------------------------------->8======= About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
