Certificate fetching for bridge CA configuration
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]
Re: Certificate fetching for bridge CA configuration
In message <[EMAIL PROTECTED]> on Thu, 07 Oct 2004 15:20:52 -0400, Charles B Cranston <[EMAIL PROTECTED]> said: zben> So, this is perhaps the most simple "bridge" PKI arrangement: zben> zben> +-+---++-+---+ zben> |T| ||T| | zben> +-+---++-+---+ zben> | P Root++ +---+ Q Root| zben> +-+| | +-+ zben> v v zben> +--+--+ +--+--+ zben> (1) | (P Root) | | (Q Root) | zben> +-+ +-+ zben> | Bridge+--+--+ Bridge| zben> +-+ | +-+ zben> | zben> +-+-+ zben> v v zben> +--+--+ +--+--+ zben> | (Bridge) | | (Bridge) | zben> +-+ +-+ zben> ++ P Sign| | Q Sign++ zben> |+-+ +-+| zben> v v zben> +--+--+ +--+--+ zben> | (P Sign) | | (Q Sign) | zben> +-+ +-+ zben> | P End User | | Q End User | zben> +-+ +-+ That diagram throws me off. I've a hard time figuring out what represents certificates, exactly, and it looks like you MIGHT imply that the a bridge certificate could be used directly to verify EE certificates, which is the wrong way to go about it. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate fetching for bridge CA configuration
In an earlier version of the diagram I had one more level of certificate between the bridge certificates and the end-user certificates, but I was trying to make it simpler. If there is one more certificate between (Bridge)QSign and (QSign)End User it could be supplied by the Q offerer. The cost here seems to be that the certificate marked (1) needs to be available to the relying party, and if the P PKI participates in multiple bridges, then there are multiple certificates in this class. Similarly, if the Q PKI participates in multiple bridges, a Q offerer might have to send along multiple bridge certificates. This means that when a PKI decides to participate in another bridge, certificates have to be disseminated into the client software. This does not scale well. Finding them in a directory seems like a good alternative. In this arrangement I could see there being three separate LDAP repositories: one for PKI P, another for PKI Q, and a third for the bridge itself. BTW my ultimate goal: my pointy-headed boss says "we will cross-certify with the Higher Ed bridge, which will then cross-certify with the Federal bridge, then our researchers will be able to submit signed grant applications to NIH." Now I'm just trying to see the shape in which this could possibly ACTUALLY WORK... Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Thu, > 07 Oct 2004 15:20:52 -0400, > Charles B Cranston <[EMAIL PROTECTED]> said: >> 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 | >> +-+ +-+ > That diagram throws me off. I've a hard time figuring out what > represents certificates, exactly, and it looks like you MIGHT imply > that the a bridge certificate could be used directly to verify EE > certificates, which is the wrong way to go about it. Does the interposition of another level above the end-user certificate address this complaint? Basically I'm trying to understand the text in RFC3280 describing AIA, which seems to refer to the CA that is TWO levels up from the certificate containing the AIA?? -- 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]
Re: Certificate fetching for bridge CA configuration
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]
