Hi Martin,
In OpenCA standard configuration the CA certificate itself is issued with the following key usages:
digitalSignature, nonRepudiation, cRLSign, keyCertSign
However, I believe that CA certs should NOT be used for anything else than signing CRLs and certificates, and this would only require the CA cert to have the key usage bits
cRLSign, keyCertSign
These are also the only key usages that are allowed according to ISIS-MTT for CA certificates, and I believe that there will be environments that will want to adhere to this standard.
ACK. Ernst-Guenter Giessman asked me such questions too. So it was on my TODO.
* OpenCA uses the CA certificate for signing the cert Role. (BTW: openca-sv does use the CA cert regardless of its key usage bits - and can create invalid signatures this way!)
We enforce this because we had no other solution.
* Verification of this signature (correctly) fails as reported by openca-sv verify) because of incorrect key usage bits in the CA certificate if the ISIS-MTT conforming profile is used.
Correct :)
* The CA private key usage should IMHO be limited to the absolutely necessary minimum, and this is cert signing and CRL signature only. Using the CA key for creating PKCS#7 signatures violates this principle and introduces not really necessary audit events once we have implemented the private key counter.
ACK.
* I am somewhat unsure if the signature on the Role is really necessary - what is the rationaly behind this anyway? The CA signed the cert, so it has expressed consent that this certificate (with the attached cert policy) is valid. A signed "Role" seems redundant to this policy to me.
The signature on the role (and CRIN) was implemented because of the access control. If the role was manipulated then we want to detect this by the signature. Today I think this is a little bit stupid because somebody - who can manipulate the role - can manipulate the CA certificate on the machine too. The dataexchange can be protected by the signature of an admin. So this is no argument.
* I may be wrong, but I think the signature on the Role does not add any security, because the clear text seems to be only the Role name, making it possible to copy the signature and use it for another certificate.
This is not correct. We always sign the role and the serial of the certificate.
To sum this up I think that using the CA cert is a bad idea and that it should either be possible to switch it off or at least to specify a dedicated CA auxiliary certificate that is issued by the CA when setting up the system and then used to sign such stuff.
I have a more radical question, does somebody believe that a signature on the role results in any additional real security? I do not think so because the major source of the role is always the CA and if a manipulation was made on the way to the database (perhaps of another node) then the CA cert can be manipulated too.
If we can agree on this then we can remove these signatures which reduces the CA key usage dramatically. This reduces the number of several possible error sources too. The dataexchange can be protected seperately and if the database is not trustworthy then the infrastructure is always broken.
This would increase the stability of the 0.9.2 release too. The "only" important question is, does this have any impact into our security?
Any additional comments?
Michael -- ------------------------------------------------------------------- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und Medienservice Tel.: +49 (0)30-2093 2482 (Computing Centre) Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
