Subject: A standard encoding for Certification Paths

From: Sean Mullan <[email-masked]>
Date: Thu, 05 Apr 2001 16:34:30 +0100

X.509 defines several ASN.1 structures for encoding a
certification path:

Certificates ::= SEQUENCE {
 userCertificate    Certificate,
 certificationPath  ForwardCertificationPath OPTIONAL }

CertificationPath ::= SEQUENCE {
 userCertificate    Certificate,
 theCACertificates  SEQUENCE OF CertificatePair OPTIONAL }

ForwardCertificationPath ::= SEQUENCE OF CrossCertificates
CrossCertificates ::= SET OF Certificate

CertificatePair ::= SEQUENCE {
 forward [0] Certificate OPTIONAL,
 reverse [1] Certificate OPTIONAL
 -- at least one of the pair shall be present -- }

But they all seem a bit more complex than necessary. A much 
simpler structure should be sufficient for most applications:

CertificationPath ::= SEQUENCE OF Certificate

where the SEQUENCE OF Certificates are ordered from the end-entity 
certificate to the certificate issued by the trust anchor.

It seems that a standard, simple ASN.1 format for representing an 
ordered certification path is useful and is missing. 
 
Has anyone else faced this issue and if so can you suggest any solutions
or other possible standard encoding formats not mentioned above? Note that
a PKCS #7 SignedData object is not a good solution, since it uses 
an ASN.1 SET OF construct to hold certificates, thus the order may not be 
preserved.  

Thanks,
Sean

---

From: Polar Humenn <[email-masked]>
Date: Thu, 5 Apr 2001 14:28:37 -0400 (EDT)

Hi,

Comment below:

> CertificationPath ::= SEQUENCE OF Certificate

I believe the lowest common denominator for a sequence of certificates is
exactly that, a stream of ASN.1 Certificate encodings.

Each ASN.1 Certificate object already has an encoded length, and is
therefore each object (certificate) is extractable from the stream.
Anyway, a byte stream is what sits behind the ASN.1 Sequence Header.

Usually, if you have such a stream, such as a file or a byte buffer, it is
encapsulated so that the length of the sequence is determinable from other
means, either by the length of the file, or buffer. So, the ASN.1 sequence
header information is really redundant. Isn't it?

IMHO, the only reason to standardize such a format, i.e. make an ASN.1
object out of a sequence of certificates, would be to place it inside
other ASN.1 object. However, that is easily accomplished by inserting

 member SEQUENCE OF Certificate

inside the object's description.

Cheers,
-Polar

---

From: Russ Housley <[email-masked]>
Date: Thu, 05 Apr 2001 14:19:32 -0400

Sean:

You are right, but I want to explain why RFC 2630 uses a SET OF construct 
for certificates.  We do not assume that each of the recipients has the 
same trust anchors as the originator.  Therefore, the "bag of certificates" 
provided might help construct certification paths to any number of 
potential trust anchors.

Russ

---

From: Dean Povey <[email-masked]>
Date: Fri, 06 Apr 2001 07:00:00 +1000

>provided might help construct certification paths to any number of 

Although just to be a grouch, the exact same semantics could have been
achieved using a SEQUENCE OF and saying that it is not ordered, as SET
OF is a pain in the butt to encode with DER.  But let us not start on
what is wrong with PKCS#7/CMS, as we could be here for a long time
:-).

Degenerate PKCS#7/CMS SignedData indeed seems to be the most common
method to pass around cert paths, which although something of an
insanity is a small insanity in a very large universe of insanities.
SEQUENCE OF Certificate is also not uncommon, and Polar's method of
just streaming the Certificates without wrapping them up in a higher
level ASN.1 structure is the way it is done in SSL/TLS.

Cheers.
--
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com |