11-05-2012, 04:35 PM
xml encryption
xml encryption.doc (Size: 73 KB / Downloads: 35)
Abstract
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.
Status of this document
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] to describe the content model.
"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." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."
1.2 Design Philosophy
The design philosophy and requirements of this specification (including the limitations related to instance validity) are addressed in the XML Encryption Requirements [EncReq].
1.3 Versions, Namespaces, URIs, and Identifiers
This 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 "xenc" XML 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; is defined so as to provide short-hand identifiers for URIs defined in this specification. For example "&xenc;Element" corresponds to "http://www.w32001/04/xmlenc#Element".
This specification makes use of the XML Signature [XML-DSIG] namespace and schema definitions
URIs [URI] MUST abide by the [XML-Schema] anyURI type definition and the [XML-DSIG, 4.3.3.1 The URI Attribute] specification (i.e., permitted characters, character escaping, scheme support, etc.).
This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in 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; 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. 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
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://examplepaymentv2'>
<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,000USD.
2.1.1 Encrypting an XML Element
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://examplepaymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w32001/04/xmlenc#Element'
xmlns='http://www.w32001/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 encrypted:
<?xml version='1.0'?>
<PaymentInfo xmlns='http://examplepaymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<EncryptedData xmlns='http://www.w32001/04/xmlenc#'
Type='http://www.w32001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>
2.1.3 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:
<payaymentInfo xmlns:pay='http://examplepaymentv2'>
<EncryptedData Id='ED1' xmlns='http://www.w32001/04/xmlenc#'
Type='http://www.w32001/04/xmlenc#Element'>
<CipherData>
<CipherValue>originalEncryptedData</CipherValue>
</CipherData>
</EncryptedData>
</payaymentInfo>
A valid super-encryption of "//xenc:EncryptedData[@Id='ED1']" would be:
<payaymentInfo xmlns:pay='http://examplepaymentv2'>
<EncryptedData Id='ED2' xmlns='http://www.w32001/04/xmlenc#'
Type='http://www.w32001/04/xmlenc#Element'>
<CipherData>
<CipherValue>newEncryptedData</CipherValue>
</CipherData>
</EncryptedData>
</payaymentInfo>
where the CipherValue content of 'newEncryptedData' is the base64 encoding of the encrypted octet sequence resulting from encrypting the EncryptedData element with Id='ED1'