Signed Receipts Technical Documentation

English | Français

> Documentation > Trustedbird > Signed Receipt > Technical Documentation

Specifications

The reference for the implementation of this functionality is the RFC 2634

Additional resources:

• http://fr.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions
• http://tools.ietf.org/html/rfc1847

Architecture

Synthetic presentation of the architecture of the extension

This functionality is in the list of features to be implemented by the Mozilla foundation: http://www.mozilla.org/projects/security/pki/nss/smime/. So, it is integrated to the source code of Thunderbird, without relaying on an extension. Furthermore, this make more simple the addition of this functionality, because we need to update the heart of the product.

The heart of this implementation is to add attributes to the signature of a message. A message with a signed receipt request must be signed. When receiving such a message, theses attributes are decoded in order to send back a signed receipt.

This functionality is going to be integrated with the official source code by Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=386313

GUI files

To send a message with a signed receipt request, it is mandatory to sign the message. So, the signed receipt request is bound to the security layer.

At the GUI level, signing is implemented by a flag signMessage, encapsulated in a nsIMsgSMIMECompFields object. The whole code handling this flag is contained in the JS built-in library msgCompSMIMEOverlay.js.

Then, the object nsIMsgSMIMECompFields is forwarded to the XPCOM layer, that handles the signing. So, this class has been updated to add a flag for the signed receipt request. Furthermore, the GUI has been updated so that the user can choose this option.

XPCOM files

Message sending

The implementation is mainly located in the file nsMsgComposeSecure.cpp in the nsMsgComposeSecure class.

This implementation mainly consists in adding attributes in the signature of a message. When sending a message, the built-in Thunderbird API build the following data structure :

The attributes to add are located in the structure NSSCMSSignerInfo and are of type NSSCMSAttribute.

A NSSCMSAttribute structure is defined as:

The attribute to add is a receiptRequest, which structure is defined by the RFC 2634.

Message receiving

When receiving a message with a signed receipt request, this structure is decoded and a signed receipt is generated.

Receipt Request ASN.1 Syntax

ReceiptRequest ::= SEQUENCE {
  signedContentIdentifier ContentIdentifier,
  receiptsFrom ReceiptsFrom,
  receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }

ub-receiptsTo INTEGER ::= 16

id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}

ContentIdentifier ::= OCTET STRING

id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}

ReceiptsFrom ::= CHOICE {
  allOrFirstTier [0] AllOrFirstTier,
  -- formerly "allOrNone [0]AllOrNone"
  receiptList [1] SEQUENCE OF GeneralNames }

AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
  allReceipts (0),
  firstTierRecipients (1) }

Receipt ASN.1 Syntax

Receipt ::= SEQUENCE {
  version ESSVersion,
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}

ESSVersion ::= INTEGER  { v1(1) }