Subject: RE: Reverse paths

From: Sharon Boeyen <[email-masked]>
Date: Fri, 14 Jul 2000 09:56:00 -0400

Hi David,

The LDAPv2 schema discussion on this topic was an VERY lengthy 
debate. If you're feeling particularly masochistic, check out the 
pkix mail list archive covering about June - Oct of 1998 (but 
allow yourself plenty of time because there are probably several 
hundreds of messages on this and related topics during that time).

The text that is in the PKIX LDAPv2 schema is the compromise that 
was agreed as a result of that disucssion. 

A couple of the major factors that I believe led to the decision 
to have reverse element optional were:
a) A large deployment within the US Gov did not populate the reverse
   element and did not use the reverse element to develop paths. If 
   we mandated population of the reverse element, we would have caused
   that deployment to be non-conformant.
b) Back then, hierarchies were dominant and in hierarchies it is generally
   much more efficient to build paths from the subscriber cert to the 
   root of the hierarchy, and in this trust model, the reverse element
   is not required.

However, since 98 I think we've seen much greater support for the 
distributed trust model as well as for mixed mode environments where
hierarchies are 
cross-certified through the distributed trust model. The US Federal Bridge
CA 
project is an example. While I agree that the forward element is required, 
especially for the hierarchical trust model, I think this is an appropriate
time to 
revisit the reverse element. While we need to maintain backward
compatibility 
with the LDAPv2 schema, we don't necessarily need to be bound by the same 
restrictions.

In a hierarchical trust model, there is no dispute that it is more efficient

to build a path from the subscriber cert to the root. In a distributed trust

model, I definitely agree with Sean that it is more efficient to build your 
path from the trust anchor toward the subscriber cert (pruning branches as
you 
proceed). In a mixed environment, it may be most efficient to build from a 
subscriber cert to a hierarchical root and then build from the trust anchor
toward
that root, pruning as you go. I don't think we need to get into a discussion

of what direction is most efficient though, because that would probably lead
to 
an endless debate again. Instead I would suggest that we just recognize that

some certificate using systems will, at times, build in one direction and
some
certificate using systems will, at times, build in the opposite direction. 

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.

Sharon

> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: Thursday, July 13, 2000 10:27 AM
> To: [email-masked]; Sean Mullan
> Subject: Reverse paths
> 
> 
> Date sent:      	Wed, 12 Jul 2000 19:40:47 +0100
> From:           	Sean Mullan <[email-masked]>
> To:             	[email-masked], 
> [email-masked], [email-masked]
> Subject:        	Re: I-D 
> ACTION:draft-ietf-pkix-ldap-schema-00.txt
> 
> Sean 
> this thread should be opened up to the whole PKIX list. I am happy 
> to put this into the LDAPv3 schema if that is what is wanted, but 
> there must have been some earlier discussion as to why it is 
> optional and not mandatory.
> David
> 
> 
> > Building certification paths in a 'reverse'
> > direction (from trust anchor to EE) is a valid way to build
> > certification paths. However, RFC 2587 (PKIX LDAPv2 schema) 
> specifies
> > that the storage of cross certificates in the reverse 
> component of the
> > crossCertificatePair is optional. It is not possible to efficiently
> > build a certification path in a 'reverse' direction unless the
> > certificates are populated in the reverse component of the
> > crossCertificatePair attribute. Specifying that this feature is
> > optional makes it difficult to build paths in a reverse 
> direction in a
> > trust model where lots of cross certificates and multiple 
> directories
> > are involved and you don't know if the CAs support the optional
> > storage.
> > 
> > I would like to suggest that RFC 2587 be amended/updated
> > to make storage of cross certificates in the reverse 
> component of the
> > crossCertificatePair attribute mandatory.
> > 
> > Thanks,
> > Sean
> >
> 
> ***************************************************
> 
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 790 167 0359
> Email [email-masked]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************
>

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 14 Jul 2000 16:32:23 +0100

Sharon,

> 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,
> 
> information it seeks.

How do we handle one-way cross certification where CA A trusts 
CA B but not vice versa. In this case either the forward or reverse 
path might be missing (depending upon which side you are coming 
from).

David

David Chadwick

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jul 2000 15:03:13 -0400

Sharon,

<snip>

>being built, the certificate using system will be able to locate the

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: Steve Hanna <[email-masked]>
Date: Thu, 20 Jul 2000 10:04:23 -0400

> misunderstand the implication?

I'm not sure what you mean by "reverse path certificate generation". This change would require that
when a CA issues a cross certificate, they would have to place a copy of it in their own directory
entry (in the reverse element of a value of the crossCertificate attribute). It would not require the
generation of any additional certificates.

> implications of such a change.

I don't see this as a vendor-specific issue, but rather as an aid to building certification paths.

-Steve

---

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

>generation of any additional certificates.

I though Sharon suggested that each CA entry would hold mandated 
pairs of cross certs, one forward and one back, for each CA it was 
being linked to. In today's mostly hierarchic environment, a CA 
issues a forward cert (using X.509 terminology) to CAs "below" it and 
is certified by CAs "above" it, but CAs do not usually generate the 
other, reverse certs, even though they are defined and a valid part 
of the X.509 model.  Only when CAs in different organizational 
domains certify one another is there typically a a pair of certs 
available. Thus, if one were to impose a constraint, via LDAP, that 
caused CAs to issues reverse certs, it would constitute a major 
change in the way most PKIs today are arranged.

>building certification paths.

It is vendor specific in so far as Entrust products have long 
(always?) issued reverse certs, while no other major products have.

Steve