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

Hi,

From:  "Ronald L. Rivest" <rivest@mit.edu>
Date:  Fri, 26 Oct 2001 13:05:56 -0400 (EDT)
Message-Id:  <5.0.2.1.2.20011026130526.024421e8@pop.ne.mediaone.net>
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/

Chaining modes are not broken out as an orthogonal parameter but
combined in the name of the encryption algorithm.  There is no
difficulty in defining additional algorithm ids with different
chaining modes.

On OCB itself, as far as I can see it has a patent problem with at
least three people claiming to have patents pending covering it.
While there is a proof, many experts are not very interested in
looking at it since they believe it will not be widely adopted until
the patent mess is cleared up. There have been cryptographic proofs
that have been broken later. While there is a proposal before NIST for
OCB, it has not been adopted and it is unclear if it will be unless
the patent situation is clarified up.

>>(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...

There isn'ta any explicit mechanism for this in XML Encryption but if
one is worried about it, you would probably use XML Signature and
verify that first...

>>(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.

While I don't knonw that we thought much about that, I think the
Transform mechanism is general enough to handle most anything.

>>(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.

I can understand that concern. The XML Signature Recommendation does
NOT allow the signature algorithm to be understood. But I guess the
encryption Working Group felt that established sessions or whatever,
with the encryption algorithm and keying understood, would be common
enough to make this worth while.

>>         Cheers,
>>         Ron

Thanks,
Donald

>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 Thursday, 15 November 2001 21:35:41 UTC