Re: Use of containers for non-XML documents

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

You are technically correct, John; DSIG does not mandate
what can be signed.

Speaking from an implementers point of view, I would state
that while signing binaries is less expensive on computer
resources, I would recommend mandating that all content be
Base64-encoded in the NotarizedDocument container.

NotarizedDocuments will be e-mailed, transferred over FTP,
HTTP and likely many other protocols.  Having embedded
documents be Base64-encoded takes one worry away from all
downstream applications and users - the content can be
universally transmitted anywhere by any application.

This is a detail that must be documented in the Specification
(one of my deliverables in Phase 3) and voted on by the TC
eventually.

WRT the second point, the XSD has an element called
"NotarizationActType" that allows applications/tools to
provide this choice at run-time:

     <xsd:simpleType name="NotarizationActType">
         <xsd:annotation>
             <xsd:documentation>
                 A code list that enumerates the types of notary acts.
             </xsd:documentation>
         </xsd:annotation>
         <xsd:restriction base="xsd:token">
             <xsd:enumeration value="Acknowledgment"/>
             <xsd:enumeration value="Jurat"/>
             <xsd:enumeration value="Other"/>
         </xsd:restriction>
     </xsd:simpleType>

We can add other values to this element if the TC foresees
specific values for notary acts.

Arshad Noor
StrongAuth, Inc.

John Messing wrote:
> I understand that Arshad has given thought in his deliverable about
> legacy applications, but I would like to approach the use of the
> deliverable with regard to non-XML documents from a slightly different
> angle.
> 
> In the land recording industry, it is unlikely that "pure" XML documents
> will be recorded for some time despite existing XML structures for that
> purpose.
> 
> I think tiffs and pdf's will continue to dominate document filings for
> some time, as they do in court filings.
> 
> Therefore, to improve the receptivity to the land recorders of the
> deliverable and demonstrate its current relevance, I suggest that
> specific consideration be given to non-XML documents, which I seek to
> exemplify by two hypothetical work flows. I limit the discussion to the
> symmetric signature profile only for sake of example.
> 
> 1. Signer signs a paper document and wants the notary to e-notarize it
> for e-recording purposes.
> 
> 2. Signer signs a pdf document by simply typing his or her name into the
> signature space in front of the notary for e-recording purposes.
> 
> Notary laws theoretically support notarization in each case.
> 
> In case 1, the notary scans the document as a tiff image, and
> acknowledges it, which means the signer tells the notary he or she
> signed it before coming to the notary. The scanned document is then sent
> to the recording office in the notary container with the certificate,
> probably as a base64 encoded blob, which is hashed and the certificate
> signed using the symmetric key profile.
> 
> In case 2, the signer types his or her name into an appropriate field on
> the pdf in front of the notary as an e-signature, the pdf is again
> base64 encoded and hashed and the certificate signed, and in this case
> the certificate is a jurat.
> 
> These scenarios do not necessarily require base64 encoding IMHO, because
> DSIG legally allows for signing binaries as such, so perhaps base64 
> methods for accomplishing these signatures may be optional. I think some
> consideration of these points should be explicitly set out for the
> benefit of potential users.
> 
> The subdivision of certificates into jurats or acknowledgments as child
> elements should be relatively straight-forward technically, but my sense
> is that in the notary community, the semantics and relationship of
> parent and child elements between certificate, jurat and acknowledgment
> could become non-technical and potentially divisive, and so careful
> testing of the waters may be required, lest non-technical disputes
> erupt, dominate and distract.
> 
> I wonder if the group agrees as to a need to focus on these matters,
> particularly those with considerable MISMO-PRIA or notary experience,
> such as Marc, Mark, John and Harry.
> 
> 
> 
>  
>