RE: Draft Minutes from 010611 Teleconf (changes)

[Resulting document: note I've moved the editor's draft out of the proposal 
status into a more stable URI with links to the current schema and example.
        http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
        $Revision: 1.1 $ on $Date: 2001/06/13 18:19:28 $
]


At 12:02 6/13/2001, Blair Dillaway wrote:
>1. I believe the first paragraph is incorrect and should read
>         "If CipherValue is not supplied directly, the
>         CipherReference identifies a source which, when
>         processed, yields the octet sequence to be decrypted."
>It does not yield a base64 encoded octet sequence.  The 2nd paragraph
>Correctly states that a base64 decode transform is required if the data
>is base64 encoded.  There is no requirement that the target of a
>CipherReference be encrypted XML or reside in an XML document context.

No, but in the end (after dereferencing and transforming) what's the data 
and encoding? I think we need to be specific about this, and when I was 
editing this section I thought it made sense to require it to be the same 
value that would've occured in the SignatureValue element. Are you stating 
that it should be unspecified, or that the result of processing 
CipherReference is the base64 decoded version of the CipherValue? (Under my 
understanding, the base64 is used in the example where the whole document is 
base64 encoded. IF, I had a seperate XML document, or a database that 
returns the base64 encoded encrypted information *as* it appears in the 
SignatureValue, then you don't need to base64 explicitly decode it, you just 
handle it off to the SignatureValue method as is.)

>2. Please remove the 4th paragraph discussion 'reversibility, i.e., the
>one starting "Consequently, in XML Encryption the specified transforms ...".
>There is actually nothing wrong with the encryptor using an XSLT transform to
>obtain the data to be encrypted.  It is presumably the result of this
>encryptor-transform
>the decryptor needs, not the original document(s).  Such a transform may
>also useful in decribing how to obtain the octet sequence to be
>decrypted
>if it happens to be embedded in some larger external XML document
>context.

Removed.

>3. In the example there needs to be a base64 decode transform following
>the Xpath selection.

This is where our understanding differs as above. If the base64 follows the 
XPath, then you're getting the raw octects that then need to be handled 
differently than if you just treated it as SignatureValue content.


--
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 Wednesday, 13 June 2001 14:21:10 UTC