W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

Section 4.1 and 4.2 proposal

From: Blair Dillaway <blaird@microsoft.com>
Date: Tue, 7 Aug 2001 17:02:15 -0700
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCD49@red-msg-01.redmond.corp.microsoft.com>
To: <edsimon@xmlsec.com>, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "XML Encryption WG" <xml-encryption@w3.org>
I'm back from vacation (very enjoyable BTW) and have read through the
recent discussions re: "Replace and encrypt will be Recommended
(optional)".  Looks like some good progress has been made.  In reading
the lastest draft (8/02) I find the processing discussion a little too
terse.  Primarily I'm concerned about the things that aren't said which
may lead to confusion.  

I've made a pass through and expanded these sections to try and make
assumptions explicit and indicate more clearly where the dividing line
between the applications and an XML Encryption implementation lies. 

What do you think?  

4.1 Encryption
For each data item 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.  If the key
is to be transported to the decryptor, obtain the algorithm/parameters
and key-encryption key from the application.  Use these to encrypt the
key value and create an EncryptedKey structure to hold the encrypted key
value.  This will be encoded using the UTF-8 character set. Encryptors
shall support the ability to return the EncryptedKey structure to the
application or embed it the EncryptedData structure described in Step 5.
If returned to the application, the application will typically supply a
URI for the EncryptedKey which can be incorporated in the EncryptedData
(using the RetrievalMethod element).  Alternately the application could
use an indirect method such as lookup based on a KeyName value.

	3. Encrypting an [XML <> ] Element
<http://www.w3.org/TR/2000/REC-xml-20001006>  or [XML <> ] element
Content <http://www.w3.org/TR/2000/REC-xml-20001006> 
		a. The application is responsible serializing the
Element or Content to produce a valid string-based XML source
representation.  This could be a simple "as-is" serialization (commonly
referred to as the OuterXml and InnerXml for an element) or a
canonicalized form such as defined in [XML-C14N].  It is assumed the
application knows the appropriate format to insure the decryptor has
sufficient information to process the decrypted data.  
		b. If the string-based XML representation not UTF-8
encoded, it must be converted to UTF-8 prior to passing it to the XML
Encryptor.  The application must also provide the Type of the data
(Element or Content).
		c. The Encryptor accepts the UTF-8 encoded string
representation and interprets it as an octet sequence for encryption.
The octet sequence is encrypted based on the algorithm/parameters and
key value determined in steps 1 and 2 producing an encrypted octet
sequence.

	4. Encrypting other types of data
		a. The application is responsible for generating the
octet sequence to be encrypted.  This may represent any type of data.
For example, it could be a serialization of an XML document, textual
document,  binary image data, or a serialized and compressed XML element
representation.  From the perspective of an XML Encryptor, this is an
untyped octet sequence and no encoding is assumed.  Unless the decryptor
will implicitly know the type of the encrypted data, it is recommended
the application provide an appropriate Type value to include with the
encrypted data.
		b. The Encryptor will encrypt the supplied octet
sequence based on the algorithm/parameters and key value determined in
steps 1 and 2 producing an encrypted octet sequence.
		
	5. Building the EncryptedData structure 
		a. An EncryptedData element is created encoding
information about the algorithm, parameters, key value, Type of
encrypted data, and so forth.  The key value will typically be
communicated using the EncryptedKey structure optionally generated in
Step 2.  The EncryptedData element will be encoded using the UTF-8
character set.
		b. If the encrypted octet sequence obtained in Step 3 or
4 is to be stored in the CipherData element within the EncryptedData,
then the encrypted octet sequence is base64 encoded and inserted as the
text value of a CipherValue element.  If the encrypted octet sequence is
to be stored externally to the EncryptedData structure, then the
encrypted octet sequence is returned to the application.  The
application must supply a URI, and optional transforms, required for the
decryptor to retrieve the encrypted octet sequence.  The URI and
transforms are encoded in a CipherReference element.

	6. EncryptedData Processing
		a. If the Type of the encrypted data is Element or
Content, compliant implementations shall provide a way to return the
EncryptedData element to the application (REQUIRED). The application may
use this as the top-level element in a new XML Document or insert it
into another XML document. Encryption implementations may also support
replacement of the unencrypted Element or Content with the
EncryptedData(RECOMMENDED).  In the latter case, the application must
supply an XML Document context and a reference to the Element, or parent
Element of the Content, encrypted.  In this case, the Encryptor will
remove the XML that has been encrypted and insert the EncryptedData
element in its place.  This may require re-encoding the URT-8
EncryptedData into the character set encoding used by the supplied
Document context.
 		b.  If the Type of the encrypted data is not Element or
Content, then the EncrypedData structure is returned to the application.
The application may use this as the top-level element in a new XML
Document or insert it into another XML document.


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

	1. Parse the application identified 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 as the
key may itself be encrypted. Or, one might retrieve the data encryption
key from a local store using the provided attributes or implicit
binding.)  If the data encryption key is not stored in an accessible
EncryptedKey structure, then the application must supply the correct key
value.  Key attributes, stored in a KeyInfo element, may supply hints
for locating this key.

	3. Decrypt the data contained in the required CipherData
element. 
		a. If a CipherValue child element is present, then the
associated text value is retrieved, de-base64 encoded to obtain the
encrypted octet sequence, and decrypted yielding the cleartext octet
sequence.
		b. If a CipherReference child element is present, then
the URI and optional transforms are used to retrieve the encrypted octet
sequence.  The encrypted octed sequence is decrypted yielding the
cleartext octet sequence.
		c. If the cleartext octet sequence represents a key
value, it is saved for use in decrypting the associated EncryptedData
element(s).  The Decryptor should support passing this key value to the
application for persistant storage.  If it represents encrypted data
then subsequent processing as decribed below is required.

	4.  Decrypting data whose Type is [XML <> ] Element
<http://www.w3.org/TR/2000/REC-xml-20001006>  or [XML <> ] element
Content <http://www.w3.org/TR/2000/REC-xml-20001006>  
		a. The cleartext octet sequence obtained in Step 3 is
interpreted as a UTF-8 encoded string representing XML source for either
an Element or Content.
		b. The Decryptor shall support the ability to return the
UTF-8 XML source string, and Type, to the application for further
processing (REQUIRED)
		c. The Decryptor may support the ability to replace the
EncryptedData element with the decrypted Element or Content XML
(RECOMMENDED). In this case, the Decryptor parses the XML source string
to obtain a NodeList.  If the Type was Element, this will have exactly
one top-level Element which replaces the EncryptedData element.  If the
Type was Content, the NodeList may have one or more top-level nodes
including CDATA, Element, ProcessingInstructions, and Comment nodes.  In
this case the EncryptedData element is removed and the nodes in the
NodeList inserted as children of the EncryptedData's parent element.
When replacing the EncryptedData elements, it may be necessary to
transform the encoding of the inserted nodes from UTF-8 to the character
encoding of the containing XML Document.

	5. Decrypting other Types of data
		a. The cleartext octet sequence obtained in Step 3, and
Type if available, is always returned to the application for further
processing.
Received on Thursday, 9 August 2001 08:52:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC