[x500standard] SV: [Spam] Re: SV: Re: Forward and Reverse Certification Path

David, David and others,

 

Personally, I do not care too much, whether we define a certification path
going one direction or the other. However, defining as going from top to
bottom may ease some descriptions. We may even not need to define forward
and reverse direction, as validation is from top to bottom.  In any case,  I
do want a clear and unambiguous definition. 

 

Attached you may see a couple of messages leading to the current definition.

 

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: era@xxxxxxx

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

 

Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af David A. Cooper
Sendt: 5. oktober 2011 15:59
Til: x500standard@xxxxxxxxxxxxx
Emne: [Spam] [x500standard] Re: SV: Re: Forward and Reverse Certification
Path

 

On 10/05/2011 06:20 AM, Erik Andersen wrote: 

We had a somewhat lengthy debate in particular on the PKIX list on the
definition of certification path. There seemed to be a general consensus on
the following definition:
 
"certification path: An ordered list of public-key certificates starting
with the public-key certificate to be validated, optionally followed by an
ordered list of CA certificates, the last one being signed by a trust
anchor."


Erik,

I must have totally missed this debate on the PKIX list, but this definition
contradicts the use of the term "certification path" in RFC 5280.  Just by
searching for "certification path" in RFC 5280, I came across several
references to the direction of the path.  Here are a few of them:

Section 3.2 Certification Paths and Trust:

Internet Policy Registration Authority (IPRA):  This authority, operated
under the auspices of the Internet Society, acts as the root of the PEM
certification hierarchy at level 1.  It issues certificates only for the
next level of authorities, PCAs.  All certification paths start with the
IPRA.

These restrictions included [...] a pure top-down hierarchy, with all
certification paths starting from IPRA;

Certification paths start with a public key of a CA in a user's own domain,
or with the public key of the top of a hierarchy.

Self-signed certificates are used to convey a public key for use to begin
certification paths.

4.2.1.9.  Basic Constraints:

In this case, [the  pathLenConstraint field] gives the maximum number of
non-self-issued intermediate certificates that may follow this certificate
in a valid certification path.  (Note: The last certificate in the
certification path is not an intermediate certificate, and is not included
in this limit.  Usually, the last certificate is an end entity certificate,
but it can be a CA certificate.)

6.1.  Basic Path Validation:

To meet this goal, the path validation process verifies, among other things,
that a prospective certification path (a sequence of n certificates)
satisfies the following conditions:

a.       for all x in {1, ..., n-1}, the subject of certificate x is the
issuer of certificate x+1;

b.      certificate 1 is issued by the trust anchor;

c.       certificate n is the certificate to be validated (i.e., the target
certificate); and

d.      for all x in {1, ..., n}, the certificate was valid at the time in
question.



I don't know what the basis was for the general consensus on the PKIX list,
but I don't think anyone could seriously argue that RFC 5280 uses the term
"certification path" to mean "[a]n ordered list of public-key certificates
starting with the public-key certificate to be validated."

I also think referring to a certification path as beginning with the
certificate to be validated would be very confusing.  Would we then have to
say such things as that the pathLenConstraint in BasicConstraints restricts
the number of certificates that may in the certification path appear before
the certificate that includes the constraint, and that the nameConstraints
extension limits the names that may appear the subject and subjectAltName
fields of certificates that precede in the certification path the
certificate that includes the extension, and that certification path
validation begins at the end of the prospective certification path and works
towards the beginning of the path?  I think that would be very confusing.

Dave

----- www.x500standard.com: The central source for information on the X.500
Directory Standard. 

--- Begin Message ---
  • From: "Carl Wallace" <carl@xxxxxxxxxxxxxxxxxxxx>
  • To: "Erik Andersen" <era@xxxxxxx>, "PKIX" <pkix@xxxxxxxx>
  • Date: Thu, 14 Jul 2011 12:50:05 +0200
> Does a certification path go from the end-entity to the trust anchor or
>does it go from the trust anchor to the end-entity? What is forward and
>what is reverse?

See RFC 4158, Section 1.3, Terminology:
http://tools.ietf.org/html/rfc4158.html#section-1.3.


--- End Message ---
--- Begin Message ---
  • From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
  • To: "PKIX" <pkix@xxxxxxxx>
  • Date: Mon, 18 Jul 2011 21:27:06 +0200
WARNING: contains banned part
--- Begin Message ---
  • From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
  • To: "PKIX" <pkix@xxxxxxxx>
  • Date: Mon, 18 Jul 2011 21:27:06 +0200
Does Interstate 95 go from north to south, or from south to north?  It
hardly matters whether one starts paving in Miami FL or in Houlton ME, or
start at both ends and meet in the middle - the end result after
construction is done is a path.

This sounds less like a minefield question (c.f. non-repudiation) and more
like a meaningless question.

Even for validation, RFC 5280 says:

   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

Whoever decided to flip a coin and assign Forward and Reverse to a
particular direction along a cert path did PKI a great disservice, about as
silly as labeling the northbound lanes of I-95 as forward and southbound as
reverse.  But now that the coin has landed, the standard PKI assignment of
forward is rootward, and reverse is leafward:

   Building in the Forward direction: The process of building a
      certification path from the target certificate to a trust anchor.
      'Forward' is the former name of the crossCertificatePair element
      'issuedToThisCA'.

Dave


-----Original Message-----
From: Stephen Kent

At 12:27 PM +0200 7/14/11, Erik Andersen wrote:
>Does a certification path go from the end-entity to the trust anchor 
>or does it go from the trust anchor to the end-entity? What is 
>forward and what is reverse?
>

paths generally are built bottom up, always verified top down. So, in 
part, it's a question  of which activity one is performing.


--- End Message ---
_______________________________________________
pkix mailing list
pkix@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pkix

--- End Message ---

Other related posts: