[x500standard] SV: Re: Forward and Reverse Certification Path
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Wed, 5 Oct 2011 12:20:05 +0200
Hi David,
You bring up a lot of issues that also been puzzling me. I did not invent
those different ASN.1 definitions. I am just trying to make some sense out
of them, as we cannot remove them.
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."
It is now described in a Defect Report 369
(http://www.x500standard.com/uploads/Ig/DR_369.pdf).
I was not proposing to define more ASN.1 than we already have. I only feel
that for descriptive purpose it would be useful to defined direction of a
certification path. As an example we have 8.4.1 item j).
"j) A CA needs to be able to inhibit use of policy mapping and to
require explicit certificate policy identifiers to be present in subsequent
certificates in a certification path."
What is the "subsequent certificate"? From the context one may deduct it the
next in sequence is one in the direction toward the end-entity. There are
more such examples where a precise definition is desirable. It would be
desirable to have precise term. So I propose the following definitions:
Forward path direction: The sequence of public-key certificates taken in the
same order as the certification path.
Reverse path direction: The sequence of public-key certificates taken in the
reverse order of the certification path.
Now to some comments on the different ASN.1 data types.
The PkiPath data type is defining a path in the reverse path direction.
The Certificates data type does not defined a certification path. Somewhere
X.509 states "In some situations, conflicting or overlapping requirements
for constraints, such as name constraints, may require a CA to issue more
than one cross-certificate to another CA." The Certificates data type
describes that configuration. I do not see the need for an ASN1 data type to
describe that, but anyway, we got it. It is currently out of context.
The CertificatesPath data type is defining a path in the forward path
direction. Not everybody is happy with that definition. However, we cannot
do anything about except putting some word around it to make it usable. It
is imported by other modules, like X.511 used for strong authentication on
directory protocols.
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
-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af Kemp, David P.
Sendt: 3. oktober 2011 15:41
Til: Directory list
Emne: [x500standard] Re: Forward and Reverse Certification Path
This definition is a model of clarity:
"PkiPath :: SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence,
the order of certificates is such that the subject of the first
certificate
is the issuer of the second certificate, etc."
This definition is mush:
Certificates ::= SEQUENCE {
userCertificate Certificate,
certificationPath CertPath OPTIONAL }
"In addition, the following ASN.1 data type can be used to represent
the
forward certification path. This component contains the
certification
path which can point back to the originator."
CertPath ::= SEQUENCE OF CrossCertificates
CrossCertificates ::= SET OF Certificate
(What does "point back to the originator" mean? And who is the
"originator" anyway - a higher power who created the original
X.509 in 7 days and 7 nights of fevered typing? The subject
of the userCertificate who is performing path construction prior
to sending a message? How are the multiple Certificate objects
in the CrossCertificates SET related to each other, and to other
Certificates in the CertPath? How large can the SET be?)
The CertificationPath ASN.1 definition expresses its meaning clearly:
"A user may obtain one or more certificates from one or more
Certification
Authorities. Each certificate bears the name of the Certification
Authority
Which issued it. The following ASN.1 data types can be used to
represent
Certificates and a certification path:
CertificationPath ::= SEQUENCE {
userCertificate Certificate,
theCACertificates SEQUENCE OF CertificatePair OPTIONAL }
CertificatePair ::= SEQUENCE {
issuedToThisCA [0] Certificate OPTIONAL,
issuedByThisCA [1] Certificate OPTIONAL
And finally, the non-ASN.1 definition of certification path says nothing
about forward or reverse:
"A certification path from A to B
- starts with a certificate produced by CA(A)
- continues with further certificates
- ends with the certificate of B
So which of the four existing definitions (A to B, CertificationPath,
Certificates, or PkiPath) are you proposing to augment with a definition
going in the opposite direction? And what is the purpose of the
additional definition? Using PkiPath as an example, I see no benefit to
defining a new structure ReversePkiPath consisting of the identical
certificates but placed in the SEQUENCE in the opposite order.
Dave
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Erik Andersen
Sent: Monday, October 03, 2011 8:11 AM
To: Directory list
Subject: [x500standard] Forward and Reverse Certification Path
A certification path is currently defined a going from the end-entity
toward the trust anchor. I would be convenient to defined a forward
certification path equivalent to a certification path and a reverse
communication path going from the a CA-certificate signed by the trust
anchor down to the end-entity public-key certificate.
Any comments?
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>
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
