-
Notifications
You must be signed in to change notification settings - Fork 6
Implementation and Scaling Issues and Options
This wiki page focuses on implementation and scaling aspects of the Washington, DC Cranch project electronic legal materials authentication project.
The purpose of this Wiki page is to note issues and options for design and prototype phase so as to garner the most value and set the conditions for longer term successful wide adoption as best as possible. Taking a little time and energy to carefully hit key strategic steps and document them appropriately for later decision makers and adopters to review will be important. For so long as this project is operating with no dedicated funding and staff support, it will be up to people working on the volunteer effort to choose the things to test and documentation to create. A small amount of attention and effort spent on smoothing future scalable adoption can be important to the success of achieving the intended goal of creating a UELMA authentication solution fit for general use by the public sector.
The Cranch project is intended to design and implement an authentication solution addressing the requirements of the [Uniform Electronic Legal Materials Act (UELMA)](An official publisher of legal material in an electronic record that is designated as official under Section 4 shall authenticate the record. To authenticate an electronic record, the publisher shall provide a method for a user to determine that the record received by the user from the publisher is unaltered from the official record published by the publisher).
Section 5 of UELA reads:
"An official publisher of legal material in an electronic record that is designated as official under Section 4 shall authenticate the record. To authenticate an electronic record, the publisher shall provide a method for a user to determine that the record received by the user from the publisher is unaltered from the official record published by the publisher."
The term "authenticate an electronic record is used here (generally) in the judicial evidence sense of the word and not the information security and digital identity sense of the word, as was estabished by the American Bar Association's Digital Signature Guidelines.
Use of GPG for signing and authentication of legal documents is an attractive, light-weight approach to an important element of establishing information security and process integrity. Some of the issues to be addressed to independently confirm and establish the reliability and scalability of this authentication solution include:
-
Binding the private signing key used to encrypt the message digest resulting from a hash process with the authoritative publisher of the legal materials that were signed;
-
Ensuring ease of use and reasonable cost and management over the lifecycle of the legal materials; and
-
Providing routine and provable methods to validate the underlying processes and mechanisms used, such as to satisfy a spot-check audit or resolve a dispute over the authenticity of legal materials.
Much can be said in favor of using GPG as a base technology to accomplish each of the above needs. More background on the authenticity requirement (the first of three requirements posed for UELMA compliant electronic legal materials) is available in the DC Council's "Cranch" project repository, at: (https://github.com/DCCouncil/Cranch/blob/master/documentation/authenticity.md). The signing function of GPG directly addresses the authentication requirement for electronic records that are "legal materials" under UELMA. and possesses many advantages over use of X.509v3 certificates, third party certification authorities and Public Key Infrastructure overhead in general.
As good a fit as GPG appears to be in general, an important next steps toward honing a production-ready solution is to clarify or specify in more detail relevant business/operations, legal/policy and technical/security aspects of use and performance from the vantage point of each key stakeholder and relying party. There are many creative and very lightweight ways to associating the signing key of the authoritative governmental publisher of legal materials with the corresponding public key in order to meet the UELMA authentication criteria.
Once the library and GPG capabilities are successfully installed and configured (which was not completed during the DC Code Legal Hackathon on May 10th, 2014), the following steps could be useful:
-
Confirm how life-cycle private key and application management "out of the box" works and what pre-configured or otherwise refined builds, templates, automation, etc can/should be developed for others to implement the solution and avoid the difficulties of deploying raw open source complex software. For instance, while doing initial phase design work with GPG, it would be valuable to establish the process of key generation, storage, protection, access and destruction and note any gaps between the unrefined/default processes and the foreseeably expected minimum expectations of implementing governmental entities and other stakeholders.
-
Confirm the process of creating and storing (ie the location) of the message digest resulting from SHA hashing of the legal material being "signed" is stored. Then verify that the same message digest results when the same legal materials are hashed using SHA in the same way on an independent system.
Staging a multi-party proof-of-concept to confirm and demonstrate how this solution would work in the state and local public sector context will be help as part of defining and refining the solution during the design and prototype phase of this project. This is ideally addressed not only to the technical aspects of the solution but also very importantly to the business and legal aspects as well. In the public sector context, the business aspects include operations, work flow, practices, administration, costing, etc.
To assess and evaluate proof-of-concept level business/operations, legal/policy and technical/security aspects of the solution if is valuable to attempt a "normal" usage by two or more different independent but collaborating governmental legal entities acting as authoritative publisher of UELMA compliance legal materials and as "relying party" (aka "user" of such materials by an external entity).
The evaluation should be focused upon an agreed simple and base-case scenario implementation such as conducting the following steps: 1) Install, configure and apply the authentication method to sign legal materials for which each entity is the authoritative publisher and 2) publish the signed legal materials on a web server, and 3) Verify and validate whether legal materials purporting to be signed and published by one or more OTHER collaborating governmental entities are in fact authentic, and 3) Document and share the results. When staff or consultants of a single legal entity create two installations of a solution such as this, it is predictable that a range of business, legal and technical usability, reliability, interoperability and scalability issues may go unrevealed due to operation within the same business, legal and technical environments, networks and other systems.
For additional value, at least one deliberately erroneous condition can be tested, such as publication of legal materials with a knowingly erroneous signature or other basic error. However, adding complexity and additional testing scenarios to an initial light-weight staging test may not be worth the value of the information revealed and instead scheduling a series of staging tests that are light-weight and iterative be more realistic and successful overall.
When assessing and evaluating GPG for UELMA signing in the above recommended initial testing and the staging of independent installations, gaps and other open questions should be noted as issue tickets or wiki documentation, as appropriate and proportional to the gap identified. The results of verification and validations attempts should be carefully noted.
The issues with implementation from the default open source code can be daunting for IT staff and others who are not schooled in this type of implementation and the related underlying cryptographic processes. By harvesting as much documentation of step-by-step processes during early phase design and build work, the initial adoption and testing will be greatly advantaged. Specifically, the process of confirming and documenting the above items should shed light on how to install, configure, operate, archive, recover and migrate the GPG and related components that will comprise the authentication solution will be important for ease of adoption and building users in communities of practice who can support one another.
An initial evaluation of the type suggested above should be simple, quick and very low cost ideally carried out in the course of a few hours from start to finish. However, despite the light-weight nature of the exercise, such an evaluation is designed to surface and harvest a "punch list" of high value needed functionality, significant high priority errors and other problems including potential systemic, transactional, data management or other risks. For this evaluation exercise, it is important that the entities in fact be different and not peer or superior/subordinate units of the same legal entity. Legal counsel, library or legislative staff at city #1 and at city #2 or at any state government, county government or regional authority (eg water resource authority, regional school district, etc) would very likely be from different legal entities. By contrast, legal office staff and public library staff of the same city, county or state would likely be from the same legal or unduly intermeshed legal entities and would not qualify to conduct the evaluation.
Potentially, the use of GPG "subkeys" (see informal discussion at (http://superuser.com/questions/466396/how-to-manage-gpg-keys-across-multiple-systems)) could be appropriate for government publishers that are comprised of many lesser included authoritative publishers (eg a state government that includes different agencies and publishing operations for various types of legal materials) or potentially for a consortium approach that includes many different participating cities or towns that wish to share resources and operational load without making the mistake of also sharing private signing keys. The Debian project makes use of subkeys in a relevant manner: (https://wiki.debian.org/Subkeys?action=show&redirect=subkeys).
It is noteworthy that the Colorado was the first state to enact UELMA (http://www.ncsl.org/research/telecommunications-and-information-technology/uniform-electronic-legal-material-legislation.aspx), given it has also established a very similar method to achieve simple yet secure electronic notarization. The Colorado "Document Authentication Number" (DAN) is the basic design pattern for electronic notarization, and is defined in Colorado Regulation 8 CCR 1505-11 as follows:
". “Document authentication number” means a number issued by the Secretary of State that includes the Secretary of State’s accounting system validation number issued to each notary upon commissioning and a randomly generated number that when used together may constitute the notary’s electronic signature and identify both the individual notary and the document to which the document authentication number has been affixed." (http://www.sos.state.co.us/CCR/GenerateRulePdf.do?ruleVersionId=3508&fileName=8%20CCR%201505-11)
In addition, opportunities should be provided for governments that wish to use this approach to easily publish their public keys associated with signing keys. For example, there may be a web page hosted by an umbrella group - or many groups - that bind the keys to the names of the publishing governments. Whether block chains (as used by BitCoin but in a novel way tailored for transactions that constitute the act of signing legal materials by the authoritative government publisher).
The insight that GPG can provide a good solution to achieve the aims of UELMA is sound and with appropriate design work can provide high value and enable deep innovation. Accomplishing short term and achievable objectives while maintaining awareness about and ample paths for longer term realization of the big goal to transition United States law from paper to electronic records in open data and service accessible formats.