- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Thu, 17 May 2001 12:19:38 -0400
- To: "XML Encryption WG " <xml-encryption@w3.org>
- Cc: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, "'Joseph Ashwood'" <jashwood@arcot.com>, Amir Herzberg <AMIR@newgenpay.com>
At 12:43 5/15/2001 -0400, Eastlake III Donald-LDE008 wrote:
%% Well, if you look in Schneier's book I'm sure you can find hundreds of
%% algorithms, but so what? The specification is extensible so that people
%% who want to use rare, proprietary, or bizarre algorithms certainly can....
%% symmetric algorithms. 2 or 3 well chosen strong algorithms are a much
%% better idea from the viewpoint of the goals of interoperability and
%% widespread implementation, including lower end devices....
%% The question of parameterization is as I have commented above and needs,
%% in my opinion, more feedback from WG members to determine a consensus.
%% In this case, parameterization would probably have to be via child
%% parameter element(s) of the algorithm role element.
Just to reiterate Don's points, our goal via the requirements document [1]
(which is derived from the charter [2] on this note) is to come up with the
a minimal set of required algorithms that are/will-soon be widely
implemented, relatively strong, unencumbered, and exercise the features of
the specification for interoperability purposes. There has been consensus
that [3] represents the general scope, number, and actual algorithms we will
specify. We can alter and make improvements when the benefit is clear and
there's a ground swell of support, but given 25 folks agreed to it at the
last meeting I consider it be a rather stable selection. Like we did in
xmldsig, the number of optional algorithms should be kept to a minimum from
the start: we want strong evidence that they will be implemented in
implementations tracking the spec in the next 4 months. (For example, the
April release of the Alphaworks XSS is supporting [4].)
Specifying the algorithms as we did in xmldsig would be symmetric with that
spec, but Amir's proposal isn't counter to that (others can still specify a
suite via one identifier) and nicely addresses a couple of issues and we
should give it some more thought -- since we've been discussing it for a
while now, I think it merits a more fully specified proposal incorporating
the results of the discussion.
[1]
http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420#sec-design-principles-scope
[2] http://www.w3.org/Encryption/2001/01/xmlenc-charter.html
5. The specification must define a minimal set of algorithms and key
structures necessary for interoperability purposes. {Reagle}
[3] http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420#sec-Algorithms
[4] Supported algorithms:
RSA using v1.5 padding (requiring IBM JCE 1.2.1)
Three-key triple-DES using EDE in CBC mode with PKCS #5 padding
DES in CBC mode with PKCS #5 padding
Base64
__
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 Thursday, 17 May 2001 12:20:17 UTC