Paul,
At 08:32 PM 9/16/97 -0700, Paul Hoffman / IMC wrote:
Greetings, all. During the S/MIME developers' meeting last week, we
discussed the open issues on the S/MIME message draft. We deferred
discussion of the cert draft until a special session last Friday, and there
will be a report about that in a few days.
Below is what people brought up as open issues. I've commented on what I
think the resolution for some of them should be, but all are open for
discussion.
** adding "no substitutions" profiles to SMIMECapabilities **
Right now, there is no way to say "anything you send me must match the
following capabilites"; instead, capabilities are suggestions, and are not
necessarily complete lists. There was a desire to add definitive profiles
that restricted clients could send out.
I don't think we need to address this in the document. Instead, we should
discuss this more on the mailing list, and add the desired profiles (if
any) to the OIDs list that is separate from the document. That way, if we
think of other profiles later, we can add them at will.
I'm not sure it falls into this category, but part of the discussion dealt
with the issue of "suites". In some cases (especially where hardware tokens
are involved) all possible combinations of digest, signature, encryption,
and keymgmt algs may not work - consequently, capabilities need to express
and handle combinations/suites.
** chosing an signing algorithm if there are multiple recipients **
We never explicitly tell people what to do if a sender is trying to sign
for multiple recipients. I propose we add:
If a sending agent is composing a signed message to a group of recipients
where the S/MIME capabilities of some of the recipients are not known, the
agent MUST use SHA-1 for the DigestAlgorithmIdentifier, rsaEncryption for
the DigestEncryptionAlgorithmIdentifier and
KeyEncryptionAlgorithmIdentifier, and multipart/signed for the MIME
encapsulation.
The other facet of this is what to do when encrypting a message for multiple
recipients with different capabilities - in particular a case when some
recipients handle only weak encryption. Should an implementation take the
"lowest common denominator", send multiple messages, exclude weak-only
recipients, engage the sender?
Dave