- 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