Charles, One question: Are you talking about the NIST bridge CA concept or some other variants? It is too hard to understand the diagram.
With my understanding, the bridge CA is a hub between different CA domains. Thus each root CA (or principal CA) issues a cross certificate to bridge. -Kiyoshi Kiyoshi Watanabe > So, this is perhaps the most simple "bridge" PKI arrangement: > > +-+-----------+ +-+-----------+ > |T| | |T| | > +-+-----------+ +-+-----------+ > | P Root +--------+ +-------+ Q Root | > +-------------+ | | +-------------+ > v v > +------+------+ +------+------+ > (1) | (P Root) | | (Q Root) | > +-------------+ +-------------+ > | Bridge +--+--+ Bridge | > +-------------+ | +-------------+ > | > +---------+---------+ > v v > +------+------+ +------+------+ > | (Bridge) | | (Bridge) | > +-------------+ +-------------+ > +--------+ P Sign | | Q Sign +--------+ > | +-------------+ +-------------+ | > v v > +------+------+ +------+------+ > | (P Sign) | | (Q Sign) | > +-------------+ +-------------+ > | P End User | | Q End User | > +-------------+ +-------------+ > > Here P and Q are two separate PKIs bridged by the bridge Bridge. > > Let an email sender (or an SSL server) be the "offerer", > and let the email reader (or the SSL client) be the > "relying party" (latter is standard usage). > > An "offerer" in the Q PKI interacts with a "relying party" > in the P PKI. The P relying party needs this certificate > chain: > > +-+-----------+ > |T| | Presumably this is configured into the relying > +-+-----------+ party software, or available from a server that > | P Root | is secure and trusted by users of the P PKI > +-------------+ > > +-------------+ > | (P Root) | (1) This is the toughie -- could be configured into > +-------------+ the P relying party or fetched from P LDAP but > | Bridge | is NOT reasonable for Q offerer to supply... > +-------------+ > > +-------------+ > | (Bridge) | The Q offerer could supply this along with the > +-------------+ End User certificate > | Q Sign | > +-------------+ > > +-------------+ > | (Q Sign) | The Q offerer would supply this > +-------------+ > | Q End User | > +-------------+ > > So, where would you suspect the (1) certificate would be obtained? > It is unreasonable for Q End User to supply it, since she does not > necessarily know client is from P and so would have to supply EVERY > other PKI's bridge certificate. Perhaps it could be loaded from > a source named by an Authority Information Access extension in > (what? the end user certificate, or the signing certificate?) > > The only other alternative I can see is to load all the bridge > certificates (1) into all the relying parties. > > -- > 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] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
