* Serge Fonville wrote on Wed, Sep 02, 2009 at 13:00 +0200: > The chain always includes all CAs and certificates. I've done some > googling, and it shows that you can trust 'just' the intermediate CA > without trusting the root CA, altough this kinda obsoletes the purpose > of the root CA. [...] > >>>>> On Wed, Sep 2, 2009, Yin, Ben 1. <ben.1....@nsn.com> wrote: > >>>>>> OK, regarding the CA deploy, such as, we have a one root > >>>>>> ca and 1000 sub ca signed by root ca. and each sub ca > >>>>>> used as ca by 1000 terminals.so the total network size > >>>>>> is 1000*1000.
I also know people who would like to have such a setup but as far as I know this is not possible with OpenSSL. But maybe there is an indirect possiblity. Could someone please comment on that, telling if what I write below is true or an error in reasoning? I think, a sub CA can easily create a root CA certificate; it just needs to self-sign a certificate with subject == issuer (itself). If used in a mixed environment, the client cannot not send the certification chain (because the client cannot know whether the server is configured to trust root CA and thus needs the `real chain' or to trust the subCA-2-as-root and thus needs the `short chain'), but as far as I know this is not required as long as the servers have all (CA and sub CA) certificates avialable. If used in networks that trust the sub CA only and if the client `knows' that (because it belongs to that group), the client can send the `short chain'. Technically this is simply a root CA, but organisational it is not. It should be possible for someone who has both sub CA certificates (the one issued by root CA, the other the self-signed issued by sub CA 2 itself) to check whether the self-signed is authentic (it is authentic in case both certificates certify the same key). This could be important for parties that load `self signed sub CA certificates' to the 1000 terminals, for instance. Can anyone confirm that this could work or correct it, please? I see reasons for installing sub CA as highest trust anchor. First, as you mentioned, to limit damage in case of compromise. Someone here (Serge Fonville) asked how such a compromise could happen. Of course it should not happen, but in case the damage should be as low as possible. Possibilities to compromise as CA are not limited to brute-force a 2048 bit RSA key; it could be that security officiers are extorted or bribed, it could be, that the CA software is trojaned. It could be, that a big digger lorry or excavator drives straight to the secured environment, grabbing the safe with a small cran to a offroad monster jeep and escape through ways where police cannot follow. And so many other impossiblities that must not happen. But who knows. In case of the impossible happening, it is better to limit damage than not to limit it. It can be important that the treat decreased by the decreased possible damage, so it can be expected that the attack is less attractive, which could be interpreted as to indirectly increase security. Other reasons to want a sub CA could be to ease what certificates are accepted by introducing sub CAs dedicated to special purposes. Lets assume you have a root CA and a sub CA signing user certificates for use with S/MIME email, where user usally have their private keys on hard disk and a second sub CA signing special network certificates where the private keys are stored on hardware security modules (smart cards or so) exclusively. Obviously the practical security level differs a lot. Althrough the root CA of course can be trusted, here the first sub CAs signed certificates would not, because of lower policy. Of course the certificate issuer information can be checked, but isn't it more straightforward to bind the "I want to accept from subCA 2 ONYL" to the key of subCA 2, so taking subCA 2 as root certificate instead of trusting the root CA? oki, Steffen --[ end of message ]----------------------------------------------->8======= ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
