- From: John Boyer <jboyer@uwi.com>
- Date: Tue, 20 Apr 1999 17:02:26 -0700
- To: "Dsig group" <w3c-xml-sig-ws@w3.org>
>Hi Richard, > >If you have time, would you have a closer look at how XFDL signs documents? >It would answer a lot of questions. The email I just posted also explains >things further. Finally, I have a few more comments below. > >> >>I am not sure that I understand what you mean by "I do think we will have >>the most generalized solution by making them just binary blobs..." >Somewhere >>you need to identify the algorithms and the keying material used for >>signature computation. If not, how could you verify the signature? >Actually, >>identifying the algorithms and the keying material may not be always >>sufficient. Some signature values such as DSA consist of multiple values >>that need to be encoded in a well-defined way. > >In XFDL, we use our sign format to specify things like the hash algorithm >and the signing engine. The engine specifier would have a string that >identifies, for example, the Microsoft RSA Base cryptographic service >provider or the PenOp handwritten signature engine, or Netscape or Entrust. >Each of these systems has varying levels of support for existing >cryptographic standards. The Microsoft CryptoAPI, for example, is a >generalized interface that hands over the actual security operations to >cryptographic service providers, many of which are manufactured by 3rd >parties. > >The point is that I call something like CryptSignMessage(), and the >CryptoAPI hands me back a binary blob, a black box. That black box has all >of the information needed by CryptVerifyMessageSignature(). I don't care >what they put in it. To me, it's an integration to a technology. If >CryptoAPI is secure, then so are we. In general, our security relies solely >on the security of the underlying signature technology. All we do is >receive a blob and store it base-64 encoded in an element. At verification, >we know the engine to call (which we incidentally force to be part of the >message that got signed, just as you do), and the engine's verify tells us >whether it thinks the document has changed. > >You may feel that PKCS#7 and CMS don't cover every security application >that your spec covers, but I think we need to modularlize the design. If >you have new and better signature techniques, then write a new cryptography >standard and write new modules that support them. You can even make your >new security module exchange blobs that contain XML. > >The idea that I'm suggesting is that you must have a signature engine that >have sign and verify working together. Further, anyone hoping to verify >that signature must have the same signing engine. What you are talking >about is writing a standard so that "everyone" can verify a signature once >created. What I'm saying is that if this is your goal, then an >implementation must necessarily include a cryptographic implementation (or >at least the verify part). Since verification requires modular >exponentiation, an organization like the W3C will not be able to create a >compliant reference implementation that it can freely distribute to the >world. > >> >>I may agree with you if "binary blob" means that algorithms and keying >>material identification as well as signature value encoding do not need to >>be disclosed in the XML element and could be sealed in the signature value. >>But, this does not preclude the fact that the XML-DSIG specification should >>adopt a unique set of rules for producing this "binary blob". And as far as >>I know, PKCS#7 or CMS are insufficient for addressing all the requirements >>listed in the proposal - so which syntax should we adopt? If something new, >>why can't we suffice with the current proposal? >> > >This is because some of the requirements are not requirements of signed XML >but are rather security requirements of applications. These should be >addressed by more advanced security modules. The signed XML spec should >simply be able to interface to that new security module. > >I don't think we should adopt any particular syntax for the binary blobs >that represent signatures. Well, that's a bit of an overstatement since >their are some necessary guidelines to prevent security holes, but the >guidelines I'm thinking of are not too numerous or technical (that's why >it's only a *bit* of an overstatement). > >The security engine specified in the parameters will create a data structure >that it, presumably, can verify. I know that since XML is a hammer designed >to represent data structures, the temptation is great to see the signature >as a nail, but I've given numerous good reasons in the past posts and above >for not doing this. As long as the verify does detect change, the system >works. You cannot verify without the specified engine (or an equivalent). >To make this a requirement is to require a compliant implementation to >provide the cryptography. > >John Boyer >Software Development Manager >UWI.Com -- The Internet Forms Company >jboyer@uwi.com > > >>Richard D. Brown >> >> >>> -----Original Message----- >>> From: John Boyer [mailto:jboyer@uwi.com] >>> Sent: Tuesday, April 20, 1999 3:27 PM >>> To: Alan Kotok; rdbrown@GlobeSet.com; relyea@netscape.com >>> Cc: Dsig group >>> Subject: XML not better Re: XML versus ASN.1/DER blob >>> >>> >>> Hi Alan, Richard and Bob, >>> >>> I'm actually mostly in agreement with Bob's point. I don't >>> think that data >>> types 1 and 2 should be PKCS#7 blobs, but I do think we will >>> have the most >>> generalized solution by making them just binary blobs generated by the >>> underlying signature equipment, which need not even be >>> cryptographic in >>> nature. A function interface that expresses the signature >>> needs of signed >>> XML need not be much more than a dozen functions. For each >>> new signature >>> technology, UWI writes the same function interface, calling the >>> functionality of the given technology to achieve the >>> essential purposes of >>> those functions. As long as the blob coming out of the sign function >>> actually correctly measures change in the document when the blob and >>> document are passed to the verify function, we do not care >>> what format that >>> data takes. >>> >>> To wit, the better handwritten signature technologies achieve >>> at least a >>> modicum of security by encrypting the blob. It is contrary >>> to the needs of >>> this signing technology to put its internal content in a >>> human readable form >>> such as XML. >>> >>> John Boyer >>> Software Development Manager >>> UWI.Com -- The Internet Forms Company >>> jboyer@uwi.com >>> >>> >I agree! >>> > >>> >Alan >>> > >>> >At 03:16 PM 4/20/99 , Richard D. Brown wrote: >>> >>Bob, >>> >> >>> >>Sorry, but I do not understand why "Data types 1 and 2 >>> SHOULD BE PKCS#7". >>> At >>> >>the very least, one could argue that a PKCS#7 detached >>> signature could be >>> >>assumed as "some form of a signature scheme", but it SHALL >>> NOT BE the >>> unique >>> >>format. >>> >> >>> >>The argument developed at the WG did not make a lot of >>> sense to me "We >>> >>should use PKCS#7 for encoding the signature value because >>> this is how >>> >>Netscape's and other's toolkits are built..." PKCS#7, CMS, >>> and others >>> >>cryptographic toolkits rely upon some cryptographic >>> primitives such as >>> DSA, >>> >>RSA, etc... We shall make sure that we leverage this >>> legacy, but this >>> >>doesn't mean that we should adopt PKCS#7 or CMS for >>> encoding the signature >>> >>value. It simply means that we shall limit compliance >>> requirements to a >>> >>well-established set of cryptographic primitives. >>> >> >>> >>Sincerely, >>> >> >>> >>Richard D. Brown >>> >>Software Architect - R&D >>> >>GlobeSet, Inc. Auctin, TX - U.S. >>> >> >>> >> >>> >> >>> >>> -----Original Message----- >>> >>> From: w3c-xml-sig-ws-request@w3.org >>> >>> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of Bob Relyea >>> >>> Sent: Tuesday, April 20, 1999 12:12 PM >>> >>> To: dee3@us.ibm.com >>> >>> Cc: w3c-xml-sig-ws@w3.org >>> >>> Subject: Re: XML versus ASN.1/DER blob >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > (3) XML Signature Syntax. There appears to be controversy >>> >>> here. Some want >>> >>> > to start with CMS/PKCS#7 but map it into XML syntax and >>> >>> extend it to meet >>> >>> > the requirements, presumably resulting in something like >>> >>> the Richard Brown >>> >>> > proposal. Others want to just use a PKCS#7 binary blob. >>> >>> > The blob approach loses all of the transparency and >>> >>> extensibility of >>> >>> > XML. It is not clear that it can meet the requirements for >>> >>> support of >>> >>> > keyed hashes. You are locked into having two mutually >>> alien sets of >>> >>> > encoding/decodig logic: XML and ASN.1/DER. >>> >>> >>> >>> So there are a couple types of data that will wind up in XML >>> >>> signatures: >>> >>> 1) binary data -- the actual signature itself is some >>> >>> form of binary >>> >>> encoding. It will have no meaning to an XML application >>> >>> itself. This also >>> >>> includes things like X.509 certificates. >>> >>> 2) data the underlying security system needs to verify >>> >>> the signature. >>> >>> 3) data the XML application needs to to interpret to >>> >>> complete it's task >>> >>> (authentication, authorization, semantic meaning of the >>> >>> signature, etc). >>> >>> >>> >>> Data types 1 and 2 should be PKCS #7 blobs. Data types 3 >>> >>> should be XML. The >>> >>> resulting document should be an XML document with imbedded >>> >>> PKCS #7 blobs. >>> >>> >>> >>> The issue comes when the the data overlaps (both the >>> >>> underlying security system >>> >>> AND the application needs the data). Even worse is the case >>> >>> where the data is >>> >>> somehow imbedded in the X.509 Certificate. The Certificate is >>> >>> already a binary >>> >>> object. They are not cannonicalized objects... who arbitarily >>> >>> cast them into >>> >>> XML and still verify their signature. If an application need >>> >>> to access the DN >>> >>> in the cert, or some certificate extension in order to do >>> >>> it's work, the >>> >>> application will necessarily need to cooperate with the >>> >>> underlying security >>> >>> system to get these functions. You could define XML copies of >>> >>> these fields, but >>> >>> there would be no way of verifying these fields were correct >>> >>> (other than asking >>> >>> the underlying security system if they matched). >>> >>> >>> >>> This means that we need to define how XML applications can >>> >>> get access to >>> >>> non-XML objects anyway. >>> >>> >>> >>> > >>> >>> > On the other hand, wtih XML syntax as show in the >>> Richard Brown >>> >>> > proposal, you do have the readability and extensibility >>> >>> that are goals of >>> >>> > XML. >>> >>> >>> >>> I don't see anything wrong with the base structure of >>> >>> Richard's proposal. We >>> >>> just need to spend the time to hash out what specifically >>> >>> shows up as XML tags, >>> >>> what shows up in PKCS #7 blobs, what shows up in both, >>> and how do XML >>> >>> applications get to stuff in the PKCS #7 blob, and what shows >>> >>> up in both. >>> >>> >>> >>> > >>> >>> > Quite frankly, if you go with the blob, I don't see >>> >>> any justification >>> >>> > for calling the result an XML digital signature. >>> >>> >>> >>> Any more than MIME considers the PKCS #7 blob at the end of >>> >>> an S/MIME message a >>> >>> MIME signature? It's a MIME signature because it signs a mime >>> >>> document, and is >>> >>> bundled in a package. You can spit this thing out to a >>> >>> standard MIME reader and >>> >>> it will do something reasonable with it. XML should be >>> the same thing. >>> >>> >>> >>> bob >>> >>> >>> > >>> >_____________________________________________________________ >>> ______________ >>> >Alan Kotok, Associate Chairman >>mailto:kotok@w3.org >>>World Wide Web Consortium >http://www.w3.org >>>MIT Laboratory for Computer Science, 545 Technology Square, Room >NE43-409 >>>Cambridge, MA 02139, USA Voice: +1-617-258-5728 Fax: >+1-617-258-5999 >>> >> >
Received on Tuesday, 20 April 1999 19:58:20 UTC