W3C

XML Encryption Syntax and Processing (追記) Version 1.1 (追記ここまで)

W3C (追記) Proposed (追記ここまで) Recommendation (削除) 10 December 2002 (削除ここまで) (追記) 24 January 2013 (追記ここまで)

This version:
(削除) http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ (削除ここまで) (追記) http://www.w3.org/TR/2013/PR-xmlenc-core1-20130124/ (追記ここまで)
Latest (追記) published (追記ここまで) version:
(削除) http://www.w3.org/TR/xmlenc-core/ (削除ここまで) (追記) http://www.w3.org/TR/xmlenc-core1/ (追記ここまで)
(追記) Latest editor's draft: (追記ここまで)
(追記) http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/ (追記ここまで)
Previous version:
(削除) http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/ (削除ここまで) (追記) http://www.w3.org/TR/2012/WD-xmlenc-core1-20121018/ (追記ここまで)
(追記) Latest recommendation: (追記ここまで)
(削除) Editors (削除ここまで) (追記) http://www.w3.org/TR/xmlenc-core (追記ここまで)
(追記) Editors: (追記ここまで)
Donald Eastlake (削除) <dee3@torque.pothole.com> (削除ここまで) , (追記) d3e3e3@gmail.com (追記ここまで)
Joseph Reagle (削除) <reagle@w3.org> (削除ここまで) , (追記) reagle@mit.edu (追記ここまで)
(削除) Authors (削除ここまで) (追記) Frederick Hirsch (追記ここまで),(追記) frederick.hirsch@nokia.com (追記ここまで) (追記) (1.1) (追記ここまで)
(追記) Thomas Roessler (追記ここまで),(追記) tlr@w3.org (追記ここまで) (追記) (1.1) (追記ここまで)
(追記) Authors: (追記ここまで)
Takeshi Imamura (削除) <IMAMU@jp.ibm.com> (削除ここまで) , (追記) IMAMU@jp.ibm.com (追記ここまで)
Blair Dillaway (削除) <blaird@microsoft.com> (削除ここまで) , (追記) blaird@microsoft.com (追記ここまで)
Ed Simon (削除) <edsimon@xmlsec.com> (削除ここまで) , (削除) Contributors (削除ここまで) (追記) edsimon@xmlsec.com (追記ここまで) (削除) See participants . (削除ここまで)
(削除) Please see the (削除ここまで)
(削除) errata (削除ここまで) (追記) Kelvin Yiu (追記ここまで), (追記) kelviny@microsoft.com (追記ここまで) (削除) for this document, which may include some normative corrections. See also (削除ここまで) (削除) translations (削除ここまで) (追記) (1.1) (追記ここまで)
(削除) . (削除ここまで) (追記) Magnus Nystrテカm (追記ここまで), (追記) mnystrom@microsoft.com (追記ここまで) (追記) (1.1) (追記ここまで)

Copyright (削除) ゥ 2002 (削除ここまで) (追記) ツゥ 2013 (追記ここまで) W3C (削除) ョ (削除ここまで) (追記) ツョ (追記ここまで) ( MIT , (削除) INRIA (削除ここまで) (追記) ERCIM (追記ここまで) , Keio ), All Rights Reserved. W3C liability , trademark (削除) , document use (削除ここまで) and (削除) software licensing (削除ここまで) (追記) document use (追記ここまで) rules apply.


Abstract

This document specifies a process for encrypting data and representing the result in XML. The data may be (削除) arbitrary (削除ここまで) (追記) in a variety of formats, including octet streams and other unstructured data, or structured (追記ここまで) data (削除) (including an (削除ここまで) (追記) formats such as (追記ここまで) XML (削除) document), (削除ここまで) (追記) documents, (追記ここまで) an XML element, or XML element content. The result of encrypting data is an XML Encryption element (削除) which (削除ここまで) (追記) that (追記ここまで) contains or references the cipher data.

Status of (削除) this document (削除ここまで) (追記) This Document (追記ここまで)

This (追記) section describes the status of this (追記ここまで) document (削除) is (削除ここまで) (追記) at the time of its publication. Other documents may supersede this document. A list of current (追記ここまで)(追記) W3C (追記ここまで)(追記) publications and the latest revision of this technical report can be found in the (追記ここまで)(追記) W3C (追記ここまで)(追記) technical reports index (追記ここまで) (追記) at http://www.w3.org/TR/. (追記ここまで)

(追記) At (追記ここまで) the (追記) time of this publication, the most recent (追記ここまで) W3C (追記) Recommendation of XML Encryption 1 is the (追記ここまで)(追記) 10 December 2002 (追記ここまで) XML Encryption Recommendation (削除) (REC) (削除ここまで) . (削除) This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It (削除ここまで)

(追記) The most recent publication of this draft (追記ここまで) is (追記) the (追記ここまで)(追記) Last Call draft of 18 October 2012 (追記ここまで), a (削除) stable document and may be used as reference material or cited as a normative reference (削除ここまで) (追記) return to Last Call (追記ここまで) from (削除) another document. W3C's role (削除ここまで) (追記) Candidate Recommendation to allow review and comment on specific changes noted (追記ここまで) in (削除) making (削除ここまで) (追記) that draft. As noted in that draft, (追記ここまで) the (追記) Working Group planned to progress to Proposed (追記ここまで) Recommendation (削除) is (削除ここまで) (追記) upon completion of the Last Call. (追記ここまで)

(追記) Last Call was completed without formal comment, however the group received subsequent notice of a potential security threat (追記ここまで) to (削除) draw attention (削除ここまで) (追記) implementations, so the group agreed to add an additional security consideration (追記ここまで) to the (削除) specification and (削除ここまで) (追記) informative security considerations section. Thus changes (追記ここまで) to (削除) promote its widespread deployment. This enhances (削除ここまで) the (削除) functionality and interoperability of (削除ここまで) (追記) document since (追記ここまで) the (削除) Web. (削除ここまで) (追記) last publication include the following: (追記ここまで)

(削除) This specification was produced by (削除ここまで) (追記) Please review (追記ここまで) the (削除) W3C (削除ここまで) (追記) differences between the previous Last Call Working Draft and this Proposed Recommendation Working Draft (追記ここまで),(追記) and the (追記ここまで)(追記) differences between the previous (追記ここまで) XML Encryption (追記) Recommendation and this Proposed Recommendation (追記ここまで) Working (削除) Group (削除ここまで) (追記) Draft (追記ここまで) (削除) ( Activity (削除ここまで) (追記) ; a detailed explanation of changes is also available [ (追記ここまで)(追記) XMLENC-CORE1-CHGS (追記ここまで) (削除) ) which believes (削除ここまで) (追記) ]. (追記ここまで)

(追記) The previous Last Call working draft followed Candidate Recommendation since an at-risk feature was moved to an informative appendix due to lack of implementation, (追記ここまで) the (削除) specification is sufficient (削除ここまで) (追記) requirement (追記ここまで) for (削除) the creation of independent interoperable implementations as demonstrated (削除ここまで) (追記) an algorithm implementation was changed due to security concerns, an additional algorithm identifier was added and additional clarifications made based on review during implementation. This Last Call resulted (追記ここまで) in (追記) an adding a security consideration to address new research related to security threats but with no objection to (追記ここまで) the (削除) Interoperability Report. (削除ここまで) (追記) changes resulting in Last Call. (追記ここまで)

(削除) Patent disclosures relevant (削除ここまで) (追記) Conformance-affecting changes against the previous recommendation mainly affect the set of mandatory (追記ここまで) to (削除) this specification may be found on (削除ここまで) (追記) implement cryptographic algorithms, by adding Elliptic Curve Diffie-Hellman Key Agreement, making AES-128 GCM mandatory, changing RSA v1.5 to optional, adding optional AES192-GCM and adding optional RSA-OEAP algorithm variants. (追記ここまで)

(追記) This document was published by (追記ここまで) the (追記) XML Security (追記ここまで) Working (削除) Group's patent disclosure page (削除ここまで) (追記) Group (追記ここまで) (削除) in conformance with (削除ここまで) (追記) as a Proposed Recommendation. This document is intended to become a (追記ここまで) W3C (削除) policy. Please report errors in this (削除ここまで) (追記) Recommendation. The (追記ここまで)(追記) W3C (追記ここまで)(追記) Membership and other interested parties are invited to review the (追記ここまで) document (追記) and send comments (追記ここまで) to (削除) xml-encryption@w3.org (削除ここまで) (追記) public-xmlsec@w3.org (追記ここまで) ( (削除) public archive (削除ここまで) (追記) subscribe (追記ここまで),(追記) archives (追記ここまで) (削除) ). (削除ここまで) (追記) ) through 25 February 2013. Advisory Committee Representatives should consult their (追記ここまで)(追記) WBS questionnaires (追記ここまで).(追記) Note that substantive technical comments were expected during the Last Call review period that ended 13 March 2012. (追記ここまで)

(削除) The list of known errors in this specification is available at http://www.w3.org/Encryption/2002/12-xmlenc-errata (削除ここまで) (追記) Please see the Working Group's (追記ここまで)(追記) implementation report (追記ここまで) .

(削除) The English version of this specification is (削除ここまで) (追記) Publication as a Proposed Recommendation does not imply endorsement by (追記ここまで) the (削除) only normative version. Information about translations of this (削除ここまで) (追記) W3C (追記ここまで)(追記) Membership. This is a draft (追記ここまで) document (削除) (if any) (削除ここまで) (追記) and may be updated, replaced or obsoleted by other documents at any time. It (追記ここまで) is (削除) available http://www.w3.org/Encryption/2002/12-xmlenc-translations . (削除ここまで) (追記) inappropriate to cite this document as other than work in progress. (追記ここまで)

(削除) A (削除ここまで) (追記) This document was produced by a group operating under the (追記ここまで)(追記) 5 February 2004 (追記ここまで)(追記) W3C (追記ここまで)(追記) Patent Policy (追記ここまで).(追記) W3C (追記ここまで)(追記) maintains a (追記ここまで)(追記) public (追記ここまで) list of (削除) current (削除ここまで) (追記) any patent disclosures (追記ここまで) (追記) made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains (追記ここまで)(追記) Essential Claim(s) (追記ここまで) (追記) must disclose the information in accordance with (追記ここまで)(追記) section 6 of the (追記ここまで) W3C (削除) Recommendations and other technical documents can be found at http://www.w3.org/TR/ (削除ここまで) (追記) Patent Policy (追記ここまで) .

(削除) Table (削除ここまで) (追記) Additional information related to the IPR status (追記ここまで) of (削除) Contents (削除ここまで) (追記) XML Encryption 1.1 (追記ここまで) (追記) is also available. (追記ここまで)

(追記) Table of Contents (追記ここまで)

(追記) 1. (追記ここまで)(追記) Introduction (追記ここまで)

This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element (削除) which (削除ここまで) (追記) that (追記ここまで) contains (via one of its children's content) or identifies (via a URI reference) the cipher data.

When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document.

When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document.

1.1 Editorial and Conformance Conventions

This specification uses XML schemas [ (削除) XML-schema (削除ここまで) (追記) XMLSCHEMA-1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) XMLSCHEMA-2 (追記ここまで) ] to describe the content model. (追記) The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions. (追記ここまで)

The key words (削除) "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", (削除ここまで) (追記) " (追記ここまで)(追記) must (追記ここまで)(追記) ", " (追記ここまで)(追記) must not (追記ここまで)(追記) ", " (追記ここまで)(追記) required (追記ここまで)(追記) ", " (追記ここまで)(追記) shall (追記ここまで)(追記) ", " (追記ここまで)(追記) shall not (追記ここまで)(追記) ", " (追記ここまで)(追記) should (追記ここまで)(追記) ", " (追記ここまで)(追記) should not (追記ここまで)(追記) ", " (追記ここまで)(追記) recommended (追記ここまで)(追記) ", " (追記ここまで)(追記) may (追記ここまで)(追記) ", (追記ここまで) and (削除) "OPTIONAL" (削除ここまで) (追記) " (追記ここまで)(追記) optional (追記ここまで)(追記) " (追記ここまで) in this specification are to be interpreted as described in (削除) RFC2119 (削除ここまで) [ (削除) KEYWORDS (削除ここまで) (追記) RFC2119 (追記ここまで) ]:

(削除) "they MUST (削除ここまで) (追記) "They (追記ここまで)(追記) must (追記ここまで) only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being (削除) "optional." (削除ここまで) (追記) "optional". (追記ここまで) Compliance with the XML-namespace specification [ (削除) XML-NS (削除ここまで) (追記) XML-NAMES (追記ここまで) ] is described as (削除) "REQUIRED." (削除ここまで) (追記) " (追記ここまで)(追記) required (追記ここまで)(追記) ". (追記ここまで)

1.2 Design Philosophy

The design philosophy and requirements of this specification (including the limitations related to instance validity) are addressed in the (追記) original (追記ここまで) XML Encryption Requirements [ (削除) EncReq (削除ここまで) (追記) XML-ENCRYPTION-REQ (追記ここまで) (追記) ] and the XML Security 1.1 Requirements document [ (追記ここまで)(追記) XMLSEC11-REQS (追記ここまで) ].

1.3 (削除) Versions , (削除ここまで) (追記) Versions, (追記ここまで) Namespaces, URIs, and Identifiers

(削除) No provision is made for an explicit version number in this syntax. If a future version is needed, it will (削除ここまで) (追記) This specification makes (追記ここまで) use (削除) a different namespace. The experimental (削除ここまで) (追記) of (追記ここまで) XML (削除) namespace (削除ここまで) (追記) namespaces, and uses Uniform Resource Identifiers (追記ここまで) [ (削除) XML-NS (削除ここまで) (追記) URI (追記ここまで) ] (削除) URI that MUST be used by implementations (削除ここまで) (追記) to identify resources, algorithms, and semantics. (追記ここまで)

(追記) Implementations (追記ここまで) of this (削除) (dated) (削除ここまで) specification (削除) is: (削除ここまで) (追記) must (追記ここまで)(追記) use the following XML namespace URIs: (追記ここまで)

(削除) xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' This (削除ここまで)
(追記) URI (追記ここまで) namespace (削除) is also used as the (削除ここまで) prefix (削除) for algorithm identifiers used by this specification. While applications MUST support XML and (削除ここまで) XML (削除) namespaces, the use of (削除ここまで) internal (削除) entities [ XML , section 4.2.1], the " (削除ここまで) (追記) entity (追記ここまで)
(削除) xenc (削除ここまで) (追記) http://www.w3.org/2001/04/xmlenc# (追記ここまで) (削除) " XML (削除ここまで) (追記) default (追記ここまで) namespace (削除) prefix [ XML-NS , section 2] and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples. Additionally, the entity (削除ここまで) , (削除) &xenc; (削除ここまで) (追記) xenc: (追記ここまで) (削除) is defined so as to provide short-hand identifiers for URIs defined (削除ここまで) (追記) <!ENTITY xenc "http://www.w3.org/2001/04/xmlenc#"> (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11# (追記ここまで)(追記) xenc11: (追記ここまで)(追記) <!ENTITY xenc11 "http://www.w3.org/2009/xmlenc11#"> (追記ここまで)

(追記) The (追記ここまで)(追記) http://www.w3.org/2001/04/xmlenc# (追記ここまで)(追記) ( (追記ここまで)(追記) xenc: (追記ここまで)(追記) ) namespace was introduced (追記ここまで) in (追記) version 1.0 of (追記ここまで) this specification. (削除) For example " (削除ここまで) (追記) The present version does not coin any new elements or algorithm identifiers in that namespace; instead, the (追記ここまで) (削除) &xenc;Element" (削除ここまで) (追記) http://www.w3.org/2009/xmlenc11# (追記ここまで) (削除) corresponds to "http://www.w3.org/2001/04/xmlenc#Element". (削除ここまで) (追記) ( (追記ここまで)(追記) xenc11: (追記ここまで)(追記) ) namespace is used. (追記ここまで)

(削除) This (削除ここまで) (追記) No provision is made for an explicit version number in this syntax. If a future version of this (追記ここまで) specification (削除) makes use (削除ここまで) (追記) requires explicit versioning (追記ここまで) of the (削除) XML Signature [ XML-DSIG ] (削除ここまで) (追記) document format, a different (追記ここまで) namespace (削除) and schema definitions (削除ここまで) (追記) will be used. (追記ここまで)

(削除) xmlns:ds='http://www.w3.org/2000/09/xmldsig#' (削除ここまで)

(削除) URIs [ URI ] MUST abide by the [ XML-Schema ] anyURI type definition (削除ここまで) (追記) Additionally, this specification uses elements (追記ここまで) and (追記) algorithm identifiers from (追記ここまで) the (追記) XML Signature name spaces (追記ここまで) [ (削除) XML-DSIG , 4.3.3.1 The URI Attribute (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) (削除) ] specification (i.e., permitted characters, character escaping, scheme support, etc.). (削除ここまで) (追記) ]: (追記ここまで)

(追記) URI (追記ここまで)(追記) namespace prefix (追記ここまで)(追記) XML internal entity (追記ここまで)
(追記) http://www.w3.org/2000/09/xmldsig# (追記ここまで)(追記) default namespace (追記ここまで),(追記) ds: (追記ここまで),(追記) dsig: (追記ここまで)(追記) <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> (追記ここまで)
(追記) http://www.w3.org/2009/xmldsig11# (追記ここまで)(追記) dsig11: (追記ここまで)(追記) <!ENTITY dsig11 "http://www.w3.org/2009/xmldsig11#"> (追記ここまで)

(削除) 1.4 Acknowledgements (削除ここまで) (追記) 1.4 (追記ここまで)(追記) Acknowledgements (追記ここまで)

The contributions of the following Working Group members to this specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster (削除) . (削除ここまで) : Joseph (削除) Ashwood (削除ここまで) (追記) Ashwood, (追記ここまで) Simon Blake-Wilson, (削除) Certicom (削除ここまで) (追記) Certicom, (追記ここまで) Frank D. Cavallito, BEA (削除) Systems (削除ここまで) (追記) Systems, (追記ここまで) Eric Cohen, (削除) PricewaterhouseCoopers (削除ここまで) (追記) PricewaterhouseCoopers, (追記ここまで) Blair Dillaway, Microsoft (削除) (Author) (削除ここまで) (追記) (Author), (追記ここまで) Blake Dournaee, RSA (削除) Security (削除ここまで) (追記) Security, (追記ここまで) Donald Eastlake, Motorola (削除) (Editor) (削除ここまで) (追記) (Editor), (追記ここまで) Barb Fox, (削除) Microsoft (削除ここまで) (追記) Microsoft, (追記ここまで) Christian Geuer-Pollmann, University of (削除) Siegen (削除ここまで) (追記) Siegen, (追記ここまで) Tom Gindin, (削除) IBM (削除ここまで) (追記) IBM, (追記ここまで) Jiandong Guo, (削除) Phaos (削除ここまで) (追記) Phaos, (追記ここまで) Phillip Hallam-Baker, (削除) Verisign (削除ここまで) (追記) Verisign, (追記ここまで) Amir Herzberg, (削除) NewGenPay (削除ここまで) (追記) NewGenPay, (追記ここまで) Merlin Hughes, (削除) Baltimore (削除ここまで) (追記) Baltimore, (追記ここまで) Frederick (削除) Hirsch (削除ここまで) (追記) Hirsch, (追記ここまで) Maryann Hondo, (削除) IBM (削除ここまで) (追記) IBM, (追記ここまで) Takeshi Imamura, IBM (削除) (Author) (削除ここまで) (追記) (Author), (追記ここまで) Mike Just, Entrust, (削除) Inc. (削除ここまで) (追記) Inc., (追記ここまで) Brian LaMacchia, (削除) Microsoft (削除ここまで) (追記) Microsoft, (追記ここまで) Hiroshi Maruyama, (削除) IBM (削除ここまで) (追記) IBM, (追記ここまで) John Messing, (削除) Law-on-Line (削除ここまで) (追記) Law-on-Line, (追記ここまで) Shivaram Mysore, Sun (削除) Microsystems (削除ここまで) (追記) Microsystems, (追記ここまで) Thane Plambeck, (削除) Verisign (削除ここまで) (追記) Verisign, (追記ここまで) Joseph Reagle, W3C (Chair, (削除) Editor) (削除ここまで) (追記) Editor), (追記ここまで) Aleksey (削除) Sanin (削除ここまで) (追記) Sanin, (追記ここまで) Jim Schaad, Soaring Hawk (削除) Consulting (削除ここまで) (追記) Consulting, (追記ここまで) Ed Simon, XMLsec (削除) (Author) (削除ここまで) (追記) (Author), (追記ここまで) Daniel Toth, (削除) Ford (削除ここまで) (追記) Ford, (追記ここまで) Yongge Wang, (削除) Certicom (削除ここまで) (追記) Certicom, (追記ここまで) Steve Wiley, (削除) myProof (削除ここまで) (追記) myProof. (追記ここまで)

Additionally, we thank the following for their comments during and subsequent to Last Call: Martin (削除) D?rst, (削除ここまで) (追記) Dテシrst, (追記ここまで) W3C , Dan Lanz, (削除) Zolera (削除ここまで) (追記) Zolera, (追記ここまで) Susan Lesch, W3C , David Orchard, BEA (削除) Systems (削除ここまで) (追記) Systems, (追記ここまで) Ronald Rivest, MIT .

(追記) Contributions for version 1.1 were received from the members of the XML Security Working Group: Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar, Ken Graf, Phillip Hallam-Baker, Brad Hill, Frederick Hirsch, Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob Miller, Sean Mullan, Shivaram Mysore, Magnus Nystrテカm, Bruce Rich, Thomas Roessler, Ed Simon, Chris Solc, John Wray, Kelvin Yiu. (追記ここまで)

(追記) The working group also acknowledges the contribution of Juraj Somorovsky raising the issue of the CBC chosen ciphertext attack and contributions to revising the security considerations of XML Encryption 1.1. (追記ここまで)

(削除) 2 (削除ここまで) (追記) 2. (追記ここまで) Encryption Overview and Examples (削除) (Non-normative) (削除ここまで)

(追記) This section is non-normative. (追記ここまで)

This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in (追記) section 3. (追記ここまで) Encryption Syntax (削除) (section 3); (削除ここまで) (追記) ; (追記ここまで) the specific processing is given in Processing Rules (section 4).

Expressed in shorthand form, the EncryptedData element has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences; (追記) "|" denotes a choice; (追記ここまで) and the empty element tag means the element must be empty ):

(削除) <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> (削除ここまで)

The CipherData element envelopes or references the raw encrypted data. (追記) A (追記ここまで)(追記) CipherData (追記ここまで)(追記) element must have either a (追記ここまで)(追記) CipherValue (追記ここまで)(追記) or (追記ここまで)(追記) CipherReference (追記ここまで)(追記) child element. (追記ここまで) If enveloping, the raw encrypted data is the CipherValue element's content; if referencing, the CipherReference element's URI attribute points to the location of the raw encrypted data

2.1 Encryption Granularity

(追記) This section is non-normative. (追記ここまで)

(追記) Note: Examples in this document do not consider plaintext guessing attacks or other risks, and are only for illustrative purposes. (追記ここまで)

Consider the following fictitious payment information, which includes identification information and information appropriate to a payment method (e.g., credit card, money transfer, or electronic check):

(削除) <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> (削除ここまで)

This markup represents that John Smith is using his credit card with a limit of 5,000ドルUSD.

2.1.1 Encrypting an XML Element

(追記) This section is non-normative. (追記ここまで)

Smith's credit card number is sensitive information! If the application wishes to keep that information confidential, it can encrypt the CreditCard element:

(削除) <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> (削除ここまで)

By encrypting the entire CreditCard element from its start to end tags, the identity of the element itself is hidden. (An eavesdropper doesn't know whether he used a credit card or money transfer.) The CipherData element contains the encrypted serialization of the CreditCard element.

2.1.2 Encrypting XML Element Content (Elements)

As an alternative scenario, it may be useful for intermediate agents to know that John used a credit card with a particular limit, but not the card's number, issuer, and expiration date. In this case, the content (character data or children elements) of the CreditCard element (削除) is (削除ここまで) (追記) can be (追記ここまで) encrypted:

(削除) <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </CreditCard> </PaymentInfo> (削除ここまで)

2.1.3 Encrypting XML Element Content (Character Data)

(削除) Or, (削除ここまで) (追記) Alternatively, (追記ここまで) consider the scenario in which all the information except the actual credit card number can be in the clear, including the fact that the Number element exists:

(削除) <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </a> </a> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> (削除ここまで)

Both CreditCard and Number are in the clear, but the character data content of Number is encrypted.

2.1.4 Encrypting Arbitrary Data and XML Documents

If the application scenario requires all of the information to be encrypted, the whole document is encrypted as an octet sequence. This applies to arbitrary data including XML documents.

(削除) <?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </a> </ EncryptedDat a> (削除ここまで)

(追記) Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute (追記ここまで)(追記) should (追記ここまで)(追記) be provided and indicate the use of EXI. The optional MimeType (追記ここまで)(追記) may (追記ここまで)(追記) be used to record the actual (non-EXI-encoded) type, but is not necessary and may be omitted, as in the following EXI encryption example: (追記ここまで)

2.1.5 (削除) Super-Encryption : (削除ここまで) (追記) Super-Encryption: (追記ここまで) Encrypting EncryptedData

An XML document may contain zero or more EncryptedData elements. EncryptedData cannot be the parent or child of another EncryptedData element. However, the actual data encrypted can be anything, including EncryptedData and EncryptedKey elements (i.e., super-encryption). During super-encryption of an EncryptedData or EncryptedKey element, one must encrypt the entire element. Encrypting only the content of these elements, or encrypting selected child elements is an invalid instance under the provided schema.

For example, consider the following:

(削除) xmlns:pay='http://example.org/paymentv2'> <EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#' Type=''> <CipherData> <CipherValue>EncryptedData</CipherValue> </CipherData> </EncryptedData> </pay:PaymentInfo> (削除ここまで)

A valid super-encryption of " //xenc:EncryptedData[@Id='ED1'] " would be:

(削除) xmlns:pay='http://example.org/paymentv2'> <EncryptedData Id='ED2' xmlns='http://www.w3.org/2001/04/xmlenc#' Type=''> <CipherData> <CipherValue>EncryptedData</CipherValue> </a> </a> </ pay:PaymentInf o> (削除ここまで)

where the CipherValue content of ' newEncryptedData ' is the base64 encoding of the encrypted octet sequence resulting from encrypting the EncryptedData element with Id='ED1' .

2.2 EncryptedData and EncryptedKey Usage

2.2.1 EncryptedData with Symmetric Key (削除) (削除ここまで) ( KeyName )

(削除) [s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type=''/> [s2] <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> [s3] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [s4] <ds:KeyName>John Smith</e> [s5] </ds:KeyInfo> [s6] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> [s7] </EncryptedData> (削除ここまで)

[s1] The type of data encrypted may be represented as an attribute value to aid in decryption and subsequent processing. In this case, the data encrypted was an 'element'. Other alternatives include 'content' of an element, or an external octet sequence which can also be identified via the MimeType and Encoding attributes.

[s2] This (3DES CBC) is a symmetric key cipher.

[s4] The symmetric key has an associated name "John Smith".

[s6] CipherData contains a CipherValue , which is a base64 encoded octet sequence. Alternately, it could contain a CipherReference , which is a URI reference along with transforms necessary to obtain the encrypted data as an octet sequence

2.2.2 EncryptedKey ( ReferenceList , ds:RetrievalMethod , CarriedKeyName )

The following EncryptedData structure is very similar to the one above, except this time the key is referenced using a ds:RetrievalMethod :

(削除) [t01] <EncryptedData Id='ED' xmlns='http://www.w3.org/2001/04/xmlenc#'> [t02] <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/> [t03] <d xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t04] <ds: URI='#EK' Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> [t05] <ds:KeyName>Sally Doe</ds:KeyName> [t06] </ds:KeyInfo> [t07] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> [t08] </EncryptedData> (削除ここまで)

[t02] This (AES-128-CBC) is a symmetric key cipher.

[t04] ds:RetrievalMethod is used to indicate the location of a key with type (削除) &xenc;EncryptedKey (削除ここまで) (追記) xenc:EncryptedKey (追記ここまで) . The (AES) key is located at '#EK'.

[t05] ds:KeyName provides an alternative method of identifying the key needed to decrypt the CipherData . Either or both the ds:KeyName and ds:KeyRetrievalMethod could be used to identify the same key.

Within the same XML document, there existed an EncryptedKey structure that was referenced within [t04] :

(削除) [t09] <EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'> [t10] <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> [t11] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t12] <ds:KeyName>John Smith</e> [t13] </ds:KeyInfo> [t14] <CipherData><CipherValue>xyzabc</CipherValue></CipherData> [t15] <ReferenceList> [t16] <DataReference URI='#ED'/> [t17] </ReferenceList> [t18] <CarriedKeyName>Sally Doe</CarriedKeyName> [t19] </EncryptedKey> (削除ここまで)

[t09] The EncryptedKey element is similar to the EncryptedData element except that the data encrypted is always a key value.

[t10] The EncryptionMethod is the RSA public key algorithm.

[t12] ds:KeyName of "John Smith" is a property of the key necessary for decrypting (using RSA) the CipherData .

[t14] The CipherData 's CipherValue is an octet sequence that is processed (serialized, encrypted, and encoded) by a referring encrypted object's EncryptionMethod . (Note, an EncryptedKey's EncryptionMethod is the algorithm used to encrypt these octets and does not speak about what type of octets they are.)

[t15-17] A ReferenceList identifies the encrypted objects ( DataReference and KeyReference ) encrypted with this key. The ReferenceList contains a list of references to data encrypted by the symmetric key carried within this structure.

[t18] The CarriedKeyName element is used to identify the encrypted key value which may be referenced by the KeyName element in ds:KeyInfo . (Since ID attribute values must be unique to a document, CarriedKeyName can indicate that several EncryptedKey structures contain the same key value encrypted for different recipients.)

(削除) 3 (削除ここまで)

(追記) 3. (追記ここまで) Encryption Syntax

This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section (削除) MUST (削除ここまで) (追記) must (追記ここまで) be implemented unless otherwise noted. The syntax is defined via [ (削除) XML-Schema (削除ここまで) (追記) XMLSCHEMA-1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) XMLSCHEMA-2 (追記ここまで) ] with the following XML preamble, declaration, internal entity, and import:

(削除) Schema Definition: (削除ここまで)
(削除) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ATTLIST schema xmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#' xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'> <!ENTITY xenc 'http://www.w3.org/2001/04/xmlenc#'> <!ENTITY % p ''> <!ENTITY % s ''> ]> <schema xmlns='http://www.w3.org/2001/XMLSchema' version='1.0' xmlns:ds='http://www.w3.org/2000/09/xmldsig#' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' targetNamespace='http://www.w3.org/2001/04/xmlenc#' element='qualified'> (削除ここまで)
(追記) (Note: A newline has been added to the schemaLocation URI to fit on this page, but is not part of the URI.) (追記ここまで)

(追記) Additional markup defined in this specification uses the (追記ここまで)(追記) xenc11: (追記ここまで)(追記) namespace. The syntax is defined in an XML schema with the following preamble: (追記ここまで)

(削除) <import namespace='http://www.w3.org/2000/09/xmldsig#' schemaLocation='http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd'/> (削除ここまで)
(追記) (Note: A newline has been added to the schemaLocation URI to fit on this page, but is not part of the URI.) (追記ここまで)

3.1 The EncryptedType Element

EncryptedType is the abstract type from which EncryptedData and EncryptedKey are derived. While these two latter element types are very similar with respect to their content models, a syntactical distinction is useful to processing. (削除) Implementation MUST (削除ここまで) (追記) Implementations (追記ここまで)(追記) must (追記ここまで) generate laxly schema valid [ (削除) XML-schema (削除ここまで) (追記) XMLSCHEMA-1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) XMLSCHEMA-2 (追記ここまで) ] EncryptedData or EncryptedKey (追記) elements (追記ここまで) as specified by the subsequent schema declarations. (Note the laxly schema valid generation means that the content permitted by xsd:ANY need not be valid.) Implementations (削除) SHOULD (削除ここまで) (追記) should (追記ここまで) create these XML structures ( EncryptedType elements and their (削除) descendents/content) (削除ここまで) (追記) descendants/content) (追記ここまで) in Normalization Form C [ NFC (削除) , NFC-Corrigendum (削除ここまで) ].

(削除) Schema Definition: (削除ここまで)
(削除) <complexType name='' abstract='true'> <sequence> <element name='' minOccurs='0'/> <element ref='' minOccurs='0'/> <element ref=''/> <element ref='xenc:EncryptionProperties' minOccurs='0'/> </sequence> <attribute name='Id' type='ID' use='optional'/> <attribute name='Type' type='anyURI' use='optional'/> <attribute name='MimeType' type='string' use='optional'/> <attribute name='Encoding' type='anyURI' use='optional'/> </complexType> (削除ここまで)

EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm must be known by the recipient or the decryption will fail.

ds:KeyInfo is an optional element, defined by [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ], that carries information about the key used to encrypt the data. Subsequent sections of this specification define new elements that may appear as children of ds:KeyInfo .

CipherData is a mandatory element that contains the CipherValue or CipherReference with the encrypted data.

EncryptionProperties can contain additional information concerning the generation of the EncryptedType (e.g., date/time stamp).

Id is an optional attribute providing for the standard method of assigning a string id to the element within the document context.

Type is an optional attribute identifying type information about the plaintext form of the encrypted content. While optional, this specification takes advantage of it for (削除) mandatory (削除ここまで) processing described in (削除) Processing Rules: (削除ここまで) (追記) section 4.4 (追記ここまで) Decryption (削除) (section 4.2). (削除ここまで) . If the EncryptedData element contains data of Type 'element' or element 'content', and replaces that data in an XML document context, (追記) or contains data of (追記ここまで)(追記) Type (追記ここまで)(追記) 'EXI', (追記ここまで) it is strongly recommended the Type attribute be provided. Without this information, the decryptor will be unable to automatically restore the XML document to its original cleartext form.

MimeType is an optional (advisory) attribute which describes the media type of the data which has been encrypted. The value of this attribute is a string with values defined by [ (削除) MIME (削除ここまで) (追記) RFC2045 (追記ここまで) ]. For example, if the data that is encrypted is a base64 encoded PNG, the transfer Encoding may be specified as ' http://www.w3.org/2000/09/xmldsig#base64 ' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required and it does not indicate the encryption application must do any additional processing. Note, this information may not be necessary if it is already bound to the identifier in the Type attribute. For example, the Element and Content types defined in this specification are always UTF-8 encoded text. (追記) In the case of Type EXI the MimeType attribute is not necessary, but if used should reflect the underlying type and not "EXI". (追記ここまで)

(追記) Encoding (追記ここまで)(追記) is an optional (advisory) attribute which describes the transfer encoding of the data that has been encrypted. (追記ここまで)

3.2 The EncryptionMethod Element

EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm must be known (削除) by (削除ここまで) (追記) to (追記ここまで) the recipient or the decryption will fail.

(削除) Schema Definition: (削除ここまで)
(削除) <complexType name='EncryptionMethodType' mixed='true'> <sequence> <element name='KeySize' minOccurs='0' type='xenc:KeySizeType'/> <element name='OAEPparams' minOccurs='0' type='base64Binary'/> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='Algorithm' type='anyURI' use='required'/> </complexType> (削除ここまで)

The permitted child elements of the EncryptionMethod are determined by the specific value of the Algorithm attribute URI, and the KeySize child element is always permitted. For example, the RSA-OAEP algorithm (追記) ( (追記ここまで)(追記) section 5.5.2 RSA-OAEP (追記ここまで) (削除) (section 5.4.2) (削除ここまで) (追記) ) (追記ここまで) uses the ds:DigestMethod and OAEPparams (削除) elements. (削除ここまで) (追記) elements, and may use the (追記ここまで)(追記) xenc11:MGF (追記ここまで)(追記) element when needed. (追記ここまで) (We rely upon the ANY schema construct because it is not possible to specify element content based on the value of an attribute.)

The presence of any child element under EncryptionMethod (削除) which (削除ここまで) (追記) that (追記ここまで) is not permitted by the algorithm or the presence of a KeySize child inconsistent with the algorithm (削除) MUST (削除ここまで) (追記) must (追記ここまで) be treated as an error. (All algorithm URIs specified in this document imply a key size but this is not true in general. Most popular stream cipher algorithms take variable size keys.)

3.3 The CipherData Element

The CipherData is a mandatory element that provides the encrypted data. It must either contain the encrypted octet sequence as base64 encoded text (追記) as element content (追記ここまで) of the CipherValue element, or provide a reference to an external location containing the encrypted octet sequence via the CipherReference element.

(削除) Schema Definition: (削除ここまで)
(削除) <element name=''/> <complexType name=''> <choice> <element name='' type='base64Binary'/> <element ref=''/> </choice> </complexType> (削除ここまで)

3.3.1 The CipherReference Element

If CipherValue is not supplied directly, the CipherReference identifies a source which, when processed, yields the encrypted octet sequence.

The actual value is obtained as follows. The CipherReference URI contains an identifier that is dereferenced. Should the CipherReference element contain an (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) sequence of Transform s, the data resulting from dereferencing the URI is transformed as specified so as to yield the intended cipher value. For example, if the value is base64 encoded within an XML document; the transforms could specify an XPath expression followed by a base64 decoding so as to extract the octets.

The syntax of the URI and Transforms is (削除) similar to that of (削除ここまで) (追記) defined in XML Signature (追記ここまで) [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) (削除) ]. However, there (削除ここまで) (追記) ], however XML Encryption places the (追記ここまで)(追記) Transforms (追記ここまで)(追記) element in the XML Encryption namespace since it (追記ここまで) is (削除) a difference between signature and encryption processing. (削除ここまで) (追記) used in XML Encryption to obtain an octet stream for decryption. (追記ここまで) In [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ] both generation and validation processing start with the same source data and perform that transform in the same order. In encryption, the decryptor has only the cipher data and the specified transforms are enumerated for the decryptor, in the order necessary to obtain the octets. Consequently, because it has different semantics Transforms is in the (削除) &xenc; (削除ここまで) (追記) xenc: (追記ここまで) namespace.

For example, if the relevant cipher value is captured within a CipherValue element within a different XML document, the CipherReference might look as follows:

(削除) <CipherReference URI="http://www.example.com/CipherValues.xml"> <Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath xmlns:rep="http://www.example.org/repository"> self::text()[parent::rep:CipherValue[@Id="example1"]] </ds:XPath> </ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/> </Transforms> </CipherReference> (削除ここまで)

Implementations (削除) MUST (削除ここまで) (追記) must (追記ここまで) support the CipherReference feature and the same URI encoding, dereferencing, scheme, and HTTP response codes as that of [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ]. The Transform feature and particular transform algorithms are (削除) OPTIONAL. (削除ここまで) (追記) optional (追記ここまで).

(削除) Schema Definition: (削除ここまで)
(削除) <element name=''/> <complexType name=''> <sequence> <element name='Transforms' type='xenc:TransformsType' minOccurs='0'/> </sequence> <attribute name='URI' type='anyURI' use='required'/> </complexType> (削除ここまで)

(削除) <complexType name='TransformsType'> <sequence> <element ref='ds:Transform' maxOccurs='unbounded'/> </sequence> </complexType> (削除ここまで) 3.4 The EncryptedData Element

The EncryptedData element is the core element in the syntax. Not only does its CipherData child contain the encrypted data, but it's also the element that replaces the encrypted element, or (追記) element content, or (追記ここまで) serves as the new document root.

(削除) Schema Definition: (削除ここまで)
(削除) <element name=''/> <complexType name=''> <complexContent> <extension base=''> </extension> </complexContent> </complexType> (削除ここまで)

3.5 Extensions to ds:KeyInfo Element

There are three ways that the keying material needed to decrypt CipherData can be provided:

  1. The EncryptedData or EncryptedKey element specify the associated keying material via a child of ds:KeyInfo . All of the child elements of ds: KeyInfo specified in [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ] (削除) MAY (削除ここまで) (追記) may (追記ここまで) be used as qualified:
    1. Support for ds:KeyValue is (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) and may be used to transport public keys, such as (追記) Diffie-Hellman Key Values ( (追記ここまで)(追記) section 5.6.1 (追記ここまで) Diffie-Hellman Key Values (削除) (section 5.5.1). (削除ここまで) (追記) ). (追記ここまで) (Including the plaintext decryption key, whether a private key or a secret key, is obviously (削除) NOT RECOMMENDED.) (削除ここまで) (追記) not recommended (追記ここまで).)
    2. Support of ds:KeyName to refer to an EncryptedKey CarriedKeyName is (削除) RECOMMENDED. (削除ここまで) (追記) recommended (追記ここまで).
    3. Support for same document ds:RetrievalMethod is (削除) REQUIRED. (削除ここまで) (追記) required (追記ここまで).

    In addition, we provide two additional child elements: applications (削除) MUST (削除ここまで) (追記) must (追記ここまで) support EncryptedKey (削除) (section 3.5.1) (削除ここまで) (追記) ( (追記ここまで)(追記) section 3.5.1 The EncryptedKey Element (追記ここまで) (追記) ) (追記ここまで) and (削除) MAY (削除ここまで) (追記) may (追記ここまで) support AgreementMethod (削除) (section 5.5). (削除ここまで) (追記) ( (追記ここまで)(追記) section 5.6 Key Agreement (追記ここまで) (追記) ). (追記ここまで)

  2. A detached (not inside ds:KeyInfo ) EncryptedKey element can specify the EncryptedData or EncryptedKey to which its decrypted key will apply via a DataReference or KeyReference (追記) ( (追記ここまで)(追記) section 3.6 The ReferenceList Element (追記ここまで) (削除) (section 3.6). (削除ここまで) (追記) ). (追記ここまで)
  3. The keying material can be determined by the recipient by application context and thus need not be explicitly mentioned in the transmitted XML.

3.5.1 The EncryptedKey Element

(削除) Identifer (削除ここまで) (追記) Identifier (追記ここまで)
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"

(This can be used within a ds:RetrievalMethod element to identify the referent's type.)

The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an EncryptedData element as a child of a ds:KeyInfo element. The key value is always encrypted to the recipient(s). When EncryptedKey is decrypted the resulting octets are made available to the EncryptionMethod algorithm without any additional processing.

(削除) Schema Definition: (削除ここまで)
(削除) <element name=''/> <complexType name=''> <complexContent> <extension base=''> <sequence> <element ref='' minOccurs='0'/> <element name='' type='string' minOccurs='0'/> </sequence> <attribute name='Recipient' type='string' use='optional'/> </extension> </complexContent> </complexType> (削除ここまで)

ReferenceList is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to EncryptedKey and EncryptedData elements. This is done using KeyReference and DataReference elements respectively. These are defined below.

CarriedKeyName is an optional element for associating a user readable name with the key value. This may then be used to reference the key using the ds:KeyName element within ds:KeyInfo . The same CarriedKeyName label, unlike an ID type, may occur multiple times within a single document. The value of the key (削除) is to (削除ここまで) (追記) must (追記ここまで) be the same in all EncryptedKey elements identified with the same CarriedKeyName label within a single XML document. Note that because whitespace is significant in the value of the ds:KeyName element, whitespace is also significant in the value of the CarriedKeyName element.

Recipient is an optional attribute that contains a hint as to which recipient this encrypted key value is intended for. Its contents are application dependent.

The Type attribute (削除) inheritted (削除ここまで) (追記) inherited (追記ここまで) from EncryptedType can be used to further specify the type of the encrypted key if the EncryptionMethod Algorithm does not define a unambiguous encoding/representation. (Note, all the algorithms in this specification have an (削除) unambigous (削除ここまで) (追記) unambiguous (追記ここまで) representation for their associated key structures.)

3.5.2 The (追記) DerivedKey (追記ここまで)(追記) Element (追記ここまで)

(追記) Identifier (追記ここまで)
(追記) Type="http://www.w3.org/2009/xmlenc11#DerivedKey" (追記ここまで)

(追記) (This can be used within a (追記ここまで) ds:RetrievalMethod (追記) element to identify the referent's type.) (追記ここまで)

(追記) The (追記ここまで)(追記) DerivedKey (追記ここまで)(追記) element is used to transport information about a derived key from the originator to recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) or (追記ここまで)(追記) Signature (追記ここまで)(追記) element as a child of a (追記ここまで)(追記) ds:KeyInfo (追記ここまで)(追記) element. The key value itself is never sent by the originator. Rather, the originator provides information to the recipient(s) by which the recipient(s) can derive the same key value. When the key has been derived the resulting octets are made available to the (追記ここまで)(追記) EncryptionMethod (追記ここまで)(追記) or (追記ここまで)(追記) SignatureMethod (追記ここまで)(追記) algorithm without any additional processing. (追記ここまで)

(追記) KeyDerivationMethod (追記ここまで)(追記) is an optional element that describes the key derivation algorithm applied to the master (underlying) key material. If the element is absent, the key derivation algorithm must be known by the recipient or the recipient's key derivation will fail. (追記ここまで)

(追記) ReferenceList (追記ここまで)(追記) is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to (追記ここまで)(追記) EncryptedKey (追記ここまで)(追記) or (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) elements. This is done using (追記ここまで)(追記) KeyReference (追記ここまで)(追記) and (追記ここまで)(追記) DataReference (追記ここまで)(追記) elements from XML Encryption. (追記ここまで)

(追記) The optional (追記ここまで)(追記) DerivedKeyName (追記ここまで)(追記) element is used to identify the derived key value. This element may then be referenced by the (追記ここまで)(追記) ds:KeyName (追記ここまで)(追記) element in (追記ここまで)(追記) ds:KeyInfo (追記ここまで).(追記) The same (追記ここまで)(追記) DerivedKeyName (追記ここまで)(追記) label, unlike an ID type, may occur multiple times within a single document. Note that because whitespace is significant in the value of the (追記ここまで)(追記) ds:KeyName (追記ここまで)(追記) element, whitespace is also significant in the value of the (追記ここまで)(追記) DerivedKeyName (追記ここまで)(追記) element. (追記ここまで)

(追記) MasterKeyName (追記ここまで)(追記) is an optional element for associating a user readable name with the master key (or secret) value. The same (追記ここまで)(追記) MasterKeyName (追記ここまで)(追記) label, unlike an ID type, may occur multiple times within a single document. The value of the master key (追記ここまで)(追記) must (追記ここまで)(追記) be the same in all (追記ここまで)(追記) DerivedKey (追記ここまで)(追記) elements identified with the same (追記ここまで)(追記) MasterKeyName (追記ここまで)(追記) label within a single XML document. If no (追記ここまで)(追記) MasterKeyName (追記ここまで)(追記) is provided, the master key material must be known by the recipient or key derivation will fail. (追記ここまで)

(追記) Recipient (追記ここまで)(追記) is an optional attribute that contains a hint as to which recipient this derived key value is intended for. Its contents are application dependent. (追記ここまで)

(追記) The optional (追記ここまで)(追記) Id (追記ここまで)(追記) attribute provides for the standard method of assigning a string id to the element within the document context. (追記ここまで)

(追記) The (追記ここまで)(追記) Type (追記ここまで)(追記) attribute can be used to further specify the type of the derived key if the (追記ここまで)(追記) KeyDerivationMethod (追記ここまで)(追記) algorithm does not define an unambiguous encoding/representation. (追記ここまで)

(追記) 3.5.3 (追記ここまで)(追記) The (追記ここまで)(追記) ds:RetrievalMethod (追記ここまで) Element

The ds:RetrievalMethod [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ] with a Type of ' http://www.w3.org/2001/04/xmlenc#EncryptedKey ' provides a way to express a link to an EncryptedKey element containing the key needed to decrypt the CipherData associated with an EncryptedData or EncryptedKey element. The ds:RetrievalMethod (追記) [ (追記ここまで)(追記) XMLDSIG-CORE1 (追記ここまで) (追記) ] (追記ここまで) with (削除) this type (削除ここまで) (追記) a (追記ここまで)(追記) Type (追記ここまで)(追記) of ' (追記ここまで)(追記) http://www.w3.org/2001/04/xmlenc#DerivedKey (追記ここまで)(追記) ' provides a way to express a link to a (追記ここまで)(追記) DerivedKey (追記ここまで)(追記) element used to derive the key needed to decrypt the (追記ここまで)(追記) CipherData (追記ここまで)(追記) associated with an (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) or (追記ここまで)(追記) EncryptedKey (追記ここまで)(追記) element. The (追記ここまで)(追記) ds:RetrievalMethod (追記ここまで)(追記) with one of these types (追記ここまで) is always a child of the ds:KeyInfo element and may appear multiple times. If there is more than one instance of a ds:RetrievalMethod in a ds:KeyInfo of this type, then the EncryptedKey objects referred to must contain the same key value, possibly encrypted in different ways or for different recipients.

(削除) Schema Definition: <!-- <attribute name='Type' type='anyURI' use='optional' fixed='http://www.w3.org/2001/04/xmlenc#' /> --> (削除ここまで)

3.6 The ReferenceList Element

ReferenceList is an element that contains pointers from a key value of an EncryptedKey (追記) or (追記ここまで)(追記) DerivedKey (追記ここまで) to items encrypted by that key value ( EncryptedData or EncryptedKey elements).

(削除) Schema Definition: <element name='ReferenceList'> <complexType> <choice minOccurs='1' maxOccurs='unbounded'> <element name='DataReference' type='xenc:ReferenceType'/> <element name='KeyReference' type='xenc:ReferenceType'/> </choice> </complexType> </element> (削除ここまで)
(削除) <complexType name=''> <sequence> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='URI' type='anyURI' use='required'/> </complexType> (削除ここまで)

DataReference elements are used to refer to EncryptedData elements that were encrypted using the key defined in the enclosing EncryptedKey (追記) or (追記ここまで)(追記) DerivedKey (追記ここまで) element. Multiple DataReference elements can occur if multiple EncryptedData elements exist that are encrypted by the same key.

KeyReference elements are used to refer to EncryptedKey elements that were encrypted using the key defined in the enclosing EncryptedKey (追記) or (追記ここまで)(追記) DerivedKey (追記ここまで) element. Multiple KeyReference elements can occur if multiple EncryptedKey elements exist that are encrypted by the same key.

For both types of references one may optionally specify child elements to aid the recipient in retrieving the EncryptedKey and/or EncryptedData elements. These could include information such as XPath transforms, decompression transforms, or information on how to retrieve the elements from a document storage facility. For example:

(削除) <ReferenceList> <DataReference URI="#invoice34"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> self::xenc:EncryptedData[@Id="example1"] </ds:XPath> </ds:Transform> </ds:Transforms> </DataReference> </ReferenceList> (削除ここまで)

3.7 The EncryptionProperties Element

Identifier
Type="http://www.w3.org/2001/04/xmlenc#EncryptionProperties"

(This can be used within a ds:Reference element to identify the referent's type.)

Additional information items concerning the generation of the EncryptedData or EncryptedKey can be placed in an EncryptionProperty element (e.g., date/time stamp or the serial number of cryptographic hardware used during encryption). The Target attribute identifies the EncryptedType structure being described. anyAttribute permits the inclusion of attributes from the XML namespace to be included (i.e., xml:space , xml:lang , and xml:base ).

(削除) Schema Definition: <element name='EncryptionProperties' type='xenc:EncryptionPropertiesType'/> <complexType name='EncryptionPropertiesType'> <sequence> <element ref='xenc:EncryptionProperty' maxOccurs='unbounded'/> </sequence> <attribute name='Id' type='ID' use='optional'/> </complexType> (削除ここまで)
(削除) <element name='EncryptionProperty' type='xenc:EncryptionPropertyType'/> <complexType name='EncryptionPropertyType' mixed='true'> <choice maxOccurs='unbounded'> <any namespace='##other' processContents='lax'/> </choice> <attribute name='Target' type='anyURI' use='optional'/> <attribute name='Id' type='ID' use='optional'/> <anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/> </complexType> (削除ここまで)

(削除) 4 (削除ここまで) (追記) 4. (追記ここまで) Processing Rules

This section describes the operations to be performed as part of encryption and decryption processing by implementations of this specification. The conformance requirements are specified over the following roles:

(削除) Application The application which makes request of an XML Encryption implementation via the provision of data and parameters necessary for its processing. (削除ここまで) Encryptor
An XML Encryption implementation with the role of encrypting data.
Decryptor
An XML Encryption implementation with the role of decrypting data.

(追記) Encryptor and Decryptor are invoked by the (追記ここまで)(追記) Application (追記ここまで).(追記) This specification does not include normative definitions for application behavior. However, this specification does include conformance requirements on encrypted data that may only be achievable through appropriate behavior by all three parties. It is up to specific deployment contexts how this is achieved. (追記ここまで)

4.1 (追記) Intended Application Model (追記ここまで)

(追記) The processing rules for XML Encryption are designed around an intended application model that this version of the specification does not cover normatively. (追記ここまで)

(追記) In the intended processing model, XML Encryption is used to encrypt an octet-stream, an EXI stream, or a fragment of an XML document that matches either the (追記ここまで)(追記) content (追記ここまで)(追記) or (追記ここまで)(追記) element (追記ここまで)(追記) production from [ (追記ここまで)(追記) XML10 (追記ここまで) (追記) ]. (追記ここまで)

(追記) If XML Encryption is used with some octet-stream, the precise encoding and meaning of that octet-stream is up to the application, but treated as opaque by the Encryptor or Decryptor. The application may use the (追記ここまで)(追記) Type (追記ここまで),(追記) Encoding (追記ここまで)(追記) and (追記ここまで)(追記) MimeType (追記ここまで)(追記) parameters to transport further information about the nature of that octet-stream. Hence, an unknown (追記ここまで)(追記) Type (追記ここまで)(追記) parameter is, in general, not treated as an error by either the Encryptor or Decryptor, but instead simply passed through, along with the other relevant parameters and the cleartext octet-stream. (追記ここまで)

(追記) If XML Encryption is used with an XML (追記ここまで)(追記) element (追記ここまで)(追記) or XML (追記ここまで)(追記) content (追記ここまで),(追記) then Encryptors and Decryptors commonly perform type-specific processing: (追記ここまで)

  • (追記) If an (追記ここまで)(追記) element (追記ここまで)(追記) is encrypted, then the Encryptor will replace the element in question with an appropriately constructed (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) element. The Decryptor will, conversely, replace the (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) element with its cleartext. (追記ここまで)
  • (追記) If XML (追記ここまで)(追記) content (追記ここまで)(追記) is encrypted, then the Encryptor will likewise replace this content with an appropriately constructed (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) element, and the Decryptor will reverse this operation. (追記ここまで)

(追記) Note that the intended Encryptor behavior will often cause the document with encrypted parts to become invalid with respect to its schema for the hosting XML format, unless that format is specifically prepared to be used with XML Encryption. An Encryptor or Decryptor that implements the intended processing model is (追記ここまで)(追記) not required (追記ここまで)(追記) to ensure that the resulting XML is schema-valid for the hosting XML format. (追記ここまで)

(追記) If XML processing is handled inside the Encryptor and Decryptor, and the (追記ここまで)(追記) Type (追記ここまで)(追記) attribute values for (追記ここまで)(追記) element (追記ここまで)(追記) and (追記ここまで)(追記) content (追記ここまで)(追記) cleartext are used, then the Encryptor and Decryptor (追記ここまで)(追記) must (追記ここまで)(追記) ensure that the XML cleartext is serialized as UTF-8 before encryption, and -- if needed -- converted back to whatever other encoding might be used by the surrounding XML context. (追記ここまで)

(追記) If XML (追記ここまで) Encryption (追記) is used with an EXI stream [ (追記ここまで)(追記) EXI (追記ここまで) (追記) ], then Encryptors and Decryptors process content as for XML element or XML content processing, but taking into account EXI serialization. In particular, the encryptor will replace the XML element or XML fragment in question with an appropriately constructed EncryptedData element. The Decryptor will conversely replace the EncryptedData element with its cleartext XML element or XML fragment. Note that the XML document into which the EncryptedData element is embedded may be encoded using EXI and/or EXI may be used to encode the cleartext before encryption. (追記ここまで)

(追記) 4.2 (追記ここまで)(追記) Well-known (追記ここまで)(追記) Type (追記ここまで)(追記) parameter values (追記ここまで)

For (追記) interoperability purposes, the following types (追記ここまで)(追記) must (追記ここまで)(追記) be implemented such that an implementation will be able to take as input and yield as output data matching the production rules 39 and 43 from [ (追記ここまで)(追記) XML10 (追記ここまで) (追記) ]: (追記ここまで)

(追記) element (追記ここまで) (追記) ' (追記ここまで)(追記) http://www.w3.org/2001/04/xmlenc#Element (追記ここまで) (追記) ' (追記ここまで)
(追記) "[39] (追記ここまで)(追記) element (追記ここまで) (追記) ::= (追記ここまで)(追記) EmptyElemTag (追記ここまで) (追記) | (追記ここまで)(追記) STag (追記ここまで) (追記) content (追記ここまで) (追記) ETag (追記ここまで) (追記) " (追記ここまで)
(追記) content (追記ここまで) (追記) ' (追記ここまで)(追記) http://www.w3.org/2001/04/xmlenc#Content (追記ここまで) (追記) ' (追記ここまで)
(追記) "[43] (追記ここまで)(追記) content (追記ここまで) (追記) ::= (追記ここまで)(追記) CharData (追記ここまで) (追記) ? (( (追記ここまで)(追記) element (追記ここまで) (追記) | (追記ここまで)(追記) Reference (追記ここまで) (追記) | (追記ここまで)(追記) CDSect (追記ここまで) (追記) | (追記ここまで)(追記) PI (追記ここまで) (追記) | (追記ここまで)(追記) Comment (追記ここまで) (追記) ) (追記ここまで)(追記) CharData (追記ここまで) (追記) ?)*" (追記ここまで)

(追記) Support for the following type is (追記ここまで)(追記) optional (追記ここまで)(追記) for Encryptors and Decryptors: (追記ここまで)

(追記) http://www.w3.org/2009/xmlenc11#EXI (追記ここまで)
(追記) Presence of this (追記ここまで)(追記) Type (追記ここまで)(追記) indicates that the cleartext is an EXI stream [ (追記ここまで)(追記) EXI (追記ここまで) (追記) ]. Encryptors and Decryptors that support this type (追記ここまで)(追記) may (追記ここまで)(追記) operate directly on (parts of) EXI streams. (追記ここまで)

(追記) Encryptors and Decryptors (追記ここまで)(追記) should (追記ここまで)(追記) handle unknown or empty (追記ここまで)(追記) Type (追記ここまで)(追記) attribute values as a signal that the cleartext is to be handled as an opaque octet-stream, whose specific processing is up to the invoking application. In this case, the (追記ここまで)(追記) Type (追記ここまで),(追記) MimeType (追記ここまで)(追記) and (追記ここまで)(追記) Encoding (追記ここまで)(追記) parameters (追記ここまで)(追記) should (追記ここまで)(追記) be treated as opaque data whose appropriate processing is up to the application. (追記ここまで)

(追記) 4.3 (追記ここまで)(追記) Encryption (追記ここまで)

(追記) The selection of the algorithm, parameters, and encryption keys is out of scope for this specification. (追記ここまで)

(追記) The cleartext data are assumed to be present as an octet stream. If the cleartext is of type (追記ここまで)(追記) element (追記ここまで)(追記) or (追記ここまで)(追記) content (追記ここまで),(追記) the data (追記ここまで)(追記) must (追記ここまで)(追記) be serialized in UTF-8 as specified in [ (追記ここまで)(追記) XML10 (追記ここまで) (追記) ], using Normal Form C [ (追記ここまで)(追記) NFC (追記ここまで) (追記) ]. (追記ここまで)

(追記) For (追記ここまで) each data item to be encrypted as an EncryptedData or EncryptedKey (削除) (elements derived from EncryptedType ), (削除ここまで) (追記) element, (追記ここまで) the encryptor (削除) must: (削除ここまで) (追記) must (追記ここまで):

  1. (削除) Select the algorithm (and parameters) to be used in encrypting this data. (削除ここまで) Obtain (追記) (or derive) (追記ここまで) and (optionally) represent the key.
    1. If the key is to be identified (via naming, URI, or included in a child element), construct the ds:KeyInfo as (削除) approriate (削除ここまで) (追記) appropriate (追記ここまで) (e.g., ds:KeyName , ds:KeyValue , ds:RetrievalMethod , etc.)

    2. If the key itself is to be encrypted, construct an EncryptedKey element by recursively applying this encryption process. The result may then be a child of ds:KeyInfo , or it may exist elsewhere and may be identified in the preceding step.

    3. (削除) Encrypt the data (削除ここまで)

      If the (削除) data is an ' element ' [ XML , section 3] or (削除ここまで) (追記) key was derived from a master key, construct a (追記ここまで)(追記) DerivedKey (追記ここまで) element (削除) ' content ' [ XML , section 3.1], obtain the octets by serializing the data in UTF-8 (削除ここまで) (追記) with associated child elements. The result may, (追記ここまで) as (削除) specified (削除ここまで) in (削除) [ XML ]. (The application MUST provide XML data in [ NFC ].) Serialization MAY be done by the encryptor . If the encryptor does not serialize, then the application MUST perform (削除ここまで) the (削除) serialization. If the data is (削除ここまで) (追記) EncryptedKey (追記ここまで)(追記) case, be a child (追記ここまで) of (削除) any other type that is not already octets, the application MUST serialize (削除ここまで) (追記) ds:KeyInfo (追記ここまで),(追記) or (追記ここまで) it (削除) as octets. (削除ここまで) (追記) may exist elsewhere. (追記ここまで)

  2. (追記) Encrypt the data: (追記ここまで)

    1. Encrypt the octets using the algorithm and (削除) key from steps 1 and 2. (削除ここまで) (追記) key. (追記ここまで)

    2. Unless the decryptor will implicitly know the type of the encrypted data, the encryptor (削除) SHOULD provide (削除ここまで) (追記) should (追記ここまで)(追記) set (追記ここまで) the (削除) type for representation. The definition of this type as bound to an identifier specifies how (削除ここまで) (追記) Type (追記ここまで) to (削除) obtain and interpret the plaintext octets after decryption. For example, the idenifier could (削除ここまで) indicate (削除) that (削除ここまで) the (削除) data is an instance (削除ここまで) (追記) intended interpretation (追記ここまで) of (削除) another application (e.g., some XML compression application) that must be further processed. Or, if (削除ここまで) (追記) the cleartext data. See (追記ここまで)(追記) section 4.2 Well-known Type parameter values (追記ここまで) (追記) for known parameter values. (追記ここまで)

      (追記) If (追記ここまで) the data is a simple octet sequence it (削除) MAY (削除ここまで) (追記) may (追記ここまで) be described with the MimeType and Encoding attributes. For example, the data might be an XML document ( MimeType="text/xml" ), sequence of characters ( MimeType="text/plain" ), or binary image data ( MimeType="image/png ").

  3. Build the (削除) EncryptedType ( (削除ここまで) EncryptedData or EncryptedKey (削除) ) (削除ここまで) structure:

    An (削除) EncryptedType (削除ここまで) (追記) EncryptedData (追記ここまで)(追記) or (追記ここまで)(追記) EncryptedKey (追記ここまで) structure represents all of the information previously discussed including the type of the encrypted data, encryption algorithm, parameters, key, type of the encrypted data, etc.

    1. If the encrypted octet sequence obtained in step (削除) 3 (削除ここまで) (追記) 2 (追記ここまで) is to be stored in the CipherData element within the (削除) EncryptedType , (削除ここまで) (追記) EncryptedData (追記ここまで)(追記) or (追記ここまで)(追記) EncryptedKey (追記ここまで)(追記) element, (追記ここまで) then the (追記) base64 representation of the (追記ここまで) encrypted octet sequence is (削除) base64 encoded and (削除ここまで) inserted as the content of a CipherValue element.
    2. If the encrypted octet sequence is (削除) to be (削除ここまで) stored externally to the (削除) EncryptedType (削除ここまで) (追記) EncryptedData (追記ここまで) (削除) structure, then store (削除ここまで) or (削除) return the encrypted octet sequence, and represent (削除ここまで) (追記) EncryptedKey (追記ここまで)(追記) element, then (追記ここまで) the URI and transforms (if any) required for the (削除) decryptor (削除ここまで) (追記) Decryptor (追記ここまで) to retrieve the encrypted octet sequence (追記) are described (追記ここまで) within a CipherReference element. (削除) Process EncryptedData If the Type of the encrypted data is ' element ' or element ' content ', then the encryptor MUST be able to return the EncryptedData element to the application . The application MAY use this as the top-level element in a new XML document or insert it into another XML document, which may require a re-encoding. The encryptor SHOULD be able to replace the unencrypted 'element' or 'content' with the EncryptedData element. When an application requires an XML element or content to be replaced, it supplies the XML document context in addition to identifying the element or content to be replaced. The encryptor removes the identified element or content and inserts the EncryptedData element in its place. (削除ここまで)

      (削除) (Note: If the Type is "content" the document resulting from decryption will not be well-formed if (a) the original plaintext was not well-formed (e.g., PCDATA by itself is not well-formed) and (b) the EncryptedData element was previously the root element of the document) If the Type of the encrypted data is not ' element ' or element ' content ', then the encryptor MUST always return the EncryptedData element to the application . The application MAY use this as the top-level element in a new XML document or insert it into another XML document, which may require a re-encoding. (削除ここまで)

(削除) 4.2 (削除ここまで) (追記) 4.4 (追記ここまで) Decryption

For each (削除) EncryptedType derived element, (i.e., (削除ここまで) EncryptedData or EncryptedKey (削除) ), (削除ここまで) to be decrypted, the decryptor (削除) must: (削除ここまで) (追記) must (追記ここまで):

  1. (削除) Process the element to determine (削除ここまで) (追記) Determine (追記ここまで) the algorithm, parameters and (削除) ds:KeyInfo element (削除ここまで) (追記) key information (追記ここまで) to be used. (削除) If some (削除ここまで) (追記) This (追記ここまで) information (削除) is omitted, the application MUST supply it. Locate the data encryption key (削除ここまで) (追記) may be obtained out-of-band, or determined (追記ここまで) according to (削除) the (削除ここまで) (追記) a (追記ここまで) ds:KeyInfo (削除) element, which may contain one or more children elements. These children have no implied processing order. If the data encryption key is encrypted, locate the corresponding key (削除ここまで) (追記) element; see (追記ここまで)(追記) section 3.5 Extensions (追記ここまで) to (削除) decrypt it. (This may be a recursive step as the key-encryption key may itself be encrypted.) Or, one might retrieve the data encryption key from a local store using the provided attributes or implicit binding. (削除ここまで) (追記) ds:KeyInfo Element (追記ここまで).
  2. Decrypt the data contained in the CipherData element.

    1. If a CipherValue child element is present, then the associated text value is retrieved and base64 decoded so as to obtain the encrypted octet sequence.

    2. If a CipherReference child element is present, the URI and transforms (if any) are used to retrieve the encrypted octet sequence.

    3. The encrypted octet sequence is decrypted using the (削除) algorithm/parameters (削除ここまで) (追記) algorithm, parameters (追記ここまで) and key value already determined from (削除) steps 1 and 2. Process decrypted data of Type ' element ' or element ' content '. The cleartext octet sequence obtained in (削除ここまで) step (削除) 3 is interpreted as UTF-8 encoded character data. The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. The decryptor is NOT REQUIRED to perform validation on the serialized XML. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted ' element ' or element ' content ' represented by the UTF-8 encoded characters. The decryptor is NOT REQUIRED to perform validation on the result of this replacement operation. The application supplies the XML document context and identifies the EncryptedData element being replaced. If the document into which the replacement is occurring is not UTF-8, the decryptor MUST transcode the UTF-8 encoded characters into the target encoding. (削除ここまで) (追記) 1. (追記ここまで)

      (削除) Process decrypted data if Type is unspecified or is not ' element ' or element ' content '. The cleartext octet sequence obtained in Step 3 MUST be returned to the application for further processing along with the Type , MimeType , and Encoding attribute values when specified. MimeType and Encoding are advisory. The Type value is normative as it may contain information necessary for the processing or interpration of the data by the application. Note, this step includes processing data decrypted from an EncryptedKey . The cleartext octet sequence represents a key value and is used by the application in decrypting other EncryptedType element(s). (削除ここまで)

(削除) 4.3 (削除ここまで) (追記) 4.5 (追記ここまで) XML Encryption

Encryption and decryption operations are (削除) transforms (削除ここまで) (追記) operations (追記ここまで) on octets. The application is responsible for the marshalling XML such that it can be serialized into an octet sequence, encrypted, decrypted, and be of use to the recipient.

For example, if the application wishes to canonicalize its data or encode/compress the data in an XML packaging format, the application needs to marshal the XML accordingly and identify the resulting type via the EncryptedData Type attribute. The likelihood of successful decryption and subsequent processing will be dependent on the recipient's support for the given type. Also, if the data is intended to be processed both before encryption and after decryption (e.g., XML Signature [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ] validation or an XSLT transform) the encrypting application must be careful to preserve information necessary for that process's success.

(削除) For interoperability purposes, the following types MUST be implemented such that an implementation will be able to take as input and yield as output data matching the production rules 39 and 43 from [ XML ]: element ' http://www.w3.org/2001/04/xmlenc#Element ' "[39] element ::= EmptyElemTag | STag content ETag " content ' http://www.w3.org/2001/04/xmlenc#Content ' "[43] content ::= CharData ? (( element | Reference | CDSect | PI | Comment ) CharData ?)*" (削除ここまで) The following sections contain specifications for decrypting, replacing, and serializing XML content (i.e., Type ' element ' or element ' content ') using the [ (削除) XPath (削除ここまで) (追記) XPATH (追記ここまで) ] data model. These sections are non-normative and (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) to (削除) implementors (削除ここまで) (追記) implementers (追記ここまで) of this specification, but they may be normatively referenced by and (削除) MANDATORY to (削除ここまで) (追記) be required by (追記ここまで) other specifications that require a consistent processing for applications, such as [ (削除) XML-DSIG-Decrypt (削除ここまで) (追記) XMLENC-DECRYPT (追記ここまで) ].

(削除) 4.3.1 (削除ここまで) (追記) 4.5.1 (追記ここまで) A Decrypt Implementation (Non-normative)

Where P is the context in which the serialized XML should be parsed (a document node or element node) and O is the octet sequence representing UTF-8 encoded characters resulting from step 4.3 in (削除) the (削除ここまで) (追記) section 4.4 (追記ここまで) Decryption (削除) Processing (section 4.2). (削除ここまで) . Y is node-set representing the decrypted content obtained by the following steps:

  1. Let C be the parsing context of a child of P , which consists of the following items:
    • Prefix and namespace name of each namespace that is in scope for P .
    • Name and value of each general entity that is effective for the XML document causing P .
  2. Wrap the decrypted octet stream O in the context C as specified in (追記) section 4.5.4 (追記ここまで) Text Wrapping .
  3. Parse the wrapped octet stream as described in The Reference Processing Model (section 4.3.3.2) of [ (削除) XML-Signature (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ], resulting in a node-set.
  4. Y is the node-set obtained by removing the root node, the wrapping element node, and its associated set of attribute and namespace nodes from the node-set obtained in Step 3.

(削除) 4.3.2 (削除ここまで) (追記) 4.5.2 (追記ここまで) A Decrypt and Replace Implementation (Non-normative)

Where X is the [ (削除) XPath (削除ここまで) (追記) XPATH (追記ここまで) ] node set corresponding to an XML document and e is an EncryptedData element node in X .

  1. Z is an [ (削除) XPath (削除ここまで) (追記) XPATH (追記ここまで) ] node-set that identical to X except where the element node e is an EncryptedData element type. In which case:
    1. Decrypt e in the context of its parent node as specified in the (削除) Decryption (削除ここまで) (追記) section 4.5.1 A Decrypt (追記ここまで) Implementation (追記) (Non-normative) (追記ここまで) (削除) (section 4.3.1) (削除ここまで) yielding Y , an [ (削除) XPath (削除ここまで) (追記) XPATH (追記ここまで) ] node set.
    2. Include Y in place of e and its descendants in X . Since [ (削除) XPath (削除ここまで) (追記) XPATH (追記ここまで) ] does not define methods of replacing node-sets from different documents, the result (削除) MUST (削除ここまで) (追記) must (追記ここまで) be equivalent to replacing e with the octet stream resulting from its decryption in the serialized form of X and (削除) reparsing (削除ここまで) (追記) re-parsing (追記ここまで) the document. However, the actual method of performing this operation is left to the implementor.

(削除) 4.3.3 (削除ここまで) (追記) 4.5.3 (追記ここまで) Serializing XML (Non-normative)

(追記) 4.5.3.1 (追記ここまで) Default Namespace Considerations

In (削除) Encrypting XML (削除ここまで) (追記) section 4.3 Encryption (追記ここまで) (削除) (section 4.1, step (削除ここまで) (追記) (step (追記ここまで) 3.1), when serializing an XML fragment special care (削除) SHOULD (削除ここまで) (追記) should (追記ここまで) be taken with respect to default namespaces. If the data will be subsequently decrypted in the context of a parent XML document then serialization can produce elements in the wrong namespace. Consider the following fragment of XML:

(削除) <Document xmlns="http://example.org/"> <ToBeEncrypted xmlns="" /> </Document> (削除ここまで)

Serialization of the element ToBeEncrypted fragment via [ XML-C14N ] would result in the characters " <ToBeEncrypted></ToBeEncrypted> " as an octet stream. The resulting encrypted document would be:

(削除) <Document xmlns="http://example.org/"> <EncryptedData xmlns="..."> <!-- Containing the encrypted "<ToBeEncrypted></ToBeEncrypted>" --> </EncryptedData> </Document> (削除ここまで)

Decrypting and replacing the EncryptedData within this document would produce the following incorrect result:

(削除) <Document xmlns="http://example.org/"> <ToBeEncrypted/> </Document> (削除ここまで)

This problem arises because most XML serializations assume that the serialized data will be parsed directly in a context where there is no default namespace declaration. Consequently, they do not redundantly declare the empty default namespace with an xmlns="" . If, however, the serialized data is parsed in a context where a default namespace declaration is in scope (e.g., the parsing context (削除) of a (削除ここまで) (追記) as described in (追記ここまで)(追記) section 4.5.1 (追記ここまで) A Decrypt Implementation (追記) (Non-normative) (追記ここまで) (削除) (section 4.3.1)), (削除ここまで) (追記) ), (追記ここまで) then it may affect the interpretation of the serialized data.

To solve this problem, a canonicalization algorithm (削除) MAY (削除ここまで) (追記) may (追記ここまで) be augmented as follows for use as an XML encryption serializer:

  • A default namespace declaration with an empty value (i.e., xmlns="" ) (削除) SHOULD (削除ここまで) (追記) should (追記ここまで) be emitted where it would normally be suppressed by the canonicalization algorithm.

While the result may not be in proper canonical form, this is harmless as the resulting octet stream will not be used directly in a [ (削除) XML-Signature (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ] signature value computation. Returning to the preceding example with our new augmentation, the ToBeEncrypted element would be serialized as follows:

<ToBeEncrypted
xmlns=""></ToBeEncrypted>

When processed in the context of the parent document, this serialized fragment will be parsed and interpreted correctly.

This augmentation can be retroactively applied to an existing canonicalization implementation by canonicalizing each apex node and its descendants from the node set, inserting xmlns="" at the appropriate points, and concatenating the resulting octet streams.

(追記) 4.5.3.2 (追記ここまで) XML Attribute Considerations

Similar attention between the relationship of a fragment and the context into which it is being inserted should be given to the xml:base , xml:lang , and xml:space attributes as mentioned in the Security Considerations of [ (削除) XML-exc-C14N (削除ここまで) (追記) XML-EXC-C14N (追記ここまで) ]. For example, if the element:

(削除) <Bongo href="example.xml"/> (削除ここまで)

is taken from a context and serialized with no xml:base [ (削除) XML-Base (削除ここまで) (追記) XMLBASE (追記ここまで) ] attribute and parsed in the context of the element:

(削除) <Baz xml:base="http://example.org/"/> (削除ここまで)

the result will be:

(削除) <Baz xml:base="http://example.org/"><Bongo href="example.xml"/></Baz> (削除ここまで)

Bongo 's href is subsequently interpreted as " http://example.org/example.xml ". If this is not the correct URI, Bongo should have been serialized with its own xml:base attribute.

Unfortunately, the recommendation that an empty value be emitted to divorce the default namespace of the fragment from the context into which it is being inserted (削除) can not (削除ここまで) (追記) cannot (追記ここまで) be made for the attributes xml:base , and xml:space . ( Error 41 of the XML 1.0 Second Edition Specification Errata clarifies that an empty string value of the attribute xml:lang is considered as if, "there is no language information available, just as if xml:lang had not been specified".) The interpretation of an empty value for the xml:base or xml:space attributes is undefined or maintains the contextual value. Consequently, applications (削除) SHOULD (削除ここまで) (追記) should (追記ここまで) ensure (1) fragments that are to be encrypted are not dependent on XML attributes, or (2) if they are dependent and the resulting document is intended to be valid [ (削除) XML (削除ここまで) (追記) XML10 (追記ここまで) ], the fragment's definition permits the presence of the attributes and that the attributes have non-empty values.

(削除) 4.3.4 (削除ここまで) (追記) 4.5.4 (追記ここまで) Text Wrapping (削除) (Non-normative) (削除ここまで)

This section specifies the process for wrapping text in a given parsing context. The process is based on the proposal by Richard Tobin [ Tobin ] for constructing the infoset [ (削除) XML-Infoset (削除ここまで) (追記) XML-INFOSET (追記ここまで) ] of an external entity.

The process consists of the following steps:

  1. If the parsing context contains any general entities, then emit a document type declaration that provides entity declarations.

  2. Emit a dummy element start-tag with namespace declaration attributes declaring all the namespaces in the parsing context.

  3. Emit the text.

  4. Emit a dummy element end-tag.

In the above steps, the document type declaration and dummy element tags (削除) MUST (削除ここまで) (追記) must (追記ここまで) be encoded in UTF-8.

Consider the following document containing an EncryptedData element:

(削除) <!DOCTYPE Document [ <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> ]> <Document xmlns="http://example.org/"> <foo:Body xmlns:foo="http://example.org/foo"> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type=""> ... </EncryptedData> </foo:Body> </Document> (削除ここまで)

If the EncryptedData element is (削除) fed is (削除ここまで) decrypted to the text " <One><foo:Two/></One> ", then the wrapped form is as follows:

(削除) <!DOCTYPE dummy [ <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> ]> <dummy xmlns="http://example.org/" xmlns:foo="http://example.org/foo"><One><foo:Two/></One></dummy> (削除ここまで)

5. Algorithms

This section discusses algorithms used with the XML Encryption specification. Entries contain the identifier to be used as the value of the Algorithm attribute of the EncryptionMethod element or other element representing the role of the algorithm, a reference to the formal specification, definitions for the representation of keys and the results of cryptographic operations where applicable, and general applicability comments.

5.1 Algorithm Identifiers and Implementation Requirements

All algorithms listed below have implicit parameters depending on their role. For example, the data to be encrypted or decrypted, keying material, and direction of operation (encrypting or decrypting) for encryption algorithms. Any explicit additional parameters to an algorithm appear as content elements within the element. Such parameter child elements have descriptive element names, which are frequently algorithm specific, and (削除) SHOULD (削除ここまで) (追記) should (追記ここまで) be in the same namespace as this XML Encryption specification, the XML Signature specification, or in an algorithm specific namespace. An example of such an explicit parameter could be a nonce (unique quantity) provided to a key agreement algorithm.

This specification defines a set of algorithms, their URIs, and requirements for implementation. Levels of requirement specified, such as (削除) "REQUIRED" (削除ここまで) (追記) " (追記ここまで)(追記) required (追記ここまで)(追記) " (追記ここまで) or (削除) "OPTIONAL", refere (削除ここまで) (追記) " (追記ここまで)(追記) optional (追記ここまで)(追記) ", refer (追記ここまで) to implementation, not use. Furthermore, the mechanism is extensible, and alternative algorithms may be used.

(追記) 5.1.1 (追記ここまで) Table of Algorithms

The table below lists the categories of algorithms. Within each category, a brief name, the level of implementation requirement, and an identifying URI are given for each algorithm.

Block Encryption
  1. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) TRIPLEDES
    http://www.w3.org/2001/04/xmlenc#tripledes-cbc
  2. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) AES-128
    http://www.w3.org/2001/04/xmlenc#aes128-cbc
  3. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) AES-256
    http://www.w3.org/2001/04/xmlenc#aes256-cbc
  4. (削除) OPTIONAL (削除ここまで) (追記) required (追記ここまで)(追記) AES128-GCM (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#aes128-gcm (追記ここまで)
  5. (追記) optional (追記ここまで) AES-192
    http://www.w3.org/2001/04/xmlenc#aes192-cbc
  6. (追記) optional (追記ここまで)(追記) AES192-GCM (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#aes192-gcm (追記ここまで)
  7. (追記) optional (追記ここまで)(追記) AES256-GCM (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#aes256-gcm (追記ここまで)

(追記) Note: (追記ここまで)(追記) Use of AES GCM is strongly recommended over any CBC block encryption algorithms as recent advances in cryptanalysis [ (追記ここまで)(追記) XMLENC-CBC-ATTACK (追記ここまで) (追記) ][ (追記ここまで)(追記) XMLENC-CBC-ATTACK-COUNTERMEASURES (追記ここまで) (追記) ] have cast doubt on the ability of CBC block encryption algorithms to protect plain text when used with XML Encryption. Other mitigations should be considered when using CBC block encryption, such as conveying the encrypted data over a secure channel such as TLS. The CBC block encryption algorithms that are listed as required remain so for backward compatibility. (追記ここまで)

Stream Encryption
  1. none
    Syntax and recommendations are given below to support user specified algorithms.
Key (削除) Transport (削除ここまで) (追記) Derivation (追記ここまで)
  1. (削除) REQUIRED RSA-v1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 (削除ここまで) (追記) required (追記ここまで)(追記) ConcatKDF (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#ConcatKDF (追記ここまで)
  2. (削除) REQUIRED (削除ここまで) (追記) optional (追記ここまで)(追記) PBKDF2 (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#pbkdf2 (追記ここまで)
(追記) Key Transport (追記ここまで)
  1. (追記) required (追記ここまで) RSA-OAEP (追記) (including MGF1 with SHA1) (追記ここまで)
    http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
  2. (追記) Optional RSA-OAEP (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#rsa-oaep (追記ここまで)
  3. (追記) optional (追記ここまで)(追記) RSA-v1.5 (see (追記ここまで)(追記) RSA-v1.5 security note (追記ここまで) (追記) ) (追記ここまで)
    (追記) http://www.w3.org/2001/04/xmlenc#rsa-1_5 (追記ここまで)
Key Agreement
  1. (削除) OPTIONAL (削除ここまで) (追記) required (追記ここまで)(追記) Elliptic Curve (追記ここまで) Diffie-Hellman (追記) (Ephemeral-Static mode) (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#ECDH-ES (追記ここまで)
  2. (追記) optional (追記ここまで)(追記) Diffie-Hellman Key Agreement (Ephemeral-Static mode) with Legacy Key Derivation Function (追記ここまで)
    http://www.w3.org/2001/04/xmlenc#dh
  3. (追記) optional (追記ここまで)(追記) Diffie-Hellman Key Agreement (Ephemeral-Static mode) with explicit Key Derivation Functions (追記ここまで)
    (追記) http://www.w3.org/2009/xmlenc11#dh-es (追記ここまで)
Symmetric Key Wrap
  1. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) TRIPLEDES KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-tripledes
  2. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) AES-128 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes128
  3. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) AES-256 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes256
  4. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) AES-192 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes192
Message Digest
  1. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) SHA1 (追記) ( (追記ここまで)(追記) Use is DISCOURAGED (追記ここまで)(追記) ; see below). (追記ここまで)
    http://www.w3.org/2000/09/xmldsig#sha1
  2. (削除) RECOMMENDED (削除ここまで) (追記) required (追記ここまで) SHA256
    http://www.w3.org/2001/04/xmlenc#sha256
  3. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで)(追記) SHA384 (追記ここまで)
    (追記) http://www.w3.org/2001/04/xmlenc#sha384 (追記ここまで)
  4. (追記) optional (追記ここまで) SHA512
    http://www.w3.org/2001/04/xmlenc#sha512
  5. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) RIPEMD-160
    http://www.w3.org/2001/04/xmlenc#ripemd160
(削除) Message Authentication (削除ここまで) (追記) Canonicalization (追記ここまで)
  1. (削除) RECOMMENDED (削除ここまで) (追記) optional (追記ここまで)(追記) Canonical (追記ここまで) XML (削除) Digital Signature http://www.w3.org/2000/09/xmldsig# (削除ここまで) (追記) 1.0 (omit comments) (追記ここまで)
    (追記) http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (追記ここまで)
  2. (削除) Canonicalization (削除ここまで)
  3. (追記) optional (追記ここまで)(追記) Canonical XML 1.0 (with comments) (追記ここまで)
    (追記) http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments (追記ここまで)
  4. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) Canonical XML (削除) (omits (削除ここまで) (追記) 1.1 (omit (追記ここまで) comments) (削除) http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (削除ここまで)
    (追記) http://www.w3.org/2006/12/xml-c14n11 (追記ここまで)
  5. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) Canonical XML (削除) with Comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments (削除ここまで) (追記) 1.1 (with comments) (追記ここまで)
    (追記) http://www.w3.org/2006/12/xml-c14n11#WithComments (追記ここまで)
  6. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) Exclusive XML Canonicalization (削除) (omits (削除ここまで) (追記) 1.0 (omit (追記ここまで) comments)
    http://www.w3.org/2001/10/xml-exc-c14n#
  7. (削除) OPTIONAL (削除ここまで) (追記) optional (追記ここまで) Exclusive XML Canonicalization (削除) with Comments (削除ここまで) (追記) 1.0 (with comments) (追記ここまで)
    http://www.w3.org/2001/10/xml-exc-c14n#WithComments
Encoding
  1. (削除) REQUIRED (削除ここまで) (追記) required (追記ここまで) base64 (追記) ( (追記ここまで)(追記) *note (追記ここまで) (追記) ) (追記ここまで)
    (追記) http://www.w3.org/2000/09/xmldsig#base64 (追記ここまで)
(追記) Transforms (追記ここまで)
  1. (追記) required (追記ここまで)(追記) base64 ( (追記ここまで)(追記) *note (追記ここまで) (追記) ) (追記ここまで)
    http://www.w3.org/2000/09/xmldsig#base64

(追記) *note: The same URI is used to identify base64 both in "encoding" context (e.g. when used with the (追記ここまで)(追記) Encoding (追記ここまで)(追記) attribute of an (追記ここまで)(追記) EncryptedKey (追記ここまで)(追記) element, see (追記ここまで)(追記) section 3.1 The EncryptedType Element (追記ここまで) (追記) ) as well as in "transform" context (when identifying a base64 transform for a (追記ここまで)(追記) CipherReference (追記ここまで),(追記) see (追記ここまで)(追記) section 3.3.1 The CipherReference Element (追記ここまで) (追記) ). (追記ここまで)

5.2 Block Encryption Algorithms

Block encryption algorithms are designed for encrypting and decrypting data in fixed size, multiple octet blocks. Their identifiers appear as the value of the Algorithm attributes of EncryptionMethod elements that are children of EncryptedData .

(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).

Block encryption algorithms take, as implicit arguments, the data to be encrypted or decrypted, the keying material, and their direction of operation. For all of these algorithms specified below, an initialization vector (IV) is required that is encoded with the cipher text. For user specified block encryption algorithms, the IV, if any, could be specified as being with the cipher data, as an algorithm content element, or elsewhere.

The IV is encoded with and before the cipher text for the algorithms below for ease of availability to the decryption code and to emphasize its association with the cipher text. Good cryptographic practice requires that a different IV be used for every encryption.

(追記) 5.2.1 (追記ここまで) Padding

Since the data being encrypted is an arbitrary number of octets, it may not be a multiple of the block size. This is solved by padding the plain text up to the block size before encryption and unpadding after decryption. The padding algorithm is to calculate the smallest non-zero number of octets, say N , that must be suffixed to the plain text to bring it up to a multiple of the block size. We will assume the block size is B octets so N is in the range of 1 to B . Pad by suffixing the plain text with N-1 arbitrary pad bytes and a final byte whose value is N . On decryption, just take the last byte and, after sanity checking it, strip that many bytes from the end of the decrypted cipher text.

For example, assume an 8 byte block size and plain text of 0x616263 . The padded plain text would then be 0x616263????????05 where the "??" bytes can be any value. Similarly, plain text of 0x2122232425262728 would be padded to 0x2122232425262728??????????????08 .

(削除) 5.2.1 (削除ここまで) (追記) 5.2.2 (追記ここまで) Triple DES

Identifier:
http://www.w3.org/2001/04/xmlenc#tripledes-cbc (削除) (REQUIRED) (削除ここまで)

(削除) ANSI X9.52 (削除ここまで) (追記) NIST SP800-67 (追記ここまで) [ (削除) TRIPLEDES (削除ここまで) (追記) SP800-67 (追記ここまで) ] specifies three sequential FIPS 46-3 [ DES ] operations. The XML Encryption TRIPLEDES consists of a DES encrypt, a DES decrypt, and a DES encrypt used in the Cipher Block Chaining (CBC) mode with 192 bits of key and a 64 bit Initialization Vector (IV). Of the key bits, the first 64 are used in the first DES operation, the second 64 bits in the middle DES operation, and the third 64 bits in the last DES operation.

Note: Each of these 64 bits of key contain 56 effective bits and 8 parity bits. Thus there are only 168 operational bits out of the 192 being transported for a TRIPLEDES key. (Depending on the criterion used for analysis, the effective strength of the key may be thought to be 112 bits (due to meet in the middle attacks) or even less.)

The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example TRIPLEDES EncryptionMethod is as follows:

(削除) <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> (削除ここまで)

(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).

(削除) 5.2.2 AES (削除ここまで) (追記) 5.2.3 (追記ここまで)(追記) AES (追記ここまで)

Identifier:
http://www.w3.org/2001/04/xmlenc#aes128-cbc (削除) (REQUIRED) (削除ここまで)
http://www.w3.org/2001/04/xmlenc#aes192-cbc (削除) (OPTIONAL) (削除ここまで)
http://www.w3.org/2001/04/xmlenc#aes256-cbc (削除) (REQUIRED) (削除ここまで)

[ AES ] is used in the Cipher Block Chaining (CBC) mode with a 128 bit initialization vector (IV). The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example AES EncryptionMethod is as follows:

(削除) <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> (削除ここまで)

(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).

(追記) 5.2.4 (追記ここまで)(追記) AES-GCM (追記ここまで)

(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#aes128-gcm (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#aes192-gcm (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#aes256-gcm (追記ここまで)

(追記) AES-GCM [ (追記ここまで)(追記) SP800-38D (追記ここまで) (追記) ] is an authenticated encryption mechanism. It is equivalent to doing these two operations in one step - AES encryption followed by HMAC signing. (追記ここまで)

(追記) AES-GCM is very attractive from a performance point of view because the cost of AES-GCM is similar to regular AES-CBC encryption, yet it achieves the same result as encryption and HMAC signing. Also AES-GCM can be pipelined so it is amenable to hardware acceleration. (追記ここまで)

(追記) For the purposes of this specification, AES-GCM shall be used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified Authentication Tag, and fail if they don't match. For details on the implementation of AES-GCM, see [ (追記ここまで)(追記) SP800-38D (追記ここまで) (追記) ]. (追記ここまで)

5.3 Stream Encryption Algorithms

Simple stream encryption algorithms generate, based on the key, a stream of bytes which are XORed with the plain text data bytes to produce the cipher text on encryption and with the cipher text bytes to produce plain text on decryption. They are normally used for the encryption of data and are specified by the value of the Algorithm attribute of the EncryptionMethod child of an EncryptedData element.

NOTE: It is critical that each simple stream encryption key (or key and initialization vector (IV) if an IV is also used) be used once only. If the same key (or key and IV) is ever used on two messages then, by XORing the two cipher texts, you can obtain the XOR of the two plain texts. This is usually very compromising.

No specific stream encryption algorithms are specified herein but this section is included to provide general guidelines.

Stream algorithms typically use the optional KeySize explicit parameter. In cases where the key size is not apparent from the algorithm URI or key source, as in the use of key agreement methods, this parameter sets the key size. If the size of the key to be used is apparent and disagrees with the KeySize parameter, an error (削除) MUST (削除ここまで) (追記) must (追記ここまで) be returned. Implementation of any stream algorithms is optional. The schema for the KeySize parameter is as follows:

(削除) Schema Definition: (削除ここまで)
(削除) <simpleType name='KeySizeType'> <restriction base="integer"/> </simpleType> (削除ここまで)

5.4 Key (削除) Transport (削除ここまで) (追記) Derivation (追記ここまで)

(追記) Key derivation is a well-established mechanism for generating new cryptographic key material from some existing, original ("master") key material and potentially other information. Derived keys are used for a variety of purposes including data encryption and message authentication. The reason for doing key derivation itself is typically a combination of a desire to expand a given, but limited, set of original key material and prudent security practices of limiting use (exposure) of such key material. Key separation (such as avoiding use of the same key material for multiple purposes) is an example of such practices. (追記ここまで)

(追記) The key derivation process may be based on passphrases agreed upon or remembered by users, or it can be based on some shared "master" cryptographic keys (and be intended to reduce exposure of such master keys), etc. Derived keys themselves may be used in XML Signature and XML Encryption as any other keys; in particular, they may be used to compute message authentication codes (e.g. digital signatures using symmetric keys) or for encryption/decryption purposes. (追記ここまで)

(追記) 5.4.1 (追記ここまで)(追記) ConcatKDF (追記ここまで)

(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#ConcatKDF (追記ここまで)

(追記) The ConcatKDF key derivation algorithm, defined in Section 5.8.1 of NIST SP 800-56A [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ] (and equivalent to the KDF3 function defined in ANSI X9.44-2007 [ (追記ここまで)(追記) ANSI-X9-44-2007 (追記ここまで) (追記) ] when the contents of the (追記ここまで)(追記) OtherInfo (追記ここまで)(追記) parameter is structured as in NIST SP 800-56A), takes several parameters. These parameters are represented in the (追記ここまで)(追記) xenc11:ConcatKDFParamsType (追記ここまで):

(追記) The (追記ここまで)(追記) ds:DigestMethod (追記ここまで)(追記) element identifies the digest algorithm used by the KDF. Compliant implementations (追記ここまで)(追記) must (追記ここまで)(追記) support SHA-256 and SHA-1 (support for SHA-1 is present only for backwards-compatibility reasons). Support for SHA-384 and SHA-512 is (追記ここまで)(追記) optional (追記ここまで).

(追記) The (追記ここまで)(追記) AlgorithmID (追記ここまで),(追記) PartyUInfo (追記ここまで),(追記) PartyVInfo (追記ここまで),(追記) SuppPubInfo (追記ここまで)(追記) and (追記ここまで)(追記) SuppPrivInfo (追記ここまで)(追記) attributes are as defined in [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ]. Their presence is optional but (追記ここまで)(追記) AlgorithmID (追記ここまで),(追記) PartyVInfo (追記ここまで)(追記) and (追記ここまで)(追記) PartyUInfo (追記ここまで)(追記) must (追記ここまで)(追記) be present for applications that need to comply with [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ]. Note: The (追記ここまで)(追記) PartyUInfo (追記ここまで)(追記) component shall include a nonce when ConcatKDF is used in conjunction with a static-static Diffie-Hellman (or static-static ECDH) key agreement scheme; see further [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ]. (追記ここまで)

(追記) In [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ], (追記ここまで)(追記) AlgorithmID (追記ここまで),(追記) PartyUInfo (追記ここまで),(追記) PartyVInfo (追記ここまで),(追記) SuppPubInfo (追記ここまで)(追記) and (追記ここまで)(追記) SuppPrivInfo (追記ここまで)(追記) attributes are all defined as arbitrary-length bitstrings, thus they may need to be padded in order to be encoded into hexBinary for XML Encryption. The following padding and encoding method (追記ここまで)(追記) must (追記ここまで)(追記) be used when encoding bitstring values for the (追記ここまで)(追記) AlgorithmID (追記ここまで),(追記) PartyUInfo (追記ここまで),(追記) PartyVInfo (追記ここまで),(追記) SuppPubInfo (追記ここまで)(追記) and (追記ここまで)(追記) SuppPrivInfo (追記ここまで):

  1. (追記) The bitstring is divided into octets using big-endian encoding. If the length of the bitstring is not a multiple of 8 then add padding bits (value 0) as necessary to the last octet to make it a multiple of 8. (追記ここまで)

  2. (追記) Prepend one octet to the octets string from step 1. This octet shall identify (in a big-endian representation) the number of padding bits added to the last octet in step 1. (追記ここまで)

  3. (追記) Encode the octet string resulting from step 2 as a hexBinary string. (追記ここまで)

(追記) Example: the bitstring (追記ここまで)(追記) 11011 (追記ここまで),(追記) which is 5 bits long, gets 3 additional padding bits to become the bitstring (追記ここまで)(追記) 11011000 (追記ここまで)(追記) (or (追記ここまで)(追記) D8 (追記ここまで)(追記) in hex). This bitstring is then prepended with one octet identifying the number of padding bits to become the octet string (in hex) (追記ここまで)(追記) 03D8 (追記ここまで),(追記) which then finally is encoded as a hexBinary string value of "03D8". (追記ここまで)

(追記) Note that as specified in [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ], these attributes shall be concatenated to form a bit string 窶廾therInfo窶? that is used with the key derivation function. The concatenation (追記ここまで)(追記) shall (追記ここまで)(追記) be done using the original, unpadded bit string values.窶? Applications (追記ここまで)(追記) must (追記ここまで)(追記) also verify that these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800-56. (追記ここまで)

(追記) An example of an (追記ここまで)(追記) xenc11:DerivedKey (追記ここまで)(追記) element with this key derivation algorithm given below. In this example, the bitstring value of (追記ここまで)(追記) AlgorithmID (追記ここまで)(追記) is (追記ここまで)(追記) 00000000 (追記ここまで),(追記) the bitstring value of (追記ここまで)(追記) PartyUInfo (追記ここまで)(追記) is (追記ここまで)(追記) 11011 (追記ここまで)(追記) and the bitstring value of (追記ここまで)(追記) PartyVInfo (追記ここまで)(追記) is (追記ここまで)(追記) 11010 (追記ここまで):

(追記) Note (追記ここまで)
(追記) While any bit string can be used with ConcatKDF, it is (追記ここまで)(追記) recommended (追記ここまで)(追記) to keep byte aligned for greatest interoperability. (追記ここまで)

(追記) 5.4.2 (追記ここまで)(追記) PBKDF2 (追記ここまで)

(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#pbkdf2 (追記ここまで)

(追記) The PBKDF2 key derivation algorithm and the ASN.1 type definitions for its parameters are defined in PKCS #5 v2.0 [ (追記ここまで)(追記) PKCS5 (追記ここまで) (追記) ]. The XML schema definitions for the parameters is defined in [ (追記ここまで)(追記) PKCS5Amd1 (追記ここまで) (追記) ] and the same can be specified by enclosing them within an (追記ここまで)(追記) xenc11:PBKDF2-params (追記ここまで)(追記) child element of the (追記ここまで)(追記) xenc11:KeyDerivationMethod (追記ここまで)(追記) element. (追記ここまで)

(追記) (Note: A newline has been added to the Algorithm attribute to fit on this page, but is not part of the URI.) (追記ここまで)

(追記) The (追記ここまで)(追記) PBKDF2-params (追記ここまで)(追記) element and its child elements have the same names and meaning as the corresponding components of the (追記ここまで)(追記) PBKDF2-params (追記ここまで)(追記) ASN.1 type in [ (追記ここまで)(追記) PKCS5 (追記ここまで) (追記) ]. Note, in case of ConcatKDF and the Diffie Hellman legacy KDF, (追記ここまで)(追記) KeyLength (追記ここまで)(追記) is an implied parameter and needs to be inferred from the context, but in the case of PBKDF2 the (追記ここまで)(追記) KeyLength (追記ここまで)(追記) child element has to be specified, as it has been made a mandatory parameter to be consistent with PKCS5. For PBKDF2, the inferred key length must match the specified key length, otherwise it is an error condition. (追記ここまで)

(追記) The (追記ここまで)(追記) AlgorithmIdentifierType (追記ここまで)(追記) corresponds to the (追記ここまで)(追記) AlgorithmIdentifier (追記ここまで)(追記) type of [ (追記ここまで)(追記) PKCS5 (追記ここまで) (追記) ] and carries the algorithm identifier in the (追記ここまで)(追記) Algorithm (追記ここまで)(追記) attribute. Algorithm specific parameters, where applicable, can be specified using the (追記ここまで)(追記) Parameters (追記ここまで)(追記) element. (追記ここまで)

(追記) The (追記ここまで)(追記) PRFAlgorithmIdentifierType (追記ここまで)(追記) is derived from the (追記ここまで)(追記) AlgorithmIdentifierType (追記ここまで)(追記) and constrains the choice of algorithms to those contained in the PBKDF2-PRFs set defined in [ (追記ここまで)(追記) PKCS5 (追記ここまで) (追記) ]. This type is used to specify a pseudorandom function (PRF) for PBKDF2. Whereas HMAC-SHA1 is the default PRF algorithm in [ (追記ここまで)(追記) PKCS5 (追記ここまで) (追記) ], use of HMAC-SHA256 is (追記ここまで)(追記) recommended (追記ここまで)(追記) by this specification (see [ (追記ここまで)(追記) XMLDSIG-CORE1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) HMAC (追記ここまで) (追記) ]). (追記ここまで)

(追記) An example of an (追記ここまで)(追記) xenc11:DerivedKey (追記ここまで)(追記) element with this key derivation algorithm is: (追記ここまで)

(追記) 5.5 (追記ここまで)(追記) Key Transport (追記ここまで)

Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. Their identifiers appear as Algorithm attributes to EncryptionMethod elements that are children of EncryptedKey . EncryptedKey is in turn the child of a ds:KeyInfo element. The type of key being transported, that is to say the algorithm in which it is planned to use the transported key, is given by the Algorithm attribute of the EncryptionMethod child of the EncryptedData or EncryptedKey parent of this ds:KeyInfo element.

(Key Transport algorithms may optionally be used to encrypt data in which case they appear directly as the Algorithm attribute of an EncryptionMethod child of an EncryptedData element. Because they use public key algorithms directly, Key Transport algorithms are not efficient for the transport of any amounts of data significantly larger than symmetric keys.)

(削除) The RSA v1.5 Key Transport algorithm given below are those used in conjunction with TRIPLEDES and the Cryptographic Message Syntax (CMS) of S/MIME [ CMS-Algorithms ]. The RSA v2 Key Transport algorithm given below is that used in conjunction with AES and CMS [ AES-WRAP ]. (削除ここまで)

(削除) 5.4.1 (削除ここまで) (追記) 5.5.1 (追記ここまで) RSA Version 1.5

Identifier:
http://www.w3.org/2001/04/xmlenc#rsa-1_5 (削除) (REQUIRED) (削除ここまで)

The RSAES-PKCS1-v1_5 algorithm, specified in RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 ], takes no explicit parameters. An example of an RSA Version 1.5 EncryptionMethod element is:

(削除) <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> (削除ここまで)

The CipherValue for such an encrypted key is the base64 [ (削除) MIME (削除ここまで) (追記) RFC2045 (追記ここまで) ] encoding of the octet string computed as per RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 (削除) , (削除ここまで) (追記) ], (追記ここまで) section 7.2.1: Encryption operation]. As specified in the EME-PKCS1-v1_5 function RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 (削除) , (削除ここまで) (追記) ], (追記ここまで) section (削除) 9.1.2.1], (削除ここまで) (追記) 7.2.1, (追記ここまで) the value input to the key transport function is as follows:

(追記) Example 1 (追記ここまで)

CRYPT


(


PAD


(


KEY


))

where the padding is of the following special form:

(追記) Example 2 (追記ここまで)

02



|
(削除) PS*
 (削除ここまで)


(追記) PS
 (追記ここまで)(追記) 
*
 (追記ここまで)
|



00



|


key

where "|" is concatenation, "02" and "00" are fixed octets of the corresponding hexadecimal value, PS is a string of strong pseudo-random octets [ RANDOM ] at least eight octets long, containing no zero octets, and long enough that the value of the quantity being CRYPTed is one octet shorter than the RSA modulus, and "key" is the key being transported. The key is 192 bits for TRIPLEDES and 128, 192, or 256 bits for AES. (削除) Support of (削除ここまで)

(追記) Implementations (追記ここまで)(追記) must (追記ここまで)(追記) support (追記ここまで) this key transport algorithm for transporting (削除) 192 bit keys is MANDATORY to implement. (削除ここまで) (追記) 192-bit TRIPLEDES keys. (追記ここまで) Support of this algorithm for transporting other keys is (削除) OPTIONAL. (削除ここまで) (追記) optional (追記ここまで). RSA-OAEP is (削除) RECOMMENDED (削除ここまで) (追記) recommended (追記ここまで) for the transport of AES keys.

The resulting base64 [ (削除) MIME (削除ここまで) (追記) RFC2045 (追記ここまで) ] string is the value of the child text node of the CipherData element, e.g.

(削除) <CipherData> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4 t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw= </CipherData> (削除ここまで) (追記) (Note: A newline has been added to the (追記ここまで)(追記) CipherValue (追記ここまで)(追記) to fit on this page, but is not part of value.) (追記ここまで)

(追記) Note: Implementation of RSA v1.5 is (追記ここまで)(追記) not recommended (追記ここまで)(追記) due to security risks associated with the algorithm. (追記ここまで)

(削除) 5.4.2 RSA-OAEP (削除ここまで) (追記) 5.5.2 (追記ここまで)(追記) RSA-OAEP (追記ここまで)

Identifier:
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (削除) (REQUIRED) (削除ここまで) (追記) (including (追記ここまで)(追記) MGF1 with SHA1 (追記ここまで)(追記) mask generation function) (追記ここまで)
(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#rsa-oaep (追記ここまで)

The RSAES-OAEP-ENCRYPT algorithm, as specified in RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 ], (削除) takes three parameters. The two user specified parameters are a MANDATORY (削除ここまで) (追記) has options that define the (追記ここまで) message digest function and (追記) mask generation function, as well as (追記ここまで) an (削除) OPTIONAL encoding octet string OAEPparams . The message digest function is indicated by the (削除ここまで) (追記) optional (追記ここまで) (削除) Algorithm (削除ここまで) (追記) PSourceAlgorithm (追記ここまで) (削除) attribute of a child (削除ここまで) (追記) parameter. Default values defined in RFC 3447 are (追記ここまで) (削除) ds:DigestMethod (削除ここまで) (追記) SHA1 (追記ここまで) (削除) element and the mask generation function, (削除ここまで) (追記) for (追記ここまで) the (削除) third parameter, is always (削除ここまで) (追記) message digest and (追記ここまで) MGF1 with SHA1 (削除) (mgf1SHA1Identifier). (削除ここまで) (追記) for the mask generation function. (追記ここまで) Both the message digest and mask generation functions are used in the EME-OAEP-ENCODE operation as part of (削除) RSAES-OAEP-ENCRYPT. (削除ここまで) (追記) RSAES- OAEP-ENCRYPT. (追記ここまで)

The (削除) encoding octet string is (削除ここまで) (追記) http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p identifier defines (追記ここまで) the (削除) base64 decoding (削除ここまで) (追記) mask generation function as the fixed value (追記ここまで) of (追記) MGF1 with SHA1 (追記ここまで).(追記) In this case (追記ここまで) the (削除) content (削除ここまで) (追記) optional (追記ここまで)(追記) xenc11:MGF (追記ここまで)(追記) element (追記ここまで) of (削除) an (削除ここまで) (追記) the (追記ここまで)(追記) xenc:EncryptionMethod (追記ここまで)(追記) element (追記ここまで)(追記) must not (追記ここまで)(追記) be provided. (追記ここまで)

(追記) The http://www.w3.org/2009/xmlenc11#rsa-oaep identifier defines the mask generation function using the (追記ここまで) optional (削除) OAEPparams (削除ここまで) (追記) xenc11:MGF (追記ここまで) (削除) child (削除ここまで) element (削除) . (削除ここまで) (追記) of the (追記ここまで)(追記) xenc:EncryptionMethod (追記ここまで)(追記) element. (追記ここまで) If (削除) no (削除ここまで) (追記) not present, the default of (追記ここまで) (削除) OAEPparams (削除ここまで) (追記) MGF1 with SHA1 (追記ここまで)(追記) is to be used. (追記ここまで)

(追記) The following URIs define the various mask generation function URI values that may be used. These correspond to the object identifiers defined in RFC 4055 [ (追記ここまで)(追記) RFC4055 (追記ここまで) (追記) ]: (追記ここまで)

  • (追記) MGF1 with SHA1: http://www.w3.org/2009/xmlenc11#mgf1sha1 (追記ここまで)
  • (追記) MGF1 with SHA224: http://www.w3.org/2009/xmlenc11#mgf1sha224 (追記ここまで)
  • (追記) MGF1 with SHA256: http://www.w3.org/2009/xmlenc11#mgf1sha256 (追記ここまで)
  • (追記) MGF1 with SHA384: http://www.w3.org/2009/xmlenc11#mgf1sha384 (追記ここまで)
  • (追記) MGF1 with SHA512: http://www.w3.org/2009/xmlenc11#mgf1sha512 (追記ここまで)

(追記) Otherwise the two identifiers define the same usage of the RSA-OAEP algorithm, as follows. (追記ここまで)

(追記) The message digest function (追記ここまで)(追記) should (追記ここまで)(追記) be specified using the Algorithm attribute of the (追記ここまで)(追記) ds:DigestMethod (追記ここまで) child (追記) element of the (追記ここまで)(追記) xenc:EncryptionMethod (追記ここまで)(追記) element. If it (追記ここまで) is (削除) provided, a null string (削除ここまで) (追記) not specified, the default value of (追記ここまで)(追記) SHA1 (追記ここまで) is (追記) to be (追記ここまで) used.

(削除) Schema Definition: <!-- use these element types as children of EncryptionMethod when used with RSA-OAEP --> <element name='OAEPparams' minOccurs='0' type='base64Binary'/> <element ref='ds:DigestMethod' minOccurs='0'/> (削除ここまで)

(追記) The optional RSA-OAEP (追記ここまで)(追記) PSourceAlgorithm (追記ここまで)(追記) parameter value (追記ここまで)(追記) may (追記ここまで)(追記) be explicitly provided by placing the base64 encoded octets in the (追記ここまで)(追記) xenc:OAEPparams (追記ここまで)(追記) XML element. (追記ここまで)

(追記) The XML Encryption 1.0 schema definition and description for the (追記ここまで)(追記) EncryptionMethod (追記ここまで)(追記) element is in (追記ここまで)(追記) section 3.2 The EncryptionMethod Element (追記ここまで).(追記) The following shows the XML Encryption 1.1 addition for the MGF type: (追記ここまで)

An example of an RSA-OAEP element is:

(削除) <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"> <OAEPparams> 9lWu3Q== </OAEPparams> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> (削除ここまで)
Example 3
<EncryptionMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><OAEPparams>9lWu3Q==</OAEPparams><ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<EncryptionMethod>

(追記) Another example is: (追記ここまで)

The CipherValue for an RSA-OAEP encrypted key is the base64 [ (削除) MIME (削除ここまで) (追記) RFC2045 (追記ここまで) ] encoding of the octet string computed as per RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 (削除) , (削除ここまで) (追記) ], (追記ここまで) section 7.1.1: Encryption (削除) operation]. (削除ここまで) (追記) operation. (追記ここまで) As described in the EME-OAEP-ENCODE function RFC (削除) 2437 (削除ここまで) (追記) 3447 (追記ここまで) [ PKCS1 (削除) , (削除ここまで) (追記) ], (追記ここまで) section (削除) 9.1.1.1], (削除ここまで) (追記) 7.1.1, (追記ここまで) the value input to the key transport function is calculated using the message digest function and string specified in the DigestMethod and OAEPparams elements and using (追記) either (追記ここまで) the mask generator function (追記) specified with the (追記ここまで)(追記) xenc11:MGF (追記ここまで)(追記) element or the default (追記ここまで) MGF1 (削除) (with SHA1) (削除ここまで) (追記) with SHA1 (追記ここまで) specified in RFC (削除) 2437. (削除ここまで) (追記) 3447. (追記ここまで) The desired output length for EME-OAEP-ENCODE is one byte shorter than the RSA modulus.

The transported key size is 192 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Implementations (削除) MUST (削除ここまで) (追記) must (追記ここまで) implement RSA-OAEP for the transport of (削除) 128 (削除ここまで) (追記) all key types (追記ここまで) and (削除) 256 bit keys. (削除ここまで) (追記) sizes that are mandatory to implement for symmetric encryption. (追記ここまで) They (削除) MAY (削除ここまで) (追記) may (追記ここまで) implement RSA-OAEP for the transport of other keys.

(削除) 5.5 (削除ここまで) (追記) 5.6 (追記ここまで) Key Agreement

A Key Agreement algorithm provides for the derivation of a shared secret key based on a shared secret computed from certain types of compatible public keys from both the sender and the recipient. Information from the originator to determine the secret is indicated by an optional OriginatorKeyInfo parameter child of an AgreementMethod element while that associated with the recipient is indicated by an optional RecipientKeyInfo . A shared key is derived from this shared secret by a method determined by the Key Agreement algorithm.

Note: XML Encryption does not provide an (削除) on-line (削除ここまで) (追記) online (追記ここまで) key agreement negotiation protocol. The AgreementMethod element can be used by the originator to identify the keys and computational procedure that were used to obtain a shared encryption key. The method used to obtain or select the keys or algorithm used for the agreement computation is beyond the scope of this specification.

The AgreementMethod element appears as the content of a ds:KeyInfo since, like other ds:KeyInfo children, it yields a key. This ds:KeyInfo is in turn a child of an EncryptedData or EncryptedKey element. The Algorithm attribute and KeySize child of the EncryptionMethod element under this EncryptedData or EncryptedKey element are implicit parameters to the key agreement computation. In cases where this EncryptionMethod algorithm URI is insufficient to determine the key length, a KeySize (削除) MUST (削除ここまで) (追記) must (追記ここまで) have been included.

(追記) Key derivation algorithms (with associated parameters) may be explicitly declared by using the (追記ここまで)(追記) xenc11:KeyDerivationMethod (追記ここまで)(追記) element. This element will then be placed at the extensibility point of the (追記ここまで)(追記) xenc:AgreementMethodType (追記ここまで)(追記) (see below). (追記ここまで)

In addition, the sender may place a KA-Nonce element under AgreementMethod to assure that different keying material is generated even for repeated agreements using the same sender and recipient public keys. For example:

(削除) <EncryptedData> <EncryptionMethod Algorithm="Example:Block/Alg" <KeySize>80</KeySize> </EncryptionMethod> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <AgreementMethod Algorithm="example:Agreement/Algorithm"> <KA-Nonce>Zm9v</KA-Nonce> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/> <OriginatorKeyInfo> <ds:KeyValue>....</ds:KeyValue> </OriginatorKeyInfo> <RecipientKeyInfo> <ds:KeyValue>....</ds:KeyValue> </RecipientKeyInfo> </AgreementMethod> </ds:KeyInfo> <CipherData>...</CipherData> </EncryptedData> (削除ここまで)

If the agreed key is being used to wrap a key, rather than data as above, then AgreementMethod would appear inside a ds:KeyInfo inside an EncryptedKey element.

The Schema for AgreementMethod is as follows:

(削除) Schema Definition: (削除ここまで)
(削除) <element name="AgreementMethod" type="xenc:AgreementMethodType"/> <complexType name="AgreementMethodType" mixed="true"> <sequence> <element name="KA-Nonce" minOccurs="0" type="base64Binary"/> <!-- <element ref="ds:DigestMethod" minOccurs="0"/> --> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <element name="OriginatorKeyInfo" minOccurs="0" type="ds:KeyInfoType"/> <element name="RecipientKeyInfo" minOccurs="0" type="ds:KeyInfoType"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> (削除ここまで)

(削除) 5.5.1 (削除ここまで) (追記) 5.6.1 (追記ここまで) Diffie-Hellman Key Values

Identifier:
http://www.w3.org/2001/04/xmlenc#DHKeyValue (削除) (OPTIONAL) (削除ここまで)

Diffie-Hellman keys can appear directly within KeyValue elements or be obtained by ds:RetrievalMethod fetches as well as appearing in certificates and the like. The above identifier can be used as the value of the Type attribute of Reference or ds:RetrievalMethod elements.

As specified in [ ESDH ], a DH public key consists of up to six quantities, two large primes p and q, a "generator" g, the public key, and validation parameters "seed" and "pgenCounter". These relate as follows: The public key = ( g**x mod p ) where x is the corresponding private key; p = j*q + 1 where j >= 2. "seed" and "pgenCounter" are optional and can be used to determine if the Diffie-Hellman key has been generated in conformance with the algorithm specified in [ ESDH ]. Because the primes and generator can be safely shared over many DH keys, they may be known from the application environment and are optional. The schema for a DHKeyValue is as follows:

(削除) Schema: <element name="DHKeyValue" type="xenc:DHKeyValueType"/> <complexType name="DHKeyValueType"> <sequence> <sequence minOccurs="0"> <element name="P" type="ds:CryptoBinary"/> <element name="Q" type="ds:CryptoBinary"/> <element name="Generator"type="ds:CryptoBinary"/> </sequence> <element name="Public" type="ds:CryptoBinary"/> <sequence minOccurs="0"> <element name="seed" type="ds:CryptoBinary"/> <element name="pgenCounter" type="ds:CryptoBinary"/> </sequence> </sequence> </complexType> (削除ここまで)

(削除) 5.5.2 (削除ここまで) (追記) 5.6.2 (追記ここまで) Diffie-Hellman Key Agreement

(削除) Identifier: http://www.w3.org/2001/04/xmlenc#dh (OPTIONAL) (削除ここまで)

The Diffie-Hellman (DH) key agreement protocol [ ESDH ] involves the derivation of shared secret information based on compatible DH keys from the sender and recipient. Two DH public keys are compatible if they have the same prime and generator. If, for the second one, Y = g**y mod p , then the two parties can calculate the shared secret ZZ = ( g**(x*y) mod p ) even though each knows only their own private key and the other party's public key. Leading zero bytes (削除) MUST (削除ここまで) (追記) must (追記ここまで) be maintained in ZZ so it will be the same length, in bytes, as p . The size of p (削除) MUST (削除ここまで) (追記) must (追記ここまで) be at least 512 bits and g at least 160 bits. There are numerous other complex security considerations in the selection of g , p , and a random x as described in [ ESDH ].

(追記) The Diffie-Hellman shared secret (追記ここまで)(追記) zz (追記ここまで)(追記) is used as the input to a KDF to produce a secret key. XML Signature 1.0 defined a specific KDF to be used with Diffie-Hellman; that KDF is now known as the "Legacy KDF" and is defined in Section 5.6.2.2. Use of Diffie-Hellman with explicit KDFs is described in Section 5.6.2.1. (追記ここまで)

(追記) Implementation of (追記ここまで) Diffie-Hellman key agreement is optional (削除) to implement. (削除ここまで) . (追記) However, if implemented, such implementations (追記ここまで)(追記) must (追記ここまで)(追記) support the Legacy Key Derivation Function and (追記ここまで)(追記) should (追記ここまで)(追記) support Diffie-Hellman with explicit Key Derivation Functions (追記ここまで)

An example of a DH AgreementMethod element (追記) using the Legacy Key Derivation Function (Section 5.6.2.2) (追記ここまで) is as follows:

(削除) <AgreementMethod Algorithm="http://www.w3.org/2001/04/xmlenc#dh" ds:xmlns="http://www.w3.org/2000/09/xmldsig#"> <KA-Nonce>Zm9v</KA-Nonce> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <OriginatorKeyInfo> <ds:X509Data><ds:X509Certificate> ... </ds:X509Certificate></ds:X509Data> </OriginatorKeyInfo> <RecipientKeyInfo><ds:KeyValue> ... </ds:KeyValue></RecipientKeyInfo> </AgreementMethod> (削除ここまで)
(追記) 5.6.2.1 (追記ここまで)(追記) Diffie-Hellman Key Agreement with Explicit Key Derivation Functions (追記ここまで)
(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#dh-es (追記ここまで)

(追記) It is (追記ここまで)(追記) recommended (追記ここまで)(追記) that the shared key material for a Diffie-Hellman key agreement be calculated from the Diffie-Hellman shared secret using a key derivation function (KDF) in accordance with (追記ここまで)(追記) Section 5.4 (追記ここまで).

(追記) An example of a DH (追記ここまで)(追記) AgreementMethod (追記ここまで)(追記) element using an explicit key derivation function is as follows: (追記ここまで)

(追記) 5.6.2.2 (追記ここまで)(追記) Diffie-Hellman Key Agreement with Legacy Key Derivation Function (追記ここまで)
(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2001/04/xmlenc#dh (追記ここまで)

(追記) XML Signature 1.0 defined a specific KDF for use with Diffie-Hellman key agreement. In order to guarantee interoperability, implementations that choose to implement Diffie-Hellman (追記ここまで)(追記) must (追記ここまで)(追記) support the use of the Diffie-Hellman Legacy KDF defined in this section. (追記ここまで)

Assume (追記) that (追記ここまで) the Diffie-Hellman shared secret is the octet sequence ZZ . The (追記) Diffie-Hellman Legacy KDF calculates the (追記ここまで) shared keying material (削除) needed will then be calculated (削除ここまで) as follows:

(追記) Example 4 (追記ここまで)

Keying



Material



=
(削除) KM(1)
 (削除ここまで)


(追記) KM
 (追記ここまで)(追記) 
(
 (追記ここまで)(追記) 
1
 (追記ここまで)(追記) 
)
 (追記ここまで)
|
(削除) KM(2)
 (削除ここまで)


(追記) KM
 (追記ここまで)(追記) 
(
 (追記ここまで)(追記) 
2
 (追記ここまで)(追記) 
)
 (追記ここまで)
|
(削除) ...
 (削除ここまで)


...

where "|" is byte stream concatenation and

(削除) KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg | KA-Nonce (削除ここまで)
Example 5
KM(counter)=DigestAlg( ZZ | counter |EncryptionAlg|
(追記) KA
 (追記ここまで)(追記) 
-
 (追記ここまで)(追記) 
Nonce
 (追記ここまで)
|



KeySize



)

DigestAlg
The message digest algorithm specified by the DigestMethod child of AgreementMethod .
EncryptionAlg
The URI of the encryption algorithm, including possible key wrap algorithms, in which the derived keying material is to be used ("Example:Block/Alg" in the example above), not the URI of the agreement algorithm. This is the value of the Algorithm attribute of the EncryptionMethod child of the EncryptedData or EncryptedKey grandparent of AgreementMethod .
KA-Nonce
The base64 decoding the content of the KA-Nonce child of AgreementMethod , if present. If the KA-Nonce element is absent, it is null.
Counter
A one byte counter starting at one and incrementing by one. It is expressed as two hex digits where letters A through F are in upper case.
KeySize
The size in bits of the key to be derived from the shared secret as the UTF-8 string for the corresponding decimal integer with only digits in the string and no leading zeros. For some algorithms the key size is inherent in the URI. For others, such as most stream ciphers, it must be explicitly provided.

For example, the initial (KM(1)) calculation for the EncryptionMethod of the Key Agreement example (section 5.5) would be as follows, where the binary one byte counter value of 1 is represented by the two character UTF-8 sequence 01 , ZZ is the shared secret, and " foo " is the base64 decoding of " Zm9v ".

(削除) SHA-1 (削除ここまで)
(追記) Example 6 (追記ここまで)
(追記) 
SHA
 (追記ここまで)(追記) 
-
 (追記ここまで)(追記) 
1
 (追記ここまで)
(
(削除) ZZ01Example:Block/Algfoo80
 (削除ここまで)


(追記) ZZ01Example
 (追記ここまで):(追記) 
Block
 (追記ここまで)(追記) 
/
 (追記ここまで)(追記) 
Algfoo80
 (追記ここまで)
)

Assuming that ZZ is 0xDEADBEEF , that would be

(削除) SHA-1( (削除ここまで)
(追記) Example 7 (追記ここまで)
(追記) 
SHA
 (追記ここまで)(追記) 
-
 (追記ここまで)(追記) 
1
 (追記ここまで)(追記) 
(
 (追記ここまで)
0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830



)

whose value is

(追記) Example 8 (追記ここまで)

0x534C9B8C4ABDCB50038B42015A181711068B08C1

Each application of DigestAlg for successive values of Counter will produce some additional number of bytes of keying material. From the concatenated string of one or more KM 's, enough leading bytes are taken to meet the need for an actual key and the remainder discarded. For example, if DigestAlg is SHA-1 which produces 20 octets of hash, then for 128 bit AES the first 16 bytes from KM(1) would be taken and the remaining 4 bytes discarded. For 256 bit AES, all of KM(1) suffixed with the first 12 bytes of KM(2) would be taken and the remaining 8 bytes of KM(2) discarded.

(追記) 5.6.3 (追記ここまで)(追記) Elliptic Curve Diffie-Hellman (ECDH) Key Values (追記ここまで)

(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmldsig11#ECKeyValue (追記ここまで)

(追記) ECDH has identical public key parameters as ECDSA and can be represented with the (追記ここまで)(追記) ECKeyValue (追記ここまで)(追記) element [ (追記ここまで)(追記) XMLDSIG-CORE1 (追記ここまで) (追記) ]. Note that if the curve parameters are explicitly stated using the ECParameters element, then the Cofactor element (追記ここまで)(追記) must (追記ここまで)(追記) be included. (追記ここまで)

(追記) As with Diffie-Hellman keys, Elliptic Curve Key Values can appear directly within (追記ここまで)(追記) KeyValue (追記ここまで)(追記) elements or be obtained by (追記ここまで)(追記) ds:RetrievalMethod (追記ここまで)(追記) fetches as well as appearing in certificates and the like. The above identifier can be used as the value of the (追記ここまで)(追記) Type (追記ここまで)(追記) attribute of (追記ここまで)(追記) Reference (追記ここまで)(追記) or (追記ここまで)(追記) ds:RetrievalMethod (追記ここまで)(追記) elements. (追記ここまで)

(追記) 5.6.4 (追記ここまで)(追記) Elliptic Curve Diffie-Hellman (ECDH) Key Agreement (Ephemeral-Static Mode) (追記ここまで)

(追記) Identifier: (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#ECDH-ES (追記ここまで)

(追記) ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in [ (追記ここまで)(追記) ECC-ALGS (追記ここまで) (追記) ]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters. (追記ここまで)

(追記) Compliant implementations are (追記ここまで)(追記) required (追記ここまで)(追記) to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [ (追記ここまで)(追記) FIPS-186-3 (追記ここまで) (追記) ]. (This is the same curve that is (追記ここまで)(追記) required (追記ここまで)(追記) in XML Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It is further (追記ここまで)(追記) recommended (追記ここまで)(追記) that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively. (追記ここまで)

(追記) The shared key material is calculated from the Diffie-Hellman shared secret using a key derivation function (KDF). While applications may define other KDFs, compliant implementations (追記ここまで)(追記) must (追記ここまで)(追記) implement ConcatKDF (see (追記ここまで)(追記) section 5.4.1 ConcatKDF (追記ここまで) (追記) ). An example of (追記ここまで)(追記) xenc:EncryptedData (追記ここまで)(追記) using the ECDH-ES key agreement algorithm with the ConcatKDF key derivation algorithm is as follows: (追記ここまで)

(削除) 5.6 (削除ここまで) (追記) 5.7 (追記ここまで) Symmetric Key Wrap

Symmetric Key Wrap algorithms are shared secret key encryption algorithms especially specified for encrypting and decrypting symmetric keys. (削除) Their identifiers appear as Algorithm attribute values to EncryptionMethod elements that (削除ここまで) (追記) When wrapped keys (追記ここまで) are (削除) children of (削除ここまで) (追記) used, then an (追記ここまで) EncryptedKey (削除) which is in turn (削除ここまで) (追記) element will appear as (追記ここまで) a child of (削除) ds:KeyInfo which is in turn (削除ここまで) a (削除) child of (削除ここまで) (削除) EncryptedData (削除ここまで) (追記) ds:KeyInfo (追記ここまで) (削除) or another (削除ここまで) (追記) element. This (追記ここまで) EncryptedKey (削除) . The type of the key being wrapped is indicated by the Algorithm (削除ここまで) (削除) attribute of (削除ここまで) (追記) element will have an (追記ここまで) EncryptionMethod child (削除) of the parent of the ds:KeyInfo grandparent of the (削除ここまで) (追記) whose (追記ここまで) (削除) EncryptionMethod (削除ここまで) (追記) Algorithm (追記ここまで) (削除) specifying (削除ここまで) (追記) attribute in turn identifies (追記ここまで) the (削除) symmetric (削除ここまで) key wrap algorithm.

(削除) 5.6.1 CMS Key Checksum (削除ここまで)

(削除) Some key wrap algorithms make use of a key checksum as defined in CMS [ CMS-Wrap ]. (削除ここまで) The algorithm (削除) that provides an integrity check value (削除ここまで) for (追記) which (追記ここまで) the (追記) encrypted (追記ここまで) key (削除) being wrapped is: Compute the 20 octet SHA-1 hash (削除ここまで) (追記) is intended depends (追記ここまで) on the (削除) key being wrapped. Use the first 8 octets (削除ここまで) (追記) context (追記ここまで) of (削除) this hash (削除ここまで) (追記) the (追記ここまで)(追記) ds:KeyInfo (追記ここまで)(追記) element: (追記ここまで)(追記) ds:KeyInfo (追記ここまで)(追記) can occur (追記ここまで) as (追記) a child of either an (追記ここまで)(追記) EncryptedData (追記ここまで)(追記) or (追記ここまで)(追記) EncryptedKey (追記ここまで)(追記) element; in both cases, (追記ここまで)(追記) ds:KeyInfo (追記ここまで)(追記) will have an (追記ここまで)(追記) EncryptionMethod (追記ここまで)(追記) sibling that identifies (追記ここまで) the (削除) checksum value. (削除ここまで) (追記) algorithm. (追記ここまで)

(削除) 5.6.2 (削除ここまで) (追記) 5.7.1 (追記ここまで) CMS Triple DES Key Wrap

(削除) Identifiers and Requirements: (削除ここまで) (追記) Identifiers: (追記ここまで)
http://www.w3.org/2001/04/xmlenc#kw-tripledes (削除) (REQUIRED) (削除ここまで)

XML Encryption implementations (削除) MUST (削除ここまで) (追記) must (追記ここまで) support TRIPLEDES wrapping of 168 bit keys (追記) as described in [ (追記ここまで)(追記) CMS-WRAP (追記ここまで) (追記) ] (追記ここまで) and may optionally support TRIPLEDES wrapping of other keys.

An example of a TRIPLEDES Key Wrap EncryptionMethod element is as follows:

(削除) <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/> The following algorithm wraps (encrypts) a key (the wrapped key, WK) under a TRIPLEDES key-encryption-key (KEK) as adopted from [ CMS-Algorithms ]: Represent the key being wrapped as an octet sequence. If it is a TRIPLEDES key, this is 24 octets (192 bits) with odd parity bit as the bottom bit of each octet. Compute the CMS key checksum (section 5.6.1) call this CKS. Let WKCKS = WK || CKS , where || is concatenation. Generate 8 random octets [ RANDOM ] and call this IV. Encrypt WKCKS in CBC mode using KEK as the key and IV as the initialization vector. Call the results TEMP1. Let TEMP2 = IV || TEMP1 . Reverse the order of the octets in TEMP2 and call the result TEMP3 . Encrypt TEMP3 in CBC mode using the KEK and an initialization vector of 0x4adda22c79e82105 . The resulting cipher text is the desired result. It is 40 octets long if a 168 bit key is being wrapped. The following algorithm unwraps (decrypts) a key as adopted from [ CMS-Algorithms ]: Check if the length of the cipher text is reasonable given the key type. It must be 40 bytes for a 168 bit key and either 32, 40, or 48 bytes for a 128, 192, or 256 bit key. If the length is not supported or inconsistent with the algorithm for which the key is intended, return error. Decrypt the cipher text with TRIPLEDES in CBC mode using the KEK and an initialization vector (IV) of 0x4adda22c79e82105 . Call the output TEMP3 . Reverse the order of the octets in TEMP3 and call the result TEMP2 . Decompose TEMP2 into IV, the first 8 octets, and TEMP1 , the remaining octets. Decrypt TEMP1 using TRIPLEDES in CBC mode using the KEK and the IV found in the previous step. Call the result WKCKS . Decompose WKCKS . CKS is the last 8 octets and WK , the wrapped key, are those octets before the CKS . Calculate a CMS key checksum (section 5.6.1) over the WK and compare with the CKS extracted in the above step. If they are not equal, return error. (削除ここまで)
(削除) WK is the wrapped key, now extracted for use in data decryption. (削除ここまで)

(削除) 5.6.3 (削除ここまで) (追記) 5.7.2 (追記ここまで) AES KeyWrap

(削除) Identifiers and Requirements: (削除ここまで) (追記) Identifiers: (追記ここまで)
http://www.w3.org/2001/04/xmlenc#kw-aes128 (削除) (REQUIRED) (削除ここまで)
http://www.w3.org/2001/04/xmlenc#kw-aes192 (削除) (OPTIONAL) (削除ここまで)
http://www.w3.org/2001/04/xmlenc#kw-aes256 (削除) (REQUIRED) (削除ここまで)

Implementation of AES key wrap is described (削除) below, as suggested by NIST. (削除ここまで) (追記) in [ (追記ここまで)(追記) AES-WRAP (追記ここまで) (追記) ]. (追記ここまで) It provides for confidentiality and integrity. This algorithm is defined only for inputs which are a multiple of 64 bits. The information wrapped need not actually be a key. The algorithm is the same whatever the size of the AES key used in wrapping, called the key encrypting key or KEK . The implementation requirements are indicated below.

128 bit AES Key Encrypting Key
Implementation of wrapping 128 bit keys (削除) REQUIRED. (削除ここまで) (追記) required (追記ここまで).
Wrapping of other key sizes (削除) OPTIONAL. (削除ここまで) (追記) optional (追記ここまで).
192 bit AES Key Encrypting Key
All support (削除) OPTIONAL. (削除ここまで) (追記) optional (追記ここまで).
256 bit AES Key Encrypting Key
Implementation of wrapping 256 bit keys (削除) REQUIRED. (削除ここまで) (追記) required (追記ここまで).
Wrapping of other key sizes (削除) OPTIONAL. (削除ここまで) (追記) optional (追記ここまで).
(削除) Assume that the data to be wrapped consists of N 64-bit data blocks denoted P(1) , P(2) , P(3) ... P(N) . The result of wrapping will be N+1 64-bit blocks denoted C(0) , C(1) , C(2) , ... C(N) . The key encrypting key is represented by K . Assume integers i , j , and t and intermediate 64-bit register A , 128-bit register B , and array of 64-bit quantities R(1) through R(N) . "|" represents concatentation so x|y , where x and y and 64-bit quantities, is the 128-bit quantity with x in the most significant bits and y in the least significant bits. AES(K)enc(x) is the operation of AES encrypting the 128-bit quantity x under the key K . AES(K)dec(x) is the corresponding decryption opteration. XOR(x,y) is the bitwise exclusive or of x and y . MSB(x) and LSB(y) are the most significant 64 bits and least significant 64 bits of x and y respectively. If N is 1, a single AES operation is performed for wrap or unwrap. If N>1 , then 6*N AES operations are performed for wrap or unwrap. The key wrap algorithm is as follows: If N is 1 : B=AES(K)enc(0xA6A6A6A6A6A6A6A6|P(1) ) C(0)=MSB(B) C(1)=LSB(B) If N>1 , perform the following steps: Initialize variables: Set A to 0xA6A6A6A6A6A6A6A6 For i=1 to N , R(i)=P(i) Calculate intermediate values: For j=0 to 5 , For i=1 to N , t= i + j*N B=AES(K)enc(A|R(i)) A=XOR(t,MSB(B)) R(i)=LSB(B) Output the results: Set C(0)=A For i=1 to N , C(i)=R(i) The key unwrap algorithm is as follows: If N is 1 : B=AES(K)dec(C(0)|C(1)) P(1)=LSB(B) If MSB(B) is 0xA6A6A6A6A6A6A6A6 , return success. Otherwise, return an integrity check failure error. If N >1, perform the following steps: Initialize the variables: A=C(0) For i=1 to N , R(i)=C(i) Calculate intermediate values: For j=5 to 0 , For i=N to 1 , t= i + j*N B=AES(K)dec(XOR(t,A)|R(i)) A=MSB(B) R(i)=LSB(B) Output the results: For i=1 to N , P(i)=R(i) If A is 0xA6A6A6A6A6A6A6A6 , return success. Otherwise, return an integrity check failure error. For example, wrapping the data 0x00112233445566778899AABBCCDDEEFF with the KEK 0x000102030405060708090A0B0C0D0E0F produces the ciphertext of 0x1FA68B0A8112B447 , 0xAEF34BD8FB5A7B82 , 0x9D3E862371D2CFE5 . (削除ここまで)

(削除) 5.7 (削除ここまで) (追記) 5.8 (追記ここまで) Message Digest

Message digest algorithms can be used in AgreementMethod as part of the key derivation, within RSA-OAEP encryption as a hash function, and in connection with the HMAC message authentication code method (追記) [ (追記ここまで)(追記) HMAC (追記ここまで) (追記) ] (追記ここまで) as described in [ (削除) XML-DSIG (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) ].) (追記) Use of SHA-256 is strongly recommended over SHA-1 because recent advances in cryptanalysis (see e.g. [ (追記ここまで)(追記) SHA-1-Analysis (追記ここまで) (追記) ], [ (追記ここまで)(追記) SHA-1-Collisions (追記ここまで) (追記) ] ) have cast doubt on the long-term collision resistance of SHA-1. Therefore, SHA-1 support is (追記ここまで)(追記) required (追記ここまで)(追記) in this specification only for backwards-compatibility reasons. (追記ここまで)

(削除) 5.7.1 SHA1 (削除ここまで) (追記) 5.8.1 (追記ここまで)(追記) SHA1 (追記ここまで)

Identifier:
http://www.w3.org/2000/09/xmldsig#sha1 (削除) (REQUIRED) (削除ここまで)

The SHA-1 algorithm [ (削除) SHA (削除ここまで) (追記) FIPS-180-3 (追記ここまで) ] takes no explicit parameters. An example of an SHA-1 DigestMethod element is:

(削除) <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> (削除ここまで)

A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:

(追記) Example 9 (追記ここまで)


A9993E36


4706816A


BA3E2571


7850C26C



9CD0D89D


from Appendix A of the SHA-1 standard would be:

(削除) <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue> (削除ここまで)

(削除) 5.7.2 SHA256 (削除ここまで) (追記) 5.8.2 (追記ここまで)(追記) SHA256 (追記ここまで)

Identifier:
http://www.w3.org/2001/04/xmlenc#sha256 (削除) (RECOMMENDED) (削除ここまで)

The SHA-256 algorithm [ (削除) SHA (削除ここまで) (追記) FIPS-180-3 (追記ここまで) ] takes no explicit parameters. An example of an SHA-256 DigestMethod element is:

(削除) <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> (削除ここまで)

A SHA-256 digest is a 256-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.

(削除) 5.7.3 SHA512 (削除ここまで) (追記) 5.8.3 (追記ここまで)(追記) SHA384 (追記ここまで)

Identifier:
(削除) http://www.w3.org/2001/04/xmlenc#sha512 (削除ここまで) (追記) http://www.w3.org/2001/04/xmlenc#sha384 (追記ここまで) (削除) (OPTIONAL) (削除ここまで)

The (削除) SHA-512 (削除ここまで) (追記) SHA-384 (追記ここまで) algorithm [ (削除) SHA (削除ここまで) (追記) FIPS-180-3 (追記ここまで) ] takes no explicit parameters. An example of an (削除) SHA-512 (削除ここまで) (追記) SHA-384 (追記ここまで) DigestMethod element is:

(削除) <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/> (削除ここまで)

A (削除) SHA-512 (削除ここまで) (追記) SHA-384 (追記ここまで) digest is a (削除) 512-bit (削除ここまで) (追記) 384-bit (追記ここまで) string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a (削除) 64-octet (削除ここまで) (追記) 48-octet (追記ここまで) octet stream.

(削除) 5.7.4 RIPEMD-160 (削除ここまで) (追記) 5.8.4 (追記ここまで)(追記) SHA512 (追記ここまで)

Identifier:
(削除) http://www.w3.org/2001/04/xmlenc#ripemd160 (削除ここまで) (追記) http://www.w3.org/2001/04/xmlenc#sha512 (追記ここまで) (削除) (OPTIONAL) (削除ここまで)

The (削除) RIPEMD-160 (削除ここまで) (追記) SHA-512 (追記ここまで) algorithm [ (削除) RIPEMD-160 (削除ここまで) (追記) FIPS-180-3 (追記ここまで) ] takes no explicit parameters. An example of an (削除) RIPEMD-160 (削除ここまで) (追記) SHA-512 (追記ここまで) DigestMethod element is:

(削除) <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#ripemd160"/> (削除ここまで)

A (削除) RIPEMD-160 (削除ここまで) (追記) SHA-512 (追記ここまで) digest is a (削除) 160-bit (削除ここまで) (追記) 512-bit (追記ここまで) string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a (削除) 20-octet (削除ここまで) (追記) 64-octet (追記ここまで) octet stream.

(削除) 5.8 Message Authentication (削除ここまで)

(追記) 5.8.5 (追記ここまで)(追記) RIPEMD-160 (追記ここまで)

Identifier:
(削除) http://www.w3.org/2000/09/xmldsig# (削除ここまで) (追記) http://www.w3.org/2001/04/xmlenc#ripemd160 (追記ここまで) (削除) (RECOMMENDED) (削除ここまで)

(削除) XML Signature (削除ここまで) (追記) The RIPEMD-160 algorithm (追記ここまで) [ (削除) XML-DSIG (削除ここまで) (追記) RIPEMD-160 (追記ここまで) ] (追記) takes no explicit parameters. An example of an RIPEMD-160 (追記ここまで)(追記) DigestMethod (追記ここまで)(追記) element is: (追記ここまで)

(追記) A RIPEMD-160 digest (追記ここまで) is (削除) OPTIONAL to implement for XML encryption applications. It is (削除ここまで) (追記) a 160-bit string. The content of (追記ここまで) the (削除) recommended way to provide key based authentication. (削除ここまで) (追記) DigestValue (追記ここまで)(追記) element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. (追記ここまで)

5.9 Canonicalization

A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML.

5.9.1 Inclusive Canonicalization

Identifiers:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (削除) (OPTIONAL) (削除ここまで)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments (削除) (OPTIONAL) (削除ここまで)
(追記) http://www.w3.org/2006/12/xml-c14n11 (追記ここまで)
(追記) http://www.w3.org/2006/12/xml-c14n11#WithComments (追記ここまで)

Canonical XML [ (削除) Canon (削除ここまで) (追記) XML-C14N11 (追記ここまで) ] is a method of serializing XML which includes the in scope namespace and xml namespace attribute context from ancestors of the XML being serialized.

If XML is to be encrypted and then later decrypted into a different environment and it is desired to preserve namespace prefix bindings and the value of attributes in the "xml" namespace of its original environment, then the canonical XML with comments version of the XML should be the serialization that is encrypted.

5.9.2 Exclusive Canonicalization

Identifiers:
http://www.w3.org/2001/10/xml-exc-c14n# (削除) (OPTIONAL) (削除ここまで)
http://www.w3.org/2001/10/xml-exc-c14n#WithComments (削除) (OPTIONAL) (削除ここまで)

Exclusive XML Canonicalization [ (削除) Exclusive (削除ここまで) (追記) XML-EXC-C14N (追記ここまで) ] serializes XML in such a way as to include to the minimum extent practical the namespace prefix binding and xml namespace attribute context inherited from ancestor elements.

It is the recommended method where the outer context of a fragment which was signed and then encrypted may be changed. Otherwise the validation of the signature over the fragment may fail because the canonicalization by signature validation may include unnecessary namespaces into the fragment.

(削除) 6 (削除ここまで) (追記) 6. (追記ここまで) Security Considerations

6.1 (追記) Chosen-Ciphertext Attacks (追記ここまで)

(追記) A number of chosen-ciphertext attacks against implementations of this specification have been published and demonstrated. They all involve the following elements: (追記ここまで)

  1. (追記) The attacker knows about the format of the cleartext. (追記ここまで)
  2. (追記) The attacker is able to submit substantial numbers of ciphertext messages. (追記ここまで)
  3. (追記) The attacker is able to send arbitrary ciphertext, based on previous results. (追記ここまで)
  4. (追記) The attacker is able to force the server to use the same key (secret key by CBC-based attacks and server's private key by PKCS#1.5 attacks) for processing of the adapted ciphertext. (追記ここまで)
  5. (追記) The server attempting to decrypt the ciphertext in some way signals whether the decrypted text is well-formed or not. (追記ここまで)

(追記) The attacker uses the knowledge of the format and the information about well-formedness to construct a series of ciphertext guesses which reveal the plaintext with much less work than brute force. Attacks of this type have been demonstrated against symmetric encryption using CBC mode [ (追記ここまで)(追記) XMLENC-CBC-ATTACK (追記ここまで) (追記) ][ (追記ここまで)(追記) XMLENC-CBC-ATTACK-COUNTERMEASURES (追記ここまで) (追記) ] and on PKCS#1 v1.5. Other future attacks can be expected whenever these conditions are met. (追記ここまで)

(追記) 6.1.1 (追記ここまで)(追記) Attacks against the encrypted data ( (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) part) (追記ここまで)

(追記) Using the CBC-based chosen-ciphertext attacks, the attacker sends to the server an XML document with modified encrypted data in the symmetric part ( (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) ). After a few requests, the attacker is able to get the whole cleartext without knowledge of the symmetric key. (追記ここまで)

(追記) It would seem that these attacks can be countered by by disrupting any of the conditions, however in practice only preventing condition 3 (sending arbitrary ciphertext) is fully effective. To counter condition 3, it is necessary for the decrypting system to require authenticated integrity protection over the ciphertext. However, unless the mechanism used is bound to the encryption key, there will no way to be sure that the signer is not attempting to recover the plaintext. The simplest and most efficient way to do this is to use an authenticating block mode, such as GCM. An alternative would be an HMAC based on the encryption key over the ciphertext, but it is less efficient and provides no advantages. (追記ここまで)

(追記) Other countermeasures are not likely to be effective. Limiting the number of messages presented or the number of messages using the same key is not practical in large server farms. Attackers can spread their attempts over different servers and long or short periods of time, to foil attempts to detect attacks in progress or determine the location of the attacker. (追記ここまで)

(追記) Signaling well-formedness can occur by emitting different messages for distinct security errors or by exhibiting timing differences. Implementations should avoid these practices, however that is not sufficient to prevent such attacks in an XML protocol environment, such as SOAP. Using a technique called encryption wrapping, the attacker can insert the ciphertext in some schema-legal part of the message. If the decryption code notices a format error, an error will be returned, but if not the message will be passed to the application which will ignore the bogus plaintext and ultimately respond with an application level success or failure message. (追記ここまで)

(追記) 6.1.2 (追記ここまで)(追記) Attacks against the encrypted key (Bleichenbacher's Million question attack on PKCS#1.5) (追記ここまで)

(追記) The goal of the attacker applying the Bleichenbacher's attack is to get the symmetric secret key, which is encrypted in the (追記ここまで)(追記) <EncryptedKey> (追記ここまで)(追記) part. Afterward, he would be able to decrypt the whole data carried in the (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) part. (追記ここまで)

(追記) The basic idea of this attack is to modify the data in the (追記ここまで)(追記) <EncryptedKey> (追記ここまで)(追記) part, send the document to the server, and observe if the modified ciphertext contains PKCS#1.5 conformant data. This can be done by: (追記ここまで)

  1. (追記) Observing fault messages of the server notifying directly that the request was not PKCS#1.5 conformant (this should not happen). (追記ここまで)
  2. (追記) Enlarging the data in the (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) part and observing the timing differences between inclusion of PKCS-valid and PKCS-invalid keys: if the key is PKCS-valid, the session key is extracted, and the large data is decrypted. Otherwise, the session key cannot be extracted and the large data is not processed, which yields a timing difference. (追記ここまで)
  3. (追記) Making specific modifications of the (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) part based on CBC and padding-properties. (追記ここまで)

(追記) These problems are described in detail in RFC 3218 [ (追記ここまで)(追記) RFC3218 (追記ここまで) (追記) ]. (追記ここまで)

(追記) The most effective countermeasure against the timing attack (2) is to generate a random secret key every time when the decrypted data was not PKCS#1-conformant. This way, the attacker would not get any timing side-channel. (追記ここまで)

(追記) Please note however that this is not a valid countermeasure against the specific modification of the (追記ここまで)(追記) <EncryptedData> (追記ここまで)(追記) described in part (3). The attacker could still use a few millions of requests to decrypt the encrypted symmetric key. Therefore, we recommend the usage of RSA-OAEP. RSA-OAEP also has a risk of a chosen ciphertext attack [ (追記ここまで)(追記) OAEP-ATTACK (追記ここまで) (追記) ] which can be mitigated in security library implementations. (追記ここまで)

(追記) 6.1.3 (追記ここまで)(追記) Backwards Compatibility Attacks (追記ここまで)

(追記) Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP and AES-GCM can become insecure when the adversary can force the server to process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 v1.5 or AES-CBC [ (追記ここまで)(追記) XMLENC-BACKWARDS-COMP (追記ここまで) (追記) ]: (追記ここまで)

  1. (追記) The attacker may be able to break the security of an AES-GCM ciphertext if he is able to force the server to process the ciphertext with AES-CBC and the same symmetric key. (追記ここまで)
  2. (追記) The attacker may be able to decrypt an RSA-OAEP ciphertext if he is able to force the server to process the ciphertext with RSA-PKCS#1 v1.5 and the same asymmetric key. (追記ここまで)
  3. (追記) The attacker may be able to forge valid server signatures if the server decrypts RSA-PKCS#1 v1.5 ciphertexts and the signatures are computed with the same asymmetric key pair. (追記ここまで)

(追記) Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend the following to implementers: (追記ここまで)

  1. (追記) Implementations (追記ここまで)(追記) should (追記ここまで)(追記) always use a different public key pair for data confidentiality and for data integrity functionality. (追記ここまで)
  2. (追記) Implementations using symmetric keys (追記ここまで)(追記) should not (追記ここまで)(追記) use the same key material for different algorithms, even if serving the same purpose. Key derivation based on a single key and the algorithm identifier can be used to accomplish this, for example. (追記ここまで)
  3. (追記) Implementations that plan to use the same symmetric key for both confidentiality and integrity functions (追記ここまで)(追記) should (追記ここまで)(追記) use it as the basis for a key derivation producing different keys for those functions. (追記ここまで)
  4. (追記) Implementations (追記ここまで)(追記) should (追記ここまで)(追記) restrict algorithm usage to algorithms known to be secure in the face of chosen-ciphertext attacks (RSA-OAEP, AES-GCM). In that case, documents containing RSA-PKCS#1 v1.5 [ (追記ここまで)(追記) XMLENC-PKCS15-ATTACK (追記ここまで) (追記) ] and AES-CBC [ (追記ここまで)(追記) XMLENC-CBC-ATTACK (追記ここまで) (追記) ] ciphertexts (追記ここまで)(追記) should (追記ここまで)(追記) be rejected without decryption. (追記ここまで)

(追記) 6.2 (追記ここまで) Relationship to XML Digital Signatures

The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult. In particular, when verifying a signature one must know whether the signature was computed over the encrypted or unencrypted form of elements.

A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks. This vulnerability can be mitigated by using secure hashes and the nonces in the text being processed.

In accordance with the requirements document [ (削除) EncReq (削除ここまで) (追記) XML-ENCRYPTION-REQ (追記ここまで) ] the interaction of encryption and signing is an application issue and out of scope of the specification. However, we make the following recommendations:

  1. When data is encrypted, any digest or signature over that data should be encrypted. This satisfies the first issue in that only those signatures that can be seen can be validated. It also addresses the possibility of a plaintext guessing vulnerability, though it may not be possible to identify (or even know of) all the signatures over a given piece of data.

  2. Employ the "decrypt-except" signature transform [ (削除) XML-DSIG-Decrypt] . (削除ここまで) (追記) XMLENC-DECRYPT (追記ここまで) (追記) ]. (追記ここまで) It works as follows: during signature transform processing, if you encounter a decrypt transform, decrypt all encrypted content in the document except for those excepted by an enumerated set of references.

Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, applications should discourage user misapprehension by communicating clearly which information has integrity, or is authenticated, confidential, or non-repudiable when multiple processes (e.g., signature and encryption) and algorithms (e.g., symmetric and asymmetric) are used:

  1. When an encrypted envelope contains a signature, the signature does not necessarily protect the authenticity or integrity of the ciphertext [ Davis (削除) ] . (削除ここまで) (追記) ]. (追記ここまで)

  2. While the signature secures plaintext it only covers that which is signed, recipients of encrypted messages must not infer integrity or authenticity of other unsigned information (e.g., headers) within the encrypted envelope, see [ (削除) XML-DSIG , (削除ここまで) (追記) XMLDSIG-CORE1 (追記ここまで) (追記) ], (追記ここまで) (追記) section (追記ここまで) 8.1.1 Only What is Signed is Secure ].

(削除) 6.2 (削除ここまで) (追記) 6.3 (追記ここまで) Information Revealed

Where a symmetric key is shared amongst multiple recipients, that symmetric key should only be used for the data intended for all recipients; even if one recipient is not directed to information intended (exclusively) for another in the same symmetric key, the information might be discovered and decrypted.

Additionally, application designers should be careful not to reveal any information in parameters or algorithm identifiers (e.g., information in a URI) that weakens the encryption.

(削除) 6.3 (削除ここまで) (追記) 6.4 (追記ここまで) Nonce and IV (Initialization Value or Vector)

An undesirable characteristic of many encryption algorithms and/or their modes is that the same plaintext when encrypted with the same key has the same resulting ciphertext. While this is unsurprising, it invites various attacks which are mitigated by including an arbitrary and non-repeating (under a given key) data with the plaintext prior to encryption. In encryption chaining modes this data is the first to be encrypted and is consequently called the IV (削除) (initalization (削除ここまで) (追記) (initialization (追記ここまで) value or vector).

Different algorithms and modes have further requirements on the characteristic of this information (e.g., randomness and secrecy) that affect the features (e.g., confidentiality and integrity) and their (削除) resistence (削除ここまで) (追記) resistance (追記ここまで) to attack.

Given that XML data is redundant (e.g., Unicode encodings and repeated tags ) and that attackers may know the data's structure (e.g., DTDs and schemas) encryption algorithms must be carefully implemented and used in this regard.

For the Cipher Block Chaining (CBC) mode used by this specification, the IV must not be reused for any key and should be random, but it need not be secret. Additionally, under this mode an adversary modifying the IV can make a known change in the plain text after decryption. This attack can be avoided by securing the integrity of the plain text data, for example by signing it.

(追記) Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks. (追記ここまで)

(追記) For the Galois/Counter Mode (GCM) used by this specification, the IV must not be reused for any key and should be random, but it need not be secret. (追記ここまで)

(削除) 6.4 (削除ここまで) (追記) 6.5 (追記ここまで) Denial of Service

This specification permits recursive processing. For example, the following scenario is possible: EncryptedKey A requires EncryptedKey B to be decrypted, which itself requires EncryptedKey A ! Or, an attacker might submit an EncryptedData for decryption that references network resources that are very large or continually redirected. Consequently, implementations should be able to restrict arbitrary recursion and the total amount of processing and networking resources a request can consume.

(削除) 6.5 (削除ここまで)

(追記) 6.6 (追記ここまで) Unsafe Content

XML Encryption can be used to obscure, via encryption, content that applications (e.g., firewalls, virus detectors, etc.) consider unsafe (e.g., executable code, viruses, etc.). Consequently, such applications must consider encrypted content to be as unsafe as the unsafest content transported in its application context. Consequently, such applications may choose to (1) disallow such content, (2) require access to the decrypted form for inspection, or (3) ensure that arbitrary content can be safely processed by receiving applications.

(追記) 6.7 (追記ここまで)(追記) Error Messages (追記ここまで)

(追記) Implementations (追記ここまで)(追記) should not (追記ここまで)(追記) provide detailed error responses related to security algorithm processing. Error messages should be limited to a generic error message to avoid providing information to a potential attacker related to the specifics of the algorithm implementation. For example, if an error occurs in decryption processing the error response should be a generic message providing no specifics on the details of the processing error. (追記ここまで)

(追記) 6.8 (追記ここまで)(追記) Timing Attacks (追記ここまで)

(追記) It has been known for some time that it is feasible for an attacker to recover keys or cleartext by repeatedly sending chosen ciphertext and measuring the time required to process different requests with different types of errors. It has been demonstrated that attacks of this type are practical even when communicating over large and busy networks, especially if the receiver is willing to process large numbers of ciphertext blocks. (追記ここまで)

(追記) Implementers (追記ここまで)(追記) should (追記ここまで)(追記) ensure that distinct errors detected during security algorithm processing do not consume systematically different amounts of processing time from each other. Implementers (追記ここまで)(追記) should (追記ここまで)(追記) consult the technical literature for more details on specific attacks and recommended countermeasures. (追記ここまで)

(追記) Deployments (追記ここまで)(追記) should (追記ここまで)(追記) treat as suspect inputs when a large number of security algorithm processing errors are detected within a short period of time, especially in messages from the same origin. (追記ここまで)

(追記) 6.9 (追記ここまで)(追記) CBC Block Encryption Vulnerability (追記ここまで)

(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).

(削除) 7 Conformance (削除ここまで) (追記) 7. (追記ここまで)(追記) Conformance (追記ここまで)

An implementation is conformant to this specification if it successfully generates syntax according to the schema definitions and satisfies all (削除) MUST/REQUIRED/SHALL (削除ここまで) (追記) must (追記ここまで)(追記) / (追記ここまで)(追記) required (追記ここまで)(追記) / (追記ここまで)(追記) shall (追記ここまで) requirements, including algorithm support and processing . Processing requirements are specified over the roles of decryptor , encryptor , and their calling application .

(削除) 8 (削除ここまで) (追記) 8. (追記ここまで) XML Encryption Media Type

8.1 Introduction

XML Encryption Syntax and Processing (削除) [ XML-Encryption ] (削除ここまで) (追記) (XMLENC-CORE1, this document) (追記ここまで) specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications to identify encrypted documents. Additionally it allows applications cognizant of this media-type (even if they are not XML Encryption implementations) to note that the media type of the decrypted (original) object might be a type other than XML.

8.2 application/xenc+xml Registration

This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [ MIME-REG ]

(削除) MIME media type (削除ここまで) (追記) Type (追記ここまで) name: application

(削除) MIME subtype (削除ここまで) (追記) Subtype (追記ここまで) name: xenc+xml

Required parameters: none

Optional parameters: charset

The allowable and recommended values for, and interpretation of the charset parameter are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [ XML-MT ].

Encoding considerations:

The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [ XML-MT ].

Security considerations:

See the (削除) [ XML-Encryption ] (削除ここまで) (追記) (XMLENC-CORE1, this document) (追記ここまで) Security Considerations section.

Interoperability considerations: none

Published specification: (削除) [ XML-Encryption ] (削除ここまで) (追記) (XMLENC-CORE1, this document) (追記ここまで)

Applications which use this media type:

XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications.

Additional Information:

Magic number(s): none

Although no byte sequences can be counted on to consistently identify XML Encryption documents, (削除) they (削除ここまで) (追記) there (追記ここまで) will be XML documents in which the root element's QName 's LocalPart is 'EncryptedData' or ' EncryptedKey ' with an associated namespace name of ' http://www.w3.org/2001/04/xmlenc# '. The application/xenc+xml type name (削除) MUST (削除ここまで) (追記) must (追記ここまで) only be used for data objects in which the root element is from the XML Encryption namespace. XML documents which contain these element types in places other than the root element can be described using facilities such as [ (削除) XML-schema (削除ここまで) (追記) XMLSCHEMA-1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) XMLSCHEMA-2 (追記ここまで) ].

File extension(s): .xml

Macintosh File Type Code(s): "TEXT"

Person & email address to contact for further information:

(削除) Joseph Reagle <reagle@w3.org> XENC Working Group <xml-encryption@w3.org> (削除ここまで) (追記) World Wide Web Consortium <web-human at w3.org> (追記ここまで)

Intended usage: COMMON

Author/Change controller:

The XML Encryption specification is a work product of the World Wide Web Consortium (削除) (W3C) (削除ここまで) (追記) ( (追記ここまで)(追記) W3C (追記ここまで)(追記) ) (追記ここまで) which has change control over the specification.

(削除) 9 (削除ここまで) (追記) 9. (追記ここまで) Schema (削除) and Valid Examples (削除ここまで)

(追記) 9.1 (追記ここまで)(追記) XSD Schema (追記ここまで)

(追記) XML Encryption Core (追記ここまで) Schema (追記) Instance (追記ここまで)
xenc-schema.xsd
(追記) XML Encryption 1.1 Schema Instance (追記ここまで)
(追記) xenc-schema11.xsd (追記ここまで)
(追記) This schema document defines the additional material defined in XML Encryption 1.1. (追記ここまで)
Example (追記) (non-normative) (追記ここまで)
enc-example.xml (not cryptographically valid but (削除) excercises (削除ここまで) (追記) exercises (追記ここまで) much of the schema)
(削除) 10 References (削除ここまで)

(追記) 9.2 (追記ここまで)(追記) RNG Schema (追記ここまで)

(追記) This section is non-normative. (追記ここまで)

(追記) Non-normative RELAX NG schema [ (追記ここまで)(追記) RELAXNG-SCHEMA (追記ここまで) (追記) ] information is available in a separate document [ (追記ここまで)(追記) XMLSEC-RELAXNG (追記ここまで) (追記) ]. (追記ここまで)

(追記) A. (追記ここまで)(追記) Reserved Algorithm Identifiers (追記ここまで)

(追記) This informative section outlines the definition and reserves identifiers for algorithms that have no requirements for implementation and have not been tested for interoperability. (追記ここまで)

(追記) A.1 (追記ここまで)(追記) AES KeyWrap with Padding (追記ここまで)

(追記) This section is non-normative. (追記ここまで)

(追記) Identifiers: (追記ここまで)
(削除) TRIPLEDES (削除ここまで) (追記) http://www.w3.org/2009/xmlenc11#kw-aes-128-pad (追記ここまで)
(削除) ANSI X9.52: Triple Data Encryption Algorithm Modes of Operation. 1998. (削除ここまで) (追記) http://www.w3.org/2009/xmlenc11#kw-aes-192-pad (追記ここまで)
(追記) http://www.w3.org/2009/xmlenc11#kw-aes-256-pad (追記ここまで)

(追記) These identifiers are reserved for symmetric key wrapping using the (追記ここまで) AES (追記) key wrap with padding algorithm with a 128, 192, and 256 bit AES key encrypting key, respectively. Implementation of AES key wrap with padding is defined in [ (追記ここまで)(追記) AES-WRAP-PAD (追記ここまで) (追記) ]. The algorithm is defined for inputs between 9 and 2^32 octets. Unlike the unpadded AES Key Wrap algorithm, the input length is not constrained to multiples of 64 bits (8 octets). (追記ここまで)

(追記) Note that the wrapped key will be distinct from the one generated by the unpadded AES Key Wrap algorithm, even if the input length is a multiple of 64 bits. (追記ここまで)

(追記) B. (追記ここまで)(追記) References (追記ここまで)

(追記) Dated references below are to the latest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported. (追記ここまで)

(追記) B.1 (追記ここまで)(追記) Normative references (追記ここまで)

(追記) [AES] (追記ここまで)
NIST FIPS 197: Advanced Encryption Standard (AES) . November 2001. (追記) URL: (追記ここまで) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
(削除) AES-WRAP (削除ここまで)
(追記) [AES-WRAP] (追記ここまで)
(追記) J. Schaad and R. Housley. (追記ここまで) RFC3394: Advanced Encryption Standard (AES) Key Wrap Algorithm . (削除) J. Schaad and R. Housley. Informational, (削除ここまで) (追記) IETF Informational RFC, (追記ここまで) September 2002. (削除) CMS-Algorithms (削除ここまで) (追記) URL: (追記ここまで)(追記) http://www.rfc-editor.org/rfc/rfc3394.txt (追記ここまで)
(追記) [AES-WRAP-PAD] (追記ここまで)
(追記) R. Housley, M. Dworkin. (追記ここまで)(追記) RFC 5649: Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm (追記ここまで) (削除) RFC3370: Cryptographic Message Syntax (CMS) Algorithms (削除ここまで) . (削除) R. Housley. Informational, February 2002. (削除ここまで) (追記) IETF Informational RFC, August 2009. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc5649.txt (追記ここまで).
(追記) [ANSI-X9-44-2007] (追記ここまで)
(削除) http://www.ietf.org/rfc/rfc3370.txt (削除ここまで) (追記) ANSI X9.44-2007: Key Establishment Using Integer Factorization Cryptography. (追記ここまで) (削除) CMS-Wrap (削除ここまで) (追記) URL: (追記ここまで)(追記) http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.44-2007 (追記ここまで)
(追記) [CMS-WRAP] (追記ここまで)
(追記) R. Housley. (追記ここまで) RFC3217: Triple-DES and (削除) RC2 (削除ここまで) (追記) R2 (追記ここまで) Key Wrapping . (削除) R. Housley. Informational, (削除ここまで) (追記) IETF Informational RFC, (追記ここまで) December 2001. (追記) URL: (追記ここまで) http://www.ietf.org/rfc/rfc3217.txt
(削除) Davis (削除ここまで)
(追記) [DES] (追記ここまで)
(削除) Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. D. Davis. USENIX Annual Technical Conference. 2001. http://www.usenix.org/publications/library/proceedings/usenix01/davis.html DES (削除ここまで)
NIST FIPS 46-3: Data Encryption Standard (追記) (DES) (追記ここまで) (削除) (DES). (削除ここまで) (追記) . (追記ここまで) October 1999. (追記) URL: (追記ここまで) http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
(削除) EncReq (削除ここまで)
(追記) [ESDH] (追記ここまで)
(削除) XML Encryption Requirements . J. Reagle. W3C Note, March 2002. http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304 ESDH (削除ここまで)
(追記) E. Rescorla. (追記ここまで) (削除) RFC 2631: (削除ここまで) Diffie-Hellman Key Agreement Method. (削除) E. Rescorla. (削除ここまで) . (追記) IETF RFC 2631 (追記ここまで) Standards Track, 1999. (追記) URL: (追記ここまで) http://www.ietf.org/rfc/rfc2631.txt
(削除) http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212 (削除ここまで)
(追記) [EXI] (追記ここまで)
(追記) Takuki Kamiya; John Schneider. (追記ここまで)(追記) Efficient XML Interchange (EXI) Format 1.0. (追記ここまで) (削除) Glossary (削除ここまで) (追記) 8 December 2009. W3C Candidate Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2009/CR-exi-20091208/ (追記ここまで)
(追記) [FIPS-180-3] (追記ここまで)
(削除) RFC 2828: Internet Security Glossary (削除ここまで) (追記) FIPS PUB 180-3 Secure Hash Standard (追記ここまで) . (削除) R Shirey. Informational, May 2000. (削除ここまで) (追記) U.S. Department of Commerce/National Institute of Standards and Technology. URL: (追記ここまで)(追記) http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf (追記ここまで)
(追記) [FIPS-186-3] (追記ここまで)
(削除) http://www.ietf.org/rfc/rfc2828.txt (削除ここまで) (追記) FIPS PUB 186-3: Digital Signature Standard (DSS) (追記ここまで) (削除) HMAC (削除ここまで) . (追記) June 2009. U.S. Department of Commerce/National Institute of Standards and Technology. URL: (追記ここまで)(追記) http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf (追記ここまで)
(追記) [HMAC] (追記ここまで)
(追記) H. Krawczyk, M. Bellare, R. Canetti. (追記ここまで) (削除) RFC 2104: (削除ここまで) HMAC: Keyed-Hashing for Message Authentication . (削除) H. Krawczyk, M. Bellare, and R. Canetti. Informational, (削除ここまで) February 1997. (追記) IETF RFC 2104. URL: (追記ここまで) http://www.ietf.org/rfc/rfc2104.txt
(削除) HTTP (削除ここまで)
(追記) [NFC] (追記ここまで)
(追記) M. Davis, Ken Whistler. (追記ここまで) (削除) RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. (削除ここまで) (追記) TR15, Unicode Normalization Forms. (追記ここまで).(追記) 17 September 2010, URL: (追記ここまで)(追記) http://www.unicode.org/reports/tr15/ (追記ここまで)
(追記) [PKCS1] (追記ここまで)
J. (削除) Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, (削除ここまで) (追記) Jonsson (追記ここまで) and (削除) T. Berners-Lee. (削除ここまで) (追記) B. Kaliski. (追記ここまで)(追記) Public-Key Cryptography (追記ここまで) Standards (削除) Track, June 1999. (削除ここまで) (追記) (PKCS) #1: RSA Cryptography Specifications Version 2.1. (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2616.txt (削除ここまで) (削除) KEYWORDS (削除ここまで) (追記) RFC 3447 (Informational), February 2003. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc3447.txt (追記ここまで)
(追記) [PKCS5] (追記ここまで)
(追記) B. Kaliski. (追記ここまで) (追記) PKCS #5 v2.0: Password-Based Cryptography Standard (追記ここまで) (追記) IETF (追記ここまで) RFC (削除) 2119: Key words for use in RFCs to Indicate Requirement Levels. (削除ここまで) (追記) 2898. September 2000. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc2898.txt (追記ここまで) (削除) S. Bradner. Best Current Practice, March 1997. (削除ここまで)
(追記) [PKCS5Amd1] (追記ここまで)
(削除) http://www.ietf.org/rfc/rfc2119.txt (削除ここまで) (追記) PKCS #5 v2.0 Amendment 1: XML Schema for Password-Based Cryptography (追記ここまで) (削除) MD5 (削除ここまで) (追記) RSA Laboratories, March 2007. URL: (追記ここまで)(追記) ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf (追記ここまで)
(追記) [RANDOM] (追記ここまで)
(削除) RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Informational, April 1992. (削除ここまで)
(追記) D. Eastlake, S. Crocker, J. Schiller. (追記ここまで) (削除) http://www.ietf.org/rfc/rfc1321.txt (削除ここまで) (追記) Randomness Recommendations for Security. (追記ここまで) (削除) MIME (削除ここまで) . (追記) IETF RFC 4086. June 2005. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc4086.txt (追記ここまで)
(追記) [RFC2045] (追記ここまで)
(追記) N. Freed and N. Borenstein. (追記ここまで) (削除) RFC 2045: (削除ここまで) Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message (削除) Bodies . N. Freed and N. Borenstein. Standards Track, (削除ここまで) (追記) Bodies. (追記ここまで) November 1996. (追記) URL: (追記ここまで) http://www.ietf.org/rfc/rfc2045.txt
(削除) MIME-REG (削除ここまで)
(追記) [RFC2119] (追記ここまで)
(追記) S. Bradner. (追記ここまで)(追記) Key words for use in RFCs to Indicate Requirement Levels. (追記ここまで) (追記) March 1997. Internet RFC 2119. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc2119.txt (追記ここまで)
(追記) [RFC4055] (追記ここまで)
(追記) J. Schaad, B. Kaliski, R. Housley. (追記ここまで) (削除) RFC 2048: Multipurpose (削除ここまで) (追記) Additional Algorithms and Identifiers for RSA Cryptography for use in the (追記ここまで) Internet (削除) Mail Extensions (MIME) Part Four: Registration Procedures . N. Freed, J. Klensin, (削除ここまで) (追記) X.509 Public Key Infrastructure Certificate (追記ここまで) and (削除) J. Postel. Best Current Practice, November 1996. (削除ここまで) (追記) Certificate Revocation List (CRL) Profile (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2048.txt (削除ここまで) . (追記) June 2005. IETF RFC 4055. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc4055.txt (追記ここまで)
(削除) NFC (削除ここまで)
(追記) [RIPEMD-160] (追記ここまで)
(削除) TR15, Unicode Normalization Forms . M. Davis (削除ここまで) (追記) B. Preneel, A. Bosselaers, (追記ここまで) and (削除) M. D?rst. Revision 18: November 1999. (削除ここまで) (追記) H. Dobbertin. (追記ここまで) (削除) http://www.unicode.org/unicode/reports/tr15/tr15-18.html . (削除ここまで) (追記) The Cryptographic Hash Function RIPEMD-160 (追記ここまで) (削除) NFC-Corrigendum (削除ここまで) . (追記) CryptoBytes, Volume 3, Number 2. pp. 9-14, RSA Laboratories 1997. URL: (追記ここまで)(追記) http://www.cosic.esat.kuleuven.be/publications/article-317.pdf (追記ここまで)
(追記) [SP800-38D] (追記ここまで)
(追記) M. Dworkin. (追記ここまで)(追記) NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (追記ここまで) (削除) Corrigendum #2: Yod with Hiriq Normalization (削除ここまで) . (追記) November 2007 URL: (追記ここまで)(追記) http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf (追記ここまで)
(追記) [SP800-56A] (追記ここまで)
(削除) http://www.unicode.org/versions/corrigendum2.html . (削除ここまで) (削除) prop1 (削除ここまで) (追記) NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) (追記ここまで).(追記) March 2007 URL: (追記ここまで)(追記) http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf (追記ここまで)
(追記) [SP800-67] (追記ここまで)
(削除) XML (削除ここまで) (追記) Recommendation for the Triple Data (追記ここまで) Encryption (削除) strawman proposal . E. Simon (削除ここまで) (追記) Algorithm (TDEA) Block Cipher, Revised January 2012. (追記ここまで) (追記) SP-800-67 Revision 1. U.S. Department of Commerce/National Institute of Standards (追記ここまで) and (削除) B. LaMacchia. Aug 2000. (削除ここまで) (追記) Technology. URL: (追記ここまで)(追記) http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf (追記ここまで)
(削除) http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0001.html (削除ここまで)
(追記) [URI] (追記ここまで)
(追記) T. Berners-Lee; R. Fielding; L. Masinter. (追記ここまで) (削除) prop2 (削除ここまで) (追記) Uniform Resource Identifiers (URI): generic syntax. (追記ここまで) (追記) January 2005. Internet RFC 3986. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc3986.txt (追記ここまで)
(追記) [XML-ENCRYPTION-REQ] (追記ここまで)
(追記) Joseph Reagle. (追記ここまで) (削除) Another proposal of (削除ここまで) XML Encryption (削除) . T. Imamura. Aug 2000. (削除ここまで) (追記) Requirements. (追記ここまで) (削除) http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0005.html (削除ここまで) (削除) prop3 (削除ここまで) (追記) 4 March 2002. W3C Note. URL: (追記ここまで)(追記) http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304 (追記ここまで)
(追記) [XML-NAMES] (追記ここまで)
(追記) Richard Tobin et al. (追記ここまで) (追記) Namespaces in (追記ここまで) XML (削除) Encryption Syntax and Processing . B. Dillaway, B. Fox, T. Imamura, B. LaMacchia, H. Maruyama, J. Schaad, and E. Simon. December 2000. (削除ここまで) (追記) 1.0 (Third Edition). (追記ここまで) (削除) http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html (削除ここまで) (削除) PKCS1 (削除ここまで) (追記) 8 December 2009. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2009/REC-xml-names-20091208/ (追記ここまで)
(追記) [XML10] (追記ここまで)
(削除) RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski and J. Staddon. Informational, October 1998. (削除ここまで)
(追記) C. M. Sperberg-McQueen et al. (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2437.txt (削除ここまで) (追記) Extensible Markup Language (XML) 1.0 (Fifth Edition). (追記ここまで) (削除) RANDOM (削除ここまで) (追記) 26 November 2008. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2008/REC-xml-20081126/ (追記ここまで)
(追記) [XMLDSIG-CORE1] (追記ここまで)
(削除) RFC 1750: Randomness Recommendations for Security . (削除ここまで)
D. Eastlake, (削除) S. Crocker, and (削除ここまで) J. (削除) Schiller. Informational, December 1994. http://www.ietf.org/rfc/rfc1750.txt (削除ここまで) (追記) Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. (追記ここまで) (追記) XML Signature Syntax and Processing Version 1.1. (追記ここまで) (削除) RIPEMD-160 (削除ここまで) (削除) CryptoBytes, Volume 3, Number 2. The Cryptographic Hash Function RIPEMD-160 . RSA Laboratories. Autumn 1997. ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto3n2.pdf (削除ここまで) (追記) 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL: (追記ここまで)(追記) http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/ (追記ここまで)
(削除) http://www.esat.kuleuven.ac.be/~cosicart/pdf/AB-9601/AB-9601.pdf (削除ここまで)
(追記) [XMLSCHEMA-1] (追記ここまで)
(追記) Henry S. Thompson et al. (追記ここまで) (削除) SHA (削除ここまで) (追記) XML Schema Part 1: Structures Second Edition. (追記ここまで) (削除) Secure Hash Standard . (削除ここまで) (削除) NIST FIPS 180-1. ( RFC 3174 (削除ここまで) (追記) 28 October 2004. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ (追記ここまで) (削除) ). April 1995. (削除ここまで)
(削除) http://www.itl.nist.gov/fipspubs/fip180-1.htm (削除ここまで)
(追記) [XMLSCHEMA-2] (追記ここまで)
(削除) Secure Hash Standard. NIST Draft FIPS 180-2 . 2001. (Extended to include SHA-384, SHA-256, and SHA-512) (削除ここまで)
(追記) Paul V. Biron; Ashok Malhotra. (追記ここまで) (削除) http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf (削除ここまで) (追記) XML Schema Part 2: Datatypes Second Edition. (追記ここまで) (削除) Tobin (削除ここまで) (追記) 28 October 2004. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ (追記ここまで)
(追記) [XPATH] (追記ここまで)
(削除) R. Tobin. Infoset for external entities , (削除ここまで) (追記) James Clark; Steven DeRose. (追記ここまで) XML (削除) Core mailing list, 2000 [ (削除ここまで) (追記) Path Language (XPath) Version 1.0. (追記ここまで) (追記) 16 November 1999. (追記ここまで) W3C (削除) Member Only (削除ここまで) (追記) Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/1999/REC-xpath-19991116/ (追記ここまで) (削除) ]. (削除ここまで)
(削除) http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054 (削除ここまで)
(削除) UTF-16 (削除ここまで)

(追記) B.2 (追記ここまで)(追記) Informative references (追記ここまで)

(追記) [Davis] (追記ここまで)
(削除) RFC 2781: UTF-16, an encoding of ISO 10646. P. Hoffman and F. Yergeau. Informational, February 2000. (削除ここまで)
(削除) http://www.ietf.org/rfc/rfc2781.txt (削除ここまで) (追記) Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. (追記ここまで) (削除) UTF-8 (削除ここまで) (追記) D. Davis. USENIX Annual Technical Conference. 2001. URL: (追記ここまで)(追記) http://www.usenix.org/publications/library/proceedings/usenix01/davis.html (追記ここまで)
(追記) [ECC-ALGS] (追記ここまで)
(追記) D. McGrew; K. Igoe; M. Salter. (追記ここまで) RFC (削除) 2279: UTF-8, a transformation format of ISO 10646F. F. Yergeau. Standards Track, January 1998. (削除ここまで) (追記) 6090: Fundamental Elliptic Curve Cryptography Algorithms. (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2279.txt (削除ここまで) (削除) URI (削除ここまで) (追記) February 2011. IETF Informational RFC. URL: (追記ここまで)(追記) http://www.rfc-editor.org/rfc/rfc6090.txt (追記ここまで)
(追記) [MIME-REG] (追記ここまで)
(追記) N. Freed, J. Klensin. (追記ここまで) RFC (削除) 2396: Uniform Resource Identifiers (URI): Generic Syntax (削除ここまで) (追記) 4289: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures (追記ここまで) . (削除) T. Berners-Lee, R. Fielding, and L. Masinter. Standards Track, August 1998. (削除ここまで) (追記) December 2005. Best Current Practice. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc4289.txt (追記ここまで)
(削除) http://www.ietf.org/rfc/rfc2396.txt (削除ここまで)
(追記) [OAEP-ATTACK] (追記ここまで)
(追記) Manger, James. (追記ここまで) (削除) http://www.ietf.org/rfc/rfc1738.txt (削除ここまで) (追記) A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0 (追記ここまで) . (追記) URL: (追記ここまで)(追記) http://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf (追記ここまで)
(削除) http://www.ietf.org/rfc/rfc2141.txt (削除ここまで)
(追記) [RELAXNG-SCHEMA] (追記ここまで)
(削除) RFC 2611: URN Namespace (削除ここまで) (追記) Information technology -- Document Schema (追記ここまで) Definition (削除) Mechanisms. Best Current Practices. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999. (削除ここまで) (追記) Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2611.txt (削除ここまで) . (追記) ISO/IEC 19757-2:2008. URL: (追記ここまで)(追記) http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip (追記ここまで)
(削除) X509v3 (削除ここまで)
(追記) [RFC3218] (追記ここまで)
(削除) ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997. (削除ここまで) (追記) Rescorla; E. (追記ここまで) (削除) XML (削除ここまで) (追記) Preventing the Million Message Attack on Cryptographic Message Syntax. (追記ここまで) (追記) January 2002. Informational RFC 3218. URL: (追記ここまで)(追記) http://tools.ietf.org/html/rfc3218 (追記ここまで)
(追記) [SHA-1-Analysis] (追記ここまで)
(削除) Extensible Markup Language (XML) 1.0 (Second Edition) . T. Bray, J. Paoli, C. M. Sperberg-McQueen, (削除ここまで)
(追記) McDonald, C., Hawkes, P., (追記ここまで) and (削除) E. Maler. W3C Recommendation, October 2000. (削除ここまで) (追記) J. Pieprzyk. (追記ここまで) (削除) XML-Base (削除ここまで) (追記) SHA-1 collisions now 2 (追記ここまで)(追記) 52 (追記ここまで).(追記) EuroCrypt 2009 Rump session. URL: (追記ここまで)(追記) http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf (追記ここまで)
(追記) [SHA-1-Collisions] (追記ここまで)
(追記) X. Wang, Y.L. Yin, H. Yu. (追記ここまで)(追記) Finding Collisions in the Full SHA-1 (追記ここまで) (削除) XML Base (削除ここまで) . (削除) J. Marsh. W3C Recommendation, June 2001. (削除ここまで) (追記) In Shoup, V., editor, Advances in Cryptology - CRYPTO 2005, 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14-18, 2005, Proceedings, volume 3621 of LNCS, pages 17窶?36. Springer, 2005. URL: (追記ここまで)(追記) http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf (追記ここまで) (追記) (also published in (追記ここまで)(追記) http://www.springerlink.com/content/26vljj3xhc28ux5m/ (追記ここまで) (追記) ) (追記ここまで)
(削除) http://www.w3.org/TR/2001/REC-xmlbase-20010627/ (削除ここまで)
(追記) [Tobin] (追記ここまで)
(追記) R. Tobin. (追記ここまで) (削除) XML-C14N (削除ここまで) (追記) Infoset for external entities. (追記ここまで) (追記) 2000. URL: (追記ここまで)(追記) http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054 (追記ここまで) (追記) [XML Core mailing list, (追記ここまで)(追記) W3C Member Only (追記ここまで) (追記) ]. (追記ここまで)
(追記) [XML-C14N] (追記ここまで)
(追記) John Boyer. (追記ここまで) Canonical (削除) XML. (削除ここまで) (追記) XML Version 1.0. (追記ここまで) (削除) J. Boyer. W3C Recommendation, (削除ここまで) (追記) 15 (追記ここまで) March 2001. (追記) W3C Recommendation. URL: (追記ここまで) http://www.w3.org/TR/2001/REC-xml-c14n-20010315
(削除) http://www.ietf.org/rfc/rfc3076.txt (削除ここまで)
(追記) [XML-C14N11] (追記ここまで)
(追記) John Boyer; Glenn Marcy. (追記ここまで) (削除) XML-exc-C14N (削除ここまで) (追記) Canonical XML Version 1.1. (追記ここまで) (追記) 2 May 2008. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ (追記ここまで)
(追記) [XML-EXC-C14N] (追記ここまで)
(追記) Donald E. Eastlake 3rd; Joseph Reagle; John Boyer. (追記ここまで) Exclusive XML Canonicalization (削除) . J. Boyer, D. Eastlake, and J. Reagle. W3C Recommendation, (削除ここまで) (追記) Version 1.0. (追記ここまで) (追記) 18 (追記ここまで) July 2002. (追記) W3C Recommendation. URL: (追記ここまで) http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
(削除) XML-DSIG (削除ここまで)
(追記) [XML-INFOSET] (追記ここまで)
(削除) XML-Signature Syntax and Processing . D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation, February 2002. (削除ここまで)
(追記) John Cowan; Richard Tobin. (追記ここまで) (削除) http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ (削除ここまで) (追記) XML Information Set (Second Edition). (追記ここまで) (削除) XML-DSIG-Decrypt (削除ここまで) (追記) 4 February 2004. W3C Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2004/REC-xml-infoset-20040204/ (追記ここまで)
(追記) [XML-MT] (追記ここまで)
(削除) Decryption Transform for XML Signature . M. Hughes, T. Imamura and H. Maruyama. W3C Recommendation, December 2002. (削除ここまで)
(追記) M. Murata, S. St.Laurent, D. Kohn. (追記ここまで) (削除) http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210 (削除ここまで) (追記) XML Media Types (追記ここまで) . (追記) IETF RFC 3023. URL: (追記ここまで)(追記) http://www.ietf.org/rfc/rfc3023.txt (追記ここまで).
(削除) XML-Encryption (削除ここまで)
(追記) [XMLBASE] (追記ここまで)
(追記) Jonathan Marsh; Richard Tobin. (追記ここまで) XML (削除) Encryption Syntax and Processing . D. Eastlake and J. Reagle. (削除ここまで) (追記) Base (Second Edition). (追記ここまで) (追記) 28 January 2009. (追記ここまで) W3C (削除) Candidate Recommendation, December 2002. (削除ここまで) (追記) Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2009/REC-xmlbase-20090128/ (追記ここまで)
(削除) http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/ (削除ここまで)
(追記) [XMLENC-BACKWARDS-COMP] (追記ここまで)
(追記) Tibor Jager, Kenneth G. Paterson, Juraj Somorovsky. (追記ここまで)(追記) One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography. (追記ここまで) (削除) XML-Infoset (削除ここまで) (追記) In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2013. URL: (追記ここまで)(追記) http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ (追記ここまで)
(追記) [XMLENC-CBC-ATTACK] (追記ここまで)
(追記) Tibor Jager; Juraj Somorovsky. (追記ここまで) (追記) How to Break (追記ここまで) XML (削除) Information Set . J. Cowan and R. Tobin. W3C Recommendation, October 2001 (削除ここまで) (追記) Encryption (追記ここまで) (削除) http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ (削除ここまで) (削除) XML-MT (削除ここまで) (追記) 17-21 October 2011. CCS窶?11, ACM. URL: (追記ここまで)(追記) http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption/ (追記ここまで)
(追記) [XMLENC-CBC-ATTACK-COUNTERMEASURES] (追記ここまで)
(追記) Juraj Somorovsky, Jテカrg Schwenk. (追記ここまで) (削除) RFC 3023: (削除ここまで) (追記) Technical Analysis of Countermeasures against Attack on (追記ここまで) XML (削除) Media Types. M. Murata, S. St. Laurent, and D. Kohn. Informational, January 2001. (削除ここまで) (追記) Encryption - or - Just Another Motivation for Authenticated Encryption (追記ここまで) (削除) http://www.ietf.org/rfc/rfc2376.txt (削除ここまで) . (追記) 2011. URL: (追記ここまで)(追記) http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf (追記ここまで)
(削除) XML-NS (削除ここまで)
(追記) [XMLENC-CORE1-CHGS] (追記ここまで)
(追記) Frederick Hirsch. (追記ここまで) (削除) Namespaces (削除ここまで) (追記) Functional Explanation of (追記ここまで) in XML (追記) Encryption 1.1 (追記ここまで) . (削除) T. Bray, D. Hollander, and A. Layman. W3C Recommendation, (削除ここまで) (追記) 24 (追記ここまで) January (削除) 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114 (削除ここまで) (追記) 2013. W3C Working Group Note. URL: (追記ここまで)(追記) http://www.w3.org/TR/2013/NOTE-xmlenc-core1-explain-20130124/ (追記ここまで)
(削除) XML-schema (削除ここまで)
(追記) [XMLENC-DECRYPT] (追記ここまで)
(追記) Takeshi Imamura; Merlin Hughes; Hiroshi Maruyama. (追記ここまで) (追記) Decryption Transform for (追記ここまで) XML (削除) Schema Part 1: Structures (削除ここまで) (追記) Signature. (追記ここまで) (削除) D. Beech, M. Maloney, and N. Mendelsohn. (削除ここまで) (追記) 10 December 2002. (追記ここまで) W3C (削除) Recommendation, May 2001. (削除ここまで) (追記) Recommendation. URL: (追記ここまで)(追記) http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210 (追記ここまで)
(削除) http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ (削除ここまで)
(追記) [XMLENC-PKCS15-ATTACK] (追記ここまで)
(追記) Tibor Jager; Sebastian Schinzel, Juraj Somorovsky. (追記ここまで) (追記) Bleichenbacher's Attack Strikes Again: Breaking PKCS#1.5 in (追記ここまで) XML (削除) Schema Part 2: Datatypes (削除ここまで) (追記) Encryption (追記ここまで) . (削除) P. Biron and A. Malhotra. W3C Recommendation, May 2001. (削除ここまで) (追記) 2012. In Proceedings of the 17th European Symposium on Research in Computer Security (ESO RICS). URL: (追記ここまで)(追記) http://www.nds.rub.de/research/publications/breaking-xml-encryption-pkcs15.pdf (追記ここまで)
(削除) http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ (削除ここまで)
(追記) [XMLSEC-RELAXNG] (追記ここまで)
(追記) Makoto Murata; Frederick Hirsch. (追記ここまで) (削除) XPath (削除ここまで) (追記) XML Security RELAX NG Schemas. (追記ここまで) (追記) 24 January 2013. W3C Working Group Note. URL: (追記ここまで)(追記) http://www.w3.org/TR/2013/NOTE-xmlsec-rngschema-20130124/ (追記ここまで)
(追記) [XMLSEC11-REQS] (追記ここまで)
(追記) Frederick Hirsch, Thomas Roessler. (追記ここまで) XML (削除) Path Language (XPath) Version 1.0 . J. Clark (削除ここまで) (追記) Security 1.1 Requirements (追記ここまで) and (削除) S. DeRose. (削除ここまで) (追記) Design Considerations. (追記ここまで) (追記) 24 January 2013. (追記ここまで) W3C (削除) Recommendation, October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116 (削除ここまで) (追記) Working Group Note. URL: (追記ここまで)(追記) http://www.w3.org/TR/2013/NOTE-xmlsec-reqs-20130124/ (追記ここまで)

AltStyle によって変換されたページ (->オリジナル) /