RE: Review of "Note on XML Encryption"

You are right in the coding scenario you present but I had
others in mind.

The coding scenario I was thinking about was an application
that gets an XML document.  The first thing it wants to do
is decrypt whatever <EncryptedData> elements it can decrypt.
To obtain the <EncryptedData> elements, it calls 

document.getElementsByTagNameNS("EncryptedData",
"http://www.example.org/xmlenc")

to get a NodeList of <EncryptedData> elements.

Now it iterates though this NodeList.  At this point, it is NOT 
interested in encrypted keys so it needs to find the context either 
through an ancestor search or attribute check.  Given that this 
scenario would be so common, it would keep things simpler to have 
separate tag names.

Similarly with XSL, 

<xsl:template match="enc:EncryptedData">...

is preferable to 

<xsl:template
match="enc:EncryptedData[not(ancestor(enc:DecryptionInfo))]">...

(Note: I might not have the XSL syntax quite correct.)

And conceptually, it is important to distinguish between application-created
ciphertext and stuff the encryption process is adding.  As part of my XML
zealousness, I think it is important to have different tag names for
information
that is significantly different semantically.

OK, I've done enough ranting here given that fact we already agree with 
each other ;-}

Regards, Ed

-----Original Message-----
From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com]
Sent: Friday, October 27, 2000 9:14 AM
To: Ed Simon
Cc: xml-encryption@w3.org; Hiroshi Maruyama
Subject: RE: Review of "Note on XML Encryption"




Hi Ed,

>Using <EncryptedData> for both application data and keying material will
require either
>an ancestor search or attribute check for an application to determine
whether the
>content is application data or not.  For stream based parsers, these
checks would likely
>be particularly annoying.  To keep things straight-forward for
applications and ourselves,
>let's use different tag names.

I discussed this with Hiroshi Maruyama, and we agreed with you on changing
<EncryptedData> to <EncryptedKey> for keying material.  However, we think
that the parser doesn't require any ancestor search or attribute check.  In
the context of decryption, it processes an <EncryptedData> element, finds
the corresponding <DecryptionInfo> element, and then processes an
<EncryptedKey> element...  That is, when the parser is parsing the
<DecryptionInfo> element, it already knows that it is processing keying
material.  This is why the parser doesn't require them.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com



From: Ed Simon <ed.simon@entrust.com>@w3.org on 2000/10/26 09:52 PM

Please respond to Ed Simon <ed.simon@entrust.com>

Sent by:  xml-encryption-request@w3.org


To:   xml-encryption@w3.org
cc:
Subject:  RE: Review of "Note on XML Encryption"





Comments imbedded below.

Look for the "[Ed]...[/Ed]" strings,
Ed

-----Original Message-----
From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com]
Sent: Thursday, October 26, 2000 7:31 AM
To: Ed Simon
Cc: xml-encryption@w3.org
Subject: Re: Review of "Note on XML Encryption"



Ed, thank you for your comments.

>3.  Use the element name <EncryptedKey> rather than
><EncryptedData> when the content is an encrypted key inside
<EncryptionInfo>.

Do you mean that only the name should be changed (i.e., the structure does
not have to be changed)?

[Ed]Essentially, yes.  From a schema view, the structure of <EncryptedKey>
would
have the same substructure except, perhaps, that any irrelevant elements or
attributes may not be allowed.[/Ed]

>4.  Here's an idea for handling IVs and other <EncryptionInfo> data.
>...
>If an <EncryptedData> element has BOTH a child <EncryptionInfo> element
>AND an EncryptionInfo attribute, it combines the two giving priority to
>its child <EncryptionInfo> element where specific parameters conflict (eg.
an IV).

I think that specifying both may be useful in a case where a child
<EncryptionInfo> element contains an IV and a remote one contains the
keying information, as presented in [1].

By the way, according to [2], the content model of the <EncryptedData>
element must be MIXED so that it can also contain an <EncryptionInfo>
element.  However, it is a little troublesome to handle mixed contents.  I
think that encrypted data should be tagged as:

  <EncryptedData EncryptionInfo="#encryptionInfo23">
    <EncryptionInfo>...</EncryptionInfo>
    <foo>...</foo>  <!-- base64-encoded encrypted data -->
  </EncryptedData>

[Ed]I think it makes sense for <EncryptedData> to have the actual encrypted
data in a <CipherText> element so we'd have

  <EncryptedData EncryptionInfo="#encryptionInfo23">
    <EncryptionInfo>...</EncryptionInfo>
    <CipherText>...</CipherText>  <!-- base64-encoded encrypted data -->
  </EncryptedData>

[/Ed]

>5.  I would structure <EncryptionInfo> (which I think might be better
>termed <DecryptionInfo>) as follows:
>...
>I've also made it possible for <KeyInfo> to hold one or more types of key
data
>so that an application can simultaneously provide multiple ways of
specifying the key.

I totally agree with you.  In fact, I had the same idea, but I missed
including a description in the note.

[Ed]Great!  Let's make it so.[/Ed]

[1] http://lists.w3.org/Archives/Public/xml-encryption/2000Sep/0010.html
[2]
http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmlen
coverview.html


Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com


From: Ed Simon <ed.simon@entrust.com>@w3.org on 2000/10/26 06:44 AM

Please respond to Ed Simon <ed.simon@entrust.com>

Sent by:  xml-encryption-request@w3.org

To:   "'xml-encryption@w3.org'" <xml-encryption@w3.org>
cc:
Subject:  Review of "Note on XML Encryption"




Takeshi and Hiroshi,
I think the Note on XML Encryption is a big step forward with respect to
defining <EncryptionInfo>.  Its great to see such progress. Here are my
comments:

1.  I lean gently toward renaming <EncryptionInfo> as <DecryptionInfo>
because
its ultimate purpose is to provide information on decrypting the data.
This is
a minor point.

2.  As you say, an <EncryptionInfo> element can point to one or more
<EncryptedData>
elements, or an <EncryptedData> element should be able to point to an
<EncryptionInfo>
element.  I would just clarify that an <EncryptionInfo> element can both
point to
<EncryptedData> elements AND also be referenced by <EncryptedData> elements
at the
same time.

3.  Use the element name <EncryptedKey> rather than
<EncryptedData> when the content is an encrypted key inside
<EncryptionInfo>.
It is true that the structure of <EncryptedData> is valid when the content
happens
to be a key but the semantics are meaningfully different for applications.
<EncryptedData> should be reserved for data corresponding to the plaintext
instance being
secured and not for keying material introduced by the encryption process.
Using <EncryptedData> for both application data and keying material will
require either
an ancestor search or attribute check for an application to determine
whether the
content is application data or not.  For stream based parsers, these checks
would likely
be particularly annoying.  To keep things straight-forward for applications
and ourselves,
let's use different tag names.

4.  Here's an idea for handling IVs and other <EncryptionInfo> data.

If an <EncryptedData> element contains no <EncryptionInfo> element AND has
no EncryptionInfo
attribute pointing to an <EncryptionInfo> element, it is assumed the
application can figure
out the encryption info by itself.  (This is analagous to an absent
<KeyInfo> element in
XML Signatures.)

If an <EncryptedData> element has EITHER, but NOT BOTH, a child
<EncryptionInfo> element
or an EncryptionInfo attribute, there is only one associated
<EncryptionInfo> element and
that on is used.  No problem here.

If an <EncryptedData> element has BOTH a child <EncryptionInfo> element AND
an EncryptionInfo
attribute, it combines the two giving priority to its child
<EncryptionInfo> element where
specific parameters conflict (eg. an IV).

If the resulting <EncryptionInfo> element has no parameter for something
(say, an IV), it is
assumed that the application can handle that situation.

My hope is the above would provide a flexible way of handling the various
encryption scenarios
(such as encrypted video) that were discussed at Santa Barbara and on the
XML Encryption
mailing list.

5.  I would structure <EncryptionInfo> (which I think might be better
termed <DecryptionInfo>) as follows:

<DecryptionInfo (Id=)?>
  <Method Algorithm=""/>
  <PropertyList>
        <Property Name="IV">1234...</Property>+
  </PropertyList>
  <Manifest>
        <Reference.../>+
  </Manifest>
  <KeyInfo>
        <Value/>?
      <Identifier/>?
      <Agreement/>?
      <EncryptedKey/>+
  </KeyInfo>
</DecryptionInfo>

I put the <Reference> elements in a <Manifest> element simply because I
like to see lists
of the same elements structurally distinct; this is mainly a personal
preference.  <KeyInfo>
is at the bottom because this will often be a relatively huge chunk of data
and I think
it makes performance better if an application doesn't have to parser
through a bunch of stuff
it doesn't need to get to what it is looking for.  I've also made it
possible for <KeyInfo>
to hold one or more types of key data so that an application can
simultaneously provide multiple
ways of specifying the key.  (Do people think this is a good idea?  I've
not completely researched
it myself.)

Looking forward to discussing this more in Lafayette, Ed