W3C home > Mailing lists > Public > xml-encryption@w3.org > December 2000

RE: Algorithm Selections

From: Ed Simon <ed.simon@entrust.com>
Date: Sat, 2 Dec 2000 08:46:19 -0500
Message-ID: <A0E1DEC54ED42F4884DD9EEA00ACE37106D05A@sottmxs08.entrust.com>
To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>
Cc: Public XML Encryption List <xml-encryption@w3.org>
Joseph,
After the note below was written, it was iterated that the goal is to
support streaming encrypted video, not to support streaming ciphers.
If streaming encrypted video can be done with block ciphers, then that's
fine.

Though I'm interested in the area, I have a lot more to learn.  Its good
that you've asked for input from the SMIL WG.  Perhaps the MPEG 
("http://www.cselt.it/mpeg/"), particularly MPEG-7
("http://www.cselt.it/mpeg/standards/mpeg-7/mpeg-7.htm")
and MPEG-21,  might also be interested.

Ed
------------------------------------------------------------------------
--------------
Ed Simon
Software Engineer, Entrust Technologies
email:  ed.simon@entrust.com
ph: (613) 247-2583
------------------------------------------------------------------------
--------------



-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Friday, December 01, 2000 4:40 PM
To: Ed Simon
Cc: Public XML Encryption List
Subject: RE: Algorithm Selections


At 17:07 11/15/2000 -0500, Ed Simon wrote:

>The idea is that XML Encryption should support the encryption of arbitrary 
>data as well as XML elements and attributes.

Thanks for writing this up Ed, I'll forward it on to SMIL folks and see if 
it stirs any interest.

>And here's the SMIL file after the MPEG has been encrypted and stored in 
>"secret.enc" (and secret.mpg deleted):
>
><smil>
>...
><video src="secret.mpg" enc:EncryptedDataManifest="./EncryptedDataManifest"

>xmlns:enc="<http://www.example.org/xmlenc>http://www.example.org/xmlenc">
>   <EncryptedDataManifest 
> xmlns="<http://www.example.org/xmlenc>http://www.example.org/xmlenc">
>     <EncryptedData Type="video/mpeg" Name="secret.mpg">
>       <DecryptionInfo>...</DecryptionInfo>
>       <CipherText 
>
URI="<http://www.example.com/videos/secret.enc>http://www.example.com/videos
/secret.enc"/> 
>
>     </EncryptedData>
>   </EncryptedDataManifest>
></video>
>...
></smil>
>
>When a SMIL app is processing the <video> element, it detects that there is

>an EncryptedDataManifest attribute pointing to data that needs to be 
>decrypted.

This is my concern with saying that we should necessarily specify a 
streaming cipher. If your saying a SMIL application finds something from our

namespace and knows to do something, it should really be in their namespace 
(your defining behavior for a conforming SVG application) since they need to

figure it out. And if that's the case, they could provide the algorithms 
they need as appropriate. (I agree there's a real scenario here that we need

to consider, I'm just not yet sure if it requires streaming over block, and 
if stream if it's a dominant scenario such that that we should supply 
"out-of-the-box" algorithm identifiers and wraps to meet core interop, but 
we should give it more thought..)

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Saturday, 2 December 2000 08:47:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT