The STRING field is the name form and 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 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 octets
Each 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> CRLF
The syntax of the token <emailstr> is defined in Section 4.1.1.
For example:
EN,1,galvin@tis.com
is an email address identifier.
4.2.2. Arbitrary String
The arbitrary string identifier has the following syntax.
<id-string> ::= "STR" "," <keysel> "," <string> CRLF
The syntax of the token <string> is defined in Section 4.1.2.
For example:
STR,1,The SAAG mailing list maintainer
is an arbitrary string identifier.
4.2.3. Distinguished Name
The distinguished name identifier has the following syntax.
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
The 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
EAxMPSmFtZXMgTS4gR2Fsdmlu
is 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
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB
is 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. See Section 5.2 for more
details.
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com
is 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 number
The <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==,02
is an issuer name and serial number identifier according to MOSS,
while
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
is 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 RFC1422, 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> CRLF
A 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
The principal objective of this content type is to convey
cryptographic keying material from a source to a destination. This
might be in response to the receipt of an application/mosskey-request
content type or it might be in anticipation of receiving an
application/mosskey-request if it is not sent, e.g., it may be
combined with a multipart/signed object by an originator to ensure
that a recipient has the cryptographic keying material necessary to
verify the signature. When combined with other content types, the
processing by a recipient is enhanced if the application/mosskey-data
content type is positioned in its enclosing content type prior to the
content types that will make use of its cryptographic keying
material.
However, no explicit provision is made in this document for
determining the authenticity or accuracy of the data being conveyed.
In particular, when a public key and its identifier is conveyed,
there is nothing to prevent the source or an interloper along the
path from the source to the destination from substituting alternate
values for either the public key or the identifier.
It is incumbent upon a recipient to verify the authenticity and
accuracy of the data received in this way prior to its use. This
problem can be addressed by the use of certificates, since a
certification hierarchy is a well-defined mechanism that conveniently
supports the automatic verification of the data. Alternatively, the
source of the application/mosskey-data body part could digitally sign
it. In this way, if the destination believes that a correct source's
public key is available locally and if the destination believes the
source would convey accurate data, then the contents of the
application/mosskey-data from the 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.
(1) MIME type name: application
(2) MIME subtype name: mosskey-data
(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.
<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> CRLF
This 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.
(Note that the converse is not true: the validity of a protected body
part cannot be determined without the proper public keys,
certificates, or current CRL information.) As such, the
application/mosskey-data content type is an independent body part.
The <publickeydata> production contains exactly one public key. It
is used to bind a public key with its corresponding name form and key
selector. It is recommended that when responders are returning this
information that 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. Therefore, 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?
Jim
6.2. Sign Text of Original Message
When the text of the original message is signed, it will look like
this, where 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 with the text of the
original message, it will look like this, where 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 asterisk '*':
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
* How do you like the new MOSS?
*
* Jim
the 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
If, instead, we choose to sign the text before we encrypt it, the
structure would be as follows, where 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 descriptive of
the actual content that would appear in a real body part. The actual
message would be like this:
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
In addition to text, the MOSS services as defined here will protect
arbitrary body parts, for example, the following audio body part:
Content-Type: audio/basic
AUDIO DATA HERE
6.6.1. Sign Audio Content
When signed an audio content would appear as follows, 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 descriptive
of the content that would appear in a real body part.
6.6.2. Encrypt Audio Content
When encrypted an audio content would appear as follows, 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 descriptive of the
content that would appear in a real body part.
7. Observations
The use of MIME and the framework defined by [7] exhibits several
properties:
(1) It allows arbitrary content types to be protected, not just the
body of an RFC822 message.
(2) It allows a message to contain several body parts which may or
may not be protected.
(3) It allows the components of a multipart or message content to be
protected with different services.
The use of a MIME-capable user agent makes complex nesting of
protected message body parts much easier. For example, the user can
separately sign and encrypt a message. This allows complete
separation of the confidentiality security service from the digital
signature security service. That is, different key pairs could be
used for the different services and could be protected separately.
This is useful for at least two reasons. First, some public key
algorithms do not support both digital signatures and encryption; two
key pairs would be required in this case. Second, an employee's
company could be given access to the (private) decryption key but not
the (private) signature key, thereby granting the company the ability
to decrypt messages addressed to the employee in emergencies without
also granting the company the ability to sign messages as the
employee.
8. Comparison of MOSS and PEM Protocols
MOSS differs from PEM in the following ways.
(1) When using PEM, users are required to have certificates. When
using MOSS, users need only have a public/private key pair.
(2) MOSS broadens the allowable name forms that users may use to
identify their public keys, including arbitrary strings, email
addresses, or distinguished names.
(3) 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.
(4) 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.
(5) MIME includes transfer encoding operations to ensure the
unmodified transfer of body parts. Therefore, unlike PEM, MOSS
does not need to include these functions.
(6) 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 MIME Content-Type: headers.
The Proc-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 the Version: header
specified in this document.
(7) 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 MIME Content-Type: headers.
(8) 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- request and application/mosskey-data.
(9) The header fields having to do with certificates (Originator-
Certificate: and Issuer-Certificate:) and CRLs (CRL:) are
relegated for use only in the application/mosskey-data and
application/mosskey-request content 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.
(10) 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].
(11) 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.
(12) In [3], when asymmetric key management is used, an Originator-ID
field is required in order to identify the private key used to
sign the MIC argument in the MIC-Info: field. Because no MIC-
Info: field is associated with the encryption security service
under asymmetric key management, there is no requirement in that
case to include an Originator-ID field.
(13) The protocol specified here explicitly excludes symmetric key
management.
(14) 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.
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 specification,
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.
11. References
[1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, 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", RFC1521, Bellcore and
Innosoft, September 1993.
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures", RFC1421,
IAB IRTF PSRG, IETF PEM WG, February 1993.
[4] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management", RFC1422, BBN
Communications, February 1993.
[5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC1423, Trusted
Information Systems, February 1993.
[6] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
Part IV: Key Certification and Related Services", RFC1424, RSA
Laboratories, February 1993.
[7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC1847, 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
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.com
Appendix A: Collected Grammar
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> CRLF
Appendix B: Imported Grammar
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.)