Hi Oscar,

Thanks a lot. Most of the things are clear. 
I will be very happy if you send the document ASAP....

Thanks in anticipation,

Ravi


Oscar Jacobsson wrote:
> 
> 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]

-- 
I am NOMAD!
begin:vcard 
n:Venkata Ravi Prakash;Burlagadda
tel;cell:98490 30284
tel;home:08644 26681
tel;work:040 6328079(direct) 040 7814515/17/19 extn:387
x-mozilla-html:FALSE
org:Tata Consultancy Services;Advanced Technology Centre
version:2.1
email;internet:[EMAIL PROTECTED]
title:ASE
adr;quoted-printable:;;1-2-10, Coramandel House,=0D=0ASardar Patel Road;Secunderabad;AP;500003;India
x-mozilla-cpt:;28992
fn:Burlagadda Venkata Ravi Prakash
end:vcard

Reply via email to