RE: Draft Minutes from 010611 Teleconf (changes)

I think we're seeing this differently, but must admit I'm a little
confused by
your references to SignatureValue in the response below.  I assume you
mean
CipherValue.  If not, then my response may be off base.

I think your interpretation causes a problem.  If I follow your logic
then when
retrieving encrypted, non-XML, external data, I'd need to get the octet
sequence
and then base64 encode it so I can treat it just like CipherValue
content.  There
is no reason to ever base64 non-XML encrypted data, it just increases
the size.  
The earlier proposal/drafts were clear that the retieved/transformed
data was the
'raw' encrypted octet sequence and an explicit base64 decode transform
was required if the data was base64 encoded.

We do have a type attribute to indicate the type of the data (which
answers your
question about how we know what the data is).  One could decide that if
the type
is not XML, such as image/jpeg or binary, then the retrieved data is the
raw octet
sequence while it is base64 encoded if the type is text/xml.  However, I
find 
this less attractive since I believe the primary use of CipheReference
will be 
to refer to non-XML encrypted blobs.

Blair

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] 
Sent: Wednesday, June 13, 2001 11:20 AM
To: Blair Dillaway
Cc: edsimon@xmlsec.com; xml-encryption@w3.org
Subject: 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 15:29:07 UTC