idnits 2.17.1 draft-ietf-ltans-validate-03.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 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 5036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'S2' is mentioned on line 281, but not defined == Unused Reference: 'ANSX995' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'I180141' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'I180142' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I180143' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC3126' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC3852' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'ETSI2003' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'REQ2004' is defined on line 438, 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 (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LTANS T. Gondrom 3 Internet-Draft S. Fischer-Dieskau 4 Intended status: Informational July 12, 2010 5 Expires: January 13, 2011 7 Validation and long term verification data for Evidence Records and 8 signed documents 9 draft-ietf-ltans-validate-03 11 Abstract 13 Digitally signed documents and data in a LTANS service receive the 14 signature renwal procedures and non-repudiation services. As 15 documents can be stored for very long (theoretically inifinite) 16 times, it is very important to understand which data is and will be 17 necessary for the verification of the contained digital signatures 18 and the applied timestamps and the evidence records. This document 19 shall describe various pieces of information which SHOULD and MUST be 20 provided to effectively verify evidence records and their protected 21 data and signatures. 23 Conventions used in this document 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. General Considerations . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Basic assessment of environment of verification data . . . 4 67 3.2. Types of trust centers (fully trusted - partially 68 trusted) . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2.1. Fully trusted trust center . . . . . . . . . . . . . . 4 70 3.2.2. Partially trusted Trust Center . . . . . . . . . . . . 5 71 3.2.3. Layer model versus chain model . . . . . . . . . . . . 5 72 4. Verification data for Evidence Records . . . . . . . . . . . . 6 73 4.1. List of verification data . . . . . . . . . . . . . . . . 6 74 4.2. Location to store verification data . . . . . . . . . . . 7 75 4.3. Verification Data retrieved from an SCVP server . . . . . 7 76 5. Verification data for the signed documents secured by the 77 Evidence Records . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. List of required verification data . . . . . . . . . . . . 7 79 5.2. Location / structure to store verification data . . . . . 8 80 6. Validation policy . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Data and documents stored in a Long term archiving services may 90 contain digitally signed or encrypted data and their integrity may be 91 assured with the use of timestamps and archivetimestamps as specified 92 in ERS and XMLERS. As such data and it's proof of existence and non- 93 repudiation may be verified at a point in time very far in the 94 future, it is important to analyse and understand what information 95 may be needed for this verification and what controls need to be 96 implemented to ensure the availability and integrity of this data. 98 2. Terminology 100 Archived data object: Data unit that is archived and has to be 101 preserved for a long time by the Long-term Archive Service. 103 Archived data object group: A multitude of data objects, which for 104 some reason belong together. E.g. a document file and a signature 105 file could be a archived data object group, which represent signed 106 data. 108 Archive Timestamp: Is a timestamp and lists of hash values, which 109 allows to verify the existence of several data objects at a 110 certain time. 112 Evidence: Information that may be used to resolve a dispute about 113 various aspects of authenticity of archived data objects. 115 Evidence record: Collection of evidence compiled for one or more 116 given archived data objects over time. An evidence record 117 includes all Archive Timestamps (within structures of Archive 118 Timestamp Chains and Archive Timestamp Sequences) and additional 119 verification data, like certificates, revocation information, 120 trust anchors, policy details, role information, etc. 122 Long-term Archive Service(LTA): A service responsible for 123 preserving data for long periods of time, including generation and 124 collection of evidence, storage of archived data objects and 125 evidence, etc. 127 hash-tree: a hash tree as decribed by Merkle in [MER1980] is a 128 list of sorted hash values ordered in a tree where the child nodes 129 are combined and hashed to generate the father nodes up to one top 130 node. This hash-tree can also be reduced to a list as decribed in 131 ERS. 133 Timestamp: A cryptographically secure confirmation generated by a 134 Time Stamping Authority (TSA) [RFC3161] specifies a structure for 135 timestamps and a protocol for communicating with a Time-stamp 136 Authority (TSA). Besides this, other data structures and 137 protocols may also be appropriate, e.q., such as defined in [ISO- 138 18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and 139 [ANSI.X9-95.2005]. 141 Trust Center: A Trust Center may be operated as a Trusted Third 142 Party (TTP) service (as also specified in RFC 3161), though other 143 operational models may be appropriate. Depending on local laws 144 and criteria the services of a trust center may include to provide 145 certificates, OCSP responses and CRL for a guarantted period of 146 time. The Trust center can also function as the Trusted Third 147 party connecting (and guaranteeing the identity of the owner of a 148 certificate with a certain person. 150 3. General Considerations 152 3.1. Basic assessment of environment of verification data 154 Due to the lack of a common, international wide applicable 155 understanding of terms used in respect of digital signature related 156 objects some basic assessments have to be presumed and are discussed 157 in this section. 159 3.2. Types of trust centers (fully trusted - partially trusted) 161 Depending on local laws and authorities trust centers can be of 162 different levels of trust which can have impact on the verification 163 data needed for a later verification of the digital signatures, time 164 stamps and ERS. 165 Typically two types of trust centers can be envisioned: 167 3.2.1. Fully trusted trust center 169 A trust center that has been accredited by a local government 170 authority or a private office declared as competent from such, the 171 accreditation saying that all relevant requirements to ensure a 172 certain security level are fulfilled (as typically done in most of 173 the European countries) can be classified as a fully trusted at least 174 in the national context. In case of multinational mutual acceptance 175 agreements this trust can be extended to regions or globally. Based 176 on the accreditation and the national interest in these trust centers 177 it can be assumed that it would be publicly known that and when a 178 private key of such a trust center was compromised. 180 3.2.2. Partially trusted Trust Center 182 Partially trusted centers could e.g. be private organizations which 183 function as a kind of common notary but whose security and protection 184 is not accredited by a government authority. This usually means that 185 the validity and availability of the verification data can not be 186 guaranteed. This implies that the LTA (Long term archive) has to 187 ensure at least the availability and usually also the integrity of 188 the data itself including all OCSP responses and or CRLs. 190 3.2.3. Layer model versus chain model 192 Typically a signature depends on other instances that issue a 193 certificate which again have their certificates issued by another 194 instance. E.g. a person could get his certificate issued by a local 195 (or company) trust center, which in turn gets its own certificate 196 issued by a government authority of fully trusted trust center. So 197 for verifiying a signature it is necessary to verify all certificates 198 up to the root which must be trusted if the signature shall be 199 verified positively. 201 This raises the question if it is necessary that all certificates up 202 to the roof have to be valid at the time of signing (layer model), or 203 if it is sufficient that only the latest signature is not yet expired 204 at the time of signing and all signature algorithms used in the chain 205 are still considered secure (chain model). 207 Both models have pros and cons regarding the consequences occurring 208 from different scenarios. As the layer model is established on the 209 international level more respected and accepted point of view. 211 Based on discussion in the working group the layer model is necessary 212 for verifying a chain of certificates when you verify a signature. 214 This would mean that all signatures in the certificates must be valid 215 at the time of signing. This means all used algorithms must still be 216 secure and none of them must have been revoked. (note: both cases 217 would mean that the chain could have been compromised at this level 218 and below and which means the final signature can not be trusted.) 220 Note: the layer model for the validity of the signatures in the 221 certificates does not imply that all certificates have not been 222 expired. In the contrary, concerning the expiry dates of 223 certificates this means only you need to verify that the last 224 certificate has not been expired when the signature has been done. 225 It is of no interest whether certificates in the chain have already 226 been expired as long as they have been valid at the time when they 227 were used to sign (issue) the lower certificates. 229 4. Verification data for Evidence Records 231 4.1. List of verification data 233 Evidence Records contain hashtrees secured with time stamps. The 234 security and verification of the hashtrees themselves only depend on 235 the used hash algorithm and its possible parameters. Despite the 236 generally available list of algorithms and their validity period 237 (which could be documented in a general policy) no further external 238 verification data is necessary to validate the integrity of the 239 hashtrees. 241 The time stamps used in the Evidence Record are based on digital 242 Signatures. To validate these signatures in respect of their 243 authenticity additional verification data like certificates of all 244 parties involved in the issuance of the time stamp certificate, 245 Certificate Revocation Lists (CRLs) and/or OCSP responses are needed. 247 To correctly verify the time stamps in the Evidence Record an expert 248 needs to verify that the used private key has not been compromised 249 when it has been used. The time information provided by a trusted 250 time stamp authority allows to determine the reference date to which 251 the used private key had to be valid. 253 Additionally to fully evaluate the certificate used in respect of the 254 time stamp signature the correct chain of issuers of all certificates 255 up to the root need to be checked. 257 Knowing the reference date the verifier needs an OCSP response or a 258 CRL to verify that the used certificate has not been revoked at the 259 moment of signature creation. Note: OSCP responses are not needed 260 when a misuse of the certificate can be excluded before its owner has 261 obtained it, as could be the case with accredited time stamp 262 authorities. 264 In cases where a specially accredited authority is the trusted time 265 stamp authority (refer to 2.1.1 a) fully trusted trust center), it 266 could be assumed that the compromise of used keys would have so much 267 impact that it would be publicly known even without directly checking 268 the CRL or OCSP status of the used certificate. This situation can 269 justify that it is only necessary to store all certificates but no 270 CRL or OCSP response with the time stamp used in the Evidence Record. 271 Additionally based on the accreditation criteria it can also be the 272 case that certain availability of verification data is guaranteed by 273 the local government. (E.g. in Germany for 30 years). 275 4.2. Location to store verification data 277 All verification data necessary for the verification of the time 278 stamp has to be stored in a non-repudiation system as long as a later 279 verification may be needed. And as this verification data contain 280 electronic signatures which used algorithms may expire further 281 renewals of these electronic signatures may be necessary[S2]. E.g. 282 in RFC3161 time stamps the verification data can be directly 283 integrated into the time stamp, and is by this integrated, protected 284 and automatically renewed with the ERS using the time stamp. 286 4.3. Verification Data retrieved from an SCVP server 288 The necessary verification data can also be stored separately in an 289 SCVP server an be retrived from there. This relieves the archiving 290 party from integrating all evidence right at the time of archival 291 right into the document. The system can only store the data and some 292 subset of the verification data, e.g. only the end entity 293 certificates into the documents and their signatures and leave it to 294 an SCVP server to store and protect the remaining required 295 verification data. The SCVP server can provide this data and their 296 according protecting evidence recprds via ERS/SCVP [LTANS-ERS-SCVP]. 298 5. Verification data for the signed documents secured by the Evidence 299 Records 301 5.1. List of required verification data 303 In respect of the verification data needed to secure a long term 304 validation of the electronic signature all the above mentioned 305 requirements are applicable. The only differences refer to the fact 306 that the signature is not issued by a time stamp authority as owner 307 of the certificate but a person. 309 Therefore a special reference time regarding the validity of the 310 certificate at the time of signature creation is needed to verify 311 that the used private key has not been compromised before it has been 312 used. 314 With reference to the above the correct chain of issuers of all 315 certificates up to the root need to be verified to fully evaluate the 316 certificate used in respect of the signature. A CRL is needed to 317 verify that the used certificate has not been revoked at the moment 318 of signature creation. To verify the authenticity of the CRL the 319 issuer of it has to be checked by verifying the signature of the CRL. 320 Therefore the correct chain of issuers of all certificates up to the 321 root needs to be verified. 323 5.2. Location / structure to store verification data 325 All verification data necessary for the verification of the time 326 stamp have to be stored in a non-repudiation system as long as a 327 later verification may be needed. As these verification data contain 328 electronic signatures which algorithms may expire further renewals of 329 these electronic signatures may be necessary. 331 This explicitly includes OCSP or CRL data and all certificates 332 (including the complete chains for the used signatures. 334 6. Validation policy 336 To validate signatures, time stamps and evidence records it is useful 337 for a validation authority to define and apply a verification policy. 338 In this policy the verifier defines which algorithms are considered 339 valid and secure in which time frames. A policy is defined in "Data 340 Structure for Security Suitabilities of Cryptographic Algorithms" 341 [LTANS-DSSC] 343 Basically the policy simply contains the algorithm identifier and the 344 two dates valid from and expires. With this information the verifier 345 can check that all algorithms have only been used at the time when 346 they have been considered secure. Any deviation from this in the 347 historic time line of an Evidence Record or a signature SHOULD lead 348 to the failure of the verification. 350 Following examples should lead to a failure of the verification: 352 1. a signature of time stamp used an algorithm which has been secure 353 at the time of application but is no longer considered secure 354 (i.e. expired in the policy) and has not been protected by more 355 secure time stamps in an applied ERS SHOULD fail to be verified 357 2. an ERS with a timestamp in the latest structure that is not 358 considered secure SHOULD fail to verify. 360 3. Whenever in the structure of an ERS a later ArchiveTimestamp is 361 applied after the algorithm in the timestamp of the preceding 362 ArchiveTimeStamp is expired (as defined per policy) the 363 verification MUST fail. 365 4. Whenever in the structure of an ERS a ArchiveTimeStampChain is 366 applied after the hash algorithm of the preceding 367 ArchiveTimeStampChain is no longer secure (as defined in the 368 verification policy) the verification MUST fail. 370 7. Security Considerations 372 Long term availability and integrity of verification data 374 The verification data has to be stored and available including non- 375 repudiation for all verification data. 377 8. References 379 8.1. Normative References 381 [ANSX995] American National Standard for Financial Services, 382 "Trusted Timestamp Management and Security", ANSX X9.95- 383 2005, June 2005. 385 [I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: 386 Framework", ISO ISO-18014-1, February 2002. 388 [I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: 389 Mechanisms producing independent tokens", ISO ISO-18014-2, 390 December 2002. 392 [I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: 393 Mechanisms producing linked tokens", ISO ISO-18014-3, 394 February 2004. 396 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 397 3", RFC 2026, 1996. 399 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 400 Requirement Levels", RFC 2119, 1997. 402 [RFC3126] Adams, C., Pinkas, D., Ross, J., and N. Pope, "Electronic 403 Signature Formats for long term electronic signatures", 404 RFC 3126, 2001. 406 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 407 "Internet X.509 Public Key Infrastructure Time-Stamp 408 Protocol (TSP)", RFC 3161, August 2001. 410 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 411 X.509 Public Key Infrastructure Certificate and 412 Certificate Revocation List (CRL) Profile", RFC 3280, 413 August 2001. 415 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 416 RFC 3852, July 2004. 418 8.2. Informative References 420 [ETSI2003] 421 European Telecommunication Standards Institute (ETSI), 422 Electronic Signatures and Infrastructures (ESI);, 423 "Algorithms and Parameters for Secure Electronic 424 Signatures", ETSI SR 002 176 V1.1.1, March 2003. 426 [LTANS-DSSC] 427 IETF, "Data Structure for Security Suitabilities of 428 Cryptographic Algorithms (DSSC)", October 2007. 430 [LTANS-ERS-SCVP] 431 IETF, "Using SCVP to Convey Long-term Evidence Records", 432 November 2007. 434 [MER1980] Merkle, R., "Protocols for Public Key Cryptosystems, 435 Proceedings of the 1980 IEEE Symposium on Security and 436 Privacy (Oakland, CA, USA)", pages 122-134, April 1980. 438 [REQ2004] Wallace, C., Brandner, R., and U. Pordesch, "Long-term 439 Archive Service Requirements", I-D ???, 2005. 441 Authors' Addresses 443 Tobias Gondrom 444 Munich 445 Germany 447 Email: tobias.gondrom@gondrom.org 449 Stefanie Fischer-Dieskau