I have carefully and meticulously read through RFC2634 (Enhanced Security
Services for S/MIME), and have questions about various sections of it. Any
insight into these issues would be greatly appreciated.
3.4.2 Processing Equivalent Labels
Q. If an organization has a security policy that maps another organization's
security labels to its own, and also trusts a message sender to specify
equivalent security labels, and the two disagree (e.g. A sender applies Acme's
"Confidential" label and claims that this is equivalent to Widgets' "Private",
but Widgets' security policy states that Acme's "Confidential" is equivalent to
Widgets' "Secret"), which label should the receiving agent (or MLA) at Widgets
use for access control? Should the more restrictive of the two be applied?
4.1 Mail List Expansion
Q. A mail list agent must add its own mlData record to the mlExpansionHistory
attribute in the outer signed layer of the message, creating the
mlExpansionHistory attribute (and possibly the signed layer that contains it) as
needed. It must also check that all the mlExpansionHistory attributes that it
can verify are identical.
What happens if an MLA can't verify a particular signerInfo because it uses
an unknown algorithm? It cannot modify the mlExpansionHistory attribute in the
signerInfo, since it A) cannot trust it, and B) cannot generate the new
signature for it using the same algorithm. If it only modifies the signerInfos
that it can sign, they no longer match, and the next MLA that can verify all the
signerInfos will (correctly) reject the message, since the mlExpansionHistory
attributes won't match. The only solution would be to drop the signerInfo that
the MLA cannot verify, despite the fact that it may be valid.
Q. How should a mail list agent process a message if the only signerInfo in the
outer layer is signed using an unknown algorithm? Since it cannot verify the
signerInfo, it should not process or expand its mlExpansionHistory list. It
should not add an additional outer signature layer, since its attributes would
not include those of the previous outer layer. Replacing the existing (possibly
valid) signerInfo is not a good option either, since previous MLAs may have
specified attributes in it (e.g. lists of additional signed receipt recipients).
Should the MLA refuse to process the message?
4.2.3.1 Processing for EnvelopedData
Q. When re-encrypting a message (or its content-encryption key), why does the
MLA list itself as the message originator? This allows anyone with access to
the MLA's private key (e.g. the MLA's administrator) to decrypt any message it
has ever processed. Also, the original sender can no longer decrypt copies of
the message that were routed. If the original encrypted data is instead
retained, and the content encryption key (CEK) is extracted (using the MLA's
private key) and encrypted once for each recipient, the originator's copy of the
CEK could be left unchanged. Once processing is finished, the MLA would no
longer have access to the plaintext. If message archiving is required, the MLA
could save a copy of the message in an archive, encrypting the CEK for any
desired profile, not necessarily its own.
If it were not for the need to search for a security label, this approach
would avoid the need for the MLA to extract the plaintext of the message at all,
and it would only require the (much smaller) CEK briefly. The MLA would not
even need to know the algorithm used to encrypt the message, merely its OID and
parameters.
4.2.3.2 Processing for SignedData
Q. Step 2 of this process has been changed from the Internet draft version
(draft-ietf-smime-ess-09.txt). It seems that now if the "outer" signed data
layer is absent or does not contain an mlExpansionHistory attribute, the MLA
simply adds a new outer signed layer, lists itself in the mlExpansionHistory
attribute, and sends the message to the recipients. It would no longer expand
any encrypted data for the recipients. If someone sent a message that was
encrypted then signed to the MLA, the recipients would not be able to decrypt
it. Have I misread this paragraph?
5. Signing Certificate Attribute
Q. How does the signingCertificate attribute enhance the security of the
message?
The signingCertificate attribute is signed. Therefore, before a receiving
agent should trust its value, it must verify the signature. To verify the
signature, it must locate the signer's certificate and those of all issuers in a
chain until it finds a trusted root certificate. As the receiving agent has
already located the certificates required to verify the signature, of what use
is the signingCertificate attribute? This is a Catch-22 situation, since the
required information is only of use when it is unavailable.
Using the signingCertificate to identify authorization certificates is no
better. If the signature on the attribute is not trusted, then the policy also
cannot be trusted and should be ignored. If the signature on the attribute has
been verified, and the authorization policy indicates that the signature is not
to be trusted under current circumstances, the policy has already been violated.
In fact, the signature should not be trusted to identify the policy that
indicates that the signature should not be trusted, and again the policy should
be ignored. This is also a Catch-22 situation.
An attacker attempting one of the attacks mentioned in this section could
replace both the signingCertificate attribute and the certificate, signing the
attribute with the new certificate. The recipient would have no way of
detecting this, and may be lulled into a false sense of security by the presence
of the (substituted) signingCertificate attribute.
The only use I can see for this attribute would be in a case where the
signature is intended to be used for (as an example) data integrity but not
non-repudiation (e.g. a server securing data in transit). In this case, an
attribute certificate might identify the usage intended, and the
signingCertificate attribute could identify the attribute certificate. This
could be achieved more simply either by including the signing certificate's
intended uses in the certificate itself, or by a statement (or disclaimer)
placed in the signed message itself by the sender stating the intended use of
the signature (e.g. "I am signing this message for data integrity purposes. I
do not warrant that the information it contains is accurate.").
5.4 Signing Certificate Attribute Definition
Q. SigningCertificate is a signed attribute. An MLA processing a message is
supposed to copy the values of all the signed attributes in the outer signature
layer when applying or replacing a signature layer. Shouldn't the
signingCertificate attribute be omitted from this? It would refer to the
previous MLA's certificate, not the current MLA's. Also, an MLA may require the
signingCertificate attribute for its own signature, and (since there can be only
one signingCertificate attribute in the signerInfo) would not be able to include
its own if it copied the previous MLA's signingCertificate attribute.
5.4.1 Certificate Identification
Q. Why must SHA-1 be used for generating the hash value of the certificate?
Some agents may only process other algorithms (e.g. MD5). Also, someone may
develop other (possibly superior) hash algorithms in the future, which might
become the new required standard. Why isn't there a field in the ESSCertID to
identify the algorithm used?