W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

RE: You only want what you want...

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Fri, 23 Apr 1999 09:33:46 -0700
Message-ID: <4992824A0863D211964B0008C7B1ACB801DDEC31@FIFI>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 11:28:04 EDT