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