RE: XML versus ASN.1/DER blob

Bob,

I certainly do not refute X509 or PKIX. I refute PKCS#7 for encoding the
signature value. PKCS#7 does not address the issues that you have listed -
PKIX and X509 do (to some extent). Also, recall that there are frameworks
that do not even make use of digital certificates - These, for sure, do not
really care about PKIX and X509...

Sincerely,

Richard D. Brown


> -----Original Message-----
> From: Bob Relyea [mailto:relyea@netscape.com]
> Sent: Tuesday, April 20, 1999 4:30 PM
> To: rdbrown@GlobeSet.com
> Cc: dee3@us.ibm.com; w3c-xml-sig-ws@w3.org
> Subject: Re: XML versus ASN.1/DER blob
>
>
>
>
> "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 19:52:04 UTC