Subject: RE: Reverse paths

From: "David P. Kemp" <[email-masked]>
Date: Fri, 21 Jul 2000 12:16:30 -0400 (EDT)

Steve,

If the intent of the bridge is to enable universal cryptographic
connectivity (which I believe it is), then using a bridge CA merely
as a "super certifier" for obtaining trusted copies of other
communities' keys doesn't avoid having to issue and manage N**2
cross certs.

And including the bridge CA in paths does not preclude name
constraints - it is feasible and reasonable for each community
to distinguish between "my namespace" and "everyone else" in it's
outbound cert, and it is also feasible to use the bridge CA as a
namespace allocation authority to enforce disjointness using the
inbound certs.

Dave

> From: Stephen Kent <[email-masked]>
> 
> Sharon,
> 
> I think the Federal Bridge CA model is broken.  It is appropriate to 
> use a bridge CA as a convenient means of distributing certificates 
> between communities, to avoid the order N**2 cross certification 
> problem.  CA-1 could go to the bridge CA to acquire the public key 
> for CA-2, then import that key into CA-1's domain, by issuing a cross 
> certificate from CA-1 to CA-2.  In this fashion CA-1 van impose the 
> appropriate name constraints extension, appropriate  policy mapping 
> constrains, even basic constraints on the depth of cert paths.  Then 
> the existing processing methods we have should work, right?
> 
> If one tries to process a path via a bridge CA, then  one looses the 
> ability to impose name constraints, and to apply selective policy 
> mapping etc, because the bridge CA is in the path, getting in the way 
> :-).  So, no, I am not persuaded by the suggestion that bridge CAs 
> are the wave of the future.  I think they are ill conceived in their 
> current use, but they could be rehabilitated!
> 
> <snip>
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2000 12:38:26 -0400

Save,

>communities' keys doesn't avoid having to issue and manage N**2

Agreed.  It just provides a way for each CA that WANTS to cross 
certify with other CAs to acquire the public key of the other CAs.

>namespace allocation authority to enforce disjointness using the

Yes, one can use the exclusion feature of name constraints to enforce 
that distinction, but that's a pretty wimpy feature compared to 
forcing each cross certified CA to issue certs ONLY within the name 
space for which it is authoritative.  Similarly, for policy stuff, 
one seems tp be restricted to a one size fits all model for dealing 
with other CAs, as opposed to being able to make pairwise decisions.

Steve