[Top] [All Lists]

Re: Certificates Field in Signed Data

1997-01-23 16:01:44

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. 

Ok, fine, that is the senders choice. But this has no effect on the 
SET or SEQUENCE issue, since an empty sequence or empty set are the 
same thing :-)

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).

This is an arguement for a SET OF SEQUENCES in my opinion

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.

But being too loose creates work for the receiver, does it not?

The issue is the following: I get a signed Data message, I decode it,
get a bunch of certificates (provided it has been attached). Now,
what would be the simplest way to select the certificate of the signer
and verify the whole chain?

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. 

That seems to be the easiest way to me, following a chain.

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).

Yes, but if you have a local database, you dont really need any 
certificates to be passed to you do you? Except to add more to your 
database. I think that the certificates in the message are for 
receivers who dont have a general certificate database, but who only 
have a very small set of trusted root keys. And to help them, one or 
more chains of certificates seems to be the best.

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.


David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
Email D(_dot_)W(_dot_)Chadwick(_at_)iti(_dot_)salford(_dot_)ac(_dot_)uk
Home Page
Understanding X.500

<Prev in Thread] Current Thread [Next in Thread>