Efficacy of current crypto

Hi Barb,

>I agree with Don's view on this. Way too much discussion over the last
>couple of days has focused on implementation details.

Actually, I thought we were focusing on how we were going to design the
markup.
I mean, at the highest level of abstraction, should we have a model that
allows signing XML with diverse signing technologies that don't actually
express the signature in XML.  Is that really an implementation detail?

>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.

I'd like to ask the meaning of "Every vendor" and "has had to extend".  Does
"has had to extend" mean that "every vendor" now supports CMS in released
software?  Does that include Microsoft, and who else besides Microsoft does
"every vendor" include?  I know that Microsoft has enough resources to
implement every standard that comes out, but what's not clear is whether
"every vendor" has followed suit.

>
>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.

Well, obviously I would agree that we can sign XML with current technology
since that's what we do with XFDL.  But I think one of the points here is
that the crypto we already have now would have to get replaced with new
crypto modules that express signatures in XML.  The other point is that it
is at least conceivable that there might be signing needs beyond what is
offered by the crypto we currently have.  This seems to fall into two
categories.  The first is things that don't offer cryptographic strength
security but which offer security that (the vendors would argue) is as good
as paper signature.  Ironically, one such vendor, PenOp, lists Microsoft as
one of its technology 'partners'.  The second category is technologies that
don't use public key.  The IETF draft seems to include such a method because
folks like Donald don't find the public key crypto we already have to be
appropriate in some important applications.  This, in and of itself, is
evidence that the makers of past standards did not create sufficient signing
flexibility to account for these diverse needs that now seem to be
necessary.  What makes us think that we can now write a standard that covers
off every signing need with "the crypto we already have"?  I guess the
question is not where do we want to go to today, but rather where will we
want to go tomorrow?

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com
>
>--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 19:11:53 UTC