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 Friday, 1 December 2000 16:43:33 UTC