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

John,

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.

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?

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:26:50 UTC