[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Comment on spec
Seconded. > -------- Original Message -------- > Subject: RE: [legalxml-enotary] Comment on spec > From: "Mark Ladd" <mladd@pria.us> > Date: Wed, December 10, 2008 2:33 pm > To: "'Arshad Noor'" <arshad.noor@strongauth.com>, "'legalxml-enotary'" > <legalxml-enotary@lists.oasis-open.org> > > > I would think this is something we'll need to run by OASIS's internal legal review. Any comment on this topic will need to be carefully crafted/disclaimed so as not to expose LegalXML or OASIS to any liability should our interpretation be contradicted by future court action - or perhaps by action of the patent holder who might claim some sort of harm based on an implication that the standard cannot be used with the patented technology. > > I don't object to including a comment on this. I just think we owe it to OASIS to allow them to review and comment on what we might include. > > > Mark Ladd > PRIA Consultant > > 262-498-0850 > mladd@pria.us > > > > > -----Original Message----- > From: Arshad Noor [mailto:arshad.noor@strongauth.com] > Sent: Wednesday, December 10, 2008 12:38 PM > To: legalxml-enotary > Subject: Re: [legalxml-enotary] Comment on spec > > 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. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]