Subject: RE: Reverse paths

From: Sharon Boeyen <[email-masked]>
Date: Fri, 14 Jul 2000 13:52:33 -0400

The forward element would be populated in the CA entry of the subject
of the cross-certificate and the reverse element would be populated in 
the CA entry of the issuer of the cross-certificate. 

The only difference between what is specified in the LDAPv2 schema 
and this proposal is that issuer must populate the reverse element of 
its own entry. In the LDAPv2 schema, ONLY the subject CA's entry needed 
to contain the cross-certificate. 

I'm certainly not advocating requiring bilateral cross-certification, 
and I don't think Sean is either.

Cheers
Sharon
> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: Friday, July 14, 2000 11:32 AM
> To: [email-masked]; Sean Mullan; Sharon Boeyen
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> > 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.
> 
> 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
> 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: [email-masked] (Peter Gutmann)
Date: Fri, 21 Jul 2000 07:17:38 (NZST)

Paul Koning <[email-masked]> writes:

>>>>>> "Peter" == Peter Gutmann <[email-masked]> writes:
>
>Peter> ...  (I've seen a
>Peter> paper which tries to formally model PKIX path processing and
>Peter> finds that it's somewhat problematic once you try to create a
>Peter> precise, formal spec rather than the informal description in
>Peter> the RFC, there are some things which actually require the
>Peter> informal spec because they can't be specified in a precise,
>Peter> formal manner).

>A program (algorithm) is a precise formal specification, so does what you say
>mean that the RFC cannot be translated into an algorithm? That would be a
>problem, indeed...

A program constitutes one interpretation of the text in the RFC, however the
RFC really presents an entire class of solutions (or alternatively a rather
large solution space) within which it's possible to construct many different
concrete implementations, all of which are compliant but none of which produce
the same result.  This is why trying to formally specify the path processing
was so difficult, you're trying to construct an unambiguous, exact
specification for something which isn't unambiguous or exact.  In the (draft)
paper I saw they couldn't go as far as they would have liked because it turned
out to be a lot harder than expected to produce a formal spec for the path
processing.  Originally the intent was to model all the path processing stuff,
in the end I think the only thing they managed to complete was policies, and
even then there were some areas where there was no clear indication of what to
do.

The paper is "The PKI Specification Dilemna: A Formal Solution", it was (or at
least will have been by now) published at a conference in Australia, but I
can't find any reference to it online.

Peter.