XML Encryption:
Issues Regarding
Attribute Values and Referenced, External Data
Ed
Simon
Entrust Technologies
The Issues
•
Attribute values
XML Encryption enables encryption of
whole elements and element content.
Should it also define encryption of other XML structures, particularly
attribute values? If so, what would
attribute value encryption look like?
•
Referenced, external
data
XML Encryption defines how to encrypt
arbitrary data but does not provide a mechanism to mark that an element’s
referenced, external data has been encrypted.
Both attribute values and referenced,
external data are similar from the element perspective in that they are both
data associated with the element. The
difference is that attribute values are internal and referenced by name whereas
referenced, external data is external and referenced by URIs (typically).
It all boils down to…
Should XML Encryption provide a uniform
way for an application to know when
•
an element has attribute
values that have been encrypted
•
an element’s referenced,
external data has been encrypted
An Example
<video
src="secret.mpg"
alt="Alien spaceship in hangar at Area 51."/>
Want to encrypt
a) the value of the alt attribute and
b) the MPEG file named secret.mpg
How can this be done?
Proposal 1 – The EncryptedData Manifest Proposal
<video
src="secret.mpg"
enc:EncryptedDataManifest="./EncryptedDataManifest"
xmlns:enc="http://www.w3.org/xml/encryption/...">
<EncryptedDataManifest
xmlns="http://www.w3.org/xml/encryption/...">
<EncryptedData
Type="video/mpeg“
Name="secret.mpg">
...
<CipherText
URI="secret.enc"/>
</EncryptedData>
<EncryptedData
Type="AttributeValue" Name="alt">
...
<CipherText>AbCd...WxYz</CipherText>
</EncryptedData>
</EncryptedDataManifest>
</video>
Proposal 2 – Use XSLT Transforms
The Transform proposal suggests using
XSLT to convert attributes into elements and then encrypt according to rules
presently in the XML Encryption proposal.
Could perhaps also handle external data using extension functions.
An important advantage of the Transform
proposal is that it could allow tremendous flexibility in node encryption (eg.
Encrypt all the content of element X except for elements Y and Z).
The disadvantages are
•
that one needs a reverse
transform to get back to the original plaintext
•
XSLT may be deemed too
inefficient for many applications; EncryptedDataManifest may not be smart, but
it is (relatively) fast
•
Nobody has provided
an example of what the Transform proposal would look like in practice.
What to do?
Some possibilities:
•
Leave attribute value
encryption and the handling of encrypted, referenced external data until
version 2.0 of XML Encryption.
•
Develop either the
EncryptedDataManifest proposal or the Transform proposal.
•
Develop both the
EncryptedDataManifest proposal or the Transform proposal. Applications can use whichever mechanism is
best for their needs.
At this point, probably best to just get
more feedback.