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

On Friday 26 October 2001 12:05, Ronald L. Rivest wrote:
> From: "Ronald L. Rivest" <rivest@mit.edu>

Thank you for the comments! I know some participants have already responded 
or discussed these issues but this serves as a more "official" summary that 
we sometimes generate when processing external last call issues.

First, your issues have been captured at:
  http://www.w3.org/Encryption/2001/11/last-call-issues#rivest
If this table or email does not satisfactorily   address your concern, 
please let us know such that we can close the item, continue to work on it, 
or flag it as contentious during the next advancement review.

> >(1) I didn't see any provision for handling
> >some of the new combined "encryption+integrity"

As Don noted (and the telecon discussed [1]), our design would permit 
others to create identifiers for such combined modes.

[1] http://www.w3.org/Encryption/2001/Minutes/011119-tele.html

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

Ed Simon has explored this scenario and the application would be capable of 
signing such information with XML Signature, though we don't specify this 
ourselves.
  http://lists.w3.org/Archives/Public/xml-encryption/2001Nov/0063.html

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

At the November 2, 2000 Workshop threshold systems were discussed as a 
point of interest. However, we also decided that failing a substantive 
proposal by a member of the WG it would not be a required feature:

  http://www.w3.org/2000/11/02-xml-encryption-ws/minutes.html
  ...Need threshold system support. Distribution of encrypted content 
  where encrypted content and Keyinfo are shipped separately.
  Conclusions
    o Lots of hard problems
    o Basic building block for protocols
    o Let's limit scope ...

We certainly don't intend to preclude their usage but haven't had anyone to 
date interested in substantively exploring it -- though such work is still 
welcome. Presently, Blair Dillaway has expressed some interest in 
addressing it this month but we still don't plan to make this a critical 
path issue.

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

This decision followed the design of XML Signature and continues to be 
desired by the WG as discussed on the telecon [1], however, I've tried to 
strengthen the warning in the specification on this note:

   Reagle: tweaked text, "If the element is absent, the 
   encryption algorithm /+must be known by the recipient or the decryption
   will fail.+/"

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Tuesday, 11 December 2001 16:38:09 UTC