I agree -- a lot of the advanced architectures I'm studying have
a "trust root" that is NOT self-signed, instead it is signed by
another certificate somewhere else. In a different verification
paradigm the certificate in question is NOT in fact a trust point
but instead is signed by a chain that leads to ANOTHER trust point.
Like this:
+---------------+
| National Root | <-- Off-campus
| (Self signed) | Trust Point
+-------+-------+
|
V
On-campus +-------+-------+
Trust Point --> | Campus "Root" |
+-------+-------+
|
V
+-------+-------+
| End-User Cert |
+---------------+
In this case on-campus verifying parties need only construct
the chain up to a trust point (which is NOT self-signed) while
off-campus verifying parties continue construction of the chain.
Yes, in this particular case, the on-campus verifying parties
COULD just trust the National Root, though this situation might
obtain while transitioning from a campus root to a national root.
It seems to me that it would be useful to be able to designate
a set of certificates as "trust points" and for the process of
chain construction to stop when such a point is reached.
Have not though through the issues of certificate permissions
bits etc. Seems to me the whole idea of construction the chains
before examining the bits might already be broken, since the
chain construction could conceivably depend on the desired final
usage for the end-user certificate and the permissions bits on
all the certificates. I think there was some discussion on this
either in 3280 or the OpenSSL dox but cannot now remember.
Lucenius Jan wrote:
On Tue, 16 Nov 2004, David Schwartz wrote:
X509_verify_cert will construct the cert chain upto the ROOT CA and then
validates the chain and finally verify the self-certificate. What I
understand is that this function expects the ROOT CA to be
self-signed and
it MUST be present in the trusted list.
Right.
1. Is it MUST that the Root CA be self-signed.
What else would sign the root CA? If something else signed it, it
wouldn't
be a root CA.
The reason is that the
trust anchor up to which the application MAY verify need not be the ROOT
CA.
That is the definition of a root CA. It is the one that you trust.
I have thought about that also, especially as there are so many CAs and
even root CAs in real world.
In theory, if there are very few root CAs, they could cross-sign each
other's certificates, i.e. Root CA A signs Root CA B's certificate and
vice versa. This does perhaps not help much, only makes it a bit easier to
trust, say B if you know that A also trusts B. (like banks trust each
other or Dell trusts HP or vice versa :-) . Well, in the case of banks
this might prove that you are dealing with the real bank and not a fake
one unless both are fake). Would OpenSSL and other software support such
cross signing or would they fail because the chain never ends?
Jan
Is there any standard that indicates that the chain MUST be verified
up to the ROOT CA. Is there any way where I can tell the function to
return success even if the chain is not complete(upto ROOT CA).
You can replace the verify function with your own and declare a success
under whatever conditions you want. If you want a quick, ugly way to make
intermediate certificates act like root ones, just create your own temporary
root and self-signed certificate, add that self-signed certificate to your
list of trusted roots. Then, for any intermediate certificate you want to
trust, just generate your own certificate signed with your temporary root,
and add it to the list of certificates.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
"An Internet-connected Windows machine is tantamount to
a toddler carrying a baggie of $100 bills down a city street..."
Charles B (Ben) Cranston
mailto: [EMAIL PROTECTED]
http://www.wam.umd.edu/~zben
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
