380624 - ESS: Triple Wrapping (RFC2634 - 1.1)

Status: NEW

(MailNews Core :: Security: S/MIME, enhancement)

Description

[BALLET BAZ Eric]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: version 2.0.0.0 (20070326)

This patch implements the triple wrapping functionnality (RFC2634 - 1.1 http://tools.ietf.org/html/rfc2634#section-1.1)

A triple wrapped message is one that has been signed, then encrypted, then signed again.

This is the part of the following feature list:
http://www.mozilla.org/projects/security/pki/nss/smime/

and is been developped for the milimail project :
http://www.milimail.org/milimailfr/index.php/Triple_wrapping_user

This patch is based on the sources THUNDERBIRD_2_0_0_0_RELEASE

Reproducible: Always

Comment 1

[BALLET BAZ Eric]

Attachment: Triple Wrapping patch

Comment 2

[BALLET BAZ Eric]

Attachment: Icons for triple wrapping

Comment 3

[David :Bienvenu]

Cc'ing Kaie since this has to do with S/MIME, and Nelson in case he's interested.

For review, a -uwp diff would be helpful, so we can ignore the whitespace changes.

There's a few files in the diff that are missing the trailing newline - can you add those?

In general, for the compose code, we prefer not adding braces for single statement ifs, i.e.,

if (a)
  statement;

instead of 
if (a) {
  statement;
}

Otherwise, at first glance, this looks like a pretty clean patch.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Random comments about this patch.
0. First, THANKS for working on this!  It's gratifying to see that people
   still care about SMIME, enough to contribute to it.  

1. ISO-Latin-1 characters in c code.  Some compilers reject that, IINM.  

2. On some files, the line ending (e.g. \n, \r\n) has changed for every
   line in the file, making it appear that the entire fila was rewritten.
   Unless there's an unusually good reason to do that, we should avoid it.
   Affects msgHdrViewSMIMEOverlay.xul, msgReadSecurityInfo.xul, maybe others.

3. There's a large UI change in this patch.  As I understand it, there are
   UI review steps involved. (Maybe that's only for FireFox?).  Whether such
   review is formally required or not, I ask that you please attach .gifs
   showing before and after images of the windows, dialogs, panes that are
   changed, so that we can visualize the proposed change.

4. I'm quite surprised that this change could be done without any changes to
   NSS.  I expected triple wrapping would involve changes to libSMIME.
   I'm trying to decide if it's a good thing that NSS isn't changed.
   Do we want every application that uses libSMIME to have to be changed in
   this way?  Would there be less duplication of effort among applications
   if this was done in NSS rather than in the application?

Comment 5

[BALLET BAZ Eric]

Attachment: Triple Wrapping patch

Work in Progress patch v0.2

Changes since v0.1:
* Trailing newlines added
* Whitespaces cleaned
* Braces for single statement ifs removed
* ISO-Latin-1 characters removed
* Line endings cleaned

Comment 6

[BALLET BAZ Eric]

Attachment: Screenshots showing before and after images of modified UI screens

Each screenshot shows before and after images of a modified UI screen. Modifications are highlighted with red circles.

Comment 7

[BALLET BAZ Eric]

Nelson,
to answer your 4th point about changes to NSS, triple wrapping is the process to sign, encrypt and sign a message. So, since NSS provides the possibility to sign or encrypt a message, I almost only needed to call theses functions in the correct order.
I don't see how you could integrate this in NSS...
Furthermore, this functionnality has no meaning for applications other than mailing.

Comment 8

[David :Bienvenu]

Comment on attachment 264868 [details] [diff] [review]
Triple Wrapping patch

+{
+  *_retval = mTripleWrapMessage;

Need an NS_ENSURE_ARG_POINTER(_retval) here;

the rest, I'm going to ask Kaie for a review, since it's really an s/mime patch

Comment 9

[Kai Engert (:KaiE:)]

Some first comments from me, and a lot of questions. Not all questions are really technically, but more related to the UI.


Question: What happens when a triple wrapped message gets sent to an old S/Mime application, which supports nested S/Mime message, but is not aware of triple wrapping? Will such an application be able to decode and display the message?


I am very happy that your patch is for both the Thunderbird and the SeaMonkey UI!


I am worried about exposing the term "Triple Wrapping" in the user interface.
I think the term "Triple Wrapping" is the technical term used to describe this procedure, but is the term appropriate for end users?
What is the real purpose for end users?
Should the user interface use a term that is closer to the problem that triple wrapping is trying to achieve?
Would a correct term be "Message Integrity Verification"?


Might it be sufficient to have the "use triple wrapping" in the message account prefs?
When composing an email, why would a user turn on/off triple wrapping for an individual message?


When reading a received email, what is the purpose of displaying the "message was triple wrapped" status as an Icon?
When the message was successfully tested to have a correct outer signature, we could define, it is just a technical detail that helped us verifying the received message is correct.
Does it make sense to say:
- if the outer signature is broken, of course, let's display that error in the UI
  (and probably do not attempt to process the inner parts)
- if the outer signature is good, do not display a triple wrapping status
  icon in the primary message window,
  but it's ok to make that status available in the secondary "message status" window.


Your patch is against the stable 1.8 branch. I understand that this might have been easier as a base for your development.
But please note, we will not add new features to the Mozilla 1.8 / Thunderbird 2.0 branch, it's only an option for the future versions.
When trying to apply your patch against the latest development version, I get a couple of conflicts.
So, please switch your work to Mozilla's latest development code (trunk, 1.9) before attaching the next round of patches.


Just curious, will your patch allow to view the details attributes / signing cert of the outer signature?


Please do not yet work on a new patch, first I'd be interested to hear some thoughts on my questions.
Thanks!

Comment 10

[BALLET BAZ Eric]

>Question: What happens when a triple wrapped message gets sent to an old S/Mime
>application, which supports nested S/Mime message, but is not aware of triple
>wrapping? Will such an application be able to decode and display the message?

Yes, the native Thunderbird is able to decode a triple wrapped message because the S/Mime lib is recursive. You can wrap a message with as many signatures and encryptions as you want, and it stills work !


>I am worried about exposing the term "Triple Wrapping" in the user interface.
>I think the term "Triple Wrapping" is the technical term used to describe this
>procedure, but is the term appropriate for end users?

If you prefer, we can replace this label by something like "Sign, encrypt and sign" ... but "Triple wrapping" is the official term from the RFC, and I think the users will be aware of this term in the future.


>What is the real purpose for end users?
>Should the user interface use a term that is closer to the problem that triple
>wrapping is trying to achieve?

For more details on the purpose of triple wrapping, you can have a look at chapter 1.1 here :
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

Triple wrapping fixes the 'Surreptitious Forwarding' security problem. Also when used with signed receipt this is a garantee that the user was able to decode the message.


>Would a correct term be "Message Integrity Verification"?

Not really I think ...


>Might it be sufficient to have the "use triple wrapping" in the message account
>prefs?
>When composing an email, why would a user turn on/off triple wrapping for an
>individual message?

The UI has been updated to match the same options as sign or encrypt. As for sign or encrypt, the user may want to toggle this at different preference levels.


>When reading a received email, what is the purpose of displaying the "message
>was triple wrapped" status as an Icon?
>When the message was successfully tested to have a correct outer signature, we
>could define, it is just a technical detail that helped us verifying the
>received message is correct.
>Does it make sense to say:
>- if the outer signature is broken, of course, let's display that error in the
>UI
>  (and probably do not attempt to process the inner parts)
>- if the outer signature is good, do not display a triple wrapping status
>  icon in the primary message window,
>  but it's ok to make that status available in the secondary "message status"
>window.

This icon garantees to the user that the message has not been altered, and this is the same mechanism as for sign or encrypt. The user might be interested by this specific status, since it's an additionnal proof of high security.


>Your patch is against the stable 1.8 branch. I understand that this might have
>been easier as a base for your development.
>But please note, we will not add new features to the Mozilla 1.8 / Thunderbird
>2.0 branch, it's only an option for the future versions.
>When trying to apply your patch against the latest development version, I get a
>couple of conflicts.
>So, please switch your work to Mozilla's latest development code (trunk, 1.9)
>before attaching the next round of patches.

I'll see what we can do about this, but this is a lot of works for us to maintain two releases ...


>Just curious, will your patch allow to view the details attributes / signing
>cert of the outer signature?

This is not the purpose of this patch, but this is clearly a missing functionnality. This is also needed for signed receipt (https://bugzilla.mozilla.org/show_bug.cgi?id=386313) and for Security Labels, so it can be done in a separate patch.

Comment 11

[BALLET BAZ Eric]

Attachment: Triple Wrapping patch

Work in Progress patch v0.3

Changes since v0.2:
* Rebuild the patch against the trunk
* Adding NS_ENSURE_ARG_POINTER(_retval)

Comment 12

[David :Bienvenu]

Kaie, any further thoughts on this patch? Eric, is this still a work in progress?

Comment 13

[BALLET BAZ Eric]

For me this patch is complete and ready for integration.

Comment 14

[Dirk-Willem van Gulik]

Tested (osx, freebsd) and works marvelously 'as is'. And would be useful to have even without (https://bugzilla.mozilla.org/show_bug.cgi?id=386313) done.

Comment 15

[Ludovic Hirlimann [:Usul]]

Kaie : ping ?

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 275096 [details] [diff] [review]
Triple Wrapping patch

This is mailnews code.  It needs review by the Mailnews folks.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 264870 [details]
Screenshots showing before and after images of modified UI screens

This actually needs ui-review before the patch proceeds to code-review; requesting.

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 264870 [details]
Screenshots showing before and after images of modified UI screens

I'll assume that the term "Triple Wrap" is the best available term we have though it seems like a shift in terms might be necessary.  Possibly changing/downgrading the first encrypt to something like this: "Encrypt Message Body", "Sign Message", "Encrypt Entire Message".  I think we could work the terms as we move forward.

Thanks so much for providing comparison screenshots!  This is really amazing.  I'll go through the screenshots one by one.

account_settings.gif

I would take more space for the Triple Wrapping to help explain it. Possibly using a new section for it.  Though the triple wrapping is about a final layer of encryption the Encryption section we currently have is really just about choosing a cert and setting the defaults for encrypting the message body.

Here's an example using my wording from above, which doesn't have to be final.

.--- Triple Wrap Encryption ----------------------------------------
|
|  Triple Wrapping encrypts the entire message, both the encrypted body and 
|  signature of the message, preventing a method known as 
|  'Surreptitious Forwarding'.  <a>more information</a>
|
|  [ ] Encrypt Entire Message (Triple Wrap) by default
|      /this requires both a certification for signing and encryption/
|
'------------------------------------------------------------------

message_compose1.gif

Looks good.  Only depends on agreed wording changes.

message_compose2.gif

Looks good.  Only depends on agreed wording changes.

message_read.gif

I feel like we need to do something else for the icon.  In general I'd like to see a revamp of those icons.  Valid Signature and Encryption should be a single icon.  I'd recommend a similar situation for the Triple Wrap being a stronger version of that single icon.

This part needs lots of work in general so I'm not sure where to start and don't want to block this effort on getting the sig/encrypt/3w indicators correct.  Perhaps a new bug should be filed for that.

message_security1.gif

Looks good.  Only depends on agreed wording changes.

message_security2.gif

Looks good.  Only depends on agreed wording changes.

Comment 19

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 264870 [details]
Screenshots showing before and after images of modified UI screens

setting to minus for now, my comments are in comment #18

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

Comments.

> Triple Wrapping encrypts the entire message, both the encrypted body and 
> signature of the message, preventing a method known as 
> 'Surreptitious Forwarding'. 

Triple wrapping doesn't prevent Surreptitious Forwarding.  
It makes Surreptitious Forwarding detectable by the recipient.

IMO, it's OK for the sender to be given a choice of "triple wrap" or not.
That is, it's OK to use the words "triple wrap" to name the choice that the
sender has to make.  

But on the recipient's end, the important detail to explain to the recipient 
is neither "this message was triple wrapped", nor "this message was not 
triple wrapped", but rather is more like one of the following:

"This encrypted message was encrypted and sent to you by the same person who 
signed the original message content (before it was encrypted)", 
or 
"This encrypted message was encrypted and sent to you by SOMEONE OTHER THAN
the person who signed the original message content (before it was encrypted).
The signer of the original message may or may not have intended for it to be
sent to you."  
or
"It cannot be determined if the signer of the original message was the person
who sent this message to you.  The signer of the original message may or may not have intended for it to be sent to you." 

I don't think that message can be adequately conveyed by the presence or 
absence of the characters "3W" inside a lock icon, nor by the presence or
absence of the proposed phrase 
  This message was triple wrapped before it was send to you"
nor by the presence of the words "yes" or "no", as in the proposed UI:
  Triple Wrapped: Yes  

If anything, for triple-wrapped messages, we need to show the recipient 
the names of both the "inner" and "outer" signers of the message, especially 
if they're different.

Comment 21

[Ludovic Hirlimann [:Usul]]

We need a new patch that deals with the ui-review.

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 275096 [details] [diff] [review]
Triple Wrapping patch

We need a patch that passes UI-review before we move on to code review.  Removing review-requests.

Comment 23

[Raphaël Fairise]

Here is a patch for comm-central which provides RFC 2634 S/MIME Triple Wrapping for Thunderbird and Seamonkey.
This is Eric's patch updated and adapted to comm-central.

The patch is split in 3 parts:
* patch-smime-3w-backend.diff
* patch-smime-3w-ui.diff
* patch-smime-3w-skin.diff

(These patches have been updated with comm-central as of 2010/09/15)


Screenshots are available here (in comm-central section):
http://adullact.net/plugins/mediawiki/wiki/milimail/index.php/Triple_Wrapping

This patch is NOT ready for integration as it does not handle UI issues pointed out by previous comments, mainly:
- display inner and outer signatures in the UI
- display different messages depending on the status of both signatures
- determine what texts/icons need to be displayed

If somebody wants to work on this issue, I don't think that there is still a lot of work to do.

Comment 24

[Raphaël Fairise]

Attachment: patch-smime-3w-backend.diff

Comment 25

[Raphaël Fairise]

Attachment: patch-smime-3w-ui.diff

Comment 26

[Raphaël Fairise]

Attachment: patch-smime-3w-skin.diff

Comment 27

[Kai Engert (:KaiE:)]

I finally took the time to look at this again.
Thanks a lot for comment 10, especially the link was very helpful.

I will write a series of separate comments, so it's easier to refer to them.


First, some thoughts related to the "attack" which this work is trying to prevent.

I think the effect of 'Surreptitious Forwarding' is not easy to achieve when using the regular features of email clients.

When forwarding a signed message, Thunderbird will:
- either forward as attachment, 
  and the attachment will include information about original sender and recipient.
- or, When forwarding "inline", the original signature will be lost.

'Surreptitious Forwarding' probably requires the use of special email clients (or even low level manipulation tools), which will strip away the message envelope information from an original signed message.

However, even though it's difficult to do, I agree and understand it's a good idea to make it impossible.

Comment 28

[Kai Engert (:KaiE:)]

I would like to recommend to focus this work on the intended purpose.

I mostly agree with Nelson's comment 20, and I think more attention should have been given to it.
In will elaborate with greater detail, and I will make more constructive proposals.

Bryan said in comment 18
> I'll assume that the term "Triple Wrap" is the best available term we have ...

In my understanding and opinion, this is not true.
The term "triple wrapping" is a very technical term, but does not help most users to understand what's going on.

(Even if the term triple wrapping eventually became more commonly known to experienced users, it's purpose were still not naively understandable for most users.)

Many users are able to understand the concepts of "signing" and "encryption".
We should find another easily understandable explanation of triple wrapping.

A "message is signed" means, the person listed in the signing cert really produced this message.
A "message is encrypted" means, it is known who are the intended recipients of a message.

But these are separate steps. When receiving a message that is both signed and encrypted, the claim is, most users will simply conclude that I (the recipient) is an intended recipient of the original signed message. But this conclusion can be wrong, because someone might have wrapped a signed-only message, which has been originally send to someone one.

In my opinion:

=============================================================================
The intention of triple wrapping 
is to confirm the list of intended recipients of the original signed message,
as intended by the signer of the original message
=============================================================================

The list of intended recipients is contained in the encryption layer.
By signing the encrypted layer (using the outer signature, which is the third S/MIME layer), the signer confirms the list of recipients intended by the signer.

Comment 29

[Kai Engert (:KaiE:)]

Unfortunately, introducing triple wrapping, technically, introduces the possibility for new manipulations, tricks or attacks.

Some bad person might have received a signed-and-encrypted message. The bad person could use their own certificate to add a triple-wrapping outer layer.
When receiving such a message, the message is technically triple wrapped.

In my opinion, verifying that a valid outer signature is present is NOT SUFFICIENT for showing the triple-wrap indicator icon.
I think it is very important that the mail program does additional verification steps before displaying such an icon.

What additional verification?

==========================================================
Only if the inner signature and the outer signature 
have both been created using the same signing certificate, 
only then we can conclude,
that a recipient (who is able to decrypt the message)
is also an *intended* receipient of the signed message.
==========================================================

If the inner and outer signature meet this constraint,
then it's fine to show an indicator icon for triple wrapping.

If the inner and outer signature were created using different certificates,
we should not show such an icon.

It is debatable whether to show an icon such as "incorrect triple wrapping".
Not sure about this.

In my opinion, such an icon is not very helpful,
because the absence of triple wrapping is essentially identical to 
the presence of a "bad" triple wrapping icon.

In the presence of a bad triple wrapping, maybe the classic signature icon should be weakened? (signature with question mark maybe?)

Of couse, the "message security info" dialog should explain in detail
what's going on, and if different, should allow to inspect 
both signing certs that are involved.

Maybe the attached patches already make this assumption, I have not checked.
I am explaining this in detail, in order to make it easier for Bryan and other people to participate in the discussion how the UI should look like.

When displaying a classic, "double-wrapped" message, our extended information might say something like "Can not verify you as an intended recipient of this message".
When displaying a triple wrapped message, with matching inner and outer signatures, our extended information could say "This message has been encrypted and signed, and it is verified that you are an intended recipient."

Comment 30

[Kai Engert (:KaiE:)]

So, what icon could be used to visualize triple wrap?

In my opinion, the proposed "3W-signature" icon does not carry that information.
I would rather invent a new combined icon, that essentially means "Verified as intended for you". 

What about an icon that shows the following?

  (human) -> (human)
   green checkmark

Comment 31

[Kai Engert (:KaiE:)]

Regarding configuration preferences

Do you agree that triple wrapping only makes sense if inner and outer signatures are producing using the same certificate?

If you agreed, would it still make sense to offer selection of the signature certificate as a separate preference?

Should we rather offer a checkbox that enables/disables triple wrapping, and, whenever the checkbox is checked, we simply use the same signing certificate for both inner and outer signature?

Comment 32

[Kai Engert (:KaiE:)]

Comment on attachment 475825 [details] [diff] [review]
patch-smime-3w-ui.diff

I'm removing the request-review flags, I think this first needs some more discussion.

Comment 33

[Nelson Bolyard (seldom reads bugmail)]

Kai, I disagree with your conclusion in comment 28, where you wrote:
> The intention of triple wrapping is to confirm the list of intended 
> recipients of the original signed message, as intended by the signer 
> of the original message

That goal cannot be reached with SMIME (CMS) as defined now, so I think it is
not the goal of the present SMIME/CMS design.  The reason it cannot be reached
is that the signed attributes of signed messages include nothing that
identifies the recipients.  Only encrypted messages identify the recipients.
A "signed and encrypted" message is a signed message wrapped inside an 
encrypted message.  There's no way to tell if the recipients of the original
signed message are the same as the recipients of the encrypted message.  

Triple wrapping doesn't change that.  Triple wrapping tells you nothing about
the recipients of the original (innermost) signed message.  It can ONLY tell
you if the signer of the original message is the same as the signer of the 
encrypted message.  

Triple wrapping cannot tell you if the list of recipients of the outer triple wrapped message is the same as the list of recipients of the innermost message.
As a sender of a triple wrapped message, I can send an original signed but not
encrypted to one user (Alice), then encrypt it for sending a second user (Bob)
and sign it again.  I am the same signer in both cases, but the set of recipients is different for the inner and outer message.  

So Triple wrapping CANNOT tell any recipient that "The original inner message was meant for you when it was sent".  It can only tell you if the signer of 
the original message was the same as the signer of the outer message.  If they
are the same, then you (the recipient) know that the signer of the original 
message really did intend to send it to you, because he is also the signer of
the message you received.  It tells you nothing about whether the original 
message was originally sent to you first, or whether sending to you was an 
afterthought.  

One consequence of this is that I can write a message that appears on its face
to have been written to Alice and Bob, and sign it, but never send it to Alice.
Then I encrypt it to Bob and sign the copy I send to Bob.  The result is that
Bob gets a message that APPEARS to have been intended for both Bob and Alice, and Bob still has no assurance that it was actually send to Alice.  Bob only
knows that *I*, the author of the original, meant to send him the copy he received. 

This is why the UI must be VERY CAREFUL to present the right message about 
what the recipient may correctly infer from the fact that the message was 
triple wrapped and both signers are the same.

Comment 34

[Kai Engert (:KaiE:)]

Nelson, I agree with your comment 20 from 2009.

My comment 28 is an attempt to provide a simple description of the intention of triple wrapping.

If you disagree with my words, would you like to make an attempt to phrase the intention of triple wrapping?

(I'm not asking for the initial intention that the designers of triple wrapping had in mind. Rather, I'm asking, in your opinion, what is the benefit of using triple wrapping for a sender and a recipient, as currently described by the RFCs, phrased in a short and simple way?)

Comment 35

[Kai Engert (:KaiE:)]

I said (in comment 28):
"The intention of triple wrapping 
is to confirm the list of intended recipients of the original signed message,
as intended by the signer of the original message"


You said, in comment 34, that you disagree with that statement.


I took me a while to understand why you disagree.

I believe you disagree, because I make a statement about the "original" message.

Well, of course, it is absolutely possible that the inner signed message might have been sent to additional recipients. I fully agree.

But I think this is obvious, isn't it? Owning a signed piece of paper is in no way a guarantee that I'm the only person in possession of the information written on the paper. Even if the paper is in an envelope, and the envelope is signed again, the original author of the paper might have produced another piece of paper which he gave to another person.


If I understand your point correctly, you remind me, not to make any statements about the original signed message, since we have idea what might have happened with that information in addition.

Ok. Point taken. Let me attempt to phrase again.


"The intention of signing + encrypting + triple wrapping
 is to confirm that the author of this signed and encrypted message 
    (as identified through the signing certifiate) 
 has specified
 that the list of people who are able to decrypt the message
    (the message recipient who is able to decrypt this message)
 are INTENDED recipients of this message."


In other words, trying to phrase it in a shorter way, if inner and outer signature were done by the same signing certificate:

"This message is signed.
 The list of recipients of the encrypted message is signed, too.
 Both signatures were made by the same signer.
 Because you are able to decrypt and read this message 
 (using one of your own private keys),
 it is verified that it was the intention of the signer of this message 
 to send this message to you."


Nelson, do you agree with these statements?

Comment 36

[Kai Engert (:KaiE:)]

And IMHO, if a message carries a valid triple wrapping, with matching inner and outer signature certs, and we are able to decrypt the message, then the statement could be shortened to say:

"The signer of this message has intended that you should receive this message."

And in my understanding, it was the intention of the invention of the triple wrapping procedure, to be able to make statements like this.


Nelson, if you still disagree with my words, it would be very helpful if you could simply point to the parts of my phrases that are wrong / misleading. Thanks.

Comment 37

[Sean Leonard]

I didn't really want to interject much into the conversation, but I feel somewhat compelled to do so.

Generally, I am in agreement with Nelson's comment 34.

The (original) purpose of triple wrapping has very little to do with much described in this bug.

RFC 2634 <http://tools.ietf.org/html/rfc2634> clearly states:
1.1 Triple Wrapping


   Some of the features of each service use the concept of a "triple
   wrapped" message. A triple wrapped message is one that has been
   signed, then encrypted, then signed again. The signers of the inner
   and outer signatures may be different entities or the same entity.
   Note that the S/MIME specification does not limit the number of
   nested encapsulations, so there may be more than three wrappings.

1.1.1 Purpose of Triple Wrapping


   Not all messages need to be triple wrapped. Triple wrapping is used
   when a message must be signed, then encrypted, and then have signed
   attributes bound to the encrypted body. Outer attributes may be added
   or removed by the message originator or intermediate agents, and may
   be signed by intermediate agents or the final recipient.

   The inside signature is used for content integrity, non-repudiation
   with proof of origin, and binding attributes (such as a security
   label) to the original content. These attributes go from the
   originator to the recipient, regardless of the number of intermediate
   entities such as mail list agents that process the message. The
   signed attributes can be used for access control to the inner body.
   Requests for signed receipts by the originator are carried in the
   inside signature as well.

   The encrypted body provides confidentiality, including
   confidentiality of the attributes that are carried in the inside
   signature.

   The outside signature provides authentication and integrity for
   information that is processed hop-by-hop, where each hop is an
   intermediate entity such as a mail list agent. The outer signature
   binds attributes (such as a security label) to the encrypted body.
   These attributes can be used for access control and routing
   decisions.

*********

The key takeaways:
 - inner signature is for the sender (originator of the message) to communicate signed things to the recipient
 - "Outer attributes may be added or removed by the message originator or intermediate agents, and may be signed by intermediate agents or the final recipient".
 - "triple wrapping" does not really exist as a technical, legal, moral, or whatever-else standard. It is just a shorthand for saying "a message was signed, then encrypted, then signed again by somebody" (and that somebody can be the same as the first signer, OR NOT).

In other words, it is just a technical shorthand for saying "there are 3 MIME layers".

Now I am perfectly aware of <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>, but people's conclusions drawn from that document about how to interpret triple-wrapping are basically wrong. Even that document says: "Note that our S/E/S double-signing only superficially resembles S/MIME's optional ``triple-wrapping'' feature; the two are different in mechanism and in purpose." "Triple-wrapping allows mail servers to securely annotate messages on-the-fly (``hop-by-hop''), primarily for the benefit of other mail-servers."

For what it's worth, as I understand the history (I wasn't there when the decisions were made), Don Davis brought this to the S/MIME working group in 2001. The problem was looked upon with skepticism for the reasons mentioned in comment 33, and the decision to placate was made to add "Header Protection" in S/MIME v3.1, which basically uses S/MIME on a message/rfc822 body, rather than a normal MIME content type (such as text/plain or multipart/alternative).

If people want to deal with this surreptitious forwarding issue--or perhaps more concretely the "Defective Sign & Encrypt" issue--start with Header Protection as a basis for discussion.

If all you want is to check a box that says yes, TB supports triple-wrapping, then fine. But as has been pointed out, triple-wrapping is just a shorthand for "this message has 3 layers". That is already implied by the S/MIME v3+ base standards anyway, and Thunderbird already supports it.

Can Signing, then Encrypting, then Signing the inner content again be used as a possible way to do deal with surreptitious forwarding? Perhaps. But again, it's not part of the standards. Surreptitious forwarding *detection* (not prevention) could also be solved in numerous other ways, as section 5 of the "Defective Sign & Encrypt" document discusses.

I am mildly interested in fixing this problem, so if somebody is interested in working with me to solve this problem and make it a standard, I would consider authoring an RFC on the topic. However, getting a standard written is only one part of a multi-faceted battle. The much harder part is getting the world's various S/MIME implementations to implement the standard in a consistent and interoperable way.

Comment 38

[Nelson Bolyard (seldom reads bugmail)]

In reply to comments 35 and 36, 
Kai, the part of your statement with which I disagree is that the intent has
something to do with RECIPIENTS.  I claim that the intent has nothing to do 
with identifying recipients and everything to do with identifying SENDERS.

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 37, I claim that, in general, the signed attribute(s) being bound to the encrypted body always include the identity of the sender of the encrypted body.  It's primarily (in my view) about identifying the sender. 
The fact that other attributes may also be signed by the sender of the outer
message is ... mere icing on the cake.

Comment 40

[Kai Engert (:KaiE:)]

After having heard Nelson's and Sean's explanations, I'm no longer convinced we need this feature. Obviously I have failed in my attempt to find a valid supporting argument to add triple wrapping support.

As it has been said before, our engine already supports multiple nesting levels of messages.

In my opinion, the term "triple wrapping" is too abstract, and doesn't help the majority of users. Let's not add unclear terms to the user interface. We should strive to report helpful properties and explanations.

Bug reporter, if you still want this feature added, in my opinion,
it's your task to argue why Nelson and/or Sean are wrong,
or alternatively,

to provide another explanation what the benefit of triple wrapping to users is, 
how we could explain that benefit to users,
and make sure this benefit is widely seen as agreed.

If we are not able to come up with such an obvious benefit,
and given that our code already supports nested messages,
this bug might be wontfix.

Comment 41

[Nelson Bolyard (seldom reads bugmail)]

Kai, perhaps my position needs clarification.  
I believe that this so-called triple wrapping feature (sign, encrypt, sign) 
DOES have significant value for users.  It's a feature I would like to see 
in the product.  But if it is added, it must be made clear to the user what
the feature does, and does NOT, accomplish.  It allows the recipient to tell
whether the sender of the message is also the author, or not.  Nothing else.

Comment 42

[Kai Engert (:KaiE:)]

Nelson, if you would like to see this added, would you like use my proposals from my earlier comments, and transform them into something that sounds right?

Comment 43

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.