Peter:
PKCS#7 version 1.5 does not constrain the ordering of the certificates, so
the recipient must be prepared for the worst possible haphazard ordering.
CMS has a backward comparability goal, so we get this feature too.
Russ
At 05:10 AM 6/6/98 +0000, Peter Gutmann wrote:
I've got two questions about certificate encoding in transport formats, I've
sent them to both lists since they're a bit nonspecific.
The first one concerns the order of certs in a cert chain. Looking at the
CMS
spec, it says that the SET OF Certificate should contain chains from the
root
down to each required subject, but doesn't give any explicit ordering. An
ASN.1 SET is inherently unordered, but is there any recommended, consistent
way to encode a cert chain, or do you just add them in whatever order you
feel
like? So far I've seen them ordered from subject to root, from root to
subject, and pseudorandomly (using the DER SET encoding rules)... all of
these
are equally valid, it just seems messy to have any number of possible
orderings present.
The second one concerns something which isn't explicitly addressed by any
standard but which it might be worth covering somewhere. When a certificate
or cert-related object (cert request, CRL) is base64-encoded, there are
again
a large number of different interpretations on what delimiters to use around
the base64 data. I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST,
BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something
else :-). Alongside these are various creative mutations (extra blank
lines,
name:value pairs a la PGP, and other oddities). It's probably a good idea
to
specify a set format for these as well and attach them to some existing
standard. If there's a need for them I'll put together a paragraph or two
defining the exact format.
Peter.