RE: XML versus ASN.1/DER blob

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 15:57:57 UTC