Blake:
So, you suggest that key management certificates be carried in the existing
SET OF ExtendedCertificateOrCertificate. This is fine with me.
We need to say that this SHOULD be done.
Russ
At 09:57 PM 10/5/97 -0700, Blake Ramsdell wrote:
I agree that from a convenience point of view, an authenticatedAttribute
containing the key exchange certificate would be a useful thing.
However, it can be accomplished (however clumsily) by using the generic
"bag o' certs".
We are free to implement other authenticatedAttributes, and perhaps the
use of the "bag o' certs" should be deprecated in favor of specifying
two new authenticatedAttributes that can each contain a "bags o' certs"
-- one containing the chain of certificates for validating signed
messages for this sender, and one containing the chain of certificates
for enveloping messages for this sender. Of course, we would specify
this as a SEQUENCE OF and not a SET OF. Don't go there.
Placing this under SMIMECapabilities makes me feel a bit icky, but we
can do it that way if desired. I like the general idea, however, of
placing these somewhere in the authenticatedAttributes.
Blake
-----Original Message-----
From: Russ Housley [SMTP:housley(_at_)spyrus(_dot_)com]
Sent: Saturday, October 04, 1997 2:53 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: SMIMECapabilities Attribute
The current definition of the SMIMECapabilities Attribute allows the user
to state their preference for key management algorithm. I think that it
would be very useful for the user to OPTINALLY include their key management
certificate with this preference.
Today, there is not a ubiquitous Directory available, so people need to
distribute their certificates by other means. By including the key
management certificate in the SMIMECapabilities Attribute, sending a signed
message allows the recipient to respond with a signed and encrypted
message. This is a nice bootstrap mechanism that works will in a Directory
impaired environment.
What do ya think?
Russ