Subject: ESS Questions

From: [email-masked]
Date: Fri, 29 Sep 2000 11:50:13 -0400

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?

---

From: "Pawling, John" <[email-masked]>
Date: Fri, 29 Sep 2000 14:51:24 -0400

Please see my comments embedded below.

=====================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
=====================================

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 29, 2000 11:50 AM
To: [email-masked]
Subject: ESS Questions

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

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>

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

[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>

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>