idnits 2.17.1 draft-ietf-ltans-ari-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ANSX995' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'I180141' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'I180142' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'I180143' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC3126' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC3161' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC3852' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'ETSI2003' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'MER1980' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'REQ2004' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3126 (Obsoleted by RFC 5126) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Gondrom 3 Internet-Draft July 12, 2010 4 Intended status: Informational 5 Expires: January 13, 2011 7 LTANS Architecture 8 draft-ietf-ltans-ari-01 10 Abstract 12 This document outlines best practices how to use and integrate 13 components based on the various specifications prepared by the LTANS 14 WG for long term archiving and non-repudiation services can work 15 together in a best practices environment. It especially takes care 16 of the overall architecture and integration of the protocol and the 17 data structures. 19 Conventions used in this document 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. General Architecture Overview . . . . . . . . . . . . . . . . 3 62 3. ERS and XMLERS . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Hot to verify a combination of ERS and XMLERS . . . . . . 6 64 4. Protocols and DSSC . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Implementation details . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 1.1. Motivation 76 Over the last years various implementations of the specifications of 77 the LTANS drafts have been build. And as the current specifications 78 come to their final state, an architectural information about how to 79 best integrate these specifications and how to best build such an 80 archive system seems helpful. 82 After ERS, XMLERS, ERS-SCVP and DSSC have specified the necessary to 83 standards for the protocol and the data structures for such a service 84 this document only has informational character helping to understand 85 and follow best practices on how to design such a system and combine 86 the variosu drafts for maximum effect. 88 The weaknesses identied in some of today's most common hash 89 algorithms like SHA-1 also make it clear that a protection of the 90 integrity of data after the compromise of a specific hash algorithm 91 is of elemtary importance to society. Considering that one of today 92 in digital signatures used hash algorithms might loose its security 93 attributes (by e.g. cryptoanalysis attacks showing that the collision 94 resistance can no longer be guaranteed) will put all until today 95 already signed messages and data at risk. This can e.g. also hit 96 data that only needed simple integrity protection by applying 97 timestamps as defined by RFC3161. 99 2. General Architecture Overview 101 The central design principle in electronic archiving is to provide a 102 simple identification for an electronic data object. Any user who 103 knows this id and has the proper authorization can at a later point 104 in time access the digital object from any place in the world. 106 This of course has certain implications for the data. 108 1. Availability: How long shall the data be stored 110 2. Integrity: is the object still the one that has been entrusted to 111 the electronic archive? 113 * protect against modifications by the system or an attacker 115 * can the owner proof to another party that the data has not 116 been altered since archiving (including not been altered by 117 himself)? 119 3. Confidentiality: how can the data best be protected against 120 disclosure to e.g. service providers operating the system or 121 during transmission of data to and from the archive? 123 For the general system design it may also be considered how can the 124 data later be found and retrieved. Is there additional metadata 125 necessary and by which system is it handled best? 127 Availability 128 As nearly all data has only to be stored for a limited (although 129 possibly very long) time and after this can be deleted, the system 130 should deploy rules or configuration parameters when data can be 131 removed and destroyed. As the data also represents an important 132 value to its users it is also necessary that retrieval and retention 133 management employ a consistent access control management. 135 System Architecture 136 The genral server architecture of a LTANS archive service can follow 137 several possible architecture concepts: 139 1. the LTANS archiving and signature renewal system can be managed 140 as a stand-alone solution: 141 Users submit data directly via any simple protocol (e.g. HTTP, 142 WebDAV, or others) to the service. The system stores the 143 documents and based on system policies manages the signature 144 renewal and integrity protection. In the most simple 145 implementation the system may even not apply any actions 146 automatically but always need the command of a responsible data 147 owner to initiate them. The minimum actions that may be needed 148 to be performed are data storing, data retrieval, signature 149 renewal and data delete. In theory all these actions could also 150 be requested by the user. But usually a normal user does not 151 know, e.g. when a specific algorithm is no longer secure and 152 initiate a renewal in time. In the best configuration this would 153 be managed by the system. And with the long storage times coming 154 with electronic archiving the usual user may also not want to 155 manage the data retention by himself but simply want to tell the 156 system at the time of storage (or any later time) when to 157 securely delete and irreversly destroy the stored data. An 158 example of a very simple client could e.g. be a WebDAV or File 159 system like interface that directly speaks with the service and 160 stores all data with a predefined policy. Server configuration 161 and operations defines the used parameters, retention times and 162 when a signature renewal is initiated. 164 2. The LTANS signature renewal service can also be loosely coupled 165 with a normal archiving system. This can have various 166 implementations: 168 * The service might be completely hidden by the normal archive 169 system with two differnet techniques: 170 the archive system may simply transfer all its data that shall 171 be integrity protected by LTANS Evidence Records directly to 172 the LTANS server or it may keep its own data and only simply 173 submit copies of data that needs the integrity protection and 174 non-repudiation of the LTANS system to the service. With the 175 second approach it may still use its own techniques for the 176 normal operation and management and only in the case of the 177 needed integrity and non-repudiation proof retrieve data from 178 the service and verify the evidence record. 180 * the service might be provided in parallel to the normal 181 archive in a more complex system architecture. 182 In such a case a client may access either the normal document 183 management system/archive or also directly access the LTANS 184 service. Documents may be directly tansferred from the normal 185 document management system to the LTANS service for integrity 186 protection and non-repudiation services. Depending on the 187 need of the user he requests data from the document management 188 system or (if he requires a valid evidence reocrd for his 189 data) directly accesses the LTANS archive service. The 190 connection to these two services in parallel may make the 191 integration in some parts easier as every system can 192 specialize on its defined tasks but may raise issues of how to 193 ensure access control. In this case a ticketing system may be 194 helpful where the user has to obtain a secure authorization 195 ticket from the document management system or application to 196 get access to the evidence record in the LTANS system. 198 3. The LTANS signature renewal can be directly integrated in an 199 existing archiving system: 200 In this case a commercial archiving system might simply add the 201 functionality of applying timestamps and signature renewal to its 202 backend storage system. This can be done at two layers: Either 203 in the archiving system or if a more intelligent storage system 204 (like e.g. in some commercial hard disk arrays) is used in the 205 storage itself. The advantage of a tighter integration with an 206 archiving system can be that existing infrastructure and 207 management systems can be used, renewal and retention times can 208 be based on metadata available to the overall system, the 209 organization of the data on storage media and in data groups for 210 the evidence record can also be determined (and optimized) by 211 this metadata available to applications and document management 212 systems. This integration can result in various use cases for 213 the specific protocols. As most of the today existing document 214 management systems already implemented their own proprietary or 215 open protocol it may be the case that the system only extends its 216 own protocol with the ERS functionality. Or it may offer a 217 second protocol extension in parallel to it's own protocols for 218 specific clients for non-repudiation and integrtity verification. 219 In the case that the LTANS service will be implemented on the 220 storage level it may be that the storage vendors will implement a 221 protocol for their data access layer which may impose very 222 different requirements than the normal software application 223 oriented implementations. 225 3. ERS and XMLERS 227 The Evidence Records provided by ERS and XMLERS provide evidence 228 records in ASN.1 and XML. They both follow identical design 229 principles and provide the same level of security. But as the 230 signature renewal process also must involve and includes parts of the 231 byte representation of the data structures which are used, there is 232 no bidirectional transformation from one format to the other. In 233 general a system willeither implement ERS (using the ASN.1 format) or 234 XMLERS (using XML). However as the renewal and protection process 235 applies to data independent of the used data containers and formats 236 it is possible to store ERS in systems using XMLERS and vice versa. 237 But a verification process would in these cases be more complex and 238 require a system supporting both standards. 240 3.1. Hot to verify a combination of ERS and XMLERS 242 tbd 244 4. Protocols and DSSC 246 tbd 248 5. Implementation details 250 An LTANS system consists in its minimum implementation of a sevice 251 speaking a basic transfer protocol (e.g. HTTP or WebDAV), a data 252 management system organizing the data by grouping, building hashtrees 253 and executing renewal procedures, a storage media where the system 254 keeps the initial documents (for the case of later Hashtree renewals) 255 and the evidence records and a trusted time stamp source which would 256 best be provided by an independent trusted third party. 258 A client stores his to the system by using directly or indirectly 259 (e.g. via a WebDAV client to file share). As most systems already 260 deploy their own access control management the used protocol can rely 261 on the already existing infrastructure with authenticated and 262 authorized requests. This may e.g. be done via a Kerberos or other 263 implementation. 265 The system receives the data and collects it. 266 In case of digital signed documents it may in a first step verify 267 these and also receive additinal necessary verification data from 268 other sources as specified in the draft draft-ietf-ltans-validate. 269 It is recommended to integrate any necessary verification data at 270 this step into the document as e.g. specified in RFC3126 or to 271 combine all necessary date for verification with the document and 272 signatures themselves together in one container for storage and non- 273 repudiation protection so that any later party can rely on the 274 unbroken integrity and chain of custody for the documents and all the 275 verification data since the time of archiving and redo the 276 verification procedure based on the complete information as some of 277 the verification information might be difficult to obtain at a later 278 time, e.g. 30 years later. 280 The specification of ERS relies as an example on time stamps based on 281 RFC3161, but can explicitely also support and use other time stamping 282 mechanisms that rely on certain basic mechanisms: Public key 283 algorithms, using a trusted time source, and from a trusted third 284 party (which may in some countries require an accreditation by a 285 government agency. Such other time stamp sources may e.g. also be 286 the Time stamp mechanism specified by ISO. 288 Additionally to the verification data certain systems may require the 289 storage of certain metadata additional with the document as the 290 document may only be complete and understandable with this context 291 (metadata information). This can e.g. also be accomplished by 292 storing document and metadata within one container, which can be the 293 same or another container within the container of the docuemnht and 294 the verification data. 296 After the retrieval of the document and the possible enrichment of 297 the data, the document or the container is stored in the system. In 298 the case that time stamps or signatures have been applied before the 299 submission of the data, this data already has a certain level of 300 evidence based on the security level of the used algorithms and 301 procedures. Instead of evaluating the algorithms used in the initial 302 data, the system applies one initial archivetimestamp with its own 303 secure timestamps and hash algorithms to "equalize" all data to a 304 defined integrity and non-repudiation assurance level. For this step 305 the system groups all data within a hashtree and applies a timestamp 306 it received from an external trusted third party. Thhe frequency of 307 this initial step may be configured in the system, some may require 308 only a granularity of once per week, others with a high volume may 309 execute this every hour or even shorter interval. Current 310 implementations have shown that the granularity of a daily initial 311 ArchiveTimestamping seems an adequate protection. 313 After this initial Archivetimestamp the system now knows the well 314 defined algorithms it used during this step and will renew the 315 archive timestamp (and together with this, all the data already 316 stored in the container and signed or encrypted with other 317 algorithms) if the algorithms of the initial Archivetimestamp get 318 weak. 320 The execution of renewal can be configured at the LTANS server or 321 even manually executed before the algorithms used in the last 322 Archivetimestamp of the ArchiveTimestampchain as specified in ERS get 323 weak. 325 The system stores data and the created archivetimestamps, later in 326 the form of Evidence Record. For better data management it is 327 recommended to store them on the same type of media or even on the 328 same media, as the stored data may be worthless without the Evidence 329 Record and vice versa. 331 At a later point in time the client may request the data or the 332 Evidence record from the LTANS system. A certain implementaion of 333 the LTANS system may even only implement an interface to retrieve the 334 Evidence Record and not the the data itself which in such a 335 configuration would have to be stored and kept by the user or client 336 separately. (For renewals due to identified weaknesses in used hash 337 algorithms it is still necessary to store the data to the system so 338 that a hashtree renewal as defined by ERS can be performed.) 340 The client then verifies the received Evidence Record based on a 341 defined archive policy (which defines which algorithm was considered 342 secure for which period of time (begin and end) and which time stamp 343 sources and verification data may be trustworthy). This may be done 344 automatically or also done manually by an expert (e.g. during a 345 lawsuit). 347 6. Security Considerations 349 System design 351 the system architecture raises a number of security questions 352 especially in the area of access control and confidentiality as the 353 security of a system can always only as strong as the security of the 354 weakest part of the chain. 356 7. References 358 7.1. Normative References 360 [ANSX995] American National Standard for Financial Services, 361 "Trusted Timestamp Management and Security", ANSX X9.95- 362 2005, June 2005. 364 [I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: 365 Framework", ISO ISO-18014-1, February 2002. 367 [I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: 368 Mechanisms producing independent tokens", ISO ISO-18014-2, 369 December 2002. 371 [I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: 372 Mechanisms producing linked tokens", ISO ISO-18014-3, 373 February 2004. 375 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 376 3", RFC 2026, 1996. 378 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 379 Requirement Levels", RFC 2119, 1997. 381 [RFC3126] Adams, C., Pinkas, D., Ross, J., and N. Pope, "Electronic 382 Signature Formats for long term electronic signatures", 383 RFC 3126, 2001. 385 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 386 "Internet X.509 Public Key Infrastructure Time-Stamp 387 Protocol (TSP)", RFC 3161, August 2001. 389 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 390 X.509 Public Key Infrastructure Certificate and 391 Certificate Revocation List (CRL) Profile", RFC 3280, 392 August 2001. 394 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 395 RFC 3852, July 2004. 397 7.2. Informative References 399 [ETSI2003] 400 European Telecommunication Standards Institute (ETSI), 401 Electronic Signatures and Infrastructures (ESI);, 402 "Algorithms and Parameters for Secure Electronic 403 Signatures", ETSI SR 002 176 V1.1.1, March 2003. 405 [MER1980] Merkle, R., "Protocols for Public Key Cryptosystems, 406 Proceedings of the 1980 IEEE Symposium on Security and 407 Privacy (Oakland, CA, USA)", pages 122-134, April 1980. 409 [REQ2004] Wallace, C., Brandner, R., and U. Pordesch, "Long-term 410 Archive Service Requirements", I-D ???, 2005. 412 Author's Address 414 Tobias Gondrom 415 Munich 416 Germany 418 Email: tobias.gondrom@gondrom.org