- From: Blair Dillaway <blaird@microsoft.com>
- Date: Fri, 18 May 2001 09:47:57 -0700
- To: "Joseph M. Reagle Jr." <reagle@w3.org>, "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>
Joeseph, Thank you for restating the goals of the WG wrt specifying algorithms. Consistent with Don's draft, I would like to see a small number of required algorithms as a basis for interop that are: - publically available and free of IP encumberances - represent standards or de-facto standards (BTW, I support inclusion of AES and the new SHA algs as they will become standards which are critical to support) - have known performance characteristics - are useful by a fairly broad spectrum of applications In response to an earlier question by Don, I do not see a need for a required stream cipher due to limited demand from application developers. I am strongly opposed to inclusion of a "laundry list" of optional algorithms in the specification. If Mr. Ashwood, and others, feel its important to specify presicely how any number of such algorithms should be used with XML Encryption, then I encourage them to submit a separate Note on this topic. Blair -----Original Message----- From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] Sent: Thursday, May 17, 2001 9:20 AM To: XML Encryption WG Cc: Eastlake III Donald-LDE008; 'Joseph Ashwood'; Amir Herzberg Subject: RE: Early Draft Algorithms Section 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-prin ciples-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 Friday, 18 May 2001 12:56:12 UTC