- From: Ronald L. Rivest <rivest@mit.edu>
- Date: Fri, 26 Oct 2001 13:05:56 -0400 (EDT)
- To: xml-encryption@w3.org
>Date: Thu, 25 Oct 2001 21:45:24 -0400 >To: Eugene Leitl <Eugene.Leitl@lrz.uni-muenchen.de> >From: "Ronald L. Rivest" <rivest@mit.edu> >Subject: Re: [linux-elitists] W3C last call on XML Encryption... (fwd) >Cc: Joseph Reagle <reagle@w3.org> > >Hi Eugene and Joe -- > >Thanks for sending along this announcement about the proposed >XML Encryption standards. I took a brief look at them; they >seemed to be in quite good shape. Here are a few comments. They >may be off-base in one way or another, since I didn't have >time to study the documents in detail. Perhaps you will find >them helpful; please work them into your comment process >as appropriate... > >(1) I didn't see any provision for handling >some of the new combined "encryption+integrity" >modes of operation as proposed by Jutla or Rogaway et al.; >These modes are about twice as efficient as doing encryption >and integrity separately, and can have provable security >properties. For example, see the site > http://www.cs.ucdavis.edu/~rogaway/ocb/ocb.htm >on OCB mode; there are this and more similar proposals before >NIST for other new modes of operation for AES... > http://csrc.nist.gov/encryption/modes/ > >(2) You have provisions for referring to some elements >indirectly (e.g. through a URI), but you may need some >way to ensure that what you retrieve is what was intended >(e.g. through a hash of the element to be retrieved). >Perhaps this is implicitly handled already... > >(3) The are of modes of encryption that won't fit your >model, but which are very useful. For example, "secret-sharing" >allows encryption of a document into several pieces, or >shares, in such a way that a requisite number of them are >required to decrypt/reconstruct the document. Just be >sure you don't preclude somehow expansion to handle this >sort of thing later on. > >(4) I'm very uncomfortable with allowing the encryption algorithm >to be "understood" between the sender and the recipient; >you should force the sender to be explicit. Non-explicitness >is the cause of very many protocol failures. > > Cheers, > Ron > > > > > > > > Cheers, > Ron > >At 12:22 PM 10/25/2001, you wrote: >>---------- Forwarded message ---------- >>Date: Thu, 25 Oct 2001 11:32:53 -0400 >>From: Dan York <dyork@e-smith.com> >>To: linux-elitists <linux-elitists@zgp.org> >>Subject: [linux-elitists] W3C last call on XML Encryption... >> >>FYI, the W3C has issued a last call for comments on several >>proposals related to XML encryption. More info at: >> >> http://www.w3.org/Encryption/2001/ >> >>Since I know a good number of folks on this list are interested >>in encryption and Internet communication, I thought I would pass >>it along as it involves encrypting XML, much of which will no >>doubt be passed across the Internet. >> >>The specific documents are at: >> >> XML Encryption Requirements >> http://www.w3.org/TR/xml-encryption-req >> >> This document lists the design principles, scope, and requirements >> for the XML Encryption. It includes requirements as they relate to >> the encryption syntax, data model, format, cryptographic processing, >> and external requirements and coordination. >> >> XML Encryption Syntax and Processing >> http://www.w3.org/TR/xmlenc-core/ >> >> This document specifies a process for encrypting data and >> representing the result in XML. The data may be arbitrary data >> (including an XML document), an XML element, or XML element >> content. The result of encrypting data is an XML Encryption element >> which contains or references the cipher data. >> >> Decryption Transform for XML Signature >> http://www.w3.org/TR/xmlenc-decrypt >> >> This document specifies the "decryption transform", which enables >> XML Signatures verification even if both signature and encryption >> operations are performed on an XML document. >> >>Dan >> >>-- >>Dan York, Director of Training, Network Server Solutions Group >>Mitel Networks Corporation dan_york@mitel.com >>Ph: +1-613-751-4401 Cell: +1-613-263-4312 Fax: +1-613-564-7739 >>150 Metcalfe Street, Suite 1500, Ottawa,ON K2P 1P1 Canada >>http://www.e-smith.com/ http://www.mitel.com/sme/ >>_______________________________________________ >>linux-elitists >>http://zgp.org/mailman/listinfo/linux-elitists >> >> >> >> >>--------------------------------------------------------------------- >>The Cryptography Mailing List >>Unsubscribe by sending "unsubscribe cryptography" to >>majordomo@wasabisystems.com > >Ronald L. Rivest >Room 324, 200 Technology Square, Cambridge MA 02139 >Tel 617-253-5880, Fax 617-258-9738, Email <rivest@mit.edu> Ronald L. Rivest Room 324, 200 Technology Square, Cambridge MA 02139 Tel 617-253-5880, Fax 617-258-9738, Email <rivest@mit.edu>
Received on Friday, 26 October 2001 13:26:27 UTC