RE: Efficacy of current crypto

[Bfox] inline comments below
-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Friday, April 23, 1999 4:16 PM
To: Barb Fox (Exchange)
Cc: Dsig group
Subject: 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?

[Bfox] If by "diverse signing technologies" you mean algorithms, formats
(wrapped, embedded, detached), etc. then I understand and agree that we need
to specify these. This effort should define those applicable to XML. How
these get implemented using specific crypto packages will vary, and that is
not within the scope of this wg.

Where we disconnect  could be a need to define the "highest level of
abstraction" overlying some crypto API. imho: syntax of the signature is the
first requirement of this wg. Abstraction layers for signing (and the
corollary that often gets lost = verification) are generally not included as
a part of a standard. 

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

[Bfox] We have announced support for CMS as have many other vendors. CMS is
just now going to RFC, so there are no shipping products that support it --
yet. However, vendor commitment to extend PKCS#7 for S/MIME v3 is
broadly-based. This is how the standards process works. It takes lots of
work to get it right and then a lot of effort (and time, of course) to build
it. 

My justification for citing CMS as a functional baseline == it's a done
deal. I admit to some inaccuracy in assuming "every" vendor will do it.
That's their choice. The important point I was trying to make tho is that
CMS is the driver for including D-H and DSA along with other CMS goodies in
crypto engines. My recommendation is to acknowledge and in some cases even
assume CMS. 

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.

[Bfox] Just for the record, we do not implement "every" standard : - ) We
pick those which have strong application inertia and more important, those
things our customers care about. 
>
>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.  

[Bfox] We may have another technical disconnect here on what we call "crypto
modules." I still contend that signing/verifying an XML signature does not
require any new crypto modules per se. Signing a hash is independent of how
the hash was constructed. I agree that there needs to be new code, but it's
not immediately obvious how that code needs to be "packaged." I'm sure that
each vendor will have their own approach to this problem.

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

[Bfox] First, crypto is dynamic and what we have already shipped isn't the
final chapter by any means. Second,I believe that this effort should focus
on cryptographic signatures.  

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?

[Bfox] I'm confused -- again about the core crypto requirement. Do you mean
biometrics? Or are you talking about MACs? What's not there now if we keep
the scope to cryptographic signatures? 

[Bfox] == Barbara Fox
Security Achitect, Windows 2000, bfox@microsoft.com
One Microsoft Way, Redmond WA 98052-6399, 425-936-9542 


John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com
>
>--Barb Fox  
>
>-----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 Saturday, 24 April 1999 00:31:53 UTC