Internet DRAFT - draft-fhirsch-xml-mime-security
draft-fhirsch-xml-mime-security
Network Working Group F. Hirsch
Internet-Draft Zolera Systems, Inc.
Expires: April 1, 2002 October 1, 2001
XML Security for Multipart MIME: Multipart/Signed and
Multipart/Encrypted
draft-fhirsch-xml-mime-security-00
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.
Hirsch Expires April 1, 2002 [Page 1]
Internet-Draft XML Security for Multipart MIME October 2001
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.
Hirsch Expires April 1, 2002 [Page 2]
Internet-Draft XML Security for Multipart MIME October 2001
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 (Section 3.2). 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 (Section 3).
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]
Hirsch Expires April 1, 2002 [Page 3]
Internet-Draft XML Security for Multipart MIME October 2001
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 (Section 3.3)
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.
Hirsch Expires April 1, 2002 [Page 4]
Internet-Draft XML Security for Multipart MIME October 2001
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):
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"
Hirsch Expires April 1, 2002 [Page 5]
Internet-Draft XML Security for Multipart MIME October 2001
--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.
Hirsch Expires April 1, 2002 [Page 6]
Internet-Draft XML Security for Multipart MIME October 2001
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
Hirsch Expires April 1, 2002 [Page 7]
Internet-Draft XML Security for Multipart MIME October 2001
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.
From: Frederick Hirsch<hirsch@zolera.com>
To: Frederick Hirsch<hirsch@zolera.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>
Hirsch Expires April 1, 2002 [Page 8]
Internet-Draft XML Security for Multipart MIME October 2001
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>3wCiU/BeKdVr6EZCsx7QtK6sPus=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>BDx/XRkeg6a37wZNbqbCzF/bQE8GQ36Q35T4b9kbE6uf42QVhe9BOactW68T
532p6vYAI0ZuAUOLot8TrdhWtg==</SignatureValue>
<KeyInfo>
<KeyName>user@zolera.com</KeyName>
</KeyInfo>
</Signature>
--bar
Hirsch Expires April 1, 2002 [Page 9]
Internet-Draft XML Security for Multipart MIME October 2001
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
Hirsch Expires April 1, 2002 [Page 10]
Internet-Draft XML Security for Multipart MIME October 2001
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:
Hirsch Expires April 1, 2002 [Page 11]
Internet-Draft XML Security for Multipart MIME October 2001
From: Frederick Hirsch <hirsch@zolera.com>
To: Frederick Hirsch <hirsch@zolera.com>
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--
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
Hirsch Expires April 1, 2002 [Page 12]
Internet-Draft XML Security for Multipart MIME October 2001
associated with XML Digital Signatures [4] and XML Encryption [5].
Hirsch Expires April 1, 2002 [Page 13]
Internet-Draft XML Security for Multipart MIME October 2001
References
[1] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[2] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object
Security Services", RFC 1848, October 1995.
[3] Boyer, J., "Canonical XML, Version 1.0, W3C Recommendation",
RFC 3076, March 2001, <http://www.w3.org/TR/xml-c14n>.
[4] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and
Processing", RFC 3075, DRAFT, Obsoletes RFC 3075 , February
2002, <http://www.w3.org/TR/xmldsig-core/>.
[5] 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, <http://www.w3.org/TR/xmlenc-
core/>.
[6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[7] Barton, J., Thatte, S. and H. Frystyk, "SOAP Messages with
Attachments", W3C Note , December 2000,
<http://www.w3.org/TR/SOAP-attachments>.
[8] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, Obsoletes 2376, Updates 2048, January 2001.
[9] Clark, J. and S. DeRose, "XML Path Language (XPath), Version
1.0", W3C Recommendation , November 1999,
<http://www.w3.org/TR/xpath>.
[10] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
Informational , June 1999.
Hirsch Expires April 1, 2002 [Page 14]
Internet-Draft XML Security for Multipart MIME October 2001
Author's Address
Frederick J. Hirsch
Zolera Systems, Inc.
600 W. Cummings Park
Suite 2000
Woburn, MA 01801
US
Phone: +1 781 759 1122 x15
EMail: fjh@alum.mit.edu
URI: http://www.zolera.com/
Hirsch Expires April 1, 2002 [Page 15]
Internet-Draft XML Security for Multipart MIME October 2001
Appendix A. Acknowledgements
This draft was written using XML [10]. The author appreciates the
review by Rich Salz.
Hirsch Expires April 1, 2002 [Page 16]
Internet-Draft XML Security for Multipart MIME October 2001
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.
Hirsch Expires April 1, 2002 [Page 17]
