Unblobbing Re: XML Gets Blobbed

Hi Richard,


>
>     John,
>
>     I like the generality and simplicity of your solution, but I have a
>     few questions which will help me understand the position you are
>     proposing. Suppose that a future developer or standards committee
>     decided to express a signature and its descriptive parameters in XML
>     which, AFAIK, is a good idea.  Under your proposal, would the XML
>     digital signature fragment have to be "blobbed" (base64) so that it
>     would become a black box to the XML parser/application?

Thank you, and yes I think it is easy to support the unblobbed version of a
signature.  Up to now, every XFDL signature has had to undergo base 64 but
that was only because the Sign() function in all of the current technologies
return a non-XML binary block of data.  If the underlying signature engine
returns a black box that happens to be XML, then we can just put the
returned blob into the <value> tag in the clear because XML supports.
Perhaps we should work from something vaguely like this:

<signature>
    <engine>Microsoft CryptoAPI</engine>
    <provider>DataKey SmartCard</provider>
    <encoding>pkcs7</encoding>
    <params>alg="RSA"; hash="sha1"; certs="signeronly"; ... </params>
    <resources> ... </resources>
    <value></value>
</signature>

Obviously there's a lot more to it than this, and there's a lot more to it
than just defining the markup (like specifying what it takes to be a
signature module, what exactly gets passed to a signature module, and maybe
what demographic data should come back from Verify(), etc.).

When a signature is created, the result is stuffed in the value tag.
Naturally, to verify, the message will be converted back to the empty
<value> tag since the value was empty when the message was signed.

The <encoding> could control whether we base64.  If it's content is "xml",
then we expect the Sign() function to generate XML, so we just put it in
<value> in the clear.  If it is anything else, then base64 it.  The encoding
can also serve a second purpose, which is that during the verify, if the
particular engine and provider specified are not available, then it a verify
may still be possible with other equipment that understands the same
encoding format.  For example, if we start with a Netscape signature, but
the verifier uses Internet Explorer, then we run the verify with CryptoAPI
because it understands the Netscape blob (and vice versa).

Also, I know it's enticing to consider writing the content of <params> as
XML.  But leaving it as PCDATA is useful for a number of reasons.  First, we
want to just pass it off as a string to the signing engine.  Rather than
having to wrap an XML parser into the signing engine, we can use the few
dozen or so lines of code it takes to parse a block of MIME parameters.
Also, we avoid the whole DTD namespace issue, so the DTD describing the
signature element doesn't have to change every time we want to add a new
technology (it still won't anwser the first issue, but out of curiousity,
could one of you namespace demigods comment on whether there is a workaround
for this?).

Finally, adding a new signing engine is done by creating a spec that
declares the new engine and provider names, the encoding type, and the
params.  Somebody creates an implementation, and the result is an
independent module that can be thrown at the reference signed XML
implementation and suddenly start working without changing the signed XML
framework at all.

>
>     Could we consider the XML fragment itself as the black box, that is,

Yes exactly, I should've read farther before waxing...

>     it could be passed to an intermediate engine which would determine
>     whether it contains a well-defined (current practice) blob or whether
>     it needs to generate such a blob from information in the fragment?  I
>     know this raises DTD issues, but we should be able to work around
>     them, perhaps with name spaces.

Or just use a qualifying tag, or even an encoding attribute if the group
prefers it.

>
>     I believe it makes sense to define signatures in XML if we can be
>     assured that we aren't opening up new security holes.  Also, I don't
>     know if that work is appropriate for this group, but I don't think we
>     should discount the possibility.
>

I think the group of people working on this will do a fine job of expressing
signatures in XML (except of course those odd ones like biometrics which
rely on the unreadability of the blob to lock the hash and biometrics
together).

I'm advocating a two-tier approach where some of us work on a signed XML
framework while others more qualified than I work on expressing the
signatures in XML as a new crypto standard.  I think this is a way to get
signed XML off the ground within 12 months.  It will be able to easily
integrate with existing crypto packages, and signatures will be
interoperable to the extent that the packages are interoperable (in other
words, to the extent that they understand each others encodings).
Furthermore, once a new XML signatures standard happens, it can be plugged
in as another signing engine.

Thank you,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

>     Thanks,
>     Rich Himes <rhimes@nmcourt.fed.us>
>
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: Single Key in Originator Information
>Author:  w3c-xml-sig-ws@w3.org at ~Internet
>Date:    4/21/99 6:34 PM
>
>
>
>
>>Signing XML is not a fundamental and different problem.  We have many
>>worked examples to learn from like: X.410, X.509, PEM, MOSS, DNS Sec,
SDSI,
>>SPKI, PGP, DMS, and DSig 1.0.
><snip/>
>>So, hopefully we will be able learn from these past efforts.
>
>Signing XML is a fundamentally different problem.  We do not need to learn
>from these past efforts if we do not try to duplicate them, as would be the
>case if signed XML meant "sign XML then express signature in XML".  Signing
>XML only requires us to define an interface to call upon these
technologies.
>As the cryptography experts learn from their past efforts and put out new
>standards, our interface will be able to call on the technology that
>implements the new standards.  All without changing our spec, DTDs, and
>software.
>
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>jboyer@uwi.com
>
>
>

Received on Thursday, 22 April 1999 19:19:54 UTC