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

RE: "Replace and encrypt will be Recommended (optional)."

From: <edsimon@xmlsec.com>
Date: Fri, 27 Jul 2001 18:35:46 -0400
Message-ID: <3B5F179F000010F0@mail.san.yahoo.com>
To: XML Encryption WG <xml-encryption@w3.org>
Joseph wrote:
>1. Was our intent to make this distinction upon encryption as well.
I reply:
Yes, we should have similar words for encryption too.  In scenario A which
I presented at the last meeting (see "http://www.w3.org/Encryption/2001/Minutes/0720-Redwood/simon-outline.html"),
one has an unencrypted XML data set protected by some kind of authorization
and one wants to extract a certain element, encrypt it WITHOUT replacing,
and place the resultant <EncryptedData> in a SOAP message.  

>2. As written, I know it's wrong in that both are REQUIRED to implement,
>but 
>exactly is the nature of the RECOMMENDED? I think the "or" is sufficient,
I would go for RECOMMENDED simply because many applications will want to
replacement at the end of either or both the encryption and decryption processes.
 Though replacing nodes is relatively straightforward with new XML parsers,
having the functionality in Toolkits is the best way to minimize the chances
of an application messing up the replacement code.

In both encryption and decryption, the replacement step (always the last
step) is basic XML processing (in DOM, just importNode() and insert...()
calls).  I expect Toolkits will have methods like in this pseudocode:

Element encrypt(NodeList nl) {...}  

Element encryptAndReplace(NodeList nl) {

    Element elemEncData = encrypt(nl);

    Node nodeImported = doc.importNode(elemEncData);        

    doc.insertNodeAfter(nl.last, nodeImported);

    doc.deleteNodes(nl);
}

NodeList decrypt(Element elemEncData) {...}  

NodeList decryptAndReplace(Element elemEncData) {

    NodeList nl = decrypt(elemEncData);

    foreach (node = nl.item(i); i++) {
     
            Node nodeImported = doc.importNode(node);        

            doc.insertNodeAfter(elemEncData, nodeImported);
    }

    doc.deleteNode(elemEncData);
}

IMPORTANT:  Note that by RECOMMENDED, we only mean "RECOMMENDED to be implemented
(in Toolkits)", NOT "RECOMMENDED to be done by the application".  The choice
to replace or not is solely determined by the architecture of the system
where XML Encryption is being integrated, not by the XML Encryption specification.

Ed
-- Original Message --

>I've tried to reflect the decision (but have two questions):
>
>http://www.w3.org/Encryption/2001/Minutes/0720-Redwood/minutes.html#processingRules
>>    A Poll was taken of the group on the behaviors. Based on that poll
it
>>    was determined that:
>>     1. Taking in octet and deliver encrypted, take in encrypted and
>>        deliver octet is Required.
>>     2. Replace and encrypt will be Recommended (optional).
>
>  as follows
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
>$Revision: 1.29 $ on $Date: 2001/07/27 20:43:17 $
>4.2 Decryption
>...
>  4. If it is an EncryptedData structure and the Type is "Element" or
>     "Content", then:
>      1. provide the octets to the application (REQUIRED to implement),
or
>      2. place the resulting octets as characters in place of the
>         EncryptedData element with the encoding of the parent XML document
>         (RECOMMENDED to implement).
>     Else (if not of type "Element" or "Content") provide the octets to
the
>     application
>
>1. Was our intent to make this distinction upon encryption as well.
>2. As written, I know it's wrong in that both are REQUIRED to implement,
>but 
>exactly is the nature of the RECOMMENDED? I think the "or" is sufficient,
>
>and we needn't speak of required or recommended.
>
>
>--
>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 Friday, 27 July 2001 18:37:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT