Last Modified: 2004-07-09
Cryptographic means are useful, but they do not provide the whole solution. For example, digital signatures (generated with a particular key size) might become weak over time due to improved computational capabilities, new cryptanalytic attacks might "break" a digital signature algorithm, public key certificates might be revoked or expire, and so on.
Complementary methods covering potential weaknesses are necessary.
Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. A single timestamp is not sufficient for this purpose. Additionally, the reliable preservation of content across change of formats, application of electronic notarizations, and subsequent notary services require standard solutions.
The objective of the LTANS working group is to define requirements, data structures and protocols for the secure usage of the necessary archive and notary services. First, the requirements for the long-term archive will be collected. Based on that information we will develop a protocol to access archive services supplying long-term non-repudiation for signed documents and define common data structures and formats. Upon completion of the archive-related specifications, we will address 'notary services' in a similar way. The term 'notary services' is not clearly defined. The working group will determine which functions need standards, including transformation of documents from one format to another without losing the value of evidence, electronic notarization, and further verification of legal validity of signed documents. We will determine the needs via the requirements paper and act upon the results accordingly.
Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as the basis to define those structures and protocols. For example, the Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server Protocols (DVCS)", contain applicable concepts.
| Done | Initial requirements for long-term archive I-D | |
| Done | Initial data structures for long-term archive I-D | |
| Apr 04 | Last call requirements for long-term archive I-D | |
| Apr 04 | Revised requirements for long-term archive I-D | |
| May 04 | Revised data structures for long-term archive I-D | |
| May 04 | Initial requirements for notary services I-D | |
| Jun 04 | Initial protocol for long-term archive I-D | |
| Jun 04 | Last call data structures for long-term archive I-D | |
| Jul 04 | Submit requirements for long-term archive to IESG as informational | |
| Jul 04 | Submit data structures for long-term archive to IESG as proposed standard | |
| Aug 04 | Revised requirements for notary services I-D | |
| Aug 04 | Protocol revisions for long-term archive I-D | |
| Sep 04 | Last call protocol for long-term archive I-D | |
| Sep 04 | Last call requirements for notary services I-D | |
| Oct 04 | Submit protocol for long-term archive to IESG as proposed standard | |
| Oct 04 | Submit requirements for notary services to IESG as proposed standard |
|
The LTANS WG met on 8/5 from 1:00PM to 3:00PM PDT. Approximately 30 people attended the meeting.
Introduction/Administrivia/Status/etc. (Tobias Gondrom) - 5 Min. A. Notary Requirements 1. Opening Presentation of Notary Reqs (Tobias) - 15 Min. 2. Further presentations of notary reqs/ideas (Tobias) - 10 Min. 2.1 from Andreas Schmidt (Tobias) - 5 Min. 2.2 OASIS (John Ross) - 10 Min. 3. Discussion of notary requirements doc (Larry Masinter) - 30 Min. B. Long-term Archive Protocol 1. Operation of an Archive Service (Tobias) - 10 Min. 2. Presentation of protocol draft from Peter Sylvester (Carl Wallace) - 15 Min. 3. Discussion (Carl & Tobias) - 20 Min. Introduction/Status - Tobias discussed document status. Noted that Long-term Archive Requirements and ERS are stable. Last Call for the Long-Term Archive Requirements document is planned for late August. The Long-term Archive Protocol is not yet published. Notary requirements are in early stages. All documents are behind schedule. A. Notary Requirements 1. Opening Presentation of Notary Reqs (Tobias) - Tobias provided an overview of notary service functionality as described in initial requirements document and noted that a notary cannot function without trust (i.e. trust in the human behind the service). - Notary functions were defined as follows: record transactions, record events, certification of copy documents, administering of oaths, attestation and certification of events. 2. Further presentations of notary reqs/ideas 2.1 from Andreas Schmidt (Tobias) - Tobias presented slides on behalf of Andreas Schmidt, who is now a co-author of the notary requirements document. - Identified the need to address varying legal constructions in various countries. This important enough that it must be addressed in the requirements. - Noted that paper notarization is outside of scope. Larry pointed out that there are several IETF protocols that address paper, including internet fax. - Notes that E2E (Electronic-to-electronic) transformations are a core functionality of notary services. - Notion of a "transformation seal" was introduced. - Is catalog of data formats and their suitability for transformation out of scope? - Human inspection may not be avoidable. 2.2 OASIS (John Ross) - Introduced activities in OASIS relevant to LTANS: Digital Signature Services (DSS) and legalXML. legalXML defines the data structures for court filings, for example. In particular, the human interaction is addressed. DSS defines a generic framework for server-based signature generation and verification. - Noted that it is difficult to come up with one solution for notarization due to differences in various jurisdictions. Security aspects as separated from the data aspects to define a flexible solution that can be adapted from community to community to meet the various notarization requirements. - Perhaps a means of working together could be established. The group meets every two weeks with participants phoning in from a variety of locations. Group has some face-to-face meetings and significant degree of participation. - There are two documents recently released for comment: DSS Core Protocols, Elements and Bindings; XML Timestamping DSS Profile. - These documents support CMS, XML DSIG and RFC 3161. - Additionally, there is a requirements document and an FAQ available on the group's website. - Other profiles are nearly ready for publication, including XADES, German signature law, Electronic Post Mark (EPM), code signing, asynchronous operation, entity seal, policy wise operation and web services security. - OASIS participation requires membership (~$200 for individual membership). - The group is interested in making sure that work done by LTANS is complementary and consistent with OASIS work, e.g. make sure there is one standard that is adopted. - XADES is the profile related to long-term archive. It is an XML equivalent of RFC3126. - Russ was asked if working with OASIS would be a problem. Resolution is to raise issue to IAB and establish a liason. 3. Discussion about proceeding with notary work (Larry Masinter) - Larry led a discussion of the notary requirements draft. - Initial comments noted issues with the first paragraph, i.e. Wikipedia reference for notary definition. The text needs work to establish a global scope for notarization. Clarification that the initial text is not aiming to provide definitions but is simply trying to provide some context for the scope is necessary. - Folks were requested to provide info regarding notary function in their parts of the world to the mailing list. - It was discussed how far OASIS has already available standard for notary services: Currently nothing specific, the information related to notarization is carried data payload in OASIS, DSS is simply the sealing mechanism. OASIS wants to provide input to the mailinglist (their "legalXML group" has possibly a requirements document) - Discussed must/may/should text in requirements documents. Next version will feature softer uses of such terms. - Tobias solicited use cases from participants. What services would be required to satisfy notary functions globally. - In Norway, government acts as a notary. It's not really a trusted third party. It's trusted by the population, i.e. Norwegians trust their government. The transactions are primarily between individual and the government. Transactions between individuals are notarized by private notaries. - It was noted that it is difficult to imagine that governments anywhere require a third party. Larry pointed out that agencies rely on other agencies, which is a similar, e.g. the postal service provides a postmark that other agencies rely upon. - The transaction set specified in the requirments document was reviewed. An open question is what are the kinds of transactions and services that must be offered by a notary? Some in the current list may not be suitable, e.g. administration of oaths. It was suggested that the administration of oaths may accumulate more differences than some other use cases. - Section 4 provides the meat of the document. Editorially the sub-sub sections will probably go away since everything is a functional requirement. - A review of must/may/should is in order. The initial draft included such terms primarily to elicit opinion. - Authentication may simply be required in order to exercise a notary. In some cases the notary needs authentication only to aquire his payment, thus not _all_ services may need authentication. - "Provide services" needs to be made more explicit. Current text is too vague. How to demonstrate trust? Perhaps by demonstrating that you are someone with a long history of trust. Does long history of trust demonstrate trust? Demonstration of trust may be outside of scope. Bonding is an example. The term "trust" is maybe to vague. Replace with notions like proof of identity. - It's kind of like PGP web of trust. - The "Operation" requirement is not a protocol requirement but is a service requirement. For example, the notary must know how to perform his duties. How to demonstrate that the notary system is under the control of the notary? Perhaps some certified programs or evaluation to support such. The requirement seems to indicate that someone is certified as a notary. Is this necessary in internet environment? - In France, notaries are certified for specific purposes after going through some legal exercise related to that purpose. Perhaps a notary protocol could provide an indication as to whether there was a human notary involved, what the notary is authorized for, who authorized the notary, etc. - The term "notary office" is not defined. - What is the language for expressing notary capabilities? There should be profiles for notary functions (maybe like OASIS DSS profiles). - For some notarization requirements, there is not a confidentiality requirement. In some cases there may actually be a publicity requirement, i.e. notaries that only handle public documents. - The "Operational Considerations" and "Security Considerations" are incomplete. The Operational Considerations sections needs to address topics like access control to the notary itself, denial of service attacks that prevent proper service. The Security Considerations sections needs to include a threat analysis and mitigations of those threats. These sections are essentially placeholders. - Tobias noted that it is not clear to him that there is a need for notary services. The reason for producing the requirements document was to elicit input regarding whether such things are needed. One opinion was noted that the group should proceed with notary service work owing to the legal challenges and associated technical challenges. - John Ross noted that in OASIS some general characteristics had been assembled from various requirements from different countries. Most of there research was collected from the legalXML group (i.e. non-technical legal folks) to identify the requirements for the protocol. The OASIS group has concentrated on the what is required for the seal. - The entity seal profile from OASIS is the applicable profile (when available). - Show of hands yielded no one supporting notary service protocols, some folks who felt the group should not proceed with such work. Probably more "not sures" in the crowd. - Would real notaries want to replace current practices with IETF equivalent? - Service is only valuable if it is legally honored. - Is there a way to address such things in a way similar to CA policies? B Long-term Archive Protocol 1. Operation of an Archive Service (Tobias) - Should there be search functionality? Should there be management of attributes? How much should we stray into content management? - Discussed the various transactions: submission, retrieval, deletion, transfer. - Discussed the functionality that should be provided by an archive service. 2. Presentation of protocol draft from Peter Sylvester (Carl Wallace) 3. Discussion (Carl & Tobias) - The possibility of dropping the protocol in favor of bindings to existing mechanisms, e.g. WebDAV, was raised. In particular, this would avoid reinventing the wheel for things like searching. - MIME headers are important component to solution. For example, define a mulitpart archive type. - May want to access the parts separately. - There were questions as to whether content type info should be included in the protocol. There were opinions for an against. Future clients may not support MIME or the types indicated by the type. Providing a hint is probably preferrable to not providing type. The time of origin and time of archiving may be important clues for determing appropriate handler for data at points well into the future. - Tobias noted that proof of integrity/non-repudiation is the service provided by the archive service, e.g. over a blob. The payload could be XML signature, CMS signature or unsigned. - The group will consider dropping the protocol specification as it is currently considered and instead focusing on defining bindings between evidence data and data, e.g. for WebDAV. Action items - Investigate establishing liason with OASIS group - Collect details of notary operation from various countries from list participants - Solicit comments on the notary requirements - Discuss need for archive protocol vs. alternative means. Investigate, in particular, use of WebDAV. |