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 (C) The Internet Society (2001). All Rights Reserved.
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.
RFC 1847 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 and XML Encryption 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. This draft defines these parameters and a minimal set of processing rules.
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, 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). 
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.
As defined in RFC 1847, Multipart/Signed requires three parameters: boundary, protocol and micalg. XML Signatures require support for a fourth, optional parameter, "transform".
Boundary is used to separate the parts, as defined in RFC 1847.
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.
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.
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):
Content-Type: Multipart/Signed; protocol="application/signature+xml"; boundary="Signed Boundary"; micalg="http://www.w3.org/2000/09/xmldsig#sha1"; transform="http://www.w3.org/TR/1999/REC-xpath-19991116", "http://spam.com/foo","//reason"; transform="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" --Signed Boundary Content-Type: text/xml; Location: http://test.zolera.com/transformdoc.xml <start xmlns="http://spam.com/foo"> <name>Smith</name> <reason>returned</reason> </start> --Signed Boundary Content-Type: application/signature+xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE Signature [ <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> ]> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="signature"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> <Reference URI="http://test.zolera.com/transformdoc.xml"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath xmlns:tns="http://spam.com/foo">//tns:reason</XPath> </Transform> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>PxcEwz8QDxAQVqfGyJy69ql7lCE=o</DigestValue> </Reference> </SignedInfo> <SignatureValue>nVwiEUEEJSv0txxkj/XrMDCVkx9ajF8Jk4Kglpg6/54dvd5wOMbstw0+ TYx/lOD5S6CImb3J2hrdkCwAYYyL1A== </SignatureValue> </Signature> --Signed Boundary
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.
When the XML digital signature is generated:
This is an example of a detached signature over the first part.
From: Frederick Hirsch<firstname.lastname@example.org> To: Frederick Hirsch<email@example.com> Mime-Version: 1.0 Content-Type: Multipart/Signed; boundary=bar; micalg="http://www.w3.org/2000/09/xmldsig#sha1"; protocol="application/signature+xml"; transform="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" --bar Content-Type: text/xml; Location: http://test.zolera.com/testdoc.xml <start xmlns="http://spam.com/foo"> <first>Something</first> <second>Second item</second> </start> --bar Content-Type: application/signature+xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE Signature [ <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> ]> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="signature"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> <Reference URI="http://test.zolera.com/testdoc.xml"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>3wCiU/BeKdVr6EZCsx7QtK6sPus=</DigestValue> </Reference> </SignedInfo> <SignatureValue>BDx/XRkeg6a37wZNbqbCzF/bQE8GQ36Q35T4b9kbE6uf42QVhe9BOactW68T 532p6vYAI0ZuAUOLot8TrdhWtg==</SignatureValue> <KeyInfo> <KeyName>firstname.lastname@example.org</KeyName> </KeyInfo> </Signature> --bar
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.
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.
The protocol parameter is required to be "application/xml-encrypted" for XML encryption.
When the XML encrypted content is generated:
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.
An example of a encrypting the content in the first part and placing the ciphervalue in the second part is:
From: Frederick Hirsch <email@example.com> To: Frederick Hirsch <firstname.lastname@example.org> Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/xml-encrypted" --foo Content-Type: application/xml-encrypted <?xml version="1.0"?> <!DOCTYPE EncryptedData [ <!ENTITY enc "http://www.w3.org/2001/04/xmlenc#"> ]> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>John Smith</ds:KeyName> </ds:KeyInfo> <CipherData> <CipherReference URI="cid:33"/> </CipherData> </EncryptedData> --foo Content-Type: application/octet-stream Content-ID: 33 IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/b MJ01EArmKZsR5VW3rwoPxw= --foo--
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 and XML Encryption.
|||Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.|
|||Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object Security Services", RFC 1848, October 1995.|
|||Boyer, J., "Canonical XML, Version 1.0, W3C Recommendation", RFC 3076, March 2001.|
|||Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and Processing", RFC 3075, DRAFT, Obsoletes RFC 3075 , February 2002.|
|||Eastlake, D., Reagle, J., Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML-Encryption Syntax and Processing, WG DRAFT", W3C Working Draft , June 2001.|
|||Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.|
|||Barton, J., Thatte, S. and H. Frystyk, "SOAP Messages with Attachments", W3C Note , December 2000.|
|||Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, Obsoletes 2376, Updates 2048, January 2001.|
|||Clark, J. and S. DeRose, "XML Path Language (XPath), Version 1.0", W3C Recommendation , November 1999.|
|||Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, Informational , June 1999.|
|Frederick J. Hirsch|
|Zolera Systems, Inc.|
|600 W. Cummings Park|
|Woburn, MA 01801|
|Phone:||+1 781 759 1122 x15|
This draft was written using XML. The author appreciates the review by Rich Salz.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.