Greetings again. There were a bunch of requests for changes to the ESS-10
draft in IETF last call (which ended yesterday). The following is the list
of changes I intend to make in -11, which will then hopefully be sent by
Jeff Schiller to the IESG. Blake and Russ will be sending out similar lists
soon.
If there are any issues that were posted to the list that I missed (or got
wrong), please let me know in the next day or two. Please note that all of
these were already discussed on the list, so new requests at this very late
date might be frowned upon...
D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11
1: Added wording about signing certificates (Section 5) to the introduction.
1.3.4: Added the sentence at the end of the first paragraph. "All of the
attributes defined in this document, other than ContentHints and
ContentIdentifier, MUST be carried in a CMS SignedAttributes type, and MUST
NOT be carried in an UnsignedAttributes or an UnprotectedAttributes type."
1.3.4: Removed the macValue description because it was removed from CMS.
1.4: Second paragraph, replaced second sentence to indicate that some
attributes might have to be omitted. "The main disadvantage is that the
gateway must check for the presence of certain attributes in the other
signerInfos and either omit or copy those attributes."
2.1: Added paragraph at the end of this section saying that you shouldn't
request that receipts be sent to people who don't have the original
message. "A receipt request can indicate that receipts be sent to many
places, not just to the sender (in fact, the receipt request might indicate
that the receipts should not even go to the sender). In order to verify a
receipt, the recipient of the receipt must be the originator or a recipient
of the original message. Thus, the sender SHOULD NOT request that receipts
be sent to anyone who does not have an exact copy of the message."
2.6: Added paragraph near beginning about accepting more than one signed
receipt. "Although receipients are not supposed to send more than one
signed receipt, receiving agents SHOULD be able to accept multiple signed
receipts from a recipient."
2.8: Changed Version to ESSVersion and defined it as:
ESSVersion ::= INTEGER { v1(1) }
3: Clarified the last paragraph to indicate ranked levels. "The labels
often describe ranked levels..."
4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was not
found, you sign that whole message and stop.
4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]"
5.1: Changed "changing" to "replacing".
5.4: The paragraph beginning "The first certificate..." was changed to
reflect the addition of the SKI to the SignerInfo. "The first certificate
identified in the sequence of certificate identifiers MUST be the
certificate used to verify the signature. The encoding of the ESSCertID for
this certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in the
SignerInfo, the issuerSerial field MAY be omitted. The certificate
identified is used during the signature verification process. If the hash
of the certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid."
5.4.1: Changed "CMS" to "[CERT]" for the reference.
6: Entire section is new:
==========
All security considerations from [CMS] and [SMIME3] apply to applications
that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not send
back a reply if it cannot validate the signature. Similarly, if there
conflicting receipt requests in a message, the recipient must not send back
receipts, since an attacker may have inserted the conflicting request.
Sending a signed receipt to an unvalidated sender can expose information
about the recipient that it may not want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to prevent a
passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a
security label to a message will prevent recipients from viewing messages
the sender doesn't want them to view. It is expected that there will be
many S/MIME clients that will not understand security labels but will still
display a labelled message to a recipient.
A receiving agent that processes security labels must handle the content of
the messages carefully. If the agent decides not to show the message to the
intended recipient after processing the security label, the agent must take
care that the recipient does not accidentally see the content at a later
time. For example, if an error response sent to the originator contains the
content that was hidden from the recipient, and that error response bounces
back to the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message will
have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to an
attacker if that attacker has a signature that can be validated by the
recipient. The attack consists of intercepting the original message and
adding a mLData attribute that says that a receipt should be sent to the
attacker in addition to whoever else was going to get the receipt.
Mailing lists that encrypt their content may be targets for
denial-of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite
easy to subscribe one encrypted mailing list to another, thereby setting up
an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles for
the the adaptive chosen ciphertext attack described in [CMS]. MLAs should
notify an administrator if a large number of undecryptable messages are
received.
When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously
known to be valid, or certificates that have come from a signed
SigningCertificate attribute. Otherwise, the attacks described in Section 5
can cause the receiver to possibly think a signature is valid when it is
not.
==========
--Paul Hoffman, Director
--Internet Mail Consortium