At 11:06 PM 1/23/97 +0000, David Chadwick wrote:
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
Yup -- that is a way to address this issue. I think my concern is that I
don't want to get stuck in a corner where all we can use is a hierarchical
trust model, and that any structure we impose on the transmission of certs
could railroad us into a single way of thinking about trusting
certificates. The SET OF SEQUENCES seems like a good compromise in the
event that this all boils over and we absolutely have to change something.
I don't think it's difficult to rearrange a list of certificates, or to
traverse a certificate path according to a local trust convention. Take
your pile of certificates (the ones in the message, and the ones you may
have lying around), shuffle them around, and see if you get something that
makes your trust code happy. The alternative that you're proposing takes a
static snapshot of the certificates needed to form a chain according to the
hierarchical model, and some of those certificates will expire, for
instance, which makes the chain invalid without the renewed certificates
(which could be present in a local cache, since they could be transmitted
in messages received after the original message that you are trying to
re-verify). The only benefit I see to the SET OF SEQUENCE is that in the
event that you are using a hierarchical model, you don't have to go through
the trouble of arranging the certificates yourself, and it separates the
different "leaf" certificates (enveloping and signing) and their associated
chains from each other. Each of these chains may have redundant
intermediate certificates I might add, which wastes a bit of space in
transmission.
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?
Yup -- that's what I'm paid for :). I think that creating work for the
receiver is a small price to pay when the alternative is a structure that
might break a future trust model. Extra work is Just More Code. An overly
restrictive specification can become unworkable, since it may not
accommodate all the possibilities.
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.
You certainly do need certs passed to you. How do you get certificates
initially? Through the extensive public key infrastructure that we enjoy
now? Sending certificates along with a message is a convenient (and
essential, in today's S/MIME world) way to do key distribution, even if you
have the local cert store.
Blake