XML Encryption Syntax and Processing

WG Working Draft 22-Mar-2001

This version:
Latest version:
Previous version:
This draft is based on the 15-December-2000 Proposal [prop3] by Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, and Simon.
Reagle, Dillaway, ...


This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary binary data, an XML document, an XML element, or its content. When an element is encrypted, the element is replaced with an XML Encryption element. Otherwise, the encryption element serves as the root of the new document.

Status of this document

This is an editors' copy that has absolutely no standing.

Table of Contents


1.0 Introduction

This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary binary data, an XML document, or an XML element. When an element is encrypted, the element is replaced with an XML Encryption element. Otherwise the encryption element serves as the root of the new document.

1.1 Editorial and Conformance Conventions

This specification uses XML Schemas [XML-schema] to describe the content model.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"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 are addressed in the XML Encryption Requirements document [EncReq].

1.3 Versions, Namespaces and Identifiers

No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:


Additionally, this specification makes use of the XML Signature [XMLDSIG] namespace and schema definitions


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] or our "enc" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

1.4  Acknowledgements

The contributions of the following working group members to this specification are gratefully acknowledged:


2.0 Encryption Overview and Examples

This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Core Encryption Syntax (section 3); the specific processing is given in Processing Rules (section 4).

Data (XML documents, elements, or binary data) that is encrypted according to this specification is removed, encrypted, encoded, and replaced with an EncryptedData element. The EncryptedData element has the following structure:

   <enc:EncryptedData Id="" Type="">
     <enc:CipherData URI="">iamscrambled</enc:CipherData>

2.1 EncryptedData

This section could be interwoven in with an actual example very nicely, maybe those in the previous sectino 5. -- Reagle

EncryptedData replaces the part of an XML document that is encrypted, or serves as the root element of an XML document if a whole document (of any MIME type) is encrypted. When XML content is encrypted within an XML document,  the location of the EncryptedData element serves to clearly identify the location of the data that was encrypted within the document. In either case the EncryptedData element provides  information necessary for decryption. EncryptedData will always contain either the CipherData as a base64 encoded octet sequence or a URI reference and transformation instructions necessary to obtain the CipherData as an octet sequence. The latter mechanism is provided for flexibility and to support scenarios such as the encryption of a binary content stream where it would be inefficient to include the stream content directly in an XML document. 

The EncryptedData element may optionally contain information about how the CipherData may be decrypted. This can include the following:

To simplify encoding and processing, only a single CipherData may be included within an EncryptedData element. Also, it is implicit that all included information about the encryption key used will refer to the same key value. 

To meet the needs of key applications, this specification supports encryption of:

This "NodeList" needs to be investigated with respect to our processing model and using InformationSet terminology, maybe those in the previous section 5. -- Reagle.

The type of data encrypted may be encoded as an attribute of the EncryptedData to aid the decryptor in processing it. If the data is an XML Element, it is implicit the decrypted Element replaces the EncryptedData element in a given XML Document context. Similarly, a decrypted NodeList replaces the EncryptedData element in a given XML Document. An external octet sequence is always treated as external data relative to any XML Document, i.e., there is no implied document transform to be applied when the data is decrypted.

Each EncryptedData element is assumed to be independent and there is no requirement for indicating linkage or ordering between EncryptedData elements. We do recognize that an encryptor may choose an approach in which decryption order and/or state propagation between EncryptedData elements is important. For example, one may use an encryption algorithm which allows one to  use the output from one decryption as algorithm input to a second decryption. Or, if one has two EncryptedData elements which reference doubly encrypted external data, then the decryption order is critical. In such cases, the encryptor may specify this information as part of the encryption method information.

Data transformations, such as canonicalization or compression, are outside the scope of this specification as the requirements are application dependent.

2.2 Encryption Key Sharing

This section could be interwoven in with an actual example very nicely, maybe those in the previous sectino 5 -- Reagle

This specification's key sharing scope is limited to the (optional) conveyance of key information necessary to decrypt an EncryptedData element. Anything beyond this simple exchange, (such as establishing trust relationships or negotiating pre-arranged secrets), is out of scope.

When specified, key sharing information is a first class object and encoded in a way that makes this obvious. For flexibility, we support specifying:

Depending upon the application, one may include one or more types of key information within an EncryptedData element, but all must refer to a single encryption key value. Typically, only one type of information will be necessary unless alternative forms of key representation or keys for multiple recipients are required. We define a means of including hints as to which recipient is associated with an encrypted key value for the case of multiple recipients.

Specification of key attributes is based on the existing KeyInfo Element defined in [XMLDSIG]. If one is using an asymmetric encryption algorithm, then the Digital Signature defined KeyInfo is adequate. If using a symmetric key, then we support indirect key references based on a key name and/or key references. To facilitate use of key names, we provide a means of associating a name with an encrypted key value. For key references, we define a KeyRetrievalMethod to express a URI where the key may be located. This similar to ds:RetrievalMethod but the type is always of EncryptedKey. Direct inclusion of a clear text symmetric key value is not relevant in this context and is not supported.

2.3 EncryptedKey

This section could be interwoven in with an actual example very nicely, maybe those in the previous sectino 5. -- Reagle

When specifying an encrypted symmetric key value, an EncryptedKey element is used. This is distinct from, and uses a different encoding from EncryptedData, to avoid context dependent processing. The Encrypted Key object always includes the encrypted symmetric key CipherData as a base64 encoded octet sequence. In addition, the Encrypted Key object may include:

The latter capability is included primarily to support key update based on existing shared symmetric keys. 

2.4 EncryptedData and Key Sharing Object Composition

The preceding sections identified some of the rules for combining encrypted data and key sharing information. This section provides a fuller treatment of this issue. 

EncryptedData may include optional information about the key used to encrypt the CipherData. This is a KeyInfo element optionally referencing an EncryptedKey element,  a known key or both.

An XML document may contain any number of Encrypted Key objects, either as children of an EncryptedData element, or as independent objects. An Encrypted Key object may not be a child of another Encrypted Key object. The Encrypted Key object may include a KeyInfo Element with information to help the recipient decrypt the key CipherData. 

An Encrypted Key object may include references to EncryptedData element or other Encrypted Key objects. In both cases, the reference indicates that the referenced object CipherData is encrypted using the key value contained with the referencing Encrypted Key object. As depicted below, references in the Encrypted Key-1 object indicate that the EncryptedData-A CipherData and Encrypted Key-2 CipherData are encrypted using the symmetric key value in Encrypted Key-1.

2.4.1 Super-Encryption

An XML document may contain zero or more EncryptedData elements. However, EncryptedData can not be the parent or child of another EncryptedData element -- though the data encrypted by this element can be anything, including EncryptedData and EncryptedKey elements (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, will result in invalid XML against the schema defined in this specification.

For example, consider the following:

     <EncryptedData Id='1'>

A valid super-encryption of //EncryptedData/@Id='1' would be:

     <EncryptedData Id='2'>

where 'newencrypteddata' is the base64 encoding of the encrypted octet sequence resulting from encrypting the EncryptedData element with Id='1'.

Alternately, if one encrypted only the CipherData data  of the original EncryptedData (e.g. "encrypteddata") the result would be:

   <EncryptedData Id='1'>
     <EncryptedData Id='3'>

3. Encryption Syntax

This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is defined via [XML-Schema] with the following XML preamble, declaration, internal entity, and import:

  <?xml version='1.0'?>
  <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN" "http://www.w3.org/2000/10/XMLSchema.dtd" [
     <!ATTLIST schema
               xmlns:ds CDATA   #FIXED 'http://www.w3.org/2000/09/xmldsig#'>
     <!ATTLIST schema
               xmlns:enc   CDATA   #FIXED 'http://www.w3.org/Encryption/2001/03/xmlenc#'>

  <schema xmlns='http://www.w3.org/2000/10/XMLSchema' version='0.1'

  <import namespace='http://www.w3.org/2000/09/xmldsig#'

3.1 The EncryptedType

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.

  <complexType name='EncryptedType' abstract='true'>
      <!-- this shows an enc:element being of ds:type -->    
      <element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
      <!-- this shows a enc:type being extended from ds:type -->
      <element ref='enc:KeyInfo' minOccurs='0'/>
      <element ref='enc:CipherData'/>
    <attribute name='Id' type='ID' use='optional'/>

EncryptionMethod is an optional element that describes the encryption algorithm applied to the CipherData contained in this element. If the element is absent, the encryption algorithm assumed to be known by the recipient.

KeyInfo is an optional element, defined by [XMLDSIG], that carries information about the key used to encrypt the CipherData. The new elements defined by this specification that may appear a children of KeyInfo are described in the subsequent sections.

CipherData is a mandatory element that provides the encrypted data.

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

3.2 The CipherData Element

The CipherData is a mandatory element that provides the encrypted data. It may either contain the encrypted octet sequence as base64 encoded text or provide a reference to an external location (subject to the same processing rules as ds:TransformsType) containing the encrypted octet sequence.

   <element name='CipherData' type='ds:CryptoBinary'/>
   <element name="CipherData">
         <element ref="ds:Transforms" minOccurs="0"/>
     <attribute name="URI" type="uriReference" use="required"/>

This isn't valid schema. We need a schema construct that has the content (or a child with the content) of CryptoBinary, *or* a set of transforms. -- Reagle/Dillaway.

3.3 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 serves as the new document root.

There are different ways to define the key material to be used in decrypting the CipherData. In all cases, this information is contained within a KeyInfo element.

  1. The EncryptedData or EncryptedKey element specifies the associated key material:
    1. The key value may be explicitly included within an EncryptedKey element
    2. The key value may be referenced. This can be the KeyRetrievalMethod element used to indicate the URI of an EncryptedKey or a KeyName element used to indicate a key know by the recipient.
  2. The EncryptedKey element specifies the EncryptedData or EncryptedKey element which needs it:
    1. An EncryptedKey element can refer to the EncryptedData element via a DataReference element.
  3. The key material is managed at the application level, out of band of the XML Encryption specification:
    1. The key material is known to the recipient of the object by context.
  <element name='EncryptedData' type="enc:EncryptedDataType"/>
  <complexType name='EncryptedDataType'>
      <extension base='enc:EncryptedType'>
        <attribute name='Type' type='uriReference' use='optional'/>

Type is an optional attribute identifying type information about the decrypted content. Valid values for this attribute are:

Using Infoset

Element 'http://www.w3.org/2001/02/infoset#Element'
[Infoset] Element Information Item.
ElementChildren 'http://www.w3.org/2001/02/infoset#children'
[Infoset] Element Information Item children property:
MediaType 'http://www.isi.edu/in-notes/iana/assignments/media-types/*'
A user specified media type.


Using DOM

Element 'http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614'
A [DOM] Element Interface: "The Element interface represents an element in an HTML or XML document.... the Element interface inherits from Node, the generic Node interface..."
childNodes  'http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1451460987'
[DOM] childNodes: "A NodeList that contains all children of this node. If there are no children, this is a NodeList containing no nodes."
MediaType 'http://www.isi.edu/in-notes/iana/assignments/media-types/*'
A user specified meida type.


3.4 Extensions to ds:KeyInfo Element

This specification defines two elements that may be used as children of the ds:KeyInfo element. These are the EncryptedKey and KeyRetrievalMethod elements described in subsequent sections.

    <element name='KeyInfo' type='enc:KeyInfoType'/>
    <complexType name='KeyInfoType'>
        <extension base='ds:KeyInfoType'>
            <element name="EncryptedKey" minOccurs='0'/>
            <element ref='enc:KeyRetrievalMethod'
             minOccurs='0' maxOccurs='unbounded'/>

This is presently broken as validators will complain of ambigous content models. I'm working on understanding this, and it relates to the question of should create a derived enc:KeyInfoType element based in ds:KeyInfoType, create a enc:KeyInfo based on ds:KeyInfoType, or just use ds:KeyInfo? -- Reagle

3.4.1 The EncryptedKey Element

The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s). It may be used as a standalone XML document, be placed within an application document, or appear inside an EncryptedData element as a child of a KeyInfo element. The key value is always encrypted to the recipient(s).

  <element name='EncryptedKey' type='enc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
      <extension base='enc:EncryptedType'>
          <element ref='enc:ReferenceList' minOccurs='0'/>
        <attribute name='NameKey' type='string' use='optional'/>
        <attribute name='Recipient' type='string' use='optional'/>

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 repectively. These are defined below.

NameKey is an optional attribute for associating a user readable name with the key value. This may then be used to reference the key using the KeyName element within KeyInfo. The same NameKey label, unlike an id label, may occur multiple times within a single document. The value of the key is to be the same in all EncryptedKey elements identified with the same NameKey label within a single XML document

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.

3.4.2 The KeyRetrievalMethod Element

The KeyRetrievalMethod element provides a way to express a link from an EncryptedData element to the EncryptedKey element containing the key used needed to decrypt it. The KeyRetrievalMethod element may occur multiple times within a KeyInfo element referring to different EncryptedKey objects containing the same key value but encrypted in different ways or for different recipients.

   <element name='KeyRetrievalMethod' type="enc:KeyRetrievalMethodType"
            substitutionGroup="ds:RetrievalMethod" />
   <complexType name='KeyRetrievalMethodType'>
       <restriction base='ds:RetrievalMethodType'>
           <element name="Transforms" type="ds:TransformsType" minOccurs="0"/> 
         <attribute name="URI" type="uriReference"/>
         <attribute name="Type" type="uriReference"
          use="fixed" value="http://www.w3.org/Encryption/2001/03/xmlenc#EncryptedKey"/>

KeyRetrievalMethod uses similar syntax and dereferencing behavior to the RetrievalMethod element in [XMLDSIG], except the type attribute is always fixed to be of type EncryptedKey.

3.5 The ReferenceList Element

ReferenceList is an element that contains pointers from a key to encrypted data (ordinary data or EncryptedKeys).

  <element name='ReferenceList'>
        <element name='DataReference' type='enc:ReferenceType'
                 minOccurs='0' maxOccurs='unbounded'/>
        <element name='KeyReference' type='enc:ReferenceType'
                 minOccurs='0' maxOccurs='unbounded'/>
  <complexType name="ReferenceType">
      <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    <attribute name='URI' type='uriReference' use='optional'/>

DataReference elements are used to refer to EncryptedData elements that were encrypted using the key defined in the enclosing EncryptedKey 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 objects that were encrypted using the key defined in the enclosing EncryptedKey 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 objects from a document storage facility.

4. Processing Rules

This section describes the operations to be performed as part of encryption and decryption processing.

4.1 Encryption

For each data item or key to be encrypted:

  1. Select the algorithm (and parameters) to be used in encrypting this item.
  2. Generate or obtain the encryption key to be used.
  3. Locate the octet sequence to be encrypted.
    1. If the data to be encrypted is an element, the octet sequence is the UTF-8 encoded string representation of the element. This string begins with the left angle bracket of the start tag of the element, and ends with the right angle bracket of the end tag of the element, both inclusive. This string is interpreted as an octet sequence and encrypted by the key obtained in the previous step.
    2. If the data to be encrypted is an element content (i.e., a NodeList), the octet sequence is the UTF-8 encoded string representation of the NodeList. The string starts with the first character following the right angle bracket of the start tag of  the element, and ends with the last character before the left angle bracket of the end tag of the element, both inclusive. The string is interpreted as an octet sequence and encrypted by the key obtained in the previous step.
    3. If the data to be encrypted is an external octet sequence, it is encrypted by the key obtained in the previous step.
  4. Build the XML structure for this encryption step
    1. If the data being encrypted is an element or node list, the unencrypted data is removed and replaced with the new XML structure.
    2. If the data being encrypted is an external octet sequence, create an EncryptedData structure referencing the encrypted data and use it as the top-level node in a new XML Document or insert it into another XML document (the processing is application dependent).

4.2 Decryption

For each item to be decrypted (either an EncryptedData or EncryptedKey element):

  1. Parse the element to determine the algorithm, parameters and key to be used.
  2. If the data encryption key is encrypted, locate the corresponding key to decrypt it. This may be a recursive step. Alternatively, retrieve the data encryption key from some local store using the provided attributes or implicit binding.
  3. Decrypt the data, contained in the required CipherText element
  4. If it is an EncryptedData structure and the type is "Element" or "NodeList", then transform the XML document. This means the decrypted octet sequence should be interpreted as a UTF-8 encoded string representing a serialized XML fragment, and be placed into the document in place of the EncryptedData element.

6 Security Considertations

6.1 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 be know whether the signature was computed over the encrypted or unencrypted representation 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.

In accordance with the requirements document [EncReq] 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 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 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, being developed as a separate specification. 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. This specification will also need to address vulnerabilities arising from plaintext guessing attacks in a similar way.

6.2 Information Revealed

Where a symmetric key is shared amongst multiple recipients, its encapsulating EncryptedKey should not reference or be referenced by other data not intended for all of those multiple recipients. (Kind of complex...?)

Where a symmetric key is shared amongst multiple recipients, that symmetric key should *only* be used for the data intended for those multiple recipients. (Quite strong.)

7 Schema, DTD, Valid Examples


8 Issues

8.1 Recently Closed

  1. The ‘Recipient’ attribute resolves how we’ll handle multiple keys encrypted to different recipients. -- Dillaway
  2. We will not provide a way to provide a key reference that points to multiple EncryptedData or EncryptedKey elements.-- Dillaway
  3. EncryptedKey becomes a child of KeyInfo when used inside an EncryptedData.-- Dillaway
  4. Requirements moved/integrated into requirements document. -- Reagle.
  5. More complete schema definitions. -- Reagle.

8.2 Recently Openned

  1. Undersand processing model, reliance upon DOM, use Information Set Items (and replace usage of "fragment" which is undefined." -- Reagle
  2. Fix KeyInfo usage/derivation from dsig.-- Realge
  3. We need some explicit schema that indicates an EncryptedKey is valid as either a standalone element or a child of a KeyInfo. -- Dillaway
  4. Plug in algorithm section as it matures. -- Reagle.

11.0 References

ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998.
Joan Daemen and Vincent Rijmen. AES Proposal: Rijndael, 2000.
Document Object Model (DOM) Level 1 Specification. W3C Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October 1998.
Joseph Reagle. XML Encryption Requirements.
Eric Rescorla. Diffie-Hellman Key Agreement Method, RFC 2631, 1999.
RFC 2104. HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
XML Information Set, W3C Working Draft. John Cowan.
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
RFC 1321. The MD5 Message-Digest Algorithm. R. Rivest. April 1992.
RFC 2045. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N. Borenstein. November 1996.
XML Encryption strawman proposal. Ed Simon and Brian LaMacchia. Aug 09 2000.
Another proposal of XML Encryption. Takeshi Imamura. Aug 14 2000.
XML Encryption Syntax and Processing. Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, Simon. December 2000.
RFC 2437. PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998.
RFC 2781. UTF-16, an encoding of ISO 10646. P. Hoffman , F. Yergeau. February 2000.
RFC 2279. UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998.
RFC 2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998.
RFC 2732. Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999.
RFC 1738. Uniform Resource Locators (URL). Berners-Lee, T., Masinter, L., and M. McCahill. December 1994.
RFC 2141. URN Syntax. R. Moats. May 1997.
RFC 2611. URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999.
ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework"  ISO/IEC 9594-8:1997.
Extensible Markup Language (XML) 1.0. W3C Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.
XML-C14N (update)
Canonical XML. W3C Proposed Recommendation. J. Boyer. January 2001.
XML-Signature Syntax and Processing. Working Draft. D. Eastlake, J. Reagle, and D. Solo.
RFC 2376. XML Media Types. E. Whitehead, M. Murata. July 1998.
Namespaces in XML W3C Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.
XML-schema (update)
XML Schema Part 1: Structures W3C Candidate Recommendation. D. Beech, M. Maloney, N. Mendelsohn. October 2000.
XML Schema Part 2: Datatypes W3C Candidate Recommendation. P. Biron, A. Malhotra. September 2000.