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]
