On Tuesday, October 07, 1997 7:15 AM, Russ Housley
[SMTP:housley(_at_)spyrus(_dot_)com] wrote:
So, you suggest that key management certificates be carried in the existing
SET OF ExtendedCertificateOrCertificate. This is fine with me.
I had to think about this for a couple of minutes (I'm thick sometimes).
The optional certificates field in SignedData can contain any
certificates -- it is not limited to the signing cert chain at all, so
it is perfectly acceptable to put your key exchange cert chain in here
also. We can change the language in the spec to specify this also.
What made me start thinking was that a criticism in the past has been
that dumping a bunch of certificates in a pile is not as useful as
assigning some kind of structure. I think it bears thinking about
having two separate authenticated attributes, one for the key exchange
cert chain and one for the signing cert chain. For instance:
SMIMESigningCertChain ::= SEQUENCE OF Certificate
SMIMEKeyExchangeCertChain ::= SEQUENCE OF Certificate
This way, there is a clear separation between the certs that are used
for signing and the certs used for enveloping. The downside is that if
there are any common certs in the chain (for the same PCA in a
hierarchy, for instance), then these will be transmitted redundantly.
Jeff's point is a valid one also (not the one I was trying to make,
however... I'll take credit for it, though.) -- if the goal is to be
able to specify what exactly is the enveloping cert for the signer of
the message, you can dump that cert in the existing certificates member
of SignedData, and then have an authenticatedAttribute that specifies
the issuerAndSerialNumber (or whatever -- that's something else that
needs to be finalized) of the cert to use for enveloping. My original
point was to include the actual certs (as I mentioned above) -- not a
reference.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060