- From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
- Date: Fri, 23 Apr 1999 09:33:46 -0700
- To: "'John Boyer'" <jboyer@uwi.com>, dee3@us.ibm.com
- Cc: Dsig group <w3c-xml-sig-ws@w3.org>
John/Donald: I agree with Don's view on this. Way too much discussion over the last couple of days has focused on implementation details. Crypto API's all resolve down to signing hashes and good practice (i.e.not breaking underlying padding functions). Every vendor has had to extend theirs over the past year to accommodate CMS. Nothing in signing/verifying XML (that I've seen so far, anyway) makes me think it can't be done with the crypto we already have. --Barb Fox Microsoft -----Original Message----- From: John Boyer [mailto:jboyer@uwi.com] Sent: Friday, April 23, 1999 9:16 AM To: dee3@us.ibm.com Cc: Dsig group Subject: Re: You only want what you want... Hi Donald, >I'm actually quite sympathetic to your desire to be able to fit >Pen Ops security into a secure XML framework. Thanks. >I think its pretty easy. Me, too. >I might actually be able to devote more some effort at looking into and promoting that >if I didn't feel a need to keep fighting off your efforts to >eviscerate other aspects of the prospective standard and obstructing >others from satisfying their requirements. My last email to Rich Himes described how to fit everything in the IETF proposal into the model I'm describing as a signing engine. The model I'm proposing is a relatively small container idea into which the requirements of all of these other people fit. In what way is that an obstruction? > >Do you actually believe there is any substantial difficulty in just >sticking a Pen Ops blob and Pen Ops algorithm identifier in the >obvious fields in Richard Brown's proposal? There's nothing wrong with Richard Brown's proposal. This isn't about PenOp at all, this is about a model that supports packaged crypto-engines, of which the package suggested by the IETF proposal could be one. If you think that the IETF proposal in its current state could support this generalized idea, could you please show me how? The Rich Himes email gives an idea of what I'm talking about. How do you do it under the IETF proposal? > >Why the hell are you trying to push out cryprographic signatures >indefinitely when 3/4 of the people (at least of those surveyed >at the IETF BoF) think its urgent to get them standarized in >calendar 1999? >Do you think the IETF/W3C standards process would >take a year to standarize the content free skeleton you want? >If so, what do you base such a belief on? Someone previously on this list mentioned an 18 month window for the things you're talking about now. I would have preferred to say 6 months for the framework I'm talking about, but I did not want to be too presumptuous of others' time. Set whatever time frame you like. The only question is do you think it is possible in some way... in any way THAT YOU WANT... to accommodate attaching to crypto packages? As for signature expressed in XML, I am not "the hell" trying to push out crypto signatures indefinitely. I am trying to decouple signing XML from the requirement to be limited to only certain technologies that can be envisioned today. If as you say (and I believe it and would count myself in this camp), 3/4 of the people are interested in expressing signatures in XML, then you will have no shortage of people to work on the XML signature module in parallel such that there is no delay other than the delay we've had so far in trying to figure out whether we want the model I'm talking about-- which incidentally is not a delay since we don't even have a working group yet! > >Please fight for what you need and don't fight to thwart others >from getting what they need. As I said before, I don't see the thwarting part happening here. Every idea in the IETF proposal can be looked it as part of a signing engine that could be supported by a framework that attaches to cryptographic packages as they are created. Thus, the rhetorical question becomes, what is really getting thwarted here? Unless the IETF draft or similar proposals can support a model of attaching to crypto packages in general, then the ability to use all existing crypto software packages like the current Microsoft CryptoAPI, like Netscape, like Entrust, is what is getting thwarted. I'm new to this scene so maybe I just don't understand the IETF spec well enough to see how to do what I'm talking about. John Boyer Software Development Manager UWI.Com -- The Internet Forms Company jboyer@uwi.com > >Donald > >Donald E. Eastlake, 3rd >17 Skyline Drive, Hawthorne, NY 10532 USA >dee3@us.ibm.com tel: 1-914-784-7913, fax: 1-914-784-3833 > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA >dee3@torque.pothole.com tel: 1-914-276-2668 > >
Received on Friday, 23 April 1999 12:33:42 UTC