ietf-smime
[Top] [All Lists]

RE: SMIMECapabilities Attribute

1997-10-16 05:20:35
Jim:

I agree.  Pointing to a certificate in the existing PKCS#7 "bag of
certificates" is better.

Russ

At 12:56 AM 10/8/97 -0700, Jim Schaad (Exchange) wrote:
I have massive complaints about having two (or more) cert chains for the
purpose of conveying the difference between key exchange and signing
certs.  The overhead of carrying multiple chains (almost a certanty for
some products) is really bad in terms of message size.  This is
especially true given the current size and expected size of
certificates.  

I have no specific objection to an authenticated property which say --
this is what you should use for my key exchange certificate, but I see
no real value in any more than this.  The process of building
certificate chains for verification needs to be done any event as one
cannot rely that the chain provided will be either correct or useful any
more  (certificates in the chain may have expired or been revoked).  

jim


-----Original Message-----
From:        Blake Ramsdell [SMTP:BlakeR(_at_)deming(_dot_)com]
Sent:        Tuesday, October 07, 1997 4:10 PM
To:  'Russ Housley'
Cc:  'ietf-smime(_at_)imc(_dot_)org'
Subject:     RE: SMIMECapabilities Attribute

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


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