ietf-smime
[Top] [All Lists]

Open issues in the message draft

1997-09-16 20:30:18
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.

** signedData vs. application/mime wording**

Section 3 talks a lot about what to do if the sender thinks that a signed
message will go through a gateway that will separate or change the message.
This has long been a contentious issue. Of the three implementations I know
of, Microsoft and Netscape never use either of the two protection
alternatives, and Deming will only send out signedData (I think).

My proposal, which wasn't all that well received, was that we move the
whole discussion to a short appendix that covers just what the two options
are, the brief advantages and disadvantages of each, says that as of today
no one has tested application/mime, says that receiving agents SHOULD
accept both, and you make your own decision. This does describe what the
current practice is, so it's an honest approach. It also lets implementors
figure out what works best for them. Let's remember that this a very
transport-related issue for a protocol that is supposed to be
transport-independent.

If you have a different idea of how to deal with the issue, please speak up!

** signing time**

Currently, signing time in 2.5.1 says it must be UTCTime, which is not Year
2000 compliant. (Can we all say "duh"?) The proposed solution is to use the
same method that PKIX part 1 does for certificates. I propose that the
wording in our draft be:

Sending agenst shall always encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later shall be encoded as GeneralizedTime.

** adding a "doesn't accept encryption" SMIMECapabilities **

Some not-quite-S/MIME agents can only send and receive signed messages, not
encrypted ones, due to legal and technical reasons. It was generally agreed
that we should add an attribute to SMIMECapabilities that indicates that
the recipient can't decrypt any kind of message.

I propose adding the following to the "Miscellaneous" parameters:

canNotDecryptAny OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 2}
        (No parameters. In the event that this OID is present, then every
        effort should be made not to send this recipient any encrypted
        message.)

** 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.

** change "handle and display" to "handle" **

It was pointed ouot that some places in the document, we tell agents to
"display" things. Of course, not all agents can display. I've changed all
instances of "handle and display" to "handle".

** 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.

** signed content inside of envelopedData **

There was a question about whether we should recommend that if a message is
going to be signed then encrypted, the signed message should use signedData
since it is known that the recipient must have S/MIME. However, many
recipient systems are multi-staged cryptography engines, and it is not
always the case that the same system that decrypted the message will be
checking the signature. I think 3.5 says enough about this, but am open to
suggestions on additional wording.

--Paul E. Hoffman, Director
--Internet Mail Consortium



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