idnits 2.17.1 draft-ietf-ltans-dssc-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2009) is 5428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1257 -- Looks like a reference, but probably isn't: '1' on line 1258 -- Looks like a reference, but probably isn't: '2' on line 1235 -- Looks like a reference, but probably isn't: '3' on line 1236 -- Looks like a reference, but probably isn't: '4' on line 1237 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Long-term Archive And Notary T. Kunz 3 Services (LTANS) Fraunhofer Institute for Secure 4 Internet-Draft Information Technology 5 Intended status: Standards Track S. Okunick 6 Expires: December 17, 2009 pawisda systems GmbH 7 U. Pordesch 8 Fraunhofer Gesellschaft 9 June 15, 2009 11 Data Structure for the Security Suitability of Cryptographic Algorithms 12 (DSSC) 13 draft-ietf-ltans-dssc-09.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 17, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Since cryptographic algorithms can become weak over the years, it is 52 necessary to evaluate their security suitability. When signing or 53 verifying data, or when encrypting or decrypting data, these 54 evaluations must be considered. This document specifies a data 55 structure that enables an automated analysis of the security 56 suitability of a given cryptographic algorithm at a given point of 57 time which may be in the past, at the present time or in the future. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Requirements and Assumptions . . . . . . . . . . . . . . . . . 8 72 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 74 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1. SecuritySuitabilityPolicy . . . . . . . . . . . . . . . . 10 76 3.2. PolicyName . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.3. Publisher . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.4. Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.5. PolicyIssueDate . . . . . . . . . . . . . . . . . . . . . 12 80 3.6. NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.8. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 12 83 3.9. AlgorithmIdentifier . . . . . . . . . . . . . . . . . . . 13 84 3.10. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 13 85 3.11. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.12. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 3.13. Information . . . . . . . . . . . . . . . . . . . . . . . 15 88 3.14. Signature . . . . . . . . . . . . . . . . . . . . . . . . 16 89 4. Definition of Parameters . . . . . . . . . . . . . . . . . . . 17 90 5. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 5.2. Verify policy . . . . . . . . . . . . . . . . . . . . . . 18 93 5.3. Algorithm evaluation . . . . . . . . . . . . . . . . . . . 18 94 5.4. Evaluation of parameters . . . . . . . . . . . . . . . . . 19 95 5.5. Output . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 101 Appendix A. DSSC and ERS . . . . . . . . . . . . . . . . . . . . 26 102 A.1. Verification of Evidence Records using DSSC 103 (informative) . . . . . . . . . . . . . . . . . . . . . . 26 104 A.2. Storing DSSC Policies in Evidence Records (normative) . . 26 105 Appendix B. XML schema (normative) . . . . . . . . . . . . . . . 27 106 Appendix C. ASN.1 Module in 1988 Syntax (informative) . . . . . . 30 107 Appendix D. ASN.1 Module in 1997 Syntax (normative) . . . . . . . 33 108 Appendix E. Example . . . . . . . . . . . . . . . . . . . . . . . 36 109 Appendix F. Disclaimer . . . . . . . . . . . . . . . . . . . . . 41 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 112 1. Introduction 114 1.1. Motivation 116 Digital signatures can provide data integrity and authentication. 117 They are based on cryptographic algorithms that are required to have 118 certain security properties. For example, hash algorithms must be 119 resistant to collisions and in case of public key algorithms 120 computation of the private key that corresponds to a given public key 121 must be infeasible. If algorithms lack the required properties, 122 signatures could be forged, unless they are protected by a strong 123 cryptographic algorithm. 125 Cryptographic algorithms that are used in signatures shall be 126 selected to resist such attacks during their period of use. For 127 signature keys included in public key certificates, it is the 128 validity period of the certificate. Cryptographic algorithms that 129 are used for encryption shall resist during the time during which it 130 is planned to keep the information confidential. 132 Only very few algorithms satisfy the security requirements. Besides, 133 because of the increasing performance of computers and progresses in 134 cryptography, algorithms or their parameters become insecure over the 135 years. The hash algorithm MD5, for example, is unsuitable today for 136 many purposes. A digital signature using a "weak" algorithm has no 137 probative value, unless the "weak" algorithm has been protected by a 138 strong algorithm before the time it was considered to be weak. Many 139 kinds of digital signed data, including signed documents, time 140 stamps, certificates, and revocation lists, are affected, in 141 particular in the case of long-term archiving. Over long periods of 142 time, it is assumed that the algorithms used in signatures become 143 insecure. 145 For this reason, it is important to periodically evaluate an 146 algorithm's fitness and to consider the results of these evaluations 147 when creating and verifying signatures, or when maintaining the 148 validity of signatures made in the past. One result is a projected 149 validity period for the algorithm, i.e., a prediction of the period 150 of time during which the algorithm is fit for use. This prediction 151 can help to detect whether a weak algorithm is used in a signature 152 and whether that signature has been properly protected in due time by 153 another signature made using an algorithm that is suitable at the 154 present point of time. Algorithm evaluations are made by expert 155 committees. In Germany the Federal Network Agency annually publishes 156 evaluations of cryptographic algorithms [BNetzAg.2008]. Examples of 157 other European and international evaluations are 158 [ETSI-TS102176-1-2005] and [NIST.800-57-Part1.2006]. 160 These evaluations are published in documents intended to be read by 161 humans. Therefore it is necessary to define a data structure that 162 expresses the content of the evaluations to enable automated 163 processing. This standardized data structure can be used for 164 publication and can be interpreted by signature generation and 165 verification tools. Algorithm evaluations are pooled in a security 166 suitability policy. In this document a data structure for a security 167 suitability policy is specified. This document does not attempt to 168 catalog the security properties of cryptographic algorithms. 170 1.2. Terminology 172 Algorithm: A cryptographic algorithm, i.e. a public key or hash 173 algorithm. For public key algorithms, this is the algorithm with 174 its parameters, if any. Furthermore, the term 'algorithm' is used 175 for combinations of public key and hash algorithms, and actually 176 padding functions (e.g. the signature algorithm SHA-1 with RSA). 178 Operator: Instance which uses and interprets a policy, e.g. a 179 signature verification component. 181 Policy: An abbreviation for security suitability policy. 183 Publisher: Instance that publishes the policy containing the 184 evaluation of algorithms. 186 Security suitability policy: The evaluation of cryptographic 187 algorithms with regard to their security in a specific application 188 area, e.g. signing or verifying data. The evaluation is published 189 in an electronic format. 191 Suitable algorithm: An algorithm which is evaluated against a policy 192 and determined to be valid, i.e. resistant against attacks, at a 193 particular point of time. 195 1.3. Use Cases 197 In the following some use cases for a security suitability policy are 198 presented. 200 Long-term archiving: The most important use case is long-term 201 archiving of signed data. Algorithms or their parameters become 202 insecure over long time periods. Therefore signatures of archived 203 data and timestamps have to be periodically renewed. A policy 204 provides information about suitable and threatened algorithms. 205 Additionally the policy assists in verifying archived as well as 206 re-signed documents. 208 Services: Services may provide information about cryptographic 209 algorithms. On the basis of a policy a service is able to provide 210 the date when an algorithm became insecure or presumably will 211 become insecure or to provide all algorithms which are presently 212 valid. Verification tools or long-term archiving systems can 213 request such services and therefore do not need to deal with the 214 algorithm security by themselves. 215 Long-term Archive Services (LTA) as defined in [RFC4810] may use 216 the policy for signature renewal. 218 Signing and verifying: When signing documents, or certificates, it 219 must be assured that the algorithms used for signing or verifying 220 are suitable. Accordingly, when verifying CMS [RFC3852] or XML 221 signatures [RFC3275] [ETSI-TS101903], not only the validity of the 222 certificates may be checked but also the validity of the 223 algorithms. 225 Re-encryption: A security suitability policy can also be used to 226 decide if encrypted documents must be re-encrypted because the 227 encryption algorithm is no longer secure. 229 2. Requirements and Assumptions 231 Section 2.1 describes general requirements for a data structure 232 containing the security suitability of algorithms. In Section 2.2 233 assumptions are specified concerning both the design and the usage of 234 the data structure. 236 A policy contains a list of algorithms that have been evaluated by a 237 publisher. An algorithm evaluation is described by its identifier, 238 security constraints and validity period. By these constraints the 239 requirements for algorithm properties must be defined, e.g. a public 240 key algorithm is evaluated on the basis of its parameters. 242 2.1. Requirements 244 Automatic interpretation: The data structure of the policy must 245 allow automated evaluation of the security suitability of an 246 algorithm. 248 Flexibility: The data structure must be flexible enough to support 249 new algorithms. Future policy publications may include 250 evaluations of algorithms that are currently unknown. It must be 251 possible to add new algorithms with the corresponding security 252 constraints in the data structure. Additionally the data 253 structure must be independent of the intended use, e.g., 254 encryption, signing, verifying, and signature renewing. Thus, the 255 data struture is usable in every use case. 257 Source authentication: Policies may be published by different 258 institutions, e.g. on national or EU level, whereas one policy 259 needs not to be in agreement with the other one. Furthermore 260 organizations may undertake their own evaluations for internal 261 purposes. For this reason a policy must be attributable to its 262 publisher. 264 Integrity and authenticity: It must be possible to assure the 265 integrity and authenticity of a published security suitability 266 policy. Additionally the date of issue must be identifiable. 268 2.2. Assumptions 270 It is assumed that a policy contains the evaluations of all currently 271 known algorithms, including the expired ones. 273 An algorithm is suitable at a time of interest if it is contained in 274 the current policy and the time of interest is within the validity 275 period. Additionally, if the algorithm has any parameters, these 276 parameters must meet the requirements defined in the security 277 constraints. 279 If an algorithm appears in a policy for the first time, it may be 280 assumed that the algorithm has already been suitable in the past. 281 Generally, algorithms are used in practice prior to evaluation. 283 To avoid inconsistencies, multiple instances of the same algorithm 284 are prohibited. The publisher must take care about preventing 285 conflicts within a policy. 287 Assertions made in the policy are suitable at least until the next 288 policy is published. 290 Publishers may extend the lifetime of an algorithm prior to reaching 291 the end of the algorithm's validity period by publishing a revised 292 policy. Publishers should not resurrect algorithms that are expired 293 at the time a revised policy is published. 295 3. Data Structures 297 This section describes the syntax of a security suitability policy 298 defined as an XML schema. ASN.1 modules are defined in Appendix C 299 and Appendix D. The schema uses the following namespace: 301 http://www.sit.fraunhofer.de/dssc 303 Within this document, the prefix "dssc" is used for this namespace. 304 The schema starts with the following schema definition: 306 307 313 315 318 3.1. SecuritySuitabilityPolicy 320 The SecuritySuitabilityPolicy element is the root element of a 321 policy. It has an optional id attribute which must be used as a 322 reference when signing the policy (Section 3.14). The element is 323 defined by the following schema: 325 327 328 329 330 331 332 333 334 335 336 337 338 339 341 3.2. PolicyName 343 The PolicyName element consists of an arbitrary name of the policy 344 and an optional Uniform Resource Identifier (URI). 346 347 348 349 350 351 352 354 355 357 3.3. Publisher 359 The Publisher element contains information about the publisher of the 360 policy. It is composed of the name, e.g. name of institution, an 361 optional address, and an optional URI. 363 364 365 366 367 368 369 370 372 3.4. Address 374 The Address element consists of the street, the locality, the 375 optional state or province, the postal code, and the country. 377 378 379 380 381 382 383 384 385 386 388 3.5. PolicyIssueDate 390 The PolicyIssueDate element indicates the point of time when the 391 policy was issued. 393 3.6. NextUpdate 395 The optional NextUpdate element may be used to indicate when the next 396 policy will be issued. 398 3.7. Usage 400 The optional Usage element determines the intended use of the policy 401 (e.g. certificate validation, signing and verifying documents). 403 3.8. Algorithm 405 A security suitability policy must contain at least one Algorithm 406 element. An algorithm is identified by an AlgorithmIdentifier 407 element. Additionally the Algorithm element contains all evaluations 408 of the specific cryptographic algorithm. More than one evaluation 409 may be necessary if the evaluation depends on the parameter 410 constraints. The Algorithm element is defined by the following 411 schema: 413 414 415 416 417 418 419 420 422 3.9. AlgorithmIdentifier 424 The AlgorithmIdentifier element is used to identify a cryptographic 425 algorithm. It consists of the algorithm name, at least one object 426 identifer, and optional URIs. The element is defined as follows: 428 430 431 432 433 435 436 437 439 3.10. Evaluation 441 The evaluation element contains the evaluation of one cryptographic 442 algorithm in dependence of its parameter contraints. E.g. the 443 suitability of the RSA algorithm depends on the modulus length (RSA 444 with a modulus length of 1024 may have another suitability period as 445 RSA with a modulus length of 2048). Current hash algorithms like 446 SHA-1 or RIPEMD-160 do not have any parameters. Therefore the 447 Parameter element is optional. The suitability of the algorithm is 448 expressed by a validity period which is defined by the Validity 449 element. 451 452 453 454 456 457 458 460 3.11. Parameter 462 The Parameter element is used to express constraints on algorithm 463 specific parameters like the "moduluslength" parameter in case of 464 RSA. 466 The Parameter element has a name attribute which holds the name of 467 the parameter (e.g. "moduluslength" for RSA [RFC3447]). Besides a 468 better readability of the policy, the attribute may be used by 469 implementations for output messages. In Section 4 the parameter 470 names of currently known signature algorithms are defined. For the 471 actual parameter, an exact value or a range of values may be defined. 472 These constraints are expressed by the following elements: 474 Exact: The Exact element specifies the exact value of the parameter. 476 Min: The Min element defines the minimum value of the parameter. 477 That means, also all other values greater than the given one meet 478 the requirements. 480 Max: The Max element defines the maximum value the parameter may 481 take. 483 Range: The Range element is used to define a range of values, 484 consisting of a minimum and a maximum value. The parameter may 485 have any value within the defined range, including the minimum and 486 maximum values. 488 For one algorithm it is recommended not to mix these elements in 489 order to avoid inconsistencies. 491 These constraints are sufficient for all current algorithms. If 492 future algorithms will need constraints which cannot be expressed by 493 the elements above, an arbitrary XML structure may be inserted which 494 meets the new constraints. For this reason, the Parameter element 495 contains an "any" element. The schema for the Parameter element is 496 as follows: 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 519 3.12. Validity 521 The Validity element is used to define the period of the (predicted) 522 suitability of the algorithm. It is composed of an optional start 523 date and an optional end date. Defining no end date means the 524 algorithm has an open-end validity. Of course this may be restricted 525 by a future policy which sets an end date for the algorithm. If the 526 end of the validity period is in the past, the algorithm was suitable 527 until that end date. The element is defined by the following schema: 529 530 531 532 533 534 535 537 3.13. Information 539 The Information element may be used to give additional textual 540 information about the algorithm or the evaluation, e.g. references on 541 algorithm specifications. The element is defined as follows: 543 544 545 546 547 548 549 550 551 552 553 554 555 556 558 3.14. Signature 560 The optional Signature element may be used to guarantee the integrity 561 and authenticity of the policy. It is an XML signature specified in 562 [RFC3275]. The signature must relate to the 563 SecuritySuitabilityPolicy element. If the Signature element is set, 564 the SecuritySuitabilityPolicy element must have the optional id 565 attribute. This attribute must be used to reference the 566 SecuritySuitabilityPolicy element within the Signature element. 567 Since it is an enveloped signature, the signature must use the 568 transformation algorithm identified by the following URI: 570 http://www.w3.org/2000/09/xmldsig#enveloped-signature 572 4. Definition of Parameters 574 This section defines the parameter names for the currently known 575 public key algorithms. The signature algorithms RSA [RFC3447] and 576 DSA [FIPS186-2] are generally used in conjunction with a one-way hash 577 algorithm. Examples of such combined algorithms are SHA-256 with RSA 578 and SHA-1 with DSA. The following parameters refer to the 579 appropriate combined algorithms as well. 581 The parameter of RSA should be named "moduluslength". 583 The parameters for DSA should be "plength" and "qlength". 585 Publishers of policies must use the same parameter names, so that the 586 correct interpretation is guaranteed. 588 For future algorithms, it may be necessary to update the information 589 in this section. We suggest to handle this by the means of the IETF 590 standards action (e.g. an updating RFC, which defines the parameter 591 names of new algorithms). 593 5. Processing 595 Evaluation of an algorithm's security suitability is described in 596 three parts: verification of the policy, determination of algorithm 597 validity, and evaluation of algorithm parameters, if any. 599 In the following, a process is described 601 o to determine if an algorithm was suitable at a particular point of 602 time 604 o and to determine until when an algorithm was or will be suitable. 606 5.1. Inputs 608 To determine the security suitability of an algorithm, the following 609 information is required: 611 o Policy 613 o Current time 615 o Algorithm identifier and parameter constraints (if associated) 617 o Time of interest (optional). Providing no time of interest means 618 determination of the validity end date of algorithm. 620 5.2. Verify policy 622 The signature on the policy SHOULD be verified and a certification 623 path from the policy signer's certificate to a current trust anchor 624 SHOULD be constructed and validated [RFC5280]. The algorithms used 625 to verify the digital signature and validate the certification path 626 MUST be suitable per the contents of the policy being verified. If 627 signature verification fails, certification path validation fails or 628 an unsuitable algorithm is required to perform these checks, then the 629 policy MUST be rejected. 631 The nextUpdate time in the policy MUST be greater than the current 632 time or absent. If the nextUpdate time is less than the current 633 time, the policy MUST be rejected. 635 5.3. Algorithm evaluation 637 To determine the validity period of an algorithm, locate the 638 Algorithm element in the policy that corresponds to the algorithm 639 identifier provided as input. The Algorithm element is located by 640 comparing the object identifier in the element to the object 641 identifier included in the algorithm identifier provided as input. 643 If no matching Algorithm element is found, then the algorithm is 644 unknown. 646 If the time of interest was provided as input, the validity of each 647 Evaluation element MUST be checked in order to determine if the 648 algorithm was suitable at the time of interest. For each Evaluation 649 element, 651 o Confirm the Start time is less than the time of interest or 652 absent. Discard the entry if the Start time is present and 653 greater than the time of interest. 655 o Confirm the End time is greater than the time of interest or 656 absent. Discard the entry if the End time is present and less 657 than the time of interest. 659 If all Evaluation elements were rejected, the algorithm is not 660 suitable according the policy. 662 Any entries not rejected will be used for the evaluation of the 663 parameters, if any. 665 5.4. Evaluation of parameters 667 Any necessary parameters of the entries not rejected MUST be 668 evaluated within the context of the type and usage of the algorithm. 669 Details of parameter evaluation are defined on a per algorithm basis. 671 To evaluate the parameters, the Parameter elements of each Evaluation 672 element that has not been rejected in the process described in 673 Section 5.3 must be checked. For each Parameter element, 675 o Confirm that the parameter was provided as input. Discard the 676 Evaluation element if the parameter does not match to any of the 677 parameters provided as input. 679 o If the Parameter element has an Exact element, confirm that the 680 parameter value exactly complies with the according parameter 681 provided as input. Discard the Evaluation element if the 682 parameter value does not comply. 684 o If the Parameter element has a Min element, confirm that the 685 parameter value is less than or equal to the according parameter 686 provided as input. Discard the Evaluation element if the 687 parameter value does not meet the constraint. 689 o If the Parameter element has a Max element, confirm that the 690 parameter value is greater than or equal to the according 691 parameter provided as input. Discard the Evaluation element if 692 the parameter value does not meet the constraint. 694 o If the Parameter element has a Range element, confirm that the 695 value of the according parameter provided as input is within the 696 range. Discard the Evaluation element if the parameter value does 697 not meet the constraint. 699 o If the Parameter has another constraint, confirm that the value of 700 the according parameter provided as input meets this constraint. 701 If it does not or if the constraint is unrecognized, discard the 702 Evaluation element. 704 If all Evaluation elements were rejected, the algorithm is not 705 suitable according the policy. 707 Any entries not rejected will be provided as output. 709 5.5. Output 711 If the algorithm is not in the policy, return an error "algorithm 712 unknown". 714 If no time of interest was provided as input, return the maximum End 715 time of the Evaluation elements that were not discarded. If at least 716 one End time of these Evaluation elements is absent, return 717 "algorithm has an indefinite end time". 719 Otherwise, if the algorithm is not suitable relative to the time of 720 interest, return an error "algorithm unsuitable". 722 If the algorithm is suitable relative to the time of interest, return 723 the Evaluation elements that were not discarded. 725 6. Security Considerations 727 The policy for algorithm's security suitability has great impact on 728 the quality of the results of signature generation and verification 729 operations. If an algorithm is incorrectly evaluated against a 730 policy, signatures with a low probative force could be created or 731 verification results could be incorrect. The following security 732 considerations have been identified: 734 1. Publishers must ensure unauthorized manipulation of any security 735 suitability is not possible prior to a policy being signed and 736 published. There is no mechanism provided to revoke a policy 737 after publication. Since the algorithm evaluations change 738 infrequently, the lifespan of a policy should be carefully 739 considered prior to publication. 741 2. Operators should only accept policies issued by a trusted 742 publisher. It must not be possible to alter or replace a 743 security suitability once accepted by the client. 745 3. Operators should periodically check to see if a new policy has 746 been published to avoid using obsolete policy information. For 747 publishers it is suggested not to omit the NextUpdate element in 748 order to give operators a hint, when the next policy will be 749 published. 751 4. When signing a policy, algorithms should be used which are 752 suitable according this policy. 754 5. The processing rule described in Section 5 is about one 755 cryptographic algorithm independently of the use case. Depending 756 upon the use case, an algorithm that is no more suitable at the 757 time of interest, does not necessarily mean that the data 758 structure where it is used is no more secure. For example, a 759 signature has been made with an RSA signer's key of 1024 bits. 760 This signature is time-stamped with a time-stamp token that uses 761 an RSA key of 2048 bits, before an RSA key size of 1024 bits will 762 be broken. The fact that the signature key of 1024 bits is no 763 more suitable at the time of interest does not mean that the 764 whole data structure is no more secure, if an RSA key size of 765 2048 bits is still suitable at the time of interest. 767 6. In addition to the key size considerations, other considerations 768 must be applied, like whether a time-stamp token has been 769 provided by a trusted authority. It means that the simple use of 770 a suitability policy is not the single element to consider when 771 evaluating the security of a complex data structure using several 772 cryptographic algorithms. 774 7. Re-encrypting documents that were originally encrypted using an 775 algorithm that is no more suitable, will not protect the 776 semantics of the document, if the document has been intercepted. 777 However, for documents stored in an encrypted form, re-encryption 778 must be considered, unless the document has lost its original 779 value. 781 7. IANA Considerations 783 This document has no actions for IANA. Section can be removed prior 784 to publication as an RFC. 786 8. References 788 8.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 794 Language) XML-Signature Syntax and Processing", RFC 3275, 795 March 2002. 797 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 798 RFC 3852, July 2004. 800 [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence 801 Record Syntax (ERS)", RFC 4998, August 2007. 803 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 804 Housley, R., and W. Polk, "Internet X.509 Public Key 805 Infrastructure Certificate and Certificate Revocation List 806 (CRL) Profile", RFC 5280, May 2008. 808 8.2. Informative References 810 [BNetzAg.2008] 811 Federal Network Agency for Electricity, Gas, 812 Telecommunications, Post and Railway, "Bekanntmachung zur 813 elektronischen Signatur nach dem Signaturgesetz und der 814 Signaturverordnung (Uebersicht ueber geeignete 815 Algorithmen)", December 2007, 816 . 818 [ETSI-TS101903] 819 European Telecommunication Standards Institute (ETSI), 820 "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101 821 903 V1.3.2, March 2006. 823 [ETSI-TS102176-1-2005] 824 European Telecommunication Standards Institute (ETSI), 825 "Electronic Signatures and Infrastructures (ESI); 826 "Algorithms and Parameters for Secure Electronic 827 Signatures; Part 1: Hash functions and asymmetric 828 algorithms"", ETSI TS 102 176-1 V2.0.0, November 2007. 830 [FIPS186-2] 831 National Institute of Standards and Technology, "Digital 832 Signature Standard (DSS)", FIPS PUB 186-2 with Change 833 Notice, January 2000. 835 [NIST.800-57-Part1.2006] 836 National Institute of Standards and Technology, 837 "Recommendation for Key Management - Part 1: General 838 (Revised)", NIST 800-57 Part1, May 2006. 840 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 841 Standards (PKCS) #1: RSA Cryptography Specifications 842 Version 2.1", RFC 3447, February 2003. 844 [RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term 845 Archive Service Requirements", RFC 4810, March 2007. 847 Appendix A. DSSC and ERS 849 A.1. Verification of Evidence Records using DSSC (informative) 851 This section describes the verification of an Evidence Record 852 according to the Evidence Record Syntax (ERS, [RFC4998]), using the 853 presented data structure. 855 An Evidence Record contains a sequence of archiveTimeStampChains 856 which consist of ArchiveTimeStamps. For each archiveTimeStamp the 857 hash algorithm used for the hash tree (digestAlgorithm) and the 858 public key algorithm and hash algorithm in the timestamp signature 859 have to be examined. The relevant date is the time information in 860 the timestamp (date of issue). Starting with the first 861 ArchiveTimestamp it has to be assured that 863 1. The timestamp uses public key and hash algorithms which have been 864 suitable at the date of issue. 866 2. The hashtree was build with an hash algorithm that has been 867 suitable at the date of issue as well. 869 3. Algorithms for timestamp and hashtree in the preceding 870 ArchiveTimestamp must have been suitable at the issuing date of 871 considered ArchiveTimestamp. 873 4. Algorithms in the last ArchiveTimstamp have to be suitable now. 875 If the check of one of these items fails, this will lead to a failure 876 of the verification. 878 A.2. Storing DSSC Policies in Evidence Records (normative) 880 This section describes how to store a policy in an Evidence Record. 881 ERS provides the field cryptoInfos for the storage of additional 882 verification data. For the integration of a security suitability 883 policy in an Evidence Record the following content types are defined 884 for both ASN.1 and XML representation: 886 DSSC_ASN1 {iso(1) identified-organization(3) dod(6) 887 internet(1) security(5) mechanisms(5) 888 ltans(11) id-ct(1) id-ct-dssc-asn1(2) } 890 DSSC_XML {iso(1) identified-organization(3) dod(6) 891 internet(1) security(5) mechanisms(5) 892 ltans(11) id-ct(1) id-ct-dssc-xml(3) } 894 Appendix B. XML schema (normative) 896 897 903 905 907 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 946 947 948 949 950 951 952 953 954 955 956 957 958 960 961 962 963 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 989 990 991 992 993 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1020 Appendix C. ASN.1 Module in 1988 Syntax (informative) 1022 ASN.1-Module 1024 DSSC {iso(1) identified-organization(3) dod(6) 1025 internet(1) security(5) mechanisms(5) 1026 ltans(11) id-mod(0) id-mod-dssc88(6) id-mod-dssc88-v1(1) } 1028 DEFINITIONS IMPLICIT TAGS ::= 1029 BEGIN 1031 -- EXPORT ALL -- 1033 IMPORTS 1035 -- Import from RFC 5280 [RFC5280] 1036 -- Delete following import statement 1037 -- if "new" types are supported 1039 UTF8String FROM PKIX1Explicit88 1040 { iso(1) identified-organization(3) dod(6) 1041 internet(1) security(5) mechanisms(5) pkix(7) 1042 mod(0) pkix1-explicit(18) } 1044 -- Import from RFC 3852 [RFC3852] 1046 ContentInfo FROM CryptographicMessageSyntax2004 1047 { iso(1) member-body(2) us(840) 1048 rsadsi(113549) pkcs(1) pkcs-9(9) 1049 smime(16) modules(0) cms-2004(24)} 1051 ; 1053 SecuritySuitabilityPolicy ::= ContentInfo 1055 -- contentType is id-signedData as defined in [RFC3852] 1056 -- content is SignedData as defined in [RFC3852] 1057 -- eContentType within SignedData is id-ct-dssc 1058 -- eContent within SignedData is TBSPolicy 1060 id-ct-dssc OBJECT IDENTIFIER ::= { 1061 iso(1) identified-organization(3) dod(6) 1062 internet(1) security(5) mechanisms(5) 1063 ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) } 1065 TBSPolicy ::= SEQUENCE { 1066 version INTEGER { v1(1) } OPTIONAL, 1067 policyName PolicyName, 1068 publisher Publisher, 1069 policyIssueDate GeneralizedTime, 1070 nextUpdate GeneralizedTime OPTIONAL, 1071 usage UTF8String OPTIONAL, 1072 algorithms SEQUENCE OF Algorithm 1073 } 1075 PolicyName ::= SEQUENCE { 1076 name UTF8String, 1077 oid OBJECT IDENTIFIER OPTIONAL 1078 } 1080 Publisher ::= SEQUENCE { 1081 name UTF8String, 1082 address [0] Address OPTIONAL, 1083 uri [1] IA5String OPTIONAL 1084 } 1086 Address ::= SEQUENCE { 1087 street [0] UTF8String, 1088 locality [1] UTF8String, 1089 stateOrProvince [2] UTF8String OPTIONAL, 1090 postalCode [3] UTF8String, 1091 country [4] UTF8String 1092 } 1094 Algorithm ::= SEQUENCE { 1095 algorithmIdentifier AlgID, 1096 evaluations SEQUENCE OF Evaluation, 1097 information [0] SEQUENCE OF UTF8String OPTIONAL 1098 } 1100 AlgID ::= SEQUENCE { 1101 name UTF8String, 1102 oid [0] SEQUENCE OF OBJECT IDENTIFIER, 1103 uri [1] SEQUENCE OF IA5String OPTIONAL 1104 } 1106 Evaluation ::= SEQUENCE { 1107 parameters [0] SEQUENCE OF Parameter OPTIONAL, 1108 validity [1] Validity 1109 } 1111 Parameter ::= SEQUENCE { 1112 name UTF8String, 1113 constraint CHOICE { 1114 exact [0] OCTET STRING, 1115 min [1] OCTET STRING, 1116 max [2] OCTET STRING, 1117 range [3] Range, 1118 other [4] OtherConstraints 1119 } 1120 } 1122 OtherConstraints ::= SEQUENCE { 1123 otherConstraintType OBJECT IDENTIFIER, 1124 otherConstraint ANY DEFINED BY otherConstraintType 1125 } 1127 Range ::= SEQUENCE { 1128 min [0] OCTET STRING, 1129 max [1] OCTET STRING 1130 } 1132 Validity ::= SEQUENCE { 1133 start [0] GeneralizedTime OPTIONAL, 1134 end [1] GeneralizedTime OPTIONAL 1135 } 1137 END 1139 Appendix D. ASN.1 Module in 1997 Syntax (normative) 1141 ASN.1-Module 1143 DSSC {iso(1) identified-organization(3) dod(6) 1144 internet(1) security(5) mechanisms(5) 1145 ltans(11) id-mod(0) id-mod-dssc(7) id-mod-dssc-v1(1) } 1147 DEFINITIONS IMPLICIT TAGS ::= 1148 BEGIN 1150 -- EXPORT ALL -- 1152 IMPORTS 1154 -- Import from RFC 5280 [RFC5280] 1155 -- Delete following import statement 1156 -- if "new" types are supported 1158 UTF8String FROM PKIX1Explicit88 1159 { iso(1) identified-organization(3) dod(6) 1160 internet(1) security(5) mechanisms(5) pkix(7) 1161 mod(0) pkix1-explicit(18) } 1163 -- Import from RFC 3852 [RFC3852] 1165 ContentInfo FROM CryptographicMessageSyntax2004 1166 { iso(1) member-body(2) us(840) 1167 rsadsi(113549) pkcs(1) pkcs-9(9) 1168 smime(16) modules(0) cms-2004(24)} 1170 ; 1172 SecuritySuitabilityPolicy ::= ContentInfo 1174 -- contentType is id-signedData as defined in [RFC3852] 1175 -- content is SignedData as defined in [RFC3852] 1176 -- eContentType within SignedData is id-ct-dssc 1177 -- eContent within SignedData is TBSPolicy 1179 id-ct-dssc OBJECT IDENTIFIER ::= { 1180 iso(1) identified-organization(3) dod(6) 1181 internet(1) security(5) mechanisms(5) 1182 ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) } 1184 TBSPolicy ::= SEQUENCE { 1185 version INTEGER { v1(1) } OPTIONAL, 1186 policyName PolicyName, 1187 publisher Publisher, 1188 policyIssueDate GeneralizedTime, 1189 nextUpdate GeneralizedTime OPTIONAL, 1190 usage UTF8String OPTIONAL, 1191 algorithms SEQUENCE OF Algorithm 1192 } 1194 PolicyName ::= SEQUENCE { 1195 name UTF8String, 1196 oid OBJECT IDENTIFIER OPTIONAL 1197 } 1199 Publisher ::= SEQUENCE { 1200 name UTF8String, 1201 address [0] Address OPTIONAL, 1202 uri [1] IA5String OPTIONAL 1203 } 1205 Address ::= SEQUENCE { 1206 street [0] UTF8String, 1207 locality [1] UTF8String, 1208 stateOrProvince [2] UTF8String OPTIONAL, 1209 postalCode [3] UTF8String, 1210 country [4] UTF8String 1211 } 1213 Algorithm ::= SEQUENCE { 1214 algorithmIdentifier AlgID, 1215 evaluations SEQUENCE OF Evaluation, 1216 information [0] SEQUENCE OF UTF8String OPTIONAL 1217 } 1219 AlgID ::= SEQUENCE { 1220 name UTF8String, 1221 oid [0] SEQUENCE OF OBJECT IDENTIFIER, 1222 uri [1] SEQUENCE OF IA5String OPTIONAL 1223 } 1225 Evaluation ::= SEQUENCE { 1226 parameters [0] SEQUENCE OF Parameter OPTIONAL, 1227 validity [1] Validity 1228 } 1230 Parameter ::= SEQUENCE { 1231 name UTF8String, 1232 constraint CHOICE { 1233 exact [0] OCTET STRING, 1234 min [1] OCTET STRING, 1235 max [2] OCTET STRING, 1236 range [3] Range, 1237 other [4] OtherConstraints 1238 } 1239 } 1241 OtherConstraints ::= SEQUENCE { 1242 otherConstraintType CONSTRAINT-TYPE.&id ({SupportedConstraints}), 1243 otherConstraint CONSTRAINT-TYPE.&Type 1244 ({SupportedConstraints}{@otherConstraintType}) 1245 } 1247 CONSTRAINT-TYPE ::= TYPE-IDENTIFIER 1249 SupportedConstraints CONSTRAINT-TYPE ::= {...} 1251 Range ::= SEQUENCE { 1252 min [0] OCTET STRING, 1253 max [1] OCTET STRING 1254 } 1256 Validity ::= SEQUENCE { 1257 start [0] GeneralizedTime OPTIONAL, 1258 end [1] GeneralizedTime OPTIONAL 1259 } 1261 END 1263 Appendix E. Example 1265 In the following an example of a policy is presented. It is 1266 generated on the basis of an evaluation of the German Federal Network 1267 Agency ([BNetzAg.2008]). The policy consists on hash algorithms as 1268 well as public key algorithms. RSA with modulus length of 768 is an 1269 example for an expired algorithm. 1271 1273 1274 Evaluation of suitable signature algorithms 2008 1275 1276 1277 Federal Network Agency 1278 1279 2007-12-17T00:00:00 1280 Qualified electronic signatures 1281 1282 1283 SHA-1 1284 1.3.14.3.2.26 1285 1286 1287 1288 2008-06-31 1289 1290 1291 1292 1293 1294 RIPEMD-160 1295 1.3.36.3.2.1 1296 1297 1298 1299 2010-12-31 1300 1301 1302 1303 1304 1305 SHA-224 1306 2.16.840.1.101.3.4.2.4 1307 1308 1309 1310 2014-12-31 1311 1312 1313 1314 1315 1316 SHA-256 1317 2.16.840.1.101.3.4.2.1 1318 1319 1320 1321 2014-12-31 1322 1323 1324 1325 1326 1327 SHA-384 1328 2.16.840.1.101.3.4.2.2 1329 1330 1331 1332 2014-12-31 1333 1334 1335 1336 1337 1338 SHA-512 1339 2.16.840.1.101.3.4.2.3 1340 1341 1342 1343 2014-12-31 1344 1345 1346 1347 1348 1349 RSA 1350 1.2.840.113549.1.1.1 1351 1352 1353 1354 768 1355 1356 1357 2000-12-31 1359 1360 1361 1362 1363 1024 1364 1365 1366 2008-03-31 1367 1368 1369 1370 1371 1280 1372 1373 1374 2008-12-31 1375 1376 1377 1378 1379 1536 1380 1381 1382 2009-12-31 1383 1384 1385 1386 1387 1728 1388 1389 1390 2010-12-31 1391 1392 1393 1394 1395 1976 1396 1397 1398 2014-12-31 1399 ' 1400 1401 1402 1403 2048 1404 1405 1406 2014-12-31 1408 1409 1410 1411 1412 1413 DSA 1414 1.2.840.10040.4.1 1415 1416 1417 1418 1024 1419 1420 1421 160 1422 1423 1424 2007-12-31 1425 1426 1427 1428 1429 1280 1430 1431 1432 160 1433 1434 1435 2008-12-31 1436 1437 1438 1439 1440 1536 1441 1442 1443 160 1444 1445 1446 2009-12-31 1447 1448 1449 1450 1451 2048 1452 1453 1454 160 1455 1456 1457 2009-12-31 1458 1459 1460 1461 1462 2048 1463 1464 1465 224 1466 1467 1468 2014-12-31 1469 1470 1471 1472 1474 Combined algorithms should also be part of the policy since some 1475 programs know the object identifiers of combined algorithms instead 1476 of the general public key algorithm. The following excerpt describes 1477 a combined algorithm. The validity end date is given by the end 1478 dates of RSA and RIPEMD-160, in particular it is the former one. 1479 Combined algorithms could replace the public key algorithms in the 1480 policy example. They could also be listed together with public key 1481 algorithms. 1483 1484 1485 RIPEMD-160 with RSA 2048 1486 1.3.36.3.3.1.2 1487 1488 1489 1490 2048 1491 1492 1493 2010-12-31 1494 1495 1496 1498 Appendix F. Disclaimer 1500 This document may contain material from IETF Documents or IETF 1501 Contributions published or made publicly available before November 1502 10, 2008. The person(s) controlling the copyright in some of this 1503 material may not have granted the IETF Trust the right to allow 1504 modifications of such material outside the IETF Standards Process. 1505 Without obtaining an adequate license from the person(s) controlling 1506 the copyright in such materials, this document may not be modified 1507 outside the IETF Standards Process, and derivative works of it may 1508 not be created outside the IETF Standards Process, except to format 1509 it for publication as an RFC or to translate it into languages other 1510 than English. 1512 Authors' Addresses 1514 Thomas Kunz 1515 Fraunhofer Institute for Secure Information Technology 1516 Rheinstrasse 75 1517 Darmstadt D-64295 1518 Germany 1520 Email: thomas.kunz@sit.fraunhofer.de 1522 Susanne Okunick 1523 pawisda systems GmbH 1524 Robert-Koch-Strasse 9 1525 Weiterstadt D-64331 1526 Germany 1528 Email: susanne.okunick@pawisda.de 1530 Ulrich Pordesch 1531 Fraunhofer Gesellschaft 1532 Rheinstrasse 75 1533 Darmstadt D-64295 1534 Germany 1536 Email: ulrich.pordesch@zv.fraunhofer.de