RE: XML versus ASN.1/DER blob

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
>

Received on Tuesday, 20 April 1999 15:16:36 UTC