W3C  
XML Encryption Implementation and Interoperability Report

Editors(s):
Joseph Reagle, <[email protected]>
Previous versions
...

This document describes the interoperability requirements over a features, operations, and requirements specified by the XML Encryption Syntax and Processing specification of the W3C XML Encryption WG. These are specified over what is implemented, not what an application might choose to use. The minimum exit criteria for this implementation period is defined by the IETF RFC2026 Draft Standard semantic:

4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained... For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used.

There is already significant implementation experience and we expect to satisfy this definition (2 implementations) within two weeks of reaching Candidate Recommendation. However, this period may be extended so as to increase our confidence by increasing the number of compliant implementations and/or expanding the test cases.

The following information is the best assessment of the Editors/Chairs for the given dated specification and does not necessarily represent the latest state of any given implementation over this or later specifications.  The following key applies: "Y"(implemented), "Y{1,2,*}"(interoperable with others in that Y{1,2,*} set), "N"(not implemented), ""(unknown).

Test Vectors:

Application Features Key Word Baltimore IBM Phaos XMLSec NEC Datapower
Laxly valid schema generation of EncryptedData/EncryptedKey MUST Y Y Y Y Y Y
  • Normalized Form C generations.
 SHOULD Y N N Y N Y
Type, MimeType, and Encoding MUST Y Y Y Y Y

Y
CipherReference URI derefencing MUST Y Y Y Y

Y

Y
  • Transforms
 OPTIONAL Y Y Y Y

Y

?
ds:KeyInfo MUST Y Y Y Y

Y

Y
  • enc:DHKeyValue
 OPTIONAL Y N Y N

Y

N
  • ds:KeyName
 RECOMMENDED Y Y Y Y

Y

Y
REQUIRED Y Y Y Y

Y

Y
ReferenceList OPTIONAL Y Y Y N

Y

Y
EncryptionProperties OPTIONAL Y Y Y Y

Y

Y
Satisfactory Performance (required!) Y Y Y

Y

Y
Processing Features Key Word Baltimore IBM Phaos XMLSec NEC Datapower
Required Type support: Element and Content. MUST Y Y Y Y

Y

 Y
Encryption MUST Y Y Y Y

Y

 Y
MAY

MUST

 Y

Y

 Y

N

 Y

N

 Y

?

 Y

N

 N
Y
  • Encryptor returns EncryptedData structure.
 MUST Y Y Y Y Y

Y
  • Encryptor replaces EncryptedData into source document (when Type is Element or Content).
 SHOULD Y Y Y Y Y

Y
Decryption MUST Y Y Y Y

Y

Y
  • The decryptor returns the data and its Type to the application (be it an octet sequence or key value).
 MUST Y Y Y Y Y

Y
  • If data is Element or Content the decryptor return the UTF-8 encoding XML character data.
 MUST Y Y Y Y Y

Y
  • If data is Element or Content the decryptor replaces the EncryptedData in the source document with the decrypted data.
 SHOULD Y Y Y Y Y

Y
Algorithms Key Word Baltimore IBM Phaos XMLSec NEC Datapower
TRIPLEDES REQUIRED Y1  Y2 Y1 Y1  Y2 Y1 Y2 Y1 Y2 Y1 Y2
AES-128 REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
AES-256 REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
AES-192 OPTIONAL Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
RSA-v1.5 (192 bit keys for AES or DES) REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
RSA-OAEP (128 and 256 bit keys for AES) REQUIRED Y1  Y2 Y Y1 Y2 Y1 Y2* Y1 Y2 Y1 Y2
Diffie-Hellman Key Agreement OPTIONAL Y1  Y2 N Y1 Y2 Y1 Y2 Y1 Y2 N
TRIPLEDES Key Wrap REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
AES-128 Key Wrap (128 bit keys) REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
AES-256 Key Wrap (256 bit keys) REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 YY1 Y2
AES-192 Key Wrap OPTIONAL Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
SHA1 REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
SHA256 RECOMMENDED Y1  Y2 N Y1 Y2 Y1 Y2* Y1 Y2 N
SHA512 OPTIONAL Y1  Y2

N

 Y1 Y2 Y1 Y2* Y1 Y2 N
RIPEMD-160 OPTIONAL Y1 N N Y1 Y1 N
XML Digital Signature RECOMMENDED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y Y1 Y2
Decryption Transform for XML Signature RECOMMENDED Y3 Y3 Y3 N Y3 N
  • XML Mode
 o REQUIRED Y3 Y3 Y3 Y3
  • Binary Mode
 o REQUIRED Y3 Y3 Y3 Y3
  • Profiled XPointer support in Except URI
 o OPTIONAL Y3 N Y3 Y3
  • Profiled XPointer support in Except URI into replacement node-sets (i.e. super-decryption).
 o OPTIONAL ? N N Y3
  • Full XPointer support in Except URIs.
 o OPTIONAL Y N N N

Canonical XML (with and without comments)

 OPTIONAL Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y Y1 Y2
Exclusive Canonicalization (with and without comments) OPTIONAL Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y Y1 Y2
base64 Encoding REQUIRED Y1  Y2 Y1 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2
Joseph Reagle <[email protected]>

$Revision: 1.33 $ on $Date: 2003/07/16 17:26:59 $ GMT by $Author: reagle $