OASIS Open Mailing List Archives  ·  All Lists  ·  legalxml-courtfiling  ·  2003-05

legalxml-courtfiling — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: [legalxml-courtfiling] Re: [courtfiling-process] Security of court orders


It is my opinion that there is no such thing as a perfect solution for security that this TC can adopt based on technology only. But just as is the case of messaging protocols such as HTTPS, ebXML, SOAP, there must exist options for each court to determine what security model will work best for them. These options will be affected by the laws that each state has implemented regarding digital signatures, imaged signatures, implied signatures, ucc signatures, and how each state's laws are affected by the Federal E-Sign law, and how each state's laws are affected by the Uniform Electronic Transaction Act 'UETA'. The following link will guide the reader through various pages of data relating to different laws various states and some countries have implemented. http://www.pki-page.org . From this link you can also find the link to the ABA description of digital signatures. http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html Note on UETA: ------------------ UETA is important because it - establishes the legal equivalent of electronic records and signatures, eliminating the requirement to print and store hard copies and reducing storage costs - requires the retention of the electronic original in a manner that allows for later use and retrieval, which means migration issues must be addressed - establishes minimum standards for when information is considered legally sent or received in electronic form ------------------- I have found this law firms links to be of value over the years in some of these areas: http://www.bakernet.com/ecommerce/ Because of these various complexities of laws, we have pushed to make sure that our EFSP and EFM can deal with multiple Hash functions and different ways to take advantage of digital signatures and deal with some of these laws. We currently us X.509 certificates for individual signatures and digital locks. In the Atlanta Georgia meeting of the TC, I presented our use of the digital lock as an extension of the LegalXML envelope and why. We use this digital lock in addition to individual digital signatures in the Utah implementation. The digital lock is a method of binding an implied signature (whether it is an attorney submitting a filing or a judge issuing an order), together with the documents so that the evidence of the transaction is permanently locked creating evidence which can later be used against disputes that may occur. When the information about the order migrates from the approval event to the database, the event is trapped within the envelope and locked so that the information stored in the database can be audited and verified later against the envelope. The security event we are worried about here is the process of a Judge approving a documentation containing an order that he/she is viewing. The real question of security then becomes how long before the approval event is locked and what is the process of trapping that information electronically so that proper evidence exists, cannot be tampered with, and can be stored for an undetermined amount of time. Again the issues are: - what is the process of electronically trapping the event - are their any holes in the process where someone could alter the event before it is digitally locked - how is the digital lock and the information stored so that it can be verified at a later date Regarding the security of individual signatures: Most Certificate Authorities policies say that a private key is compromised and should be revoked if the user allows the key to be out of their control. This is very difficult to achieve since most people rely on their IT staff to order, install, and manage their keys and their computers. There are several points in this model where the keys are out of the control of the Judge because if it is installed in their browser any IT staff with the right authority can get to the key especially if they helped the Judge order the key. At this point it is nothing more than a username and password. Regarding the Digital Lock: We have implemented a digital lock that binds the user ID, IP address, the time the submission was created, and all documents embedded into the envelope together with a digital signature of the EFPS server that created the envelope. The weakness here is that someone can break-in with some else's user name and password and create something for submission. This weakness is inherent to any system that uses a UserName and Password even digital signatures in many cases. Regarding the DSS: It seems to me that the same weakness occurs here as any system that requires a UserName and Password to log-in, upload a document to have a signature applied to it, and then send it to the courts. It is my impression that the digital lock is less expensive and easier to manage than the DSS concept. The value of an individual digital signature, digital lock, or a DSS is that evidence is created which electronically binds data together, hopefully into a single entity for electronic storage, and is stored intentionally as long term evidence. The only way to improve the security model even with these digital signature/locking concepts, is by the author of the event to review the data after the digital signature or digital lock is applied and the database is uploaded. Even this process has some weaknesses, but we have significantly increased the level of security and it is far greater than a paper system. When we create a digitally signed receipt from the courts for a submission that goes back to the attorney or judge, we either include the original data that was submitted or we include the digital digest (hash) of the data. It provides the originator to audit the information for validity. I hope this helps. Dallas

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]