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 16:23:20 UTC