"Blake Ramsdell" <blaker(_at_)craswell(_dot_)com> 01/20/97 03:44pm >>>
You mean unordered, right?
Yes, thanks for the correction.
It seems reasonable that for size or other reasons someone might not
want
to send anything in the bag o' certs and put the responsibility on the
receiving entity to find the signing certificate and any other certificates
required to satisfy the trust requirements of the receiver. It also
seems
likely that people are going to want to push other certificates than the
ones that are required to validate the signature or signing certificate
trust (in the case of a dual key model where the signing and
enveloping
certificates are separate, you may want to push both the signing and
enveloping certificates and their respective chains).
I think that the current wording of the use of
ExtendedCertificatesAndCertificates in the S/MIME implementation
guide is
appropriate -- the sender should put in the signing certificate and
certificate chain, and the receiver should be prepared to accept
anything
in any order, but other stuff can go in there also if it's useful.
Being too restrictive in this case will probably hurt, especially in the
dual key model that I mentioned before.
Each of the SignerInfo types in the signerInfos has an
issuerAndSerialNumber member that can be compared against the
received
certificates. After that point, you need to enforce your own rules as
to
your validation of that certificate (in the case of the hierarchy model,
you look up the issuer of the parent certificate, and continue on up the
chain until the trusted root). I'm guessing that you are looking for an
easier way, but I'm not sure that there is one. In our case, we
maintain a
local cache database that has certificates indexed by
issuerAndSerialNumber
and also by subject, and root keys that are indexed by subject.
Finding
the chain is a matter of doing lookups by issuerAndSerialNumber and
by
subject (by issuerAndSerialNumber for the signing cert, and then
looking up
root keys or certificates by subject, keeping in mind that multiple
certificates can have the same subject).
In any case, I think the PKCS #7 syntax is fine. We may want to clarify
the philosophy a little better in the S/MIME implementation guide,
however,
especially with regard to the transmission of self-signed root keys.
Blake
Blake,
I think you have convinced me why an order can not *always* be
imposed on the certificates field . But, I think you have overlooked the
cases when an order can be imposed between the negotiating parties.
For example, PKCS #7 used in the degenerated cases for Certificate/CRL
Retrieval.
My point is in such cases if the negotiating parties want to impose an
order the syntax should not be a hindrance; currently, the SET OF DER
encoding destroys such orders (tell me if I'm wrong).
On the other hand an ordered collection such as SEQUENCE OF does not
necessarily mean you have to impose an order,
it merely assures that if any such order was imposed at the time of
creation it will not be disturbed afterwards. So you have the flexibility
to go either way. The optional inclusion of certificate that you have
mentioned is also satisfied by SEQUENCE OF.
Cheers,
--Arup