Re: Fw: XML versus ASN.1/DER blob

>I don't think we need to address signature schemes based on
>autographs

For starters, most have misunderstood the notion of "autographs".  The 'pen'
people don't simply mean a bitmap.  They take lots of measurements that
describe a person's signing characteristics, combine that with a sha-1 or
md5 hash of the document, and encrypt the result.  You can ask to have the
bitmap added, but this is a convenience.

I agree that we don't need to address autograph signature schemes because I
think that perhaps we should not be addressing signature schemes at all.
Anything that can conform to the interface Sign(), Verify() and a few other
functions should be allowed to sign XML.  If we dig too deep into the
internal structure, then we forced signed XML to have knowledge of signature
technologies, which constrains the spec to what we can conceive of now.

Ironically, the Richard Brown proposal is really saying that already they
can conceive of security needs beyond today's standards.  So they've added
some new tags into the signed XML framework to address these security ideas.
In and of itself this is evidence of the ongoing problems we will have as
new security ideas emerge.  What they're really saying is that the creators
of previous security standards didn't account for every security need.  It
is presumptuous of us to think that we could do a better job of coming up
with a set of tags that describes all security needs going forward.

We could simply tolerate lots of spec changes over time, as well as the
software upgrades, backwards incompatibilities, frustrations and costs that
go with that, but it is not necessary to have these problems.  We could
write a standard now that will be compatible with all signature technologies
going forward by simply *not* addressing particular signature schemes at
all.  This also has the happy benefit of not requiring that a compliant
implementation *must* be bundled with cryptographic code.

I've been using handwritten signatures as another example of a technology
that needs to sign XML that this group had not previously considered.
Richard Brown's proposal contains another example of signing that was not
accounted for by previous standards attempts.  Recently, Ko Fujimura posted
an email stating that  the digital ticket system had needs that were not
based on PKI.  I can't think of any other examples of new technologies that
might emerge, but this is precisely the point.

Since we cannot imagine all signature technologies of the future, our spec
should do as little as possible to try interpreting that binary blob
representing the signature.  'Something' will show up between the Value
start and end tags.  Whatever it is was generated by the signing engine
given in the manifest (which itself got signed), and that signing engine (or
equivalent equipment) will know how to verify it.

Any new security ideas should be expressed in a new security framework spec.
Signed XML markup itself should be as simple as possible.

Now we come to a useful distinction between markup versus semantics.  I will
address this issue in another post entitled "Markup versus Semantics".

>1) The packing format had better allow any signature scheme
> which produces as authentication data a string o' bits
> which is a function of the message and optionaly some
> additional data.
>
> There are good reasons for allowing an SHA-1 hash or an
> HMAC authentication blob, biometrics should be simply
> another such blob.

I agree in principal.  I don't know from this where you plan to put it.  In
the context of the Richard Brown draft, I'm talking about what goes into the
<Value> tag.  The biometric token could go there, or we could have a PKCS7
blob containing the encrypted hash plus signer's certificate, or we could
have as yet unforeseen data types.

That particular statement I just made about the nature of the PKCS7 blob
will be further qualified in the upcoming email "Markup versus Semantics"

>
>2) Do we think we have a need for significant input of crypto
> expertise? I don't think so, at this level we are treating
> PKCS#1 RSA, DSS etc as well behaved black boxes.
>

I agree with you.  We should stay as far away from the specific algorithms
used by the signing technology as possible.  Rely on, leverage their
standards.  Let them create the standards, let us integrate to modules to
that support those standards.

> If we feel we can proceed without detailed instructions along
> the way from Rogaway, Rivest, Kaliski et al we whould expect
> autograph identification methods to be capable of being
> treated in an equally black box fashion.
>

Absolutely.  To wit, I have no idea to this day how effective particular
handwritten technologies are at actually identifying the signer.  I think it
is possible in theory for the technology to do a better job than a
handwriting expert.  The reason is that a handwriting expert performs
"forensic" analyses on a completed signature, comparing it to writing
samples.  Most of the parameters of an electronic handwritten signature
measure the live act of signing, comparing it to writing samples that also
include the same parameters that measure the live act of signing.

>3) Biometric techniques are not commodified to the same extent that
> RSA, DSS etc are. Patent issues aside, RSA is RSA whoever you
> buy it from, same for DSS. Even the more 'exotic' reaches
> of cryptography such as eliptic curve are well defined and
> standards defined.
>
> I don't think it would be possible to address biometric
> techniques without addressing specific proprietary techniques
> which would in turn lead to the issue of endorsement which
> I don't think W3C should get involved in - not unless they
> want to actually conduct trials of biometric techniques which
> I don't think they do.
>

This is RIGHT ON THE MARK!  There are no standards for pen-based signature
technologies yet.  To us, it is just a different signing engine.  I don't
really even care whether they are doing biometrics or not.  The point is
that for each signing technology we write small interfaces that offer
Sign(), Verify() and a few other functions, then the "glue" code figures out
how to call the particular technology.  The glue goes into a DLL, the new
DLL is sent out, and suddenly a new signing engine is supported and we don't
have to replace our viewer, our language API, nor our core specs.

>4) The applications of biometrics and the applications of digital
> signatures are disjoint. I do not see an overlap, I consider
> biometrics important precisely because they can do things
> which digital signatures cannot.

This depends on your definition of digital signature.  The pen people look
at digital as 'electronic' as opposed to paper, and they look at the word
signature in the legal sense.  A signature is that which is affixed to a
document to represent authentication and authorization.  On paper,
authentication is quite implicit since for millenia we have not had the
technology to substantially alter a document without damaging the paper.
So, authentication was as simple as the signer looking over the document
before scribbling on it.  Authorization means that the signer agrees to the
statements being signed, which is quite context sensitive.  However,
authorization implies the ability to identify the signer.  A handwritten
signature on paper does this.

The pen people's biometric tokens are encrypted blobs containing biometric
measures of the act of signing as well as a sha-1 or md5 hash of the
document being signed.  The biometrics identify the signer, the act of
signing implies authorization (same as paper), the hash authenticates the
document content, and the encryption binds the two together.  The pen people
claim that this signing technology offers an electronic solution that is at
least as secure or substantially more secure than the paper signatures that
we currently accept.

> At most a biometric proves is that there was knowledge of a
> biometric profile required to create a signature. That is very
> different to the assurance of a digital signature which establishes
> that there was knowledge of a specific piece of information.

On behalf of the pen people, I'd like to disagree with this.  This is
actually what I meant about there being misunderstanding about handwritten
signature technologies.  These people actually are trying to bind the
document content to the signer in the way described above.  The hash of the
document in the biometric token provides the authentication that there was
knowledge (or at least availability) of a specific piece of information.
The biometric measures are only used to associate that information with a
particular person.

>I know there are folk in the biometric industry who dispute this, and that
>is kind of the point. I don't think the argument is usefull or necessary
>however. It is currently raqging with much FUD in the legal arena. I don't
>think we need to have the arguments rehearsed here too...

I've provided all this information because I think it is important for
people to understand this technology as a good example of the fact that we
can't anticipate what the future holds in terms of signing technologies.
Hopefully, we will create a spec that does not have to change every time a
new signing technology is created.

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

>
>
> Phill
>
>
>

Received on Wednesday, 21 April 1999 13:20:32 UTC