The concept of a secure mail lists comes from the Mail List Agent (MLA) defined by MSP and heavily used in the US DoD Defense Message System. In that system, messages are signed and encrypted, and sometimes there are many, many recipients. The processing power to generate thousands of recipient tokens is quite significant, and it takes a very long time. To eliminate this burden from the user’s email client, the MSP authors invented the MLA. The originator sends one message to the MLA, and then the MLA generates all the recipient tokens for the recipients, as shown in Figure 6-7.
Mail lists get interesting when there’s more than one MLA involved. These are called nested mail lists. Since you want to avoid the case where the mail lists end up sending messages in an endless loop, you also need to uniquely identify the mail lists, indicate which MLAs have handled the message, and set
Turner c06.tex V3 - 03/26/2008 5:34pm Page 119
Chapter 6 ■ Protecting Email Message Contents 119
Originator Recipient 1 Recipient n ... Originator MLA Recipient 1 Recipient n ...
Figure 6-7 Mail List Agent
receipt policies. When a MLA is about to expand the message for its recipients, it adds the ml-expansion-history attribute to provide this information. When the next MLA gets the message, it examines the ml-expansion-history attribute to detect and break loops. The ml-expansion-history attribute is identified by theid-aa-mlExpansionHistory object identifier, and it has the following syntax:
attr-mlExpansionHistory ATTRIBUTE ::=
{ MLExpansionHistory IDENTIFIED BY id-aa-mlExpansionHistory } id-aa-mlExpandHistory OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier SubjectKeyIdentifier } MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } ub-ml-expansion-history INTEGER ::= 64
The ml-expansion-history attribute may be in either an inner or outer layer, and it must be a signed attribute.
120 Part III ■ Secure Email
Algorithms
Algorithms supported by S/MIME have changed over time. Tables 6-2 through 6-5 provide a history of the hash, signature, key-encryption, and content-encryption algorithms from S/MIME version 2 (v2) through the latest proposed (soon to be approved) S/MIME documents. CMS, when it was origi- nally published, also included algorithms, and they matched those in S/MIME v3 specification. The algorithms were removed from CMS and placed in their own RFC, [RFC3370], so that every time an algorithm was changed it wasn’t necessary to perturb the baseline protocol document, which is much more stable.
Table 6-2 Hash Algorithms
ALGORITHM
DOCUMENT SENDING RECEIVING
S/MIME v2 SHA-1 SHOULD SHA-1 MUST
MD5 MUST
S/MIME v3 SHA-1 MUST SHA-1 MUST
MD5 SHOULD
S/MIME v3.1 SHA-1 MUST SHA-1 MUST
MD5 SHOULD S/MIME v3.2 SHA-256 MUST
SHA-1 SHOULD-
SHA-256 MUST SHA-1 SHOULD- MD5 SHOULD-
Table 6-3 Signature Algorithms
ALGORITHM
DOCUMENT SENDING RECEIVING
S/MIME v2 RSA MUST Same as sending
S/MIME v3 DSA MUST RSA SHOULD
Same as Sending S/MIME v3.1 RSA with SHA-1 or
DSA with SHA-1 MUST
DSA MUST RSA MUST S/MIME v3.2 RSA with SHA-256 MUST
RSA with SHA-1 SHOULD- RSA-PSS with SHA-256 SHOULD+ DSA with SHA-1 SHOULD- RSA with MD5 SHOULD-
Turner c06.tex V3 - 03/26/2008 5:34pm Page 121
Chapter 6 ■ Protecting Email Message Contents 121
Table 6-4 Key Management
ALGORITHM
DOCUMENT SENDING RECEIVING
S/MIME v2 RSA MUST Same as sending
S/MIME v3 E-S D-H1MUST RSA SHOULD
Same as Sending S/MIME v3.1 RSA MUST
E-S D-H1SHOULD
Same as Sending S/MIME v3.2 RSA MUST
RSA-OAEP SHOULD+ E-S D-H1SHOULD-
Same as Sending
1There are two popular modes of Diffie-Hellman: Ephemeral-Static (E-S D-H) and Static-Static (S-S D-H). When S-S D-H is used, both the originator and recipient have a static and certified key pair. When E-S D-H is used, the recipient has a static certified key pair, but the originator generates a new key pair for each message. It’s called ephemeral because it’s only used for that one message.
Table 6-5 Content Encryption and Key Wrap
ALGORITHM
DOCUMENT SENDING RECEIVING
S/MIME v2 RC2 MUST Same as Sending
S/MIME v3 Triple-DES MUST RC2 SHOULD
Same as Sending S/MIME v3.1 Triple-DES MUST
RC2 SHOULD
AES 128 CBC SHOULD AES 192 CBC SHOULD AES 256 CBC SHOULD
Same as Sending
S/MIME v3.2 AES 128 CBC MUST AES 192 CBC SHOULD+, AES 256 CBC SHOULD+ Triple-DES SHOULD-
Same as Sending
The switch from S/MIME v2 to v3 was done primarily because RSA Data Security held patents on the signature algorithm. Patented technology in a standard isn’t unheard of, but there were other unencumbered solutions avail- able, namely DSA. Almost immediately after these patents expired, S/MIME v3.1 was produced to return to the de facto standard algorithm. The proposed update will move to a new hash algorithm.
122 Part III ■ Secure Email
REQUIREMENTS TERMINOLOGY
[RFC2119] defines the terms that are used to indicate whether a protocol element or algorithm needs to be implemented. The terms, which are capitalized in Internet Drafts and RFCs, are:
MUST, SHALL, and REQUIRED. Implementation of this protocol element, algorithm, and so on is an absolute requirement.
MUST NOT and SHALL NOT. Implementation of this protocol element, algorithm, and so on is prohibited.
SHOULD and RECOMMENDED. Implementation of this protocol element, algorithm, and so on can be ignored in certain scenarios. However, the full consequences of not implementing it must be understood and care- fully weighed before choosing to not implement it.
SHOULD NOT and NOT RECOMMEND. Implementation of this protocol element, algorithm, and so on can be carried out in certain scenarios; however, the full consequences of not implementing it must be under- stood and carefully weighed before choosing to not implement it.
MAY and OPTIONAL. Implementation of this protocol element, algorithm, and so on is up to individual implementors.
Protocol specifications are living documents. You may have deduced that algorithms in the security protocol specifications get updated relatively often. To provide additional information to implementers many RFCs have started to use:
SHOULD+. This means the same things as SHOULD, but in the next version of the RFC it will likely be changed to a MUST.
SHOULD-. This means the same things as SHOULD, but in the next version of the RFC it will likely be changed to a MAY or removed.
MUST-. This means the same this as MUST, but in the next version of the RFC it will likely not be a MUST.
All of this is very necessary so that implementors know what it is they need to implement to achieve interoperable products from many different vendors.