- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 26 Aug 2002 20:35:33 +0900
- To: reagle@w3.org
- Cc: xml-encryption@w3.org
Joseph, I have a few editorial comments on the Decryption Transform spec. Hope these help. 1. In Step 2 of decryptXML() in Section 3.1, "section 4.3.1" and "section 4.3.2" would be "section 3.4.1" and "section 3.4.2", respectively. Also, itemization looks awkward. The first item is missing. 2. In Step 3 of decryptNodeSet() in Section 3.1, a step saying that Y is replaced with Y U {Od} is missing between Steps 1 and 2. 3. In execution steps of the transform in Section 3.3, each example has an item number, which would not be necessary. 4. In Section 3.4.4, a KeyInfo structure referenced by a RetrievalMethod element could be included in the second and third examples. Also, a decrypted document could be added to the end. So, examples would be as follows: [a01] <Document> [a02] <ToBeSigned Id="tbs"> [a03] <xenc:EncryptedData ...> [a04] ... [a05] <dsig:KeyInfo ...> [a06] <dsig:RetrievalMethod URI="#key-info" Type ="http://www.w3.org/2001/04/xmlenc#EncryptedKey" .../> [a07] </dsig:KeyInfo> [a08] ... [a09] </xenc:EncryptedData> [a10] ... [a11] </ToBeSigned> [a12] <xenc:EncryptedKey Id="key-info" .../> [a13] <dsig:Signature ...> [a14] ... [a15] <dsig:Reference URI="#tbs"> [a16] <dsig:Transforms> [a17] <dsig:Transform Algorithm ="http://www.w3.org/2002/07/decrypt#XML"/> [a18] </dsig:Transforms> [a19] ... [a20] </dsig:Reference> [a21] ... [a22] </dsig:Signature> [a23] </Document> [d01] <dummy><ToBeSigned Id="tbs"> [d02] <xenc:EncryptedData ...> [d03] ... [d04] <dsig:KeyInfo ...> [d05] <dsig:RetrievalMethod URI="#key-info" Type ="http://www.w3.org/2001/04/xmlenc#EncryptedKey" .../> [d06] </dsig:KeyInfo> [d07] ... [d08] </xenc:EncryptedData> [d09] ... [d10] </ToBeSigned></dummy> Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com Joseph Reagle <reagle@w3.org> To: XML Encryption <xml-encryption@w3.org> Sent by: cc: xml-encryption-req Subject: Publications of the Second xenc Candidate Recs uest@w3.org 2002/08/03 01:39 Please respond to reagle http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/ ... This version now includes (1) clarifications resulting from current implementations, see Interoperability Report, (2) a media type registry application, and (3) non-normative changes resulting from work on the XML Signature Decryption Transform [XML-DSIG-Decrypt]. In particular, informational (non-normative) text for implementing decrypt and decrypt-and-replace operations were moved to this specification's Encrypting XML (section 4.3). The exit criteria for this phase continues to be at least two interoperable implementations over every feature, one implementation of all features, and one report of satisfaction in an application context (e.g., SOAP, SAML, etc.) Present implementations must update their implementation of [XML-DSIG-Decrypt]; we will continue to solicit new implementations. We expect to meet the exit criteria within 6 weeks (closing 13 September 2002). Specific areas where we would appreciate further experience are: * Do implementations achieve satisfactory performance? * Does the specification satisfy application scenario requirements for encrypting portions of XML, particularly as they relate to document validity? http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020802 ... This version is a signficiant revision: the processing steps have been rewriten, a binary mode has been added, and many more examples and explainations have been included. Consequently, this specification uses a new namespace/identifier for the transform. ... Specific areas where we would appreciate further experience are: * Do implementations achieve satisfactory performance? * Does the specification satisfy application scenario requirements for encrypting and signing portions of XML? * Do implementors plan on supporting full XPointer expressions in the Except URI, particularly when they identify nodes resulting from super-decryption (i.e. the replacement node-set)? * Presently the specification states signature processing must fail if decryption fails; should this be relaxed such that in some cases processing can continue?
Received on Monday, 26 August 2002 07:35:33 UTC