Subject: RE: Reverse paths

From: Sharon Boeyen <[email-masked]>
Date: Thu, 20 Jul 2000 09:52:53 -0400

Hi Steve,

I guess I should have made my thoughts a little clearer.

Rather than vendors, lets talk about trust models. Within a single 
hierarchy I agree that the current text is optimum, because of the point
that every certificate has one and only one superior certificate.

However, once you start connecting hierarchies together, e.g. through 
bridge CAs and once you moved out of hierarchies into distributed trust 
models, that condition no longer holds true. As bridges become more common 
and the certificates issued to and by bridges increases, the number of 
potential paths becomes quite large.In that trust model, the 
ONLY way that you prune branches, and eliminate potential paths that are 
not appropriate, is by building in the reverse direction. Building in the 
same direction as one would in a hierarchy means that you must build each 
complete path before processing any of the certificates. Building in the
reverse
direction for the distribution trust model allows early elimination 
of paths based on such issues as name constraints, policy constraints and 
many others. 

It is my opinion that recent events, such as the US Federal Bridge CA
activity 
have shown that a single global hierarchy does not work, that distributed
trust 
models are, in fact necessary as well. Because of these events and because
the 
issue was raised, not by me but by another vendor (Sean Mullan from Sun), I
thought
it was a reasonable recommendation to support now. Having said that, let me
clarify
what I meant. To answer your first question, no I don't mean to impose
reverse in 
all contexts. Nor do I mean to impose bilateral cross-certification. Rather,
I am 
suggesting mandating that, in addition to what PKIX says currently, a CA
that issues a certificate to another CA (where the subject CA is NOT a
subordinate CA to the issuing CA within a hierarchy), must place that
certificate in the reverse element of the cross certificate pairs attribute
of the its own directory entry. No impact within a hierarchy at all, no
requirement that cross certification be bilateral. Sorry for the confusion
and I hope this is a bit clearer. So I guess to summarize: 

- Within a strict hierarchy, the forward element must be populated
- At the root of a strict hierarchy that has cross-certified with CAs
outside  
  that hierarchy, both forward and reverse must be populated. In addition to
any 
  certificates that applied to the hierarchy itself, the forward element
would contain 
  any certificates issued to the root by an external CA and reverse would
contain 
  any certificates that the root had issued to external CAs - these need not
be pairs)
- Within a distributed trust model, both forward and reverse must be
populated (actually
  I suspect that only reverse is really needed but for backward
compatibility we'd 
  need to mandate both).

Finally, I don't normally talk about Entrust products on any public list,
but since
you raised it I feel it necessary to respond. Entrust products support both
hierarchical and distributed trust models. In the hierarchical case, we
build certification paths from the end-entity certificate to the root, in
the same way as other vendors and the same way PKIX outlines. In the
distributed trust model, we build certification paths in the opposite
direction (for efficiency reasons) using the reverse element. I don't
believe this is a vendor specific issue (note it was raised by Sun not by
Entrust), but I am certainly interested in hearing from other vendors and
especially from users and will support the consensus. In no way do I wish to
pursue another long drawn out debate on this, along the lines of a few years
ago. I merely thought that we had progressed to a point where bridge CAs and
distributed trust models were more generally accepted and the requirements
for populating reverse go hand in hand with that model.

Hope this clarifies my intent.

Cheers,
Sharon  

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2000 3:03 PM
> To: Sharon Boeyen
> Cc: [email-masked]
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> <snip>
> 
> 
> >I would like to support Sean's request that for the LDAPv3 schema we
> >consider making the reverse element mandatory along with the forward
> >element.
> >This would be a great step forward in supporting 
> interoperability among PKI
> >products and services and, since it does not impact existing 
> LDAPv2 systems,
> >
> >doesn't cause those previously deployed systems to be non-conformant.
> >
> >With both elements mandatory, regardless of the direction the path is
> >being built, the certificate using system will be able to locate the
> >information
> >it seeks.
> >
> 
> I am uncomfortable with the proposal that we mandate both elements, 
> as this would seem to imply that every CA would have to engage in 
> reverse path certificate generation in all contexts.  Did I 
> misunderstand the implication?
> I know that Entrust has always encouraged (required?) this type of 
> cross certification among CAs, but it doesn't seem that other CA 
> vendors or most users have. I would not think it appropriate to 
> impose this sort of requirement, given the vendor-specific 
> implications of such a change.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jul 2000 18:14:23 -0400

Sharon,

>and I hope this is a bit clearer. So I guess to summarize:

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: Russ Housley <[email-masked]>
Date: Fri, 21 Jul 2000 19:22:35 -0400

At 06:14 PM 07/20/2000 -0400, Stephen Kent wrote:
>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?
>
>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!

If the Federal Bridge CA is not employing name constraints, then I agree 
with you.  Certificates issued by a Department to the Federal Bridge should 
exclude the name space of the issuing Department.  This will ensure that no 
one else can issue a certificate with a subject name that is in the 
Department's name space that will be validated by relying parties within 
the Department.  Also, certificates issued by Federal Bridge to a 
Department should include the name space of the subject Department.  This 
will ensure that Department cannot issue a certificate with a subject name 
in the name space of another Department that will be validated by relying 
parties outside of the misbehaving Department.

It has been over a year since I looked at the certification policies 
proposed for the Federal Bridge.  I recall at least one briefing that 
included name constraints.  They were a good idea back then, and they are 
still a good idea.

Assuming that name constraints are employed, the biggest problem with the 
Federal Bridge is certificate path construction.  It is not possible to use 
the linkage provided by the subject key identifier and the authority key 
identifier extensions.  Without this tool, certificate path creation is 
more complex, and several widely deployed implementations are not up to the 
task.  These implementations must become more robust for the Bridge to 
achieve its potential.

Russ