Hi again! I'll attempt to answer the questions you have in-line below. I hope it's ok if I try to keep things as simple as possible right now, referring to the OpenSSL command-line tools as much as possible.
PS. I hope to be able to start work on the tutorial during the day. //oscar "Ravi Prakash B.V." wrote: > Practically how it is possible...... > 1Q. Assume both parties have self signed certificates (root CA's), how > they will cross certify each other? The easiest way of doing this is to use the -ss_cert parameter to OpenSSL's ca command, which tags the input as a self-signed certificate to be "re-issued" by the specified issuer cert and key. I haven't peeked at the source yet, so I don't know how it will behave with regards to issuer key kdentifiers or path length constraints, which it might need to modify in order to keep the certification path valid. > 2Q. For cross certification, If each Root CA send their certificate > Requests to each other. How it is possible to cross certify without > having any existing CA certificate? Certificate requests are "lossy", and could conceivably leave out information that might be necessary to build valid chains, so it's probably easier to use option 1 above. Signing the certificate request would be done using the ca command as usual. > 3Q. will Cross certified root certificate contain two signatures (one is > self signed signature, other is signature of cross certified CA)? (but > as per x509 standards, there will be only one signature part) There will be only a single signature in a cross-certificate, as required by X.509. There is nothing special at all about a cross-certificate syntactically. A cross-certificate is simply a certificate issued to another certificate issuer. I hope to be able to make this much clearer in the promised document, even if UML is a bit of a mess to draw in ASCII. :-) > 4Q. Both root CA's have chain of sub-ca's and issue digital certificates > independently. After some time, both root CA's want to establish trust > with each other (if they get cross certified), As outlined above, "sub-ca's" are cross-certificates by definition. The more complex the two separate hierarchies are, the more work will have to go into "joining" them through cross-certification. I'm quite sure that two messy enough certificate hierarchies might well be impossible to merge. There are also issues where you have a large number of parties wishing to interoperate, as the number of cross-certificates required would grow exponentially (n^2 - n, where n is the number of involved parties.) This can be solved by using a bridge-CA model where the number of cross certificates would simply grow at a rate of 2n. > Is there any implication on the existing digital certificates issued by > root CA's or will they have to get new certificates? I have no idea at > all.... The existing certificates should remain the same. The result of the process should be two new cross-certificates: one using the information in root certificate a issued by root b, and one using root b issued by root a. A uses the latter in order to verify certificates issued by root b, and b uses the former to verify certs issued by a. Hope that made sense. I promise I'll make this clearer as soon as I get some time to organize the information. :-) //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
