Architecture Workgroup

MEG0028 XML Signature of a MISMO XML Document

Version: 0.02
Last Update: 12/17/2008

Purpose

1. Introduction

This MEG will provide some educational and general guidance on XML Signatures for the MISMO community. Signing is the process of transforming information (e.g., text, graphics) into something that is unreadable or unrecognized.
TBD

XML-Signature Syntax and Processing / http://www.w3.org/TR/xmldsig-core/

XML Signature in Wikipedia / http://en.wikipedia.org/wiki/XML_Signature

1.1 Audience

Analysts, Security Personnel and Developers of MISMO XML standards are concerned with the confidentiality of sensitive information. With the migration to MISMO Version 3 element centric model encryption of confidentiality information can be achieved using standard XML encryption and WS-Security SOAP Message Security mechanisms.

1.2 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. See «add reference to MISMO glossary for terminology used in this MEG».

1.3 Document Status

The information supplied in this document reflects the MISMO interoperability principles at the time of writing. It is a living document, which will be updated as required to reflect the evolving nature of XML technologies and service requirements identified by MISO constituency. Comments on this document should be sent to the MISMO designated contact identified in the document preface.

2. Rationale for this MEG

TBD

Content

1. Guidelines

Ref	Guideline
28.1	There are two basic encryption approaches: 1) XML Encryption and 2) WS-Security SOAP Message Security. Both XML Encryption and SOAP use similar structure and syntax. MISMO developers MAY encrypt native XML or wrap confidential information in a SOAP envelope depending on the use case and risk requirements.
28.2	The XML Signature MUST be used at the application layer. A benefit of application-level encryption is that it protects both data at rest and data in motion. Data that resides on any media or less-protected devices can be encrypted. The confidentiality of information packaged for transmission via either enterprise or external networks is protected. XML applications can decrypt information as required at processing time.
28.3	Encryption Examples. Consider the following fictitious borrower address and identification information: <Borrower xmlns=‘http://example.org/paymentv2’> <Name>John Smith</Name> <Address Street=‘123 Main St’ City=‘Springfield’ State=”IL”> <SSN>123 56 7890</SSN> <DOB>01/01/1970</DOB> </Address> </Borrower> Algorithm and Key information have already been negotiated.
28.3.1	The parties wish to keep Smith‘s Social Security Number (SSN) confidential, as it is sensitive information. To achieve this, the Address element is encrypted as follows: <Borrower> <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> </Borrower> By encrypting the entire Address element from its start to end tags, the sensitive information in the element itself is hidden. The CipherData element contains the encrypted serialization of the Identity element.
28.3.2	It may be useful for intermediate agents to know the borrower’s address, but not the borrower‘s SSN and DOB. In this case, the content (character data or children elements) of the Address element are encrypted: <Borrower> <Name>John Smith</Name> <Address Street=‘123 Main St’ City=‘Springfield’ State=”IL”> <EncryptedData xmlns=‘http://www.w3.org/2001/04/xmlenc#’ Type=‘http://www.w3.org/2001/04/xmlenc#Content’> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Address> </Borrower>
28.3.3	Consider the scenario in which all the information except the SSN can be in the clear, including the fact that the SSN element exists: <Borrower> <Name>John Smith</Name> <Address Street=‘123 Main St’ City=‘Springfield’ State=”IL”> <SSN> <EncryptedData xmlns=‘http://www.w3.org/2001/04/xmlenc#’ Type=‘http://www.w3.org/2001/04/xmlenc#Content’> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </SSN> <DOB>01/01/1970</DOB> </Address> </Borrower> Both Address and SSN are in the clear, but the character data content of SSN is encrypted.
28.3.4	If the use case or risk requirements dictate that all of the data be encrypted, the whole document is encrypted as an octet sequence. This applies to arbitrary data including XML documents. <EncryptedData xmlns=‘http://www.w3.org/2001/04/xmlenc#’ MimeType=‘text/xml’> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
28.4	SOAP Message Security MUST be used at the transport layer. SOAP encryption is primarily used for data in motion and can ensure confidentiality of sensitive information regardless of a transport method. SOAP Message Security CAN be used for both enterprise and external transmissions. The entire Body SHOULD be encrypted when encryption is used. Encrypting portions of the payload may be secure, but various vulnerabilities are possible. See the “Use of the MISMO Envelope (SOAP)” - MEG0030  for additional information on SOAP and security.
28.5	SOAP Full Payload Encryption <soapenv:Envelope> <soapenv:Header> <wsse:Security xmlns:wsse=“…” xmlns:ds=“…” soapenv:mustUnderstand=“1”> <xenc:EncryptedKey > <xenc:EncryptionMethod Algorithm=“…#rsa-oaep-mgf1p”> <ds:DigestMethod Algorithm=“…#sha1”/> </xenc:EncryptionMethod> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier EncodingType=“…#Base64Binary” ValueType=“…#X509SubjectKeyIdentifier”>CuJd…= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>Hyx…=</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI=“#encBody”/> </xenc:ReferenceList> </xenc:EncryptedKey> <wsu:Timestamp wsu:Id=“Timestamp” > <wsu:Created>2007-03-26T16:53:39Z</wsu:Created> </wsu:Timestamp> <wsse:BinarySecurityToken wsu:Id=“bst” ValueType=“…#X509v3” EncodingType=“…#Base64Binary”>MIID…=</wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=“…/xml-exc-c14n#”/> <ds:SignatureMethod Algorithm=“…#rsa-sha1”/> <ds:Reference URI=“#Timestamp”> <ds:Transforms>… </ds:Transforms> <ds:DigestMethod Algorithm=“…#sha1”/> <ds:DigestValue>+g0I…=</ds:DigestValue> </ds:Reference> <ds:Reference URI=“#Body”>…</ds:Reference> <ds:Reference URI=“#bst”>..</ds:Reference> </ds:SignedInfo> <ds:SignatureValue>RRT…=</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference > <wsse:KeyIdentifier EncodingType=“…#Base64Binary” ValueType=“…#X509SubjectKeyIdentifier”>Xeg5…= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soapenv:Header> <soapenv:Body wsu:Id=“Body” > <xenc:EncryptedData Id=“encBody” Type=“…#Content” MimeType=“text/xml” Encoding=“UTF-8” > <xenc:EncryptionMethod Algorithm=“…#aes256-cbc”/> <xenc:CipherData> <xenc:CipherValue>W84fn…1</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soapenv:Body> </soapenv:Envelope>

Metadata

Version: 0.02
Last Update: 12/17/2008

1. Release History