XML Encryption Data/Processing Model

Today I meant to spend a short amount of time tweaking the proposal for 
consistent use of the terms we use to describe what is is we are encrypting 
(e.g., nodes). That spilled over into trying to use the proper identifers 
for these things, which spilled into questions/conversations of our data and 
processing model. See the two alternatives and discussion thereof at [1], 
and please comment/correct!

__

[1] http://www.w3.org/Encryption/2001/03/22-proposal#sec-EncryptedData

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.

Notes

   * Data Model: The 16 March 2001 Infoset no longer includes entity and CDATA
     start/end marker items, (the 2 February 2001 version did). This means 
that
     a serialization would not be able to preserve entity references and CDATA
     sections once encrypted/decrypted. (The result would look like Example 
3.4
     in Canonical XML, which also did not have access to these items in its
     XPath data model). (XSet and XML Query could also be data model
     contenders.)
   * Serialization: We would need to define a serialization for the
     Information Set. Richard Tobin has worked on a proposal for
     serializing a post-schema-validated Infoset. Or (since the serialization
     isn't as sensitive as it was in signature which requires all 
serialization
     of the same instance to be bit-by-bit identical) we might be able to 
leave
     this up to applications.
   * Identifiers: The URIs above are taken from a non-normative appendix of an
     older Infoset Draft. Hopefully, when Infoset is published as a Candidate
     REC there will be a new appendix or note tracking the changes with new
     identifiers. Also Tobin's proposal could provide identifiers in the 
future.
   * Documents: The earlier encryption proposal specified that  "For an entire
     document, the decrypted result will be a list of nodes including the 
prolog
     and root element." In this case, we need to support encryption of the
     Document Information Item, or encrypt XML documents as a bag of octets 
with
     Type="http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml"

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.

Notes

   * Data Model: DOM extends the InfoSet model and can preserve CDATA and
     external entity references. Unfortunately, DOM doesn't have an equivalent
     of the Information Set [in-scope namespaces] which gives you a list of 
all
     prefixes+namespaces in effect for that node. (DOM can give you all the
     namespaces for a node (those declared in the node and its ancestors), but
     not the prefixes+namespaces.)
   * Serialization: We would need to define a serialization of the DOM
     representation.
   * Identifiers: There are no published URIs for these types, I've pulled
     them from the specification. We could create our own identifiers (for DOM
     or InfoSet) under are own namespace and define them via a normative
     reference. For example:  http://www.w3.org/Encryption/2001/03/xmlenc#
     childNodes means [DOM: childNode].
   * Documents: Again, if we want to encrypt the whole document, we should
     encrypt it with the text/xml MIME type or also support DOM's
     documentElement.

__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Tuesday, 27 March 2001 19:39:17 UTC