Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 1, 2002.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This draft defines how XML Digital Signatures and XML Encryption may be used with Multipart MIME security to provide MIME integrity and confidentiality. It extends RFC 1847 by defining application/signature+xml and application/encryption+xml protocols for the Multipart/Signed and Multipart/Encrypted MIME types. Although non-XML content may be signed or encrypted based on XML signing and encryption, additional capabilities are available for XML MIME content. This draft defines a signature transform parameter for partial signing or manipulation of XML MIME content as well as processing rules in addition to the XML Digital Signature and XML Encryption processing rules.

1. Introduction

RFC 1847[1] defines a general mechanism for security multiparts in MIME, defining the Multipart/Signed and Multipart/Encrypted types. This mechanism uses a protocol parameter to specify the signature or encryption mechanism. Multipart/Signed enables the first MIME part to contain arbitrary MIME content and the second to contain a signature over that content. Common mail applications currently use application/x-pkcs7-signature as the signing protocol, creating a PKCS#7 signature in the signature part. Multipart/Encrypted uses the first part to contain encryption control information, and the second part encrypted content. An alternative to Multipart/Encrypted is to pass a single MIME part containing encrypted content using using application/x-pkcs7-mime, as done by common mail applications.

XML Digital Signature[4] and XML Encryption[5] recommendations enable signing and encryption of arbitary content as well as providing advanced support for XML content. This includes the ability to sign or encrypt portions of XML, reference multiple objects in a signature and include metadata information with signed or encrypted content. XML signatures support multiple signatures, useful when content is routed for approvals. Both XML Signatures and Encryption support inclusion of the signature or encrypted content in the orginal XML document, creating a close binding. Signatures may also be separate from the signed content, especially useful when the content is large or binary and would interfere with XML processing of the signature. Likewise, encrypted cipherdata may be included in an XML encrypted element or managed separately.

Combining the XML security mechanisms with Multipart MIME security enables MIME applications to benefit from XML security as well as enabling XML security to use a defined mechanism for handling multiple parts. This draft extends the existing Multipart MIME security mechanism by defining two new protocol parameters to be used with RFC 1847, application/signature+xml and application/encryption+xml. These names follow the XML naming convention defined in RFC 3023, XML Media Types[8]. This draft defines these parameters and a minimal set of processing rules.

2. Multipart Security

Multipart Security (RFC 1847) defines multipart MIME types specific for security - Multipart/Signed and Multipart/Encrypted. The definitions of these types include the definition of required MIME parameters, and the parts which comprise these multipart definitions.

Each type requires a boundary parameter used to separate the parts of the multipart message, as common with multipart MIME. Each also requires definition of a MIME protocol, defined as a type/subtype. This draft defines two protocols for use with MIME multipart security: application/signature+xml and application/encryption+xml. These are defined using the type "application" (rather than "text") since the content is meant to be processed by an XML aware application. The subtype defines the XML security mechanism, XML Digital Signature or XML Encryption. The Multipart/Signed type also requires definition of an micalg parameter, defined in the following section on signature parameters. Definition of the parts is defined in the appropriate sections.

A general concern with mail is the ability of content to pass through a variety of mail gateways, including mail systems which are only capable of processing 7-bit UTF8. Content to be signed must be exactly the same when received as when sent for signature verification to succeed. Some gateways may convert data to enable delivery, such as automatically converting to Quoted-Printable or Base64 encoding. This will not allow signatures to be validated. For this reason all data signed according to this protocol MUST be constrained to 7 bits (8-bit data should be encoded using either Quoted-Printable or Base64). XML content should also be canonicalized, as discussed in the signature section.

As discussed in the PGP RFC[6], applications using this standard should follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly.

It's generally a good idea to encode lines that begin with From= because some mail transport agents will insert a greater-than (>) sign, thus invalidating the signature. Also, in some cases it might be desirable to encode any trailing whitespace that occurs on lines in order to ensure that the message signature is not invalidated when passing a gateway that modifies such whitespace (like BITNET). [6]

3. XML Digital Signatures with Multipart/Signed

3.1 Multipart/Signed MIME Parts

According to RFC 1847, Multipart/Signed content consists of exactly two parts, the content part and the signature part. The first part may be any type of content, encoded in MIME canonical format (e.g. base64 encoded), and must include MIME headers defining the content type.

The second part is a signature over the entire first part, including the MIME headers. The second part must be labeled with the content type of "application/signature+xml".

This signature must be an XML Digital Signature and MUST include one reference to the first part. This reference does not require a URI, but if a URI is present it may either be a CID or a full URL. If it is a CID the first part must have a Content-ID header with a matching value. If it is a URL, this URL must resolve to the same URL specified in a Content-Location header in the first part. This is discussed in detail in the SOAP with Attachments W3C Note[7].

3.2 Parameters

As defined in RFC 1847, Multipart/Signed requires three parameters: boundary, protocol and micalg. XML Signatures require support for a fourth, optional parameter, "transform".

3.2.1 Boundary Parameter

Boundary is used to separate the parts, as defined in RFC 1847.

3.2.2 Protocol Parameter

The Multipart security protocol parameter will be defined as "application/signature+xml" for XML Signatures. This parameter specifies that the XML Digital Signature recommendation rules should be followed in processing the XML Signature part, as well as the Multipart security signature processing rules discussed below.

3.2.3 Micalg Parameter

The Multipart Security RFC requires definition of the micalg parameter for Multipart/Signed types. This allows one-pass signature verification, since the parameter is used to specify the hash algorithm and allows the content part to be hashed before the signature part is processed.

This is compatible with the XML Digital Signature recommendation, which requires a hash of the document to be generated to verify a document reference. The XML digital signature recommendation requires support for the SHA-1 hash, an algorithm currently supported by common mail programs, which represent it as the "SHA1" value for the micalg parameter.

We propose in this draft that XML identifiers (URIs) be REQUIRED as micalg values for XML security types, allowing digest functions to be specified using the URIs defined in the XML Digital Signature recommendation. SHA-1 MUST be specified as "http://www.w3.org/2000/09/xmldsig#sha1", for example. Note that the digest algorithm is also specified inside the XML Signature itself, but must be provided in micalg to support one-pass processing of content before encountering the Signature element.

3.2.4 Transform Parameters

Enabling one-pass processing makes it important to allow signature transforms to be defined in a MIME header, allowing one-pass processing whenever possible, depending on the transforms. Examples include canonicalization or an XPath transform allowing specific XML content to be signed. If the signature requires transforms but they are not specified in the header, calculating the digest before processing the signature is incorrect.

The transform parameter is optional, but required if any transforms are needed to create an XML signature reference. If transforms were applied they must be specified in transform parameters, one per parameter. These are processed in the order encountered. After the transforms are applied, the hash is calculated. Each transform is specified by the transform URI, and optionally one or more transform parameters. An XPath transform, for example, will consist of the XPath transform URI, a namespace context and then an expression value, all separated by commas. Not all transforms or transform combinations will allow one-pass processing.

In the following example, the element <reason> and its content is signed (line breaks added for readability):

Any XPath expression is defined to refer to the XML content of the MIME body. This is the first part content, not including the MIME headers. Use of XPath is only meaningful in this context if the body content type is an XML type. It is required that any content transform be expressed both as a transform parameter in the MIME header as well as a transform in the XML Signature reference.

3.3 XML Signature Processing Rules

When the XML digital signature is generated:

1. The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence. XML content MUST be UTF8, if it is not, Canonical XML version 1.0 MUST be used to ensure it is UTF8. Binary data is not canonicalized.
2. An appropriate Content-Transfer-Encoding is then applied. Each line of the encoded data MUST end with the canonical <CR><LF> sequence. This is base64 encoding for binary data. XML data must have line endings normalized to <CR><LF> (not the default of canonicalization).
3. MIME content headers are then added to the body, each ending with the canonical <CR><LF> sequence. If a signature reference URI is used, the content must have either a Content-ID or Content-Location header added.
4. Before creating a signature over XML content, that content must be canonicalized using Canonical XML version 1.0. This is necessary to ensure that an XML signature will verify despite different XML processor variants. Even if the XML was canonicalized in the first step, it must have its line endings canonicalized in this step.
5. A signature may either sign the entire MIME content part (headers and content) or only a section of XML content. If the entire MIME part is signed, the XML signature is created over that part producing an XML Digital Signature element. This is the default. The processing rules of the XML Digital Signature recommendation must be followed.
6. If only a portion of XML (or only the entire XML content) is signed, this must be specified using an XPath expression applied to the entire XML content of the first MIME part (but not including the headers). This expression MUST be included as a reference transform and included in a transform header parameter. The signature is created over the specified part following the processing rules of the XML Digital Signature recommendation.
7. By default the result signature XML is placed in the second signature MIME part, with the original content in the first part. No URI is required for the content reference, but if a URI is used it must be either a CID refering to the Content-ID header in the first part, or a URL which resolves to the URL stated in a the Content-Location header in the first part.
8. Alternatively, for a signature over XML or a portion of XML, the signature may be included in the XML. In this case the second signature MIME part will be empty. This requires the signature to include the appropriate enveloped signature transform which MUST also be included as a transform MIME parameter.

3.4 XML Signature Example

This is an example of a detached signature over the first part.

4. XML Encryption with Multipart/Encrypted

4.1 Multipart/Encrypted MIME Parts

According to RFC 1847, Multipart/Encrypted content consists of exactly two parts, a control part and the encrypted content part. The control part must be the same type as the protocol parameter, in this case "application/xml-encrypted". RFC 1847 requires the second part to be labelled "application/octet-stream".

For XML encryption the control part MUST contain the XML Encryption content, XML containing one or more EncryptedData elements. The encrypted content part of the MIME message may be empty if the ciphertext is contained in the XML EncryptedData elements. This is a common case, with the CipherValue element containing the data.

If the cipher data is not included in the XML EncryptedData it may be placed in the second encrypted data MIME part, base64 encoded. The EncryptedData CipherReference element will refer to it using a CID or a URL. If a CID is used, the encrypted content MIME part must have a corresponding Content-ID header. If a URL is used, the encrypted content MIME part must have a corresponding Content-Location header.

It is possible for the cipher data to be stored in the network, in which case the CipherReference URL specifies this location and the cipher data is in neither Mime part.

4.2 Parameters

As defined in RFC 1847, Multipart/Encrypted requires two parameters: boundary and protocol. Boundary is used to separate the parts, as defined in RFC 1847.

4.2.1 Protocol Parameter

The protocol parameter is required to be "application/xml-encrypted" for XML encryption.

4.3 XML Encryption Processing Rules

When the XML encrypted content is generated:

1. Before encryption, the data should be written in MIME canonical format (body and headers).
2. If the entire content is to be encrypted (both headers and content), the XML Encryption processing rules should be followed, producing an XML EncryptedData element. This is placed in the first MIME encryption control part. If the cipher data is included in the XML EncryptedData element the second MIME part for encrypted data will be empty. Alternatively, the cipher data may be placed in the second MIME part, with a reference from the first part. This reference may be a CID which must correspond to a Content-ID header in the second part, or a URL which resolves to match a Content-Location header in the second part.
3. If a portion of XML is encrypted, it is replaced with an Encrypted Data element, and the entire content is placed in the first MIME control section. The cipherdata may be embedded in the XML and the second MIME part will be empty, or may refer to the cipher data in the second part.

Using a reference to cipher data in the second MIME part has the advantage that the XML may be parsed without the efficiency and size limitations of a large amount of cipherdata.

4.4 XML Encryption Example

An example of a encrypting the content in the first part and placing the ciphervalue in the second part is:

4.5 Security Considerations

This entire document is about security. Note that MD5 is not a recommended digest algorithm, given known security weaknesses.

Sometimes it is desirable to both digitally sign and then encrypt a message to be sent. XML digital signature and encryption are designed to be combined. Signing and then encrypting may result as a Multipart/Encrypted object as defined above. Signing an encrypted object (not necessarily meaningful if the signer did not see what they signed) would involve the data object containing the encrypted multipart content.

See the recommendations for a discussion of security considerations associated with XML Digital Signatures[4] and XML Encryption[5].

References

Author's Address

Appendix A. Acknowledgements

This draft was written using XML[10]. The author appreciates the review by Rich Salz.

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.