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-xmlencoverview.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

Received on Friday, 27 October 2000 09:14:20 UTC