Re: [legalxml-enotary] Request to add agenda item to upcoming eNotaryTC meeting

[Arshad Noor <arshad.noor@strongauth.com>]

Being the consultant that John refers to in his e-mail, I will
state this in my defense:

While I did, indeed, choose to use the XML Signature (DSIG)
standard for defining the elements within the eNotary XML Schema
Definitions (XSD), there is nothing in DSIG that states you MUST
use asymmetric-key based digital signatures to conform to it.
Indeed, the DSIG standard allows for other cryptographic key-
based signatures within its schema, and that is exactly what I
took advantage of.

The DSIG standard is a good one.  While it is traditionally
associated with PKI/Digital Signatures (in fact, John falls
into that same trap when he assumes that), it is not restricted
to just asymmetric-keys.  It can be used with symmetric keys too
(although there are security issues that must be taken into
consideration when looking at any symmetric key-based signature
standard).

Since DSIG can use any cryptographic key scheme, it made sense
to use such a well-known and accepted standard for the eNotary
specification.  And it does work.  As evidence, the sample XML
files that are included in the zip file sent to the TC, include
two symmetric-key based eNotary documents that conform to the
XSD I've created and which can be validated correctly by XSD
verifiers.

So, it is my contention that I have delivered within the spirit
and terms of the contract, albeit a little later than planned
due to unforeseen communication gaps and new requirements (see
below).  I have also indicated to the subcommittee that I plan
to complete this project well before the originally scheduled
completion date - September/October '08 instead of December '08.

The deliverable has also gone above & beyond the original terms
and it has accommodated two new business requirements not
originally written into the contract:

1) The need to allow existing XML-aware applications to notarize
    documents by adding an element to their schema, rather than
    by wrapping it within an OASIS defined eNotary element.  The
    XSD I've created now allows for both, providing maximum
    flexibility to the industry for new & legacy applications;

2) The need to have multiple notaries notarize a single document
    at different times and places;

It is my goal to ensure that the eNotary standard has the widest
acceptance by creating an XSD that is meaningful to everyone.  In
the spirit of that goal, I have already indicated to the leaders
of the subcommittee, that I will do what is necessary to achieve
that objective.  I will reiterate that sentiment here to the TC.

I believe, discussion around the rest of John's e-mail is up to
the TC.

Arshad Noor
StrongAuth, Inc.


John Messing wrote:
> 
> Unfortunately, despite the contractual commitment the consultant changed
> his mind and decided he did not want to proceed that way. The TC
> leadership has not seen its way to following through on its initial
> vision, with the result that the project implementation dates are
> grossly overdue and a new proposal, based once again on digital
> signature technology, which will likely perpetuate the problems noted in
> a and b above notwithstanding the status of xml dsig as an open standard
> in non-notary settings, has been put forth in its place.
>