W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2001

Fwd: Re: [linux-elitists] W3C last call on XML Encryption... (fwd)

From: Ronald L. Rivest <rivest@mit.edu>
Date: Fri, 26 Oct 2001 13:05:56 -0400 (EDT)
Message-Id: <>
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 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/
>>The Cryptography Mailing List
>>Unsubscribe by sending "unsubscribe cryptography" to 
>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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC