- From: Ed Simon <ed.simon@entrust.com>
- Date: Sat, 2 Dec 2000 08:46:19 -0500
- To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>
- Cc: Public XML Encryption List <xml-encryption@w3.org>
- Message-ID: <A0E1DEC54ED42F4884DD9EEA00ACE37106D05A@sottmxs08.entrust.com>
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 UTC