RE: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) - PDF(ENML-1.0-Specification-DRAFT2.pdf) uploaded

["John Messing" <jmessing@law-on-line.com>]

If I understand the point correctly, the Reference element is a form of
metadata that by itself is intended to allow someone to inspect the raw
XML and determine what was signed without also having to
cryptographically confirm the signature. If that is what we are talking
about, from a legal/forensic point of view, I think I would allow the
embedding of X-Path statements and issue a cautionary note that the
metadata should be double-checked with a cryptographic confirmation for
all mission critical matters.

> -------- Original Message --------
> Subject: Re: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT
> 2) - PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> From: Arshad Noor <arshad.noor@strongauth.com>
> Date: Thu, December 11, 2008 11:43 am
> To: legalxml-enotary@lists.oasis-open.org
> 
> 
> John,
> 
> One clarification in your description in the second paragraph:
> 
> ENML would NOT include any XPath expressions. At least, that is
> what I'm recommending in Appendix D; but, of course, as with 
> everything in a standards group, my recommendation can be over-
> ridden by a TC vote.
> 
> The reason why I am OK with the use of XPath for processing XML
> (as you correctly described in the first part of your second para)
> and, at the same time, against embedding XPath expressions inside
> ENML documents, is simply because the current specification allows
> for printing raw ENML and allowing human beings to identify what
> was signed by reading the <Reference> elements in the <Signature>
> block.  Even though, humans will be unable to cryptographically
> verify the <SignedDocuments>, <DocumentSigners> and 
> <NotaryCertificates> visually, they can at least identify the
> specific elements that are covered by the <Signature> element
> through the explicit ID values for each element.
> 
> With XPath, you run into the problem that different software can
> choose any search string and "sign" the result.  Depending on the
> XPath library implementation (which may or may not work consistently
> with other XPath library implementations), one cannot tell visually
> what the <Signature> block refers to in a signed document.
> 
> The explicit <Reference> elements leave no doubt about what was
> signed.
> 
> However, as I stated earlier, the fact that ENML may not contain
> XPath search expressions for what was signed, does NOT prevent
> software developers from using XPath in their applications, even
> when using ENML and/or searching for specific elements within an
> ENML document.  The only part of their software that will care
> about the <Reference> elements is the XMLSignature library that
> verifies the <Signature> element.  And, almost all ENML software 
> vendors will most likely use the Apache XML Security library; I
> don't believe any of the PRIA/MISMO sotware vendors will write 
> their own XMLSignature library when a free, open-source, reference-
> implementation is available from Apache.
> 
> I don't believe this is a major issue for programmers; I am more
> than happy to talk to anyone that has specific concerns about it.
> It is my personal belief that being simple and explicit will help
> avoid confusion in courts in the future - but once again, this is
> my opionion, which can be over-ridden.
> 
> Arshad
> 
> 
> ----- Original Message -----
> From: "John Messing" <jmessing@law-on-line.com>
> To: "Arshad Noor" <arshad.noor@strongauth.com>
> Cc: legalxml-enotary@lists.oasis-open.org, "Mark Ladd" <mladd@pria.us>
> Sent: Thursday, December 11, 2008 7:03:10 AM (GMT-0800) America/Los_Angeles
> Subject: RE: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) - PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> 
> I think there may be consistency between ENML, MISMO and PRIA specs,
> even with X-Path if I understand the workflow correctly.
> 
> I can see where MISMO and PRIA would make use of X-Path to enable
> contracting parties to select from a large number of potential clauses
> and possibilities in the document generation and tweaking process. ENML
> would enter the picture only after that process were complete and the
> finalized documents were ready for execution. ENML then would
> cryptographically sign and notarize the finalized loan/mortgage
> documents including their X-Path statements. What could not happen
> afterwards is a change via X-Path in the finalized and executed mortgage
> and note documents.
> 
> Recording information would probably be added later, outside of the ENML
> notarizations, and therefore should not affect the integrity of the
> signed and notarized documents. So long as the cryptographic signatures
> were not affected by the later-occurring events involved in recordation,
> then the various standards should complement each other and these
> workflow processes. Only in the event that recordation affected the
> integrity of the already completed and cryptographically signed
> documents would I envision a problem, as where a recording stamp were
> "added" to a notarized deed of trust, but I assume that such a recording
> stamp could be constructed as a digital wrapper around the notarized
> deed of trust, including the ENML notarization and its cryptographic
> protections, which to a human reader would look indistinguishable on a
> monitor from a rubber stamp on paper that is encountered in the paper
> world.
> 
> Hope this helps.
> 
> > -------- Original Message --------
> > Subject: Re: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT
> > 2) - PDF   (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> > From: Arshad Noor <arshad.noor@strongauth.com>
> > Date: Wed, December 10, 2008 2:48 pm
> > To: Mark Ladd <mladd@pria.us>
> > Cc: legalxml-enotary@lists.oasis-open.org
> > 
> > 
> > Mark,
> > 
> > I just want to clarify that developers are free to use XPath in
> > their applications with the use of ENML; the only thing we would
> > forbid is the storage of XPath expressions *inside* ENML documents.
> > 
> > So, it is perfectly possible for an ENML-conformant application
> > to use XPath for everything - including manipulating the ENML
> > itself during processing; but when it comes time to saving the
> > ENML into a Notarized/Witnessed/Apostillized document, the
> > application should not store XPath expressions in the ENML; rather,
> > it should use only the standard <Reference> elements as outlined in
> > the spec.
> > 
> > While this may cause some developers a little grief, I think this
> > price for avoiding legal headaches in courts is well worth it.  It's
> > not as if software developers don't have other effective tools to
> > address the problem - I know from experience.
> > 
> > Arshad
> > 
> > Mark Ladd wrote:
> > > I apologize for being tardy in my review of these latest drafts.  I also apologize that it appears I overlooked Appendix D in my earlier reviews, as I would have raised my concerns here earlier.
> > > 
> > > I am aware that there is a great deal of emphasis on XPath in the upcoming Version 3 MISMO & PRIA standards.  I am not certain, however, if the proposed exclusion of XPath in ENML presents any specific barriers to adoption of the eNotary standard by developers who build applications for the mortgage and recording industries.  I need to look into this and will report back (promptly).
> > >   
> > > 
> > > Mark Ladd
> > > PRIA Consultant
> > >  
> > > 262-498-0850
> > > mladd@pria.us 
> > >  
> > >  
> > > 
> > > 
> > > -----Original Message-----
> > > From: arshad.noor@strongauth.com [mailto:arshad.noor@strongauth.com] 
> > > Sent: Monday, December 01, 2008 10:09 PM
> > > To: legalxml-enotary@lists.oasis-open.org
> > > Subject: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) - PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> > > 
> > > ENML 1.0 (DRAFT 2) in PDF.
> > > 
> > >  -- Arshad Noor*
> > > 
> > > The document named ENML 1.0 Specification (DRAFT 2) - PDF
> > > (ENML-1.0-Specification-DRAFT2.pdf) has been submitted by Arshad Noor* to
> > > the OASIS LegalXML eNotarization TC document repository.
> > > 
> > > Document Description:
> > > DRAFT 2 of the eNotarization Markup Language 1.0 Specification in PDF.
> > > 
> > > View Document Details:
> > > http://www.oasis-open.org/committees/document.php?document_id=30238
> > > 
> > > Download Document:  
> > > http://www.oasis-open.org/committees/download.php/30238/ENML-1.0-Specification-DRAFT2.pdf
> > > 
> > > 
> > > PLEASE NOTE:  If the above links do not work for you, your email application
> > > may be breaking the link into two pieces.  You may be able to copy and paste
> > > the entire link address into the address field of your web browser.
> > > 
> > > -OASIS Open Administration
> > > 
> > > 
> > 
> > ---------------------------------------------------------------------
> > 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