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

Re: XML versus ASN.1/DER blob

From: Bob Relyea <relyea@netscape.com>
Date: Tue, 20 Apr 1999 14:29:53 -0700
Message-ID: <371CF1D1.8028DFA2@netscape.com>
To: rdbrown@globeset.com
CC: dee3@us.ibm.com, w3c-xml-sig-ws@w3.org


"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.

So maybe I should have been more clear... While it doesn't necessarily have to
be a unique, but it should be defined. You need to define something to make this
deployable, and you need to define something that will actually work out of the
box.

If the standard goes out with "this is how you do

>
>
> 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.

Do not assume that doing the modular decrypt of a hash is all there is to
verifying a signature. You have to get the key from somewhere. You have to
verify that that key is bound to something. You have to make sure that something
has not been revolked. There is a whole security infrastructure that has taken
4+ years to build. There is still more work to do. It's more than just PKCS
#7... there's PKIX.

If you want to go off on you're own and invent a whole new security
infrastructure, build XML versions of Certs, CRL's, Key packages, etc. Then that
should be a separate working group, and when you have that in place you can
think about how an XML only security infrastructure would work in an XML
document.

In the mean time, we should define how this stuff works with standard existing
security infrastructures, work on the mechanics of getting the right information
to the XML application, and leave the thorny security issues to PKIX for the
first round.

bob

>
>
> 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 17:30:36 EDT

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