RFC 1848
MIME Object Security Services
MIME Object Security Services 🎀
Part 1 of 8 🧚
- RFC: 1848, under the Network Working Group 💖
- Category: Standards Track ✨
- Date: October 1995 🌸
- Authors: S. Crocker (CyberCash, Inc.), N. Freed (Innosoft International, Inc.), J. Galvin (Trusted Information Systems), and S. Murphy (Trusted Information Systems) 👑
- Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates. 🫶
Status of This Memo 📜
okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🙈 For the current standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Abstract ✨
This document defines MIME Object Security Services (MOSS) 💜 It's a protocol that uses the multipart/signed and multipart/encrypted framework [7] to add digital signatures and encryption to MIME objects. The services work through end-to-end cryptography between an originator and a recipient at the application layer, and it's giving main character energy 🦋
Asymmetric (public key) cryptography handles the digital signature service and encryption key management. Symmetric (secret key) cryptography handles the encryption service. The procedures are meant to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches 🌈
Table of Contents 🗂️
1. Introduction ............................................. 3
2. Applying MIME Object Security Services ................... 4
2.1 Digital Signature Service ............................... 4
2.1.1 Canonicalization ...................................... 5
2.1.2 Digital Signature Control Information ................. 7
2.1.2.1 Version: ............................................ 8
2.1.2.2 Originator-ID: ...................................... 8
2.1.2.3 MIC-Info: ........................................... 8
2.1.3 application/moss-signature Content Type Definition .... 9
2.1.4 Use of multipart/signed Content Type .................. 10
2.2 Encryption Service ...................................... 11
2.2.1 Encryption Control Information ........................ 12
2.2.1.1 DEK-Info: ........................................... 13
2.2.1.2 Recipient-ID: ....................................... 14
2.2.1.3 Key-Info: ........................................... 14
2.2.2 application/moss-keys Content Type Definition ......... 15
2.2.3 Use of multipart/encrypted Content Type ............... 16
3. Removing MIME Object Security Services ................... 17
3.1 Digital Signature Service ............................... 18
3.1.1 Preparation ........................................... 18
3.1.2 Verification .......................................... 19
3.1.3 Results ............................................... 19
3.2 Encryption Service ...................................... 20
3.2.1 Preparation ........................................... 20
3.2.2 Decryption ............................................ 20
3.2.3 Results ............................................... 21
4. Identifying Originators, Recipients, and Their Keys ...... 21
4.1 Name Forms .............................................. 23
4.1.1 Email Addresses ....................................... 23
4.1.2 Arbitrary Strings ..................................... 23
4.1.3 Distinguished Names ................................... 23
4.2 Identifiers ............................................. 24
4.2.1 Email Address ......................................... 25
4.2.2 Arbitrary String ...................................... 25
4.2.3 Distinguished Name .................................... 26
4.2.4 Public Key ............................................ 26
4.2.5 Issuer Name and Serial Number ......................... 27
5. Key Management Content Types ............................. 27
5.1 application/mosskey-request Content Type Definition ..... 28
5.2 application/mosskey-data Content Type Definition ........ 29
6. Examples ................................................. 31
6.1 Original Message Prepared for Protection ................ 31
6.2 Sign Text of Original Message ........................... 32
6.3 Sign Headers and Text of Original Message ............... 32
6.4 Encrypt Text of a Message ............................... 33
6.5 Encrypt the Signed Text of a Message .................... 35
6.6 Protecting Audio Content ................................ 37
6.6.1 Sign Audio Content .................................... 37
6.6.2 Encrypt Audio Content ................................. 37
7. Observations ............................................. 38
8. Comparison of MOSS and PEM Protocols ..................... 39
9. Security Considerations .................................. 41
10. Acknowledgements ........................................ 41
11. References .............................................. 41
12. Authors' Addresses ...................................... 43
Appendix A: Collected Grammar .............................. 44
Appendix B: Imported Grammar ............................... 471. Introduction 🌸
okay bestie, let's start with MIME [2], which stands for "Multipurpose Internet Mail Extensions". It defines the format of Internet mail message contents and allows multi-part textual and non-textual message bodies 💌 An Internet email message has two parts: the headers and the body. The headers are a bunch of field/value pairs structured according to STD 11, RFC 822 [1]. The body, if it's structured, is defined by MIME. The catch is that MIME doesn't provide for applying security services at all 😭
Next is PEM [3-6], short for "Privacy Enhanced Mail". PEM defines message encryption and message authentication procedures for text-based email using a certificate-based key management mechanism 🔐 It has several features that MIME supports pretty naturally, like the transfer encoding operation, the Content-Domain header, and the support services in its Part IV [6]. The limitation is that PEM only applies security services to text messages 🙃
MOSS is based heavily on PEM as defined in RFC 1421. A lot of PEM's features and most of its protocol specification are carried over here. You can find a comparison of MOSS and PEM in Section 8 🧠
To use MOSS services, a user is required to have at least one public/private key pair. (Here "user" isn't limited to humans, so it could be a process or a role 🤖) The public key must be made available to the other users you want to communicate securely with. The private key must not be disclosed to any other user 🤫
The originator's private key is used to digitally sign MIME objects, and a recipient uses the originator's public key to verify that signature ✍️ The recipient's public key is used to encrypt the data encrypting key, which then encrypts the MIME object. The recipient uses the matching private key to decrypt the data encrypting key, so the MIME object can be decrypted 🗝️
As long as private keys are protected from disclosure (meaning only the user they were assigned to can access them), the recipient of a signed message knows who sent it, and the originator of an encrypted message knows only the intended recipient can read it 👀 For assurance, the ownership of public keys used to verify signatures and encrypt messages should be verified. A stored public key should be protected from modification 🛡️
The framework in [7] gives you a way to represent a MIME object along with its digital signature or encryption keys. When MOSS uses it, the framework provides digital signature and encryption services for single and multi-part textual and non-textual MIME objects 💅
2. Applying MIME Object Security Services ✨
Applying the MOSS digital signature service takes two components:
- (1) The data to be signed.
- (2) The private key of the originator.
Here's the vibe: the data gets prepared as described below. The digital signature is made by hashing the data and then encrypting that hash with the originator's private key 🔏 The signature, some extra ancillary information (also described below), and the data all get wrapped up in a multipart/signed body part. After that, the multipart/signed body part can be sent to a recipient or processed further. For example, it can be encrypted 🎁
Applying the MOSS encryption service takes three components:
- (1) The data to be encrypted.
- (2) A data encrypting key to encrypt the data.
- (3) The public key of the recipient.
The data gets prepared as described below. The originator creates a data encrypting key and uses it to encrypt the data. The recipient's public key is then used to encrypt the data encrypting key 🗝️ The encrypted data, the encrypted data encrypting key, and some extra ancillary information (described below) are packaged into a multipart/encrypted body part, ready to send to a recipient or process further. For example, it can be signed 💜
The next two sections go into detail on the digital signature and encryption services 📚
2.1. Digital Signature Service 🖋️
The MOSS digital signature service applies to MIME objects, specifically a MIME body part. The MIME body part is created according to a local convention and then made available to the digital signature service 💖
Here's the sequence of steps for applying the digital signature service:
- (1) The body part to be signed must be canonicalized.
- (2) The digital signature and other control information must be generated.
- (3) The control information must be embodied in an appropriate MIME content type.
- (4) The control information body part and the data body part must be embodied in a multipart/signed content type.
Each of these steps is described below 🦋
2.1.1. Canonicalization
okay so the body part has to get turned into a canonical form 💅 that can be written down the exact same way in the originator's environment AND the recipient's environment. Why? Because the sender has to compute the signature over the data, and the receiver has to recompute that same value and compare it to what arrived. If both sides don't have identical bytes, nothing matches, and it's a whole mess 😭. If the canonical form works on lots of different host computers, recipients can forward the signed data to other people, and they can still verify the original signature. That's called forwardable authentication 🦋
The canonicalization is a two step process ✨ First, the body part gets converted into a form that works on as many host computers as possible. Second, the line delimiters get converted into one unique, unambiguous representation.
For step one, the chosen representation is 7bit, as defined by MIME. The high order bit of each octet of the data being signed must be zero 🎀 A MIME body part is headers plus content. The headers are already required to be 7bit, so this step doesn't touch them. If the content isn't 7bit already, it has to be encoded with an appropriate MIME content transfer encoding, and a Content-Transfer-Encoding: header has to be added to the headers. For example, if the content has 8bit or binary data, it must be encoded with either quoted-printable or base64, as defined by MIME 🌸
IMPLEMENTORS NOTE: Since the MIME standard explicitly disallows nested content transfer encodings (the content types multipart and message may not themselves be encoded), the 7bit transformation requires each nested body part to be individually encoded in a 7bit representation. Any valid MIME encoding, e.g., quoted-printable or base64, may be used, and in fact a different encoding may be used on each of the non-7bit body parts. 🧚
Turning everything into 7bit makes all the content types into text-based content types. But text-based content has its own problem 🙈 The line delimiter depends on the local environment. Different environments use the single character carriage-return (<CR>), the single character line-feed (<LF>), or the two character sequence "carriage-return line-feed (<CR><LF>)".
Applying the digital signature service requires that the originator and the recipient use the same line delimiter. This document says the line delimiter must be the two character sequence <CR><LF> 💖 So the second step of the canonicalization is converting the local line delimiter into <CR><LF>.
Now, this conversion is only for computing the signature. So originators must apply the line delimiter conversion before computing the digital signature, but they must transfer the data without the line delimiter conversion. Recipients, similarly, must apply the line delimiter conversion before computing the digital signature.
NOTE: An originator can not transfer the content with the line delimiter conversion intact, because the conversion process is not idempotent. SMTP servers may themselves convert the line delimiter to a local line delimiter before the message is delivered to the recipient. So a recipient has no way of knowing whether the conversion is present or not. If the recipient applies the conversion to content where it's already present, the result may have two line delimiters, and that would make signature verification fail 💀
IMPLEMENTORS NOTE: The conversion to a 7bit representation is a function that is required in a minimally compliant MIME user agent. The line delimiter conversion required here is distinct from the same conversion included in that function. Specifically, the line delimiter conversion applied when a body part is converted to a 7bit representation (transfer encoded) is performed prior to the application of the transfer encoding. The line delimiter conversion applied when a body part is signed is performed after the body part is converted to 7bit (transfer encoded). Both line delimiter conversions are required. 👑
2.1.2. Digital Signature Control Information
The digital signature service generates control information, and that includes the digital signature itself 🔥 The syntax of this control information is a set of RFC 822 headers, with one twist: folding header values onto continuation lines is explicitly forbidden 🙅♀️ Every header and value pair the service generates has to sit on exactly one line.
Here's the full list of headers the digital signature service generates ✨
Version: indicates which version of the MOSS protocol the remaining headers represent.
Originator-ID: indicates the private key used to create the digital signature and the corresponding public key to be used to verify it.
MIC-Info: contains the digital signature value.
Every invocation of the digital signature service must emit exactly one Version: header and at least one pair of Originator-ID: and MIC-Info: headers. The Version: header must always be emitted first. The Originator-ID: and MIC-Info: headers are always emitted in pairs, in that order 🎀 This spec lets an originator make multiple signatures of the data (presumably with different signature algorithms) and include all of them in the control information. What it means when there are multiple signatures is outside the scope of this specification, with one exception: a MIC-Info: header is always interpreted in the context of the Originator-ID: header right before it 🦋
2.1.2.1. Version:
The version header is defined by the grammar token <version> like this:
<version> ::= "Version:" "5" CRLFIts value is constant. MOSS implementations that follow this spec must recognize only this value, and they must generate an error if any other value is found 🚨
2.1.2.2. Originator-ID:
The purpose of the originator header is two-fold 👯♀️ It directly identifies the public key used to verify the digital signature, and it indirectly identifies the user who owns that key and its matching private key. Recipients usually care less about the actual public key value (though they obviously need it to verify the signature) and more about who the owner is. So the originator header may convey either or both of these pieces of information:
- the public key to be used to verify the signature
- the name of the owner and which of the owner's public keys to use to verify the signature
The originator decides what goes in the value, full stop 💅 The suggested value is to include both. Recipients who have already talked with the originator will have to check that the info matches what they already know. New recipients will want all of it, and they need to verify it before storing it in their local database 🫶
The originator header is defined by the grammar token <origid> like this:
<origid> ::= "Originator-ID:" <id> CRLFThe grammar token <id> is defined in Section 4.
2.1.2.3. MIC-Info:
The whole point of the Message Integrity Check (MIC) header is to convey the digital signature value 🔐 Its value is a comma separated list of three arguments: the hash (or MIC) algorithm identifier, the signature algorithm identifier, and the digital signature.
The MIC header is defined by the grammar token <micinfo> like this:
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLFThe grammar tokens for the MIC algorithms and identifiers (<micalgid>), the signature algorithms and identifiers (<ikalgid>), and the signed MIC formats (<asymsignmic>) are defined by RFC 1423. They're also reprinted in Appendix B 📖
IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol, which includes support for symmetric signatures and key management. Because of that, some of the grammar tokens defined there (for example, <ikalgid>) include options that aren't legal for this protocol. Those options must be ignored, and they haven't been included in the appendix. 🙃
2.1.3. application/moss-signature Content Type Definition
Here's the registration info for the content type 🌈
(1) MIME type name: application
(2) MIME subtype name: moss-signature
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: quoted-printable is always sufficient
(6) Security considerations: noneThe "application/moss-signature" content type goes on the second body part of an enclosing multipart/signed. Its content is the digital signature of the data in the first body part of that multipart/signed, plus any other control information needed to verify that signature, as defined by Section 2.1.2 ✨ The label "application/moss-signature" must be used as the value of the protocol parameter of the enclosing multipart/signed, and the protocol parameter must be present 💜
Part of the signature verification info is the Message Integrity Check (MIC) algorithm(s) used when the signature was created. The MIC algorithm(s) identified in this body part must match the MIC algorithm(s) identified in the micalg parameter of the enclosing multipart/signed. If they don't match, a user agent should point out the discrepancy to the user, and it may choose to halt or continue processing, giving precedence to the algorithm(s) identified in this body part 👀
An application/moss-signature body part is built like this:
Content-Type: application/moss-signature
<mosssig>Where the grammar token <mosssig> is defined as follows:
<mosssig> ::= <version> ( 1*<origasymflds> )
<version> ::= "Version:" "5" CRLF
<origasymflds> ::= <origid> <micinfo>
<origid> ::= "Originator-ID:" <id> CRLF
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLFThe token <id> is defined in Section 4. All the other tokens are defined in Section 2.1.2.3 🍓
2.1.4. Use of multipart/signed Content Type ✨
okay so the multipart/signed content type from [7] has three steps for making the body part 💅
- The body part to be digitally signed is created according to a local convention, for example, with a text editor or a mail user agent.
- The body part is prepared for the digital signature service according to the protocol parameter, in this case according to Section 2.1.1.
- The prepared body part is digitally signed according to the protocol parameter, in this case according to Section 2.1.2.
the multipart/signed content type gets built like this 🎀
- The value of its required parameter "protocol" is set to "application/moss-signature".
- The signed body part becomes its first body part.
- Its second body part is labeled "application/moss-signature" and is filled with the control information generated by the digital signature service.
- The value of its required parameter "micalg" is set to the same value used in the MIC-Info: header in the control information. If there is more than one MIC-Info: header present the value is set to a comma separated list of values from the MIC-Info headers. The interpretation of the order of the list of values is outside the scope of this specification.
a multipart/signed content type with the MOSS protocol might look like this 🦋
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Message"
--Signed Message
Content-Type: text/plain
This is some example text.
--Signed Message
Content-Type: application/moss-signature
Version: 5
Originator-ID: ID-INFORMATION
MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION
--Signed Message--where ID-INFORMATION and SIGNATURE-INFORMATION are just descriptive of the content that would appear in a real body part 🌸
2.2. Encryption Service
the MOSS encryption service is applied to MIME objects, specifically a MIME body part 🧚 the body part gets created according to a local convention and then handed over to the encryption service.
here's the sequence of steps for the encryption service 💖
- The body part to be encrypted must be in MIME canonical form.
- The data encrypting key and other control information must be generated.
- The control information must be embodied in an appropriate MIME content type.
- The control information body part and the encrypted data body part must be embodied in a multipart/encrypted content type.
the first step is defined by MIME, and the latter three steps are described below ✨
2.2.1. Encryption Control Information
the encryption service generates control information, and that includes the data encrypting key used to encrypt the data itself 🔥 the syntax is that of a set of RFC 822 headers, except that folding header values onto continuation lines is explicitly forbidden. each header and value pair generated by the encryption service must be output on exactly one line 🫶
first, the originator must retrieve the public key of the recipient 🔑 that can come from a local database or a remote service. acquiring the recipient's public key is outside the scope of the specification, although Section 5 defines one possible mechanism.
with the public key in hand, the originator encrypts the data encrypting key according to the Key-Info: header defined below. the complete set of headers generated by the encryption service is:
Version:indicates which version of the MOSS protocol the remaining headers represent and is defined in Section 2.1.2.1.DEK-Info:indicates the algorithm and mode used to encrypt the data.Recipient-ID:indicates the public key used to encrypt the data encrypting key that was used to encrypt the data.Key-Info:contains the data encrypting key encrypted with the recipient's public key.
each invocation of the encryption service must emit exactly one Version: header, exactly one DEK-Info: header, and at least one pair of Recipient-ID: and Key-Info: headers. headers are always emitted in the order indicated. the Recipient-ID: and Key-Info: headers are always emitted in pairs in the order indicated, one pair for each recipient of the encrypted data. a Key-Info: header is always interpreted in the context of the immediately preceding Recipient-ID: header. 🎀
🙈 IMPLEMENTORS NOTE: Implementors should always generate a Recipient-ID: and Key-Info header pair representing the originator of the encrypted data. By doing so, if an originator sends a message to a recipient that is returned undelivered, the originator will be able to decrypt the message and determine an appropriate course of action based on its content. If not, an originator will not be able to review the message that was sent.
2.2.1.1. DEK-Info:
the data encrypting key information header is there to indicate the algorithm and mode used to encrypt the data, along with any cryptographic parameters that may be required, e.g., initialization vectors 🍓 its value is either a single argument indicating the algorithm and mode, or a comma separated pair of arguments where the second argument carries any cryptographic parameters required by the algorithm and mode indicated in the first argument.
the header is defined by the grammar token <dekinfo> like so:
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLFthe grammar tokens for the encryption algorithm and mode identifier (<dekalgid>) and the optional cryptographic parameters (<dekparameters>) are defined by RFC 1423. they are also reprinted in Appendix B. 💜
2.2.1.2. Recipient-ID:
the recipient header identifies the private key that must be used to decrypt the data encrypting key, which then decrypts the data 🦋 presumably the recipient owns the private key, so they're less interested in who the key's owner is and more interested in the private key value itself. still, the recipient header may convey either or both of these pieces of info:
- the public key corresponding to the private key to be used to decrypt the data encrypting key
- the name of the owner and which of the owner's private keys to use to decrypt the data encrypting key
the decision about what goes in the value rests entirely with the originator 👑 the suggested choice is to include just the public key. however, some recipients may prefer that originators not include their public key. how that preference gets conveyed to and managed by the originator is outside the scope of this specification.
the recipient header is defined by the grammar token <recipid> as follows:
<recipid> ::= "Recipient-ID:" <id> CRLFthe grammar token <id> is defined in Section 4. ✨
2.2.1.3. Key-Info:
the key information header exists to convey the encrypted data encrypting key 🔐 its value is a comma separated list of two arguments: the algorithm and mode identifier the data encrypting key is encrypted with, and the encrypted data encrypting key itself.
it's defined by the grammar token <asymkeyinfo>:
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLFthe grammar tokens for the algorithm and mode identifier (<ikalgid>) and the encrypted data encrypting key format (<asymsignmic>) are defined by RFC 1423. they're also reprinted in Appendix B.
💀 IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol, which includes support for symmetric signatures and key management. As a result, some of the grammar tokens defined there, for example, <ikalgid>, will include options that are not legal for this protocol. These options must be ignored and have not been included in the appendix.
2.2.2. application/moss-keys Content Type Definition
- (1) MIME type name: application
- (2) MIME subtype name: moss-keys
- (3) Required parameters: none
- (4) Optional parameters: none
- (5) Encoding considerations: quoted-printable is always sufficient
- (6) Security considerations: none
the "application/moss-keys" content type is used on the first body part of an enclosing multipart/encrypted 🧁 its content is made up of the data encryption key used to encrypt the data in the second body part, plus other control information required to decrypt the data, as defined by Section 2.2.1. the label "application/moss-keys" must be used as the value of the protocol parameter of the enclosing multipart/encrypted, and the protocol parameter must be present.
an application/moss-keys body part is constructed like this 🌈
Content-Type: application/moss-keys
<mosskeys>where the <mosskeys> token is defined as follows:
<mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo>
<recipid> ::= "Recipient-ID:" <id> CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLFthe token <id> is defined in Section 4. the token <version> is defined in Section 2.1.2.1. all other tokens are defined in Section 2.2.1.3. 🍬
2.2.3. Use of multipart/encrypted Content Type
the multipart/encrypted body part is defined in [7], and it specifies three steps for creating the body part 🌷
- The body part to be encrypted is created according to a local convention, for example, with a text editor or a mail user agent.
- The body part is prepared for encryption according to the protocol parameter, in this case the body part must be in MIME canonical form.
- The prepared body part is encrypted according to the protocol parameter, in this case according to Section 2.2.1.
the multipart/encrypted content type gets constructed like so 🫧
- The value of its required parameter "protocol" is set to "application/moss-keys".
- The first body part is labeled "application/moss-keys" and is filled with the control information generated by the encryption service.
- The encrypted body part becomes the content of its second body part, which is labeled "application/octet-stream".
a multipart/encrypted content type with the MOSS protocol might look like this 🦋
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Message"
--Encrypted Message
Content-Type: application/moss-keys
Version: 5
DEK-Info: DES-CBC,DEK-INFORMATION
Recipient-ID: ID-INFORMATION
Key-Info: RSA,KEY-INFORMATION
--Encrypted Message
Content-Type: application/octet-stream
ENCRYPTED-DATA
--Encrypted Message--where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION are just descriptive of the content that would appear in a real body part 💖
3. Removing MIME Object Security Services ✨
okay bestie, so checking a MOSS digital signature needs three things 💅
- A recipient to verify the digital signature.
- A multipart/signed body part with two body parts: the signed data and the control information.
- The public key of the originator.
The signed data and control information of the enclosing multipart/signed are prepared according to the description below. The digital signature is verified by re-computing the hash of the data, decrypting the hash value in the control information with the originator's public key, and comparing the two hash values. If the two hash values are equal, the signature is valid 🎀
Decrypting a MOSS encryption service is just as iconic 🦋 It needs:
- A recipient to decrypt the data.
- A multipart/encrypted body part with two body parts: the encrypted data and the control information.
- The private key of the recipient.
The encrypted data and control information of the enclosing multipart/encrypted are prepared according to the description below. The data encrying key is decrypted with the recipient's private key and used to decrypt the data. (Okay, typo, the real word is encrypting 🙈) The next two sections describe the digital signature and encryption services in detail, respectively 🌸
3.1. Digital Signature Service
This section walks through the processing steps needed to verify the MOSS digital signature service. The definition of the multipart/signed body part in [7] lays out three steps for receiving it, and we're going to go through each one 🫶
- The digitally signed body part and the control information body part are prepared for processing.
- The prepared body parts are made available to the digital signature verification process.
- The results of the digital signature verification process are made available to the user, and processing continues with the digitally signed body part, as returned by the digital signature verification process.
Each of these steps is described below 💜
3.1.1. Preparation
The digitally signed body part (the data) and the control information body part get separated from the enclosing multipart/signed body part ✨
The control information is prepared by removing any content transfer encodings that may be present.
The digitally signed body part is prepared by leaving the content transfer encodings intact and canonicalizing the line delimiters according to Step 2 of Section 2.1.1.
3.1.2. Verification
First, the recipient must obtain the public key of the originator. The public key may be contained in the control information, or it may be necessary for the recipient to retrieve the public key based on information present in the control information. The retrieval may be from a local database or from a remote service. Acquiring the originator's public key is outside the scope of the specification, although Section 5 defines one possible mechanism 🔥
With the public key, the recipient decrypts the hash value contained in the control information. Then, a new hash value is computed over the body part purported to have been digitally signed.
Finally, the two hash values are compared to determine the accuracy of the digital signature 👑
3.1.3. Results
There are two required components of the results of the verification process. The first is an indication as to whether a public key could be found that allows the hash values in the previous step to compare equal. Such an indication verifies only that the data received is the same data that was digitally signed 💅
The second indication identifies the owner of the public key, who is presumably the holder of the private key that created the digital signature. The indication must include a testament as to the accuracy of the owner identification.
Here's the real tea 🍓 At issue is a recipient knowing who created the digital signature. For the recipient to know with certainty who digitally signed the message, the binding between the owner's name and the public key must have been verified by the recipient prior to the verification of the digital signature. The verification of the binding may have been completed offline and stored in a trusted, local database or, if the owner's name and public key are embodied in a certificate, it may be possible to complete it in realtime. See Section 5 for more information.
3.2. Encryption Service
This section describes the processing steps needed to decrypt the MOSS encryption service. The definition of the multipart/encrypted body part in [7] specifies three steps for receiving it, and yes, we're doing all three 🧚
- The encrypted body part and the control information body part are prepared for processing.
- The prepared body parts are made available to the decryption process.
- The results of the decryption process are made available to the user, and processing continues with the decrypted body part, as returned by the decryption process.
Each of these steps is described below 🌈
3.2.1. Preparation
The encrypted body part (the data) and the control information body part are separated from the enclosing multipart/encrypted body part. The body parts are prepared for the decryption process by removing any content transfer encodings that may be present.
3.2.2. Decryption
First, the recipient must locate the encrypted data encrypting key in the control information. Each Recipient-ID: header is checked in order to see if it identifies the recipient or a public key of the recipient.
If it does, the immediately following Key-Info: header will contain the data encrypting key, encrypted with the public key of the recipient. The recipient must use the corresponding private key to decrypt the data encrypting key 🔑
The data is decrypted with the data encrypting key. The decrypted data will be a MIME object, a body part, ready to be processed by a MIME agent 🦋
3.2.3. Results
If the recipient is able to locate and decrypt a data encrypting key, then from the point of view of MOSS, the decryption should be considered successful. An indication of the owner of the private key used to decrypt the data encrypting key must be made available to the user 🙌
Ultimately, the success of the decryption depends on the ability of a MIME agent to continue processing with the decrypted body part 💖
4. Identifying Originators, Recipients, and Their Keys 🌸
In the PEM specifications, public keys are required to be embodied in certificates. A certificate is an object that binds each public key with a distinguished name. A distinguished name is a name form that identifies the owner of the public key. The embodiment is issued by a certification authority, a role that is expected to be trustworthy insofar as the certification authority would have procedures to verify the identity of the owner prior to issuing the certificate 👑
In MOSS, a user is not required to have a certificate 🙈 The MOSS services require that the user have at least one public/private key pair. The MOSS protocol requires the digital signature and encryption services to emit Originator-ID: and Recipient-ID: headers, as appropriate. Earlier in the discussion, the actual value of these headers was left out, since it was saved for this section. Although the value of each of these headers serves a distinct purpose, for simplicity the single grammar token <id> represents the value that may be assigned to either header ✨
One possible value for the Originator-ID: and Recipient-ID: headers is the public key values themselves. However, while it is true that the public keys alone could be exchanged and used by users to communicate, the values are, in fact, large and cumbersome 😭 In addition, public keys would appear as a random sequence of characters and, as a result, would not be immediately consumable by human users.
NOTE: It should be pointed out that a feature of being able to specify the public key explicitly is that it allows users to exchange encrypted, anonymous mail. In particular, receiving users will always know a message comes from the same originating user, even if the real identity of the originating user is unknown.
Recognizing that the use of public keys is, in general, unsuitable for use by humans, MOSS allows other identifiers in Originator-ID: and Recipient-ID: headers. These other identifiers are comprised of two parts: a name form and a key selector 🧚
The name form is chosen and asserted by the user who owns the public/private key pair. Three name forms are specified by this document. The use of a distinguished name is retained for compatibility with PEM (and compatibility with the X.500 Directory should it become a ubiquitous service). However, the Internet community has a great deal of experience with the use of electronic mail addresses as a name form. Also, arbitrary strings are useful to identify the owners of public keys when private name forms are used. Hence, email addresses and arbitrary strings are included as name forms to increase flexibility 🌈
Since a user may have more than one public key and may wish to use the same name form for each public key, a name form is insufficient for uniquely identifying a public key. A unique "key selector" must be assigned to each public key. The combination of a name form and the key selector uniquely identifies a public key. Throughout this document, this combination is called an identifier. There are 5 identifiers specified by this document 💅
NOTE: In the simplest case, key selectors will be assigned by the owners of the public/private key pairs. This works best when users generate their own key pairs for personal use, from which they distribute their public key to others, asserting by declaration that the public key belongs to them. When the assertion that the public key belongs to them is made by a third party, for example when a certification authority issues a certificate to a user according to [4], the key selector may be assigned by that third party.
The value of the key selector must be unique with respect to the name form with which it forms an identifier. Although the same key selector value may be used by more than one name form, it must not be used for two different keys with the same name form. When considered separately, neither a name form nor a key selector is sufficient for identifying the public key to be used. Either could be used to determine a set of public keys that may be tried in turn until the desired public key is identified 🔥
With a public/private key pair for one's self and software that is MOSS aware, an originating user may digitally sign arbitrary data and send it to one or more recipients. With the public keys of the recipients, a user may encrypt the data so that only the intended recipients can decrypt and read it. With the name forms assigned to the public keys, originators and recipients can easily recognize their peers in a communication 🦋
In the next section the 3 name forms are described in detail. Following that is the specification of the 5 identifiers 🎀
4.1. Name Forms
There are 3 name forms specified by this document: email addresses, distinguished names, and arbitrary strings 🫶
4.1.1. Email Addresses 💌
okay so the email address (grammar token <emailstr>) must be a valid RFC822 address, and it's defined in terms of one of two grammar tokens, <addr-spec> or <route-addr>. The grammar for those two is in the Appendix as a convenience, but the definitive source is RFC822 [1] 📮
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; one of these two tokens from RFC822For example, "crocker@tis.com", "galvin@tis.com", "murphy@tis.com", and "ned@innosoft.com" are all email addresses ✨
4.1.2. Arbitrary Strings 🧵
The arbitrary string (grammar token <string>) must have a length of at least 1. There are no other restrictions on the value chosen, so it's very chill 😌
<string> ::= ; a non-null sequence of charactersFor example, the string
the SAAG mailing list maintaineris an arbitrary string 🌸
4.1.3. Distinguished Names 🎀
The distinguished name (grammar token <dnamestr>) must be constructed according to the guidelines of the X.500 Directory. The actual syntax of the distinguished name is outside the scope of this specification, but RFC1422, for example, specifies syntactic restrictions based on its choice of a certification hierarchy for certificates. Bestie, that's a whole other universe 🌌
For the purposes of conveying a distinguished name from an originator to a recipient, it must be ASN.1 encoded and then printably encoded according to the base64 encoding defined by MIME 🦋
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name (as defined by the 'Name'
; production specified in X.501 [8])For example,
/Country Name=US
/State or Province Name=MD
/Organization Name=Trusted Information Systems
/Organizational Unit Name=Glenwood
/Common Name=James M. Galvin/is a distinguished name in a user friendly format (line breaks and leading spaces present only to improve readability). When encoded, it would appear as follows (line breaks present only to improve readability):
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
SmFtZXMgTS4gR2Fsdmlu4.2. Identifiers 🪪
There are 5 types of identifiers specified by this document, and they're all giving variety 💅
- email address identifiers
- arbitrary string identifiers
- distinguished name identifiers
- the public keys themselves
- issuer name serial number pairs from a certificate
All of these have approximately the same structure (except issuer name and serial number, which has 'TYPE, STRING, KEYSEL' for historical reasons 🙈):
TYPE, KEYSEL, STRINGThe TYPE field is a literal string chosen from the set "EN", "STR", "DN", "PK", and "IS", one for each of the possible identifiers 🏷️
The KEYSEL field is used to distinguish between the multiple public keys that may be associated with the name form in the STRING field. Its value must be unique with respect to all other key selectors used with the same name form. An example would be to use a portion (low-order 16 or 32 bits) or all of the actual public key used 🔑
The STRING field is the name form, and it has a different syntax according to the value of the TYPE field ✨
The identifier used in each of the originator and recipient fields is described by the following grammar. The definition of the key selector token is included here since it is used by several of the identifiers below 💜
<id> ::= <id-email> / <id-string> / <id-dname>
/ <id-publickey> / <id-issuer>
<keysel> ::= 1*<hexchar>
; hex dump of a non-null sequence of octetsEach of the identifier name forms is described below 🌈
4.2.1. Email Address 💖
The email address identifier has the following syntax.
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLFThe syntax of the token <emailstr> is defined in Section 4.1.1.
For example:
EN,1,galvin@tis.comis an email address identifier 💌
4.2.2. Arbitrary String 🧶
The arbitrary string identifier has the following syntax.
<id-string> ::= "STR" "," <keysel> "," <string> CRLFThe syntax of the token <string> is defined in Section 4.1.2.
For example:
STR,1,The SAAG mailing list maintaineris an arbitrary string identifier 🌷
4.2.3. Distinguished Name 🏛️
The distinguished name identifier has the following syntax.
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLFThe syntax of the token <dnamestr> is defined in Section 4.1.3.
For example (line breaks present only to improve readability):
DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R
lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U
EAxMPSmFtZXMgTS4gR2Fsdmluis a distinguished name identifier 👑
4.2.4. Public Key 🗝️
The public key identifier has the following syntax.
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<id-subset> ::= <id-email> / <id-string> / <id-dname>The production SubjectPublicKeyInfo is imported from the X.500 Directory from the certificate object. It is currently the best choice for a general purpose public key encoding 🧁
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQABis a public key identifier without the optional <id-subset> 🫶
In normal usage, the token <id-subset> is expected to be present. It represents a mechanism by which an identifier (name form and key selector) can be associated with a public key. Recipients of a public key identifier must take care to verify the accuracy of the purported association. If they do not, it may be possible for a malicious originator to assert an identifier that accords the originator unauthorized privileges. > 🚨 This one is serious, so check Section 5.2 for more details.
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.comis a public key identifier with the optional <id-subset> 🦋
4.2.5. Issuer Name and Serial Number 🧾
The issuer name and serial number identifier has the following syntax.
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<serial> ::= 1*<hexchar>
; hex dump of a certificate serial numberThe <id-issuer> identifier is included for compatibility with the ID-ASymmetric fields defined in [3] (and compatibility with X.500 Directory certificates should they become ubiquitously available). Its syntax was chosen such that the older fields are easily converted to this new form by prefixing the old value with "IS" (and replacing the field name of [3] with an appropriate new ID field name). For example (line breaks present only to improve readability):
IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02is an issuer name and serial number identifier according to MOSS, while
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02is an issuer name and serial number identifier according to PEM 🍓
5. Key Management Content Types 🔐
This document defines two key management content types: one for requesting cryptographic key material and one for sending cryptographic key material. Since MOSS depends only on the existence of public/private key pairs, these content types provide a means for conveying public keys and an assertion as to the identity of the owner. In addition, in order to be compatible with the certificate-base key management system proposed by RFC 1422, the content types may also be used to convey certificate and certificate revocation list material 🌈
The functions defined here are based on the exchange of body parts. In particular, a user would send a message containing at least one application/mosskey-request content, as defined below. In response, a user would expect to receive a message containing at least one application/mosskey-data content, as defined below. MIME provides a convenient framework for a user to send several request body parts and to receive several data (response) body parts in one message 💬
5.1. application/mosskey-request Content Type Definition 📨
- (1) MIME type name: application
- (2) MIME subtype name: mosskey-request
- (3) Required parameters: none
- (4) Optional parameters: none
- (5) Encoding considerations: quoted-printable is always sufficient
- (6) Security Considerations: none
The content of this body part corresponds to the following production.
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <id> CRLF
<issuer> ::= "Issuer:" <id> CRLF
<certification> ::= "Certification:" <encbin> CRLFA user would use this content type to specify needed cryptographic key information. The message containing this content type might be directed towards an automatic or manual responder, which may be mail-based, depending on the local implementation and environment. The application/mosskey-request content type is an independent body part because it is entirely independent of any other body part 🦋
If the application/mosskey-request content contains a Certification: field, it requests certification of the self-signed certificate in the field value. If the content contains an Issuer: field, it requests the Certificate Revocation List (CRL) chain beginning with the CRL of the issuer identified in the field value. If the content contains a Subject: field, it requests either the public key of the subject or a certificate chain beginning with the subject identified in the field value, or both if both exist 🔍
The Subject: and Issuer: fields each contain a value of type <id>, which is defined in Section 4.
One possible response to receiving an application/mosskey-request body part is to construct and return an application/mosskey-data body part. When returning public keys, certificate chains, and certificate revocation list chains, if there exists more than one, several application/mosskey-data body parts are to be returned in the reply message, one for each 🌸
5.2. application/mosskey-data Content Type Definition 🎀
okay so the main goal of this content type is to get cryptographic keying material from a source over to a destination 🔑✨. It might be a reply to an application/mosskey-request, or it might just get sent ahead of time in case no request ever shows up. For example, an originator could pair it with a multipart/signed object so the recipient already has the keys needed to verify the signature 🧚. When it's combined with other content types, processing gets easier if the application/mosskey-data part is placed in its enclosing content type before the parts that use its keying material 💅.
BUT (and this is a big but) this document doesn't make any explicit provision for checking whether the data being conveyed is authentic or accurate 😬. Especially when a public key and its identifier are sent, nothing stops the source, or some sneaky interloper along the path from source to destination, from swapping in different values for either the public key or the identifier 💀.
So it's on the recipient to verify the authenticity and accuracy of data received this way before using it 🫶. Certificates can help with that, since a certification hierarchy is a well-defined mechanism that conveniently supports automatic verification of the data. Another option is for the source to digitally sign the application/mosskey-data body part. That way, if the destination believes a correct source's public key is available locally, and believes the source would convey accurate data, then the contents from that source could be believed to be accurate 🌸.
NOTE: Insofar as a certificate represents a mechanism by which a third party vouches for the binding between a name and a public key, the signing of an application/mosskey-data body part is a similar mechanism. 🧠
Here are the registration details for this type 📋:
- MIME type name: application
- MIME subtype name: mosskey-data
- Required parameters: none
- Optional parameters: none
- Encoding considerations: quoted-printable is always sufficient.
- Security Considerations: none
The content of this body part follows this production 📜:
<mosskeydata> ::= <version>
( <publickeydata> / <certchain> / <crlchain> )
<version> ::= "Version:" "5" CRLF
<publickeydata> ::= "Key:" "PK" "," <publickey> ","
<id-subset> CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<crlchain> ::= 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLFThis content type is used to transfer public keys, certificate chains, or Certificate Revocation List (CRL) chains 🦋. The information in the body part is entirely independent of any other body part. (The converse is not true, though: the validity of a protected body part can't be determined without the proper public keys, certificates, or current CRL information.) So application/mosskey-data is an independent body part, bestie 💜.
The <publickeydata> production contains exactly one public key. It's used to bind a public key with its corresponding name form and key selector. It is recommended that when responders return this information, the enclosing body part be digitally signed by the responder in order to protect the information 🔐. The <id-subset> token is defined in Section 4.2.4.
The <certchain> production contains one certificate chain. A certificate chain starts with the requested certificate and continues with the certificates of subsequent issuers. Each issuer certificate included must have issued the preceding certificate. For each issuer, a CRL may be supplied. A CRL in the chain belongs to the immediately following issuer, so it potentially contains the immediately preceding certificate 🌈.
The <crlchain> production contains one certificate revocation list chain. The CRLs in the chain begin with the requested CRL and continue with the CRLs of subsequent issuers. The issuer of each CRL is presumed to have issued a certificate for the issuer of the preceding CRL. For each CRL, the issuer's certificate may be supplied. A certificate in the chain must belong to the issuer of the immediately preceding CRL ⭐.
The relationship between a certificate and an immediately preceding CRL is the same in both <certchain> and <crlchain>. In a <certchain> the CRLs are optional. In a <crlchain> the certificates are optional 🍓.
6. Examples ✨
Each example is included as a separate section for ease of reference 📚.
6.1. Original Message Prepared for Protection 💌
Except as explicitly indicated, the following message is used as the message to be protected.
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
How do you like the new MOSS?
Jim6.2. Sign Text of Original Message 🖊️
When the text of the original message is signed, it will look like this. Lines with an ampersand '&' are digitally signed. Note the use of the public key identifier with the included email name identifier, on the lines marked with an asterisk '*' 👀.
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary
& Content-Type: text/plain; charset="us-ascii"
& Content-ID: <21436.785186814.2@tis.com>
&
& How do you like the new MOSS?
&
& Jim
--Signed Boundary
Content-Type: application/moss-signature
Content-ID: <21436.785186814.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
* Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
* qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
* KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
* 2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf=
MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb=
sOVJjleV7vTe9yoNp2P8mi/hs7
--Signed Boundary--6.3. Sign Headers and Text of Original Message 🧁
If, instead, we choose to protect the headers along with the text of the original message, it will look like this. Lines with an ampersand '&' are encrypted 🔒.
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary
& Content-Type: message/rfc822
& Content-ID: <21468.785187044.2@tis.com>
&
& To: Ned Freed <ned@innosoft.com>
& Subject: Hi Ned!
&
&
& How do you like the new MOSS?
&
& Jim
--Signed Boundary
Content-Type: application/moss-signature
Content-ID: <21468.785187044.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WT=
wjfxFBvAceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4G=
d8dBBwMKvqMKTHAUxGXYxwNdbK
--Signed Boundary--6.4. Encrypt Text of a Message 🤫
If we choose to encrypt the text of the following message, that is, encrypt the lines marked with an asterisk '*' 🕵️♀️:
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
* How do you like the new MOSS?
*
* Jimthe message would look as follows. Note the use of the email name identifier, on the line marked with an asterisk '*' 💖:
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: application/moss-keys
Content-ID: <21535.785187667.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,D488AAAE271C8159
* Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/=
7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT=
9P6jyzcV1NzZVwfp+u
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU
d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w
onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI=
--Encrypted Boundary--6.5. Encrypt the Signed Text of a Message ✨
okay so, if we flip the order and sign the text before we encrypt it, the structure looks like this 🔐 lines with an asterisk '*' are digitally signed, and lines with an ampersand '&' are encrypted:
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: application/moss-keys
KEY INFORMATION
--Encrypted Boundary
Content-Type: application/octet-stream
& Content-Type: multipart/signed;
& protocol="application/moss-signature";
& micalg="rsa-md5"; boundary="Signed Boundary"
&
& --Signed Boundary
& * Content-Type: text/plain
& *
& * How do you like the new MOSS?
& *
& * Jim
&
& --Signed Boundary
& Content-Type: application/moss-signature
&
& SIGNATURE INFORMATION
&
& --Signed Boundary--
--Encrypted Boundary--where KEY INFORMATION and SIGNATURE INFORMATION are placeholders for the real stuff that would show up in an actual body part. Here's what a real message would look like 💌
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: application/moss-keys
Content-ID: <21546.785188458.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,11CC89F8D90F1DFE
Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz=
Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV=
jpb4EOUlwOXwRZ
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ5
2V/wkxwMrum6xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2
U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY
Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv
NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY
g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF
2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+
tL4IgMjQqm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmk
YjCxVviJP3zO2UzBvCoMfADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m
04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9Dixl8WCx3rxwN5g2QFLiyQVulzuNhimS
D4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81NcpQJRPNAvF0IkN6ddwL4q
vzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/c/vpbunQ
UqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp
+ymxhTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1f
NkSRnc8BZswIoPyRetsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6
ubygBqJiKPM4II2fCdNj7CptfQcoRTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhf
zysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8S2nLPCZl1hzdajsrqHFe8omQ
--Encrypted Boundary--6.6. Protecting Audio Content 🎧
okay, MOSS isn't just for text 🙌 the services defined here will protect arbitrary body parts too. For example, here's an audio body part:
Content-Type: audio/basic
AUDIO DATA HERE6.6.1. Sign Audio Content
when the audio gets signed, it looks like this, where lines with an ampersand '&' are digitally signed 🎶
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary
& Content-Type: audio/basic
& Content-Transfer-Encoding: base64
&
& base64(AUDIO-DATA-HERE)
--Signed Boundary
Content-Type: application/moss-signature
SIGNATURE-INFORMATION-HERE
--Signed Boundary--where AUDIO-DATA-HERE and SIGNATURE-INFORMATION-HERE are placeholders for the content that would appear in a real body part 💜
6.6.2. Encrypt Audio Content
and when it gets encrypted, it looks like this, where lines with an ampersand '&' are encrypted 🔒
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: application/moss-keys
KEY-INFORMATION-HERE
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
& Content-Type: audio/basic
&
& base64(encrypted(AUDIO-DATA-HERE))
--Encrypted Boundary--where KEY-INFORMATION-HERE and AUDIO-DATA-HERE are placeholders for the content that would appear in a real body part 🎀
7. Observations 🧠
so the use of MIME and the framework defined by [7] has a few properties that are honestly iconic 👑
- It allows arbitrary content types to be protected, not just the body of an RFC822 message.
- It allows a message to contain several body parts which may or may not be protected.
- It allows the components of a multipart or message content to be protected with different services.
a MIME-capable user agent makes complex nesting of protected message body parts so much easier 🤩 for example, the user can sign and encrypt a message separately. This gives a complete separation of the confidentiality security service from the digital signature security service. In other words, different key pairs could be used for each service, and they could be protected separately.
this is useful for at least two reasons 💅 first, some public key algorithms don't support both digital signatures and encryption, so two key pairs would be needed in that case. second, an employee's company could be given access to the (private) decryption key but not the (private) signature key. that means the company can decrypt messages addressed to the employee in emergencies, without also being able to sign messages as the employee. no cap, that's genius 🫶
8. Comparison of MOSS and PEM Protocols ⚖️
okay, here's how MOSS differs from PEM 👀
- When using PEM, users are required to have certificates. When using MOSS, users need only have a public/private key pair.
- MOSS broadens the allowable name forms that users may use to identify their public keys, including arbitrary strings, email addresses, or distinguished names.
- PEM currently only supports text-based electronic mail messages, and the message text is required to be represented by the ASCII character set with
"<CR><LF>"line delimiters. These restrictions no longer apply. - The PEM specification currently requires that encryption services be applied only to message bodies that have been signed. By providing for each of the services separately, they may be applied in any order according to the needs of the requesting application.
- MIME includes transfer encoding operations to ensure the unmodified transfer of body parts. Therefore, unlike PEM, MOSS does not need to include these functions.
- PEM specifies a
Proc-Type:header field to identify the type of processing that was performed on the message. This functionality is subsumed by the MIMEContent-Type:headers. TheProc-Type:header also includes a decimal number that is used to distinguish among incompatible encapsulated header field interpretations which may arise as changes are made to the PEM standard. This functionality is replaced by theVersion:header specified in this document. - PEM specifies a
Content-Domain:header, the purpose of which is to describe the type of the content which is represented within a PEM message's encapsulated text. This functionality is subsumed by the MIMEContent-Type:headers. - The PEM specifications include a document that defines new types of PEM messages, specified by unique values used in the
Proc-Type:header, to be used to request certificate and certificate revocation list information. This functionality is subsumed by two new content types specified in this document:application/mosskey-requestandapplication/mosskey-data. - The header fields having to do with certificates (
Originator-Certificate:andIssuer-Certificate:) and CRLs (CRL:) are relegated for use only in theapplication/mosskey-dataandapplication/mosskey-requestcontent types, and are no longer allowed in the header portion of a PEM signed or encrypted message. This separates key management services from the digital signature and encryption services. - The grammar specified here explicitly separates the header fields that may appear for the encryption and signature security services. It is the intent of this document to specify a precise expression of the allowed header fields; there is no intent to disallow the functionality of combinations of encryption and signature security found in [3].
- With the separation of the encryption and signature security services, there is no need for a
MIC-Info:field in the headers associated with an encrypted message. - In [3], when asymmetric key management is used, an
Originator-IDfield is required in order to identify the private key used to sign the MIC argument in theMIC-Info:field. Because noMIC-Info:field is associated with the encryption security service under asymmetric key management, there is no requirement in that case to include anOriginator-IDfield. - The protocol specified here explicitly excludes symmetric key management.
- This document requires all data that is to be digitally signed to be represented in 7bit form.
9. Security Considerations 🔐
this entire document is about security. Full stop 😤 Every service described here, and every choice about how to combine them, is a security decision, so please treat it with the seriousness it deserves 🚨
10. Acknowledgements 🫶
David H. Crocker suggested the use of a multipart structure for the MIME and PEM interaction, which has evolved into the MOSS protocol 🌸
The MOSS protocol is a direct descendant of the PEM protocol. The authors gratefully acknowledge the editors of those specifications, especially John Linn and Steve Kent. This work would not have been possible had it not been for all of the PEM developers, users, and interested persons who are always present on the PEM developers mailing list and at PEM working group meetings at IETF meetings, especially Amanda Walker, Bob Juenemann, Steve Dusse, Jeff Thomson, and Rhys Weatherly. thank you all, you legends 🌈💖
Okay, the references are where the receipts live, bestie 📚🫶
11. References 📚
- [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.
- [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore and Innosoft, September 1993.
- [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
- [4] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN Communications, February 1993.
- [5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, Trusted Information Systems, February 1993.
- [6] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993.
- [7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted Information Systems and Innosoft, September 1995.
- [8] The Directory -- Models. X.501, 1988. Developed in collaboration, and technically aligned, with ISO 9594-2.
- [9] The Directory -- Authentication Framework. X.509, 1988. Developed in collaboration, and technically aligned, with ISO 9594-8.
12. Authors' Addresses 💌
These are the humans behind the spec, so here's where you can find them, slay 💅
Steve Crocker
CyberCash, Inc.
2086 Hunters Crest Way
Vienna, VA 22181
Phone: +1 703 620 1222
Fax: +1 703 391 2651
EMail: crocker@cybercash.com
James M. Galvin
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Phone: +1 301 854 6889
Fax: +1 301 854 5363
EMail: galvin@tis.com
Sandra Murphy
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Phone: +1 301 854 6889
Fax: +1 301 854 5363
EMail: murphy@tis.com
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.comAppendix A: Collected Grammar ✨
The grammar is the ultimate source of truth for what a valid message looks like, so every token lives right here. Version first, then the rest 🎀
The version of the grammar in this document is as follows:
<version> ::= "Version:" "5" CRLF
The following grammar tokens are used throughout this specification:
<encbin> ::= 1*<encbingrp>
<encbingrp> ::= 4*4<encbinchar>
<encbinchar> ::= <ALPHA> / <DIGIT> / "+" / "/" / "="
<hexchar> ::= <DIGIT> / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
The content of an application/moss-signature body part is as follows:
<mosssig> ::= <version> ( 1*<origasymflds> )
<version> ::= "Version:" "5" CRLF
<origasymflds> ::= <origid> <micinfo>
<origid> ::= "Originator-ID:" <id> CRLF
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
The content of an application/moss-keys body part is as follows:
<mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo>
<recipid> ::= "Recipient-ID:" <id> CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
Identifiers are defined as follows:
<id> ::= <id-subset> / <id-publickey> / <id-issuer>
<id-subset> ::= <id-email> / <id-string> / <id-dname>
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
<id-string> ::= "STR" "," <keysel> "," <string> CRLF
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<keysel> ::= 1*<hexchar>
; hex dump of a non-null sequence of octets
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; these two tokens from RFC822
<string> ::= ; a non-null sequence of characters
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded distinguished name (as defined by the 'Name'
; production specified in X.501 [8])
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<serial> ::= 1*<hexchar>
; hex dump of a certificate serial number
The content of an application/mosskey-request body part is as
follows:
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <id> CRLF
<issuer> ::= "Issuer:" <id> CRLF
<certification> ::= "Certification:" <encbin> CRLF
The content of an application/mosskey-data body part is as follows:
<mosskeydata> ::= <version>
( <publickeydata> / <certchain> / <crlchain> )
<version> ::= "Version:" "5" CRLF
<publickeydata> ::= "Key:" "PK" "," <publickey> ","
<id-subset> CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<crlchain> ::= 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLFAppendix B: Imported Grammar 🧩
Okay so here's the deal: this bit borrows grammar from other specs, and the trimmed-down copies are just here for your convenience. The originals are still the real authority, so if they ever disagree, go with the source. Options that are illegal in MOSS have been left out of this reprint, which makes it easier to read 💜
Options normally present in the grammar reprinted here which are illegal in MOSS are excluded in this reprinting, for the convenience of the reader.
The following productions are taken from [5]. The grammar presented in [5] remains the authoritative source for these productions; they are repeated here for the convenience of the reader.
<dekalgid> ::= "DES-CBC"
<ikalgid> ::= "RSA"
<micalgid> ::= "RSA-MD2" / "RSA-MD5"
<dekparameters> ::= <DESCBCparameters>
<DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16>
<hexchar16> ::= 16*16<hexchar>
<asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin>
<asymencdek> ::= <RSAencdek>
<RSAencdek> ::= <encbin>The following productions are taken from [1]. The grammar presented in [1] remains the authoritative source for these productions; they are repeated here for the convenience of the reader.
<route-addr> ::= "<" [ <route> ] <addr-spec> ">"
<route> ::= 1# ( "@" <domain> ) ":" ; path-relative
<addr-spec> ::= <local-part> "@" <domain>; global address
<local-part> ::= <word> *( "." <word> ) ; uninterpreted
; case-preserved
<domain> ::= <sub-domain> *( "." <sub-domain> )
<sub-domain> ::= <domain-ref> / <domain-literal>
<domain-ref> ::= <atom> ; symbolic
; reference
<domain-literal>::= "[" *( <dtext> / <quoted-pair> ) "]"
<dtext> ::= <any CHAR excluding "[", "]",
"\" & <CR>, & including
linear-white-space>
; => may be folded
<word> ::= <atom> / <quoted-string>
<quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """
<qtext> ::= (any <CHAR> excepting """, "\", and CR,
and including <linear-white-space>)
<quoted-pair> ::= "\" <CHAR> ; may quote any
; char
<linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> )
; semantics = SPACE
; CRLF => folding
<LWSP-char> ::= SPACE / HTAB ; semantics = SPACE
<atom> ::= 1*(any <CHAR>
except <specials>, SPACE and <CTL>s)
<CHAR> ::= <any ASCII character>
<CTL> ::= <any ASCII control character and DEL>
<specials> ::= "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "." / "[" / "]"
; Must be in quoted-
; string, to use
; within a word.
<ALPHA> ::= <any ASCII alphabetic character>
; (101-132, 65.-90.)
; (141-172, 97.-122.)
<DIGIT> ::= <any ASCII decimal digit>; (60-71, 48.-57.)📦 where this page comes from
- ietf: rfc1848 1995-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms