Re: Draft Minutes from 010611 Teleconf (changes)

I would think CipherReference would most frequently be used to
access binary stuff via HTTP, FTP or whatever.  If it always
has to be base64, then you end up having to put in transforms
to base64 stuff just so that it can be immediately unbase64ed,
which doesn't make sense to me.  So I think the reference should
yield a binary octet-stream.

Thanks,
Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <4.3.2.7.2.20010613140930.02971bd0@localhost>
Date:  Wed, 13 Jun 2001 14:20:01 -0400
To:  "Blair Dillaway" <blaird@microsoft.com>
Cc:  <edsimon@xmlsec.com>, <xml-encryption@w3.org>
In-Reply-To:  <AA19CFCE90F52E4B942B27D42349637902CDCD11@red-msg-01.redmon
	      d.corp.microsoft.com>

>[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 15:30:10 UTC