Re: [legalxml-enotary] Comment on spec

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

Hi John,

I would concur with you that this topic should be addressed in an
appendix to the specification.  It should be written by an attorney
(IMO), with the right words to assuage any concerns of ENML software
implementers that they may be stepping over the ghost patent.

That said, based on my last (and fast) reading of the patent
description at the PTO, it is my personal belief that the patent
only covers the use of X509-based digital signatures by the Document
Signer *AND* the Notary in the same document.

So, all of the following combinations of signatures within a single
Notarized/Witnessed/Apostillized document are possible, without
stepping on the existing patent (obviously, this is not a legal
opinion, but a technical one):

	Document Signer			Notary Public
	---------------			-------------
1) NULL Cryptographic Signature    +	NULL Cryptographic Signature
2) NULL Cryptographic Signature    +	Symmetric Key Signature
3) NULL Cryptographic Signature    +	X509=based Digital Signature

4) Symmetric Key Signature	   +	NULL Cryptographic Signature
5) Symmetric Key Signature	   +	Symmetric Key Signature	
6) Symmetric Key Signature	   +	X509=based Digital Signature

7) X509-based Digital Signature    +	NULL Cryptographic Signature
8) X509-based Digital Signature    +	Symmetric Key Signature

The only combination that we would not recommend - unless the software
developer chose to pay the patent royalty - is:

    X509-based Digital Signature    +	X509=based Digital Signature

(You will notice, I have deliberately avoided showing any examples
with this combination in Section 2 of the specification).

 From a notarial point-of-view, I see no benefit in having the Document
Signer use a X509 digital certificate, since US Notary law requires
the Document Signer to be present in front of the Notary to acknowledge
their signature or take the oath.  While California allows for
Subscribed Witnesses to sign acknowledgements on behalf of Document
Signers, even they (Subscribed Witnesses) have to be present in front
of the notary for the signing.  So, this fact provides RPs with the
assurance that the Document Signer did, indeed, sign the document.

All that the RP cares for is the validity of the Notary's signature -
and as long as the Document Signer does not use a digital certificate,
we make it possible for the Notary to use any technology - including
digital certificates - for notary signatures (without stepping on the
patent).

So, I would recommend that an attorney on the TC write up the legal
language (using the above-mentioned examples) and provide guidance
to ISVs on their choices.  We can do this even after the document
goes into Public Review, so we don't have to wait on this appendix
to vote on the current spec.  We have to vote on it again after the
Public Review to make it a Committee Specification, so we can use
the 60-days in PR to write up this appendix.

Arshad


John Messing wrote:
> Arshad et al.:
> 
> I think this is a fine work. I do have one concern and I do not know
> where it should be addressed; i.e., within the spec or in a
> non-normative document annexed to it.
> 
> The concern is that there is insufficient explanation of the
> cryptographic IPR constraints and that in the absence of a suitable
> explanation, confusion and avoidance of the standard may ensue. For
> example, digital signatures are discussed in the context of Apostilles
> but not notarizations, where symmetric signatures predominate, but there
> is no explanation to guide the user of the standard that I could find. 
> 
> I think we need to make clear that the methodology for cryptography is
> intended to be all-inclusive but the ghost Arcanvs patent was a
> constraint by virtue of OASIS IPR policy that prevented us from
> including specific markup and examples of notarizations involving
> classic PKI solutions (which did not also apply to Apostilles, hence the
> difference); PKI solutions, however, should be rather trivial to adapt
> by appropriate extensions to the standard for those who so desire and
> are not concerned with the existence of such patents or possible
> infringement of them; a specific grant of a royalty free license for
> symmetric signatures was granted to the TC and through it to appropriate
> users of the standard for symmetric signatures on notarizations; and for
> that reasons, many of the examples refer to symmetric signatures and not
> to classic digital signatures. However, the overall methodology should
> not deter anyone with a desire to use classic cryptography in the
> context of the standard, whatever its basis, without regard to possible
> IPR, and otherwise incompatible cryptographic methods should be
> employable as a technical matter interoperably by virtue of the overall
> structure of the mark-up language.
> 
> I hope this is sufficiently clear.
> 
> Best regards to all.