Please see my comments embedded below.
=====================================
John Pawling, john(_dot_)pawling(_at_)wang(_dot_)com
Getronics Government Solutions, LLC
=====================================
-----Original Message-----
From: mkicksee(_at_)aepos(_dot_)adga(_dot_)ca
[mailto:mkicksee(_at_)aepos(_dot_)adga(_dot_)ca]
Sent: Friday, September 29, 2000 11:50 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: ESS Questions
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?
[JSP: Section 3.4.2 states: "A receiving agent SHOULD process the
ESSSecurityLabel before processing any EquivalentLabels. If the policy in
the ESSSecurityLabel is understood by the receiving agent, it MUST process
that label and MUST ignore all EquivalentLabels."]
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?
[JSP: Section 4.1. states: "A recipient MUST verify the signature of the
SignerInfo which covers the mlExpansionHistory attribute before processing
the mlExpansionHistory, and MUST NOT process the mlExpansionHistory
attribute unless the signature over it has been verified."]
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.
[JSP: This is subject to debate. I believe that the MLA should add a new
signerInfo including its mlExpansionHistory attribute and should preserve
the signerInfos that it can't verify. If the MLA omits the signerInfos that
it can't verify from the new signedData object, then that could cause mail
list expansion loops. For example, if an RSA-only MLA sends a message to a
DSA-only MLA which is expanding a mail list that includes the original
RSA-only MLA.]
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?
[JSP: Same answer as above.]
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?
[JSP: The MLA includes itself as the originator to support the use of key
agreement algorithms (such as static-static Diffie-Hellman or Key Exchange
Algorithm (KEA)) that require the originator's public key material to
generate the key encryption key.]
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.
[JSP: The fact that the original sender sent the encrypted message to the
MLA allows anyone with access to the MLA's private key to decrypt the
message.]
Also, the original sender can no longer decrypt copies of
the message that were routed.
[JSP: IF the original sender is part of the expanded mail list, then she
will receive a copy that she can decrypt.]
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.
[JSP: RFC 2634 already specifies that the original encrypted data must be
retained. If the original sender needs to decrypt the message sent by the
MLA, then the original sender should be included in the mail list, then she
will receive a copy that she can decrypt.]
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.
[JSP: The MLA must be trusted. It has access to the key material required
to decrypt every encrypted message that is sent to it.]
<snip>
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?
[JSP: You have misinterpreted the paragraph.]
5. Signing Certificate Attribute
Q. How does the signingCertificate attribute enhance the security of the
message?
[JSP: It can be used to indicate other certificates such as attribute
certificates or public key certificates that include additional information
(such as the sender's Clearance attribute) needed to process the message.]
<snip>
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.
[JSP: If the signingCertificate signed attribute is modified, then the
verification of the signature included in the signerInfo will fail.]
<snip>
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.
[JSP: I agree that the MLA should omit or replace the SigningCertificate
signed attribute in the signerInfo that it signs.]
<snip>