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

Re: Publications of the Second xenc Candidate Recs

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
Message-ID: <OF09A42439.4DE272DE-ON49256C21.0031F5AB@LocalDomain>


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 GMT

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