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

Fw: XML not better Re: XML versus ASN.1/DER blob

From: John Boyer <jboyer@uwi.com>
Date: Tue, 20 Apr 1999 17:02:26 -0700
Message-ID: <016401be8b8a$3d984690$9ccbf4cc@kuratowski.uwi.bc.ca>
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 EDT

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