idnits 2.17.1 draft-ietf-ltans-dssc-12.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 (September 30, 2009) is 5294 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) == Missing Reference: 'RFC3279' is mentioned on line 992, but not defined == Missing Reference: 'RFC4051' is mentioned on line 990, but not defined ** Obsolete undefined reference: RFC 4051 (Obsoleted by RFC 6931) == Missing Reference: 'RFC4055' is mentioned on line 973, but not defined == Missing Reference: 'RFC3443' is mentioned on line 989, but not defined -- Looks like a reference, but probably isn't: '0' on line 1487 -- Looks like a reference, but probably isn't: '1' on line 1488 -- Looks like a reference, but probably isn't: '2' on line 1483 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 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: April 3, 2010 pawisda systems GmbH 7 U. Pordesch 8 Fraunhofer Gesellschaft 9 September 30, 2009 11 Data Structure for the Security Suitability of Cryptographic Algorithms 12 (DSSC) 13 draft-ietf-ltans-dssc-12.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 April 3, 2010. 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. PolicyIssueDate . . . . . . . . . . . . . . . . . . . . . 12 79 3.5. NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 12 80 3.6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.7. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.8. AlgorithmIdentifier . . . . . . . . . . . . . . . . . . . 13 83 3.9. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 13 84 3.10. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 14 85 3.11. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.12. Information . . . . . . . . . . . . . . . . . . . . . . . 15 87 3.13. Signature . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4. DSSC Policies . . . . . . . . . . . . . . . . . . . . . . . . 17 89 5. Definition of Parameters . . . . . . . . . . . . . . . . . . . 18 90 6. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.2. Verify policy . . . . . . . . . . . . . . . . . . . . . . 19 93 6.3. Algorithm evaluation . . . . . . . . . . . . . . . . . . . 19 94 6.4. Evaluation of parameters . . . . . . . . . . . . . . . . . 20 95 6.5. Output . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 101 Appendix A. DSSC and ERS . . . . . . . . . . . . . . . . . . . . 32 102 A.1. Verification of Evidence Records using DSSC 103 (informative) . . . . . . . . . . . . . . . . . . . . . . 32 104 A.2. Storing DSSC Policies in Evidence Records (normative) . . 32 105 Appendix B. XML schema (normative) . . . . . . . . . . . . . . . 33 106 Appendix C. ASN.1 Module in 1988 Syntax (informative) . . . . . . 36 107 Appendix D. ASN.1 Module in 1997 Syntax (normative) . . . . . . . 39 108 Appendix E. Example . . . . . . . . . . . . . . . . . . . . . . . 42 109 Appendix F. Disclaimer . . . . . . . . . . . . . . . . . . . . . 47 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 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. Therefore the document provides a 168 framework for expressing evaluations of cryptographic algorithms. 169 This document does not attempt to catalog the security properties of 170 cryptographic algorithms. Furthermore no guidelines are made about 171 which kind of algorithms shall be evaluated: For example, security 172 suitability policies may be used to evaluate public key and hash 173 algorithms, signature schemes, and encryption schemes. 175 1.2. Terminology 177 Algorithm: A cryptographic algorithm, i.e. a public key or hash 178 algorithm. For public key algorithms, this is the algorithm with 179 its parameters, if any. Furthermore, the term "algorithm" is used 180 for cryptographic schemes, and actually padding functions. 182 Operator: Instance which uses and interprets a policy, e.g. a 183 signature verification component. 185 Policy: An abbreviation for security suitability policy. 187 Publisher: Instance that publishes the policy containing the 188 evaluation of algorithms. 190 Security suitability policy: The evaluation of cryptographic 191 algorithms with regard to their security in a specific application 192 area, e.g. signing or verifying data. The evaluation is published 193 in an electronic format. 195 Suitable algorithm: An algorithm which is evaluated against a policy 196 and determined to be valid, i.e. resistant against attacks, at a 197 particular point of time. 199 1.3. Use Cases 201 In the following some use cases for a security suitability policy are 202 presented. 204 Long-term archiving: The most important use case is long-term 205 archiving of signed data. Algorithms or their parameters become 206 insecure over long time periods. Therefore signatures of archived 207 data and timestamps have to be periodically renewed. A policy 208 provides information about suitable and threatened algorithms. 209 Additionally the policy assists in verifying archived as well as 210 re-signed documents. 212 Services: Services may provide information about cryptographic 213 algorithms. On the basis of a policy a service is able to provide 214 the date when an algorithm became insecure or presumably will 215 become insecure or to provide all algorithms which are presently 216 valid. Verification tools or long-term archiving systems can 217 request such services and therefore do not need to deal with the 218 algorithm security by themselves. 219 Long-term Archive Services (LTA) as defined in [RFC4810] may use 220 the policy for signature renewal. 222 Signing and verifying: When signing documents, or certificates, it 223 must be assured that the algorithms used for signing or verifying 224 are suitable. Accordingly, when verifying CMS [RFC3852] or XML 225 signatures [RFC3275] [ETSI-TS101903], not only the validity of the 226 certificates may be checked but also the validity of the 227 algorithms. 229 Re-encryption: A security suitability policy can also be used to 230 decide if encrypted documents must be re-encrypted because the 231 encryption algorithm is no longer secure. 233 2. Requirements and Assumptions 235 Section 2.1 describes general requirements for a data structure 236 containing the security suitability of algorithms. In Section 2.2 237 assumptions are specified concerning both the design and the usage of 238 the data structure. 240 A policy contains a list of algorithms that have been evaluated by a 241 publisher. An algorithm evaluation is described by its identifier, 242 security constraints and validity period. By these constraints the 243 requirements for algorithm properties must be defined, e.g. a public 244 key algorithm is evaluated on the basis of its parameters. 246 2.1. Requirements 248 Automatic interpretation: The data structure of the policy must 249 allow automated evaluation of the security suitability of an 250 algorithm. 252 Flexibility: The data structure must be flexible enough to support 253 new algorithms. Future policy publications may include 254 evaluations of algorithms that are currently unknown. It must be 255 possible to add new algorithms with the corresponding security 256 constraints in the data structure. Additionally the data 257 structure must be independent of the intended use, e.g., 258 encryption, signing, verifying, and signature renewing. Thus, the 259 data structure is usable in every use case. 261 Source authentication: Policies may be published by different 262 institutions, e.g. on national or EU level, whereas one policy 263 needs not to be in agreement with the other one. Furthermore 264 organizations may undertake their own evaluations for internal 265 purposes. For this reason a policy must be attributable to its 266 publisher. 268 Integrity and authenticity: It must be possible to assure the 269 integrity and authenticity of a published security suitability 270 policy. Additionally the date of issue must be identifiable. 272 2.2. Assumptions 274 It is assumed that a policy contains the evaluations of all currently 275 known algorithms, including the expired ones. 277 An algorithm is suitable at a time of interest if it is contained in 278 the current policy and the time of interest is within the validity 279 period. Additionally, if the algorithm has any parameters, these 280 parameters must meet the requirements defined in the security 281 constraints. 283 If an algorithm appears in a policy for the first time, it may be 284 assumed that the algorithm has already been suitable in the past. 285 Generally, algorithms are used in practice prior to evaluation. 287 To avoid inconsistencies, multiple instances of the same algorithm 288 are prohibited. The publisher must take care about preventing 289 conflicts within a policy. 291 Assertions made in the policy are suitable at least until the next 292 policy is published. 294 Publishers may extend the lifetime of an algorithm prior to reaching 295 the end of the algorithm's validity period by publishing a revised 296 policy. Publishers should not resurrect algorithms that are expired 297 at the time a revised policy is published. 299 3. Data Structures 301 This section describes the syntax of a security suitability policy 302 defined as an XML schema [W3C.REC-xmlschema-1-20041028]. ASN.1 303 modules are defined in Appendix C and Appendix D. The schema uses 304 the following XML namespace [W3C.REC-xml-names-20060816]: 306 urn:ietf:params:xml:ns:dssc 308 Within this document, the prefix "dssc" is used for this namespace. 309 The schema starts with the following schema definition: 311 312 318 320 323 3.1. SecuritySuitabilityPolicy 325 The SecuritySuitabilityPolicy element is the root element of a 326 policy. It has an optional id attribute which MUST be used as a 327 reference when signing the policy (Section 3.13). The optional lang 328 attribute defines the language according to [RFC4646]. The language 329 is applied to all human readable text within the policy. If the lang 330 attribute is omitted, the default language is English (en). The 331 element is defined by the following schema: 333 335 336 337 338 339 340 341 342 343 344 345 346 347 348 350 3.2. PolicyName 352 The PolicyName element contains an arbitrary name for the policy. 353 The optional elements Object Identifier (OID) and Uniform Resource 354 Identifier (URI) MAY be used for the identification of the policy. 355 OIDs MUST be expressed in the dot notation. 357 358 359 360 361 362 363 364 366 367 368 369 370 371 372 373 374 376 3.3. Publisher 378 The Publisher element contains information about the publisher of the 379 policy. It is composed of the name, e.g. name of institution, an 380 optional address, and an optional URI. The Address element contains 381 arbitrary free-format text not intended for automatic processing. 383 384 385 386 387 388 389 390 392 3.4. PolicyIssueDate 394 The PolicyIssueDate element indicates the point of time when the 395 policy was issued. 397 3.5. NextUpdate 399 The optional NextUpdate element MAY be used to indicate when the next 400 policy will be issued. 402 3.6. Usage 404 The optional Usage element determines the intended use of the policy 405 (e.g. certificate validation, signing and verifying documents). The 406 element contains free-format text intended only for human 407 readability. 409 3.7. Algorithm 411 A security suitability policy MUST contain at least one Algorithm 412 element. An algorithm is identified by an AlgorithmIdentifier 413 element. Additionally the Algorithm element contains all evaluations 414 of the specific cryptographic algorithm. More than one evaluation 415 may be necessary if the evaluation depends on the parameter 416 constraints. An optional "any" element MAY be used to extend the 417 Algorithm element. The Algorithm element is defined by the following 418 schema: 420 421 422 423 424 425 426 427 428 430 3.8. AlgorithmIdentifier 432 The AlgorithmIdentifier element is used to identify a cryptographic 433 algorithm. It consists of the algorithm name, at least one OID, and 434 optional URIs. The algorithm name is not intended to be parsed by 435 automatic processes. It is only intended to be read by humans. The 436 OID MUST be expressed in dot notation (e.g. 1.3.14.3.2.26). The 437 element is defined as follows: 439 441 442 443 444 445 446 447 449 3.9. Evaluation 451 The Evaluation element contains the evaluation of one cryptographic 452 algorithm in dependence of its parameter constraints. E.g. the 453 suitability of the RSA algorithm depends on the modulus length (RSA 454 with a modulus length of 1024 may have another suitability period as 455 RSA with a modulus length of 2048). Current hash algorithms like 456 SHA-1 or RIPEMD-160 do not have any parameters. Therefore the 457 Parameter element is optional. The suitability of the algorithm is 458 expressed by a validity period which is defined by the Validity 459 element. An optional "any" element MAY be used to extend the 460 Evaluation element. 462 463 464 465 467 468 469 470 472 3.10. Parameter 474 The Parameter element is used to express constraints on algorithm 475 specific parameters. 477 The Parameter element has a name attribute which holds the name of 478 the parameter (e.g. "moduluslength" for RSA [RFC3447]). Section 5 479 defines parameter names for currently known public key algorithms 480 which SHOULD be used. For the actual parameter, a range of values or 481 an exact value may be defined. These constraints are expressed by 482 the following elements: 484 Min: The Min element defines the minimum value of the parameter. 485 That means, values equal or greater than the given value meet the 486 requirements. 488 Max: The Max element defines the maximum value the parameter may 489 take. 491 At least one of both elements MUST be set to define a range of 492 values. A range MAY also be specified by a combination of both 493 elements, whereas the value of the Min element MUST be less than or 494 equal to the value of the Max element. The parameter may have any 495 value within the defined range, including the minimum and maximum 496 values. An exact value is expressed by using the same value in both 497 the Min and the Max element. 499 These constraints are sufficient for all current algorithms. If 500 future algorithms will need constraints which cannot be expressed by 501 the elements above, an arbitrary XML structure MAY be inserted which 502 meets the new constraints. For this reason, the Parameter element 503 contains an "any" element. A parameter MUST contain at least one 504 constraint. The schema for the Parameter element is as follows: 506 507 508 509 510 511 512 513 514 516 3.11. Validity 518 The Validity element is used to define the period of the (predicted) 519 suitability of the algorithm. It is composed of an optional start 520 date and an optional end date. Defining no end date means the 521 algorithm has an open-end validity. Of course this may be restricted 522 by a future policy which sets an end date for the algorithm. If the 523 end of the validity period is in the past, the algorithm was suitable 524 until that end date. The element is defined by the following schema: 526 527 528 529 530 531 532 534 3.12. Information 536 The Information element MAY be used to give additional textual 537 information about the algorithm or the evaluation, e.g. references on 538 algorithm specifications. The element is defined as follows: 540 541 542 543 544 545 547 3.13. Signature 549 The optional Signature element MAY be used to guarantee the integrity 550 and authenticity of the policy. It is an XML signature specified in 551 [RFC3275]. The signature MUST relate to the 552 SecuritySuitabilityPolicy element. If the Signature element is set, 553 the SecuritySuitabilityPolicy element MUST have the optional id 554 attribute. This attribute MUST be used to reference the 555 SecuritySuitabilityPolicy element within the Signature element. 556 Since it is an enveloped signature, the signature MUST use the 557 transformation algorithm identified by the following URI: 559 http://www.w3.org/2000/09/xmldsig#enveloped-signature 561 4. DSSC Policies 563 DSSC policies MUST be expressed either in XML or ASN.1. However, in 564 order to reach interoperability DSSC policies SHOULD be published in 565 both XML and ASN.1. 567 In the case of XML, a DSSC policy is an XML document that MUST be 568 well-formed and SHOULD be valid. XML encoded DSSC policies MUST be 569 based on XML 1.0 [W3C.REC-xml-20081126] and MUST be encoded using 570 UTF-8 [RFC3629]. This specification makes use of XML namespaces 571 [W3C.REC-xml-names-20060816] for identifying DSSC policies. The 572 namespace URI for elements defined by this specification is a URN 573 [RFC2141], using the namespace prefix "dssc". This URN is: 575 urn:ietf:params:xml:ns:dssc 577 XML encoded DSSC policies are identified with the MIME type 578 "application/dssc+xml" and are instances of the XML schema 579 [W3C.REC-xmlschema-1-20041028] defined in Appendix B. 581 A file containing a DSSC policy in ASN.1 representation (for 582 specification of ASN.1 refer to [CCITT.x208.1988], [CCITT.x209.1988], 583 [CCITT.x680.2002] and [CCITT.x690.2002]) MUST contain only the DER 584 encoding of one DSSC policy, i.e. there MUST NOT be an extraneous 585 header or trailer information in the file. ASN.1 based DSSC policies 586 are identified with the MIME type "application/dssc+der". 587 Appropriate ASN.1 modules are defined in Appendix C (1988-ASN.1 588 syntax) and Appendix D (1997-ASN.1 syntax). 590 5. Definition of Parameters 592 This section defines the parameter names for the currently known 593 public key algorithms. The following parameters also refer to 594 cryptographic schemes based on these public key algorithms (e.g. the 595 PKCS#1 v1.5 signature scheme SHA-256 with RSA [RFC3447]). 597 The parameter of RSA [RFC3447] SHOULD be named "moduluslength". 599 The parameters for DSA [FIPS186-2] SHOULD be "plength" and 600 "qlength". 602 These parameter names are registered by IANA (see Section 8). It may 603 be necessary to register further algorithms not given in this section 604 (in particular future algorithms). The process for registering 605 parameter names of further algorithms is described in Section 8. 606 Publishers of policies SHOULD use these parameter names, so that the 607 correct interpretation is guaranteed. 609 6. Processing 611 Evaluation of an algorithm's security suitability is described in 612 three parts: verification of the policy, determination of algorithm 613 validity, and evaluation of algorithm parameters, if any. 615 In the following, a process is described 617 o to determine if an algorithm was suitable at a particular point of 618 time 620 o and to determine until when an algorithm was or will be suitable. 622 6.1. Inputs 624 To determine the security suitability of an algorithm, the following 625 information is required: 627 o Policy 629 o Current time 631 o Algorithm identifier and parameter constraints (if associated) 633 o Time of interest (optional). Providing no time of interest means 634 determination of the validity end date of algorithm. 636 6.2. Verify policy 638 The signature on the policy SHOULD be verified and a certification 639 path from the policy signer's certificate to a current trust anchor 640 SHOULD be constructed and validated [RFC5280]. The algorithms used 641 to verify the digital signature and validate the certification path 642 MUST be suitable per the contents of the policy being verified. If 643 signature verification fails, certification path validation fails or 644 an unsuitable algorithm is required to perform these checks, then the 645 policy MUST be rejected. 647 The nextUpdate time in the policy MUST be greater than the current 648 time or absent. If the nextUpdate time is less than the current 649 time, the policy MUST be rejected. 651 6.3. Algorithm evaluation 653 To determine the validity period of an algorithm, locate the 654 Algorithm element in the policy that corresponds to the algorithm 655 identifier provided as input. The Algorithm element is located by 656 comparing the OID in the element to the OID included in the algorithm 657 identifier provided as input. 659 If no matching Algorithm element is found, then the algorithm is 660 unknown. 662 If the time of interest was provided as input, the validity of each 663 Evaluation element MUST be checked in order to determine if the 664 algorithm was suitable at the time of interest. For each Evaluation 665 element, 667 o Confirm the Start time is less than the time of interest or 668 absent. Discard the entry if the Start time is present and 669 greater than the time of interest. 671 o Confirm the End time is greater than the time of interest or 672 absent. Discard the entry if the End time is present and less 673 than the time of interest. 675 If all Evaluation elements were rejected, the algorithm is not 676 suitable according the policy. 678 Any entries not rejected will be used for the evaluation of the 679 parameters, if any. 681 6.4. Evaluation of parameters 683 Any necessary parameters of the entries not rejected MUST be 684 evaluated within the context of the type and usage of the algorithm. 685 Details of parameter evaluation are defined on a per algorithm basis. 687 To evaluate the parameters, the Parameter elements of each Evaluation 688 element that has not been rejected in the process described in 689 Section 6.3 MUST be checked. For each Parameter element, 691 o Confirm that the parameter was provided as input. Discard the 692 Evaluation element if the parameter does not match to any of the 693 parameters provided as input. 695 o If the Parameter element has a Min element, confirm that the 696 parameter value is less than or equal to the according parameter 697 provided as input. Discard the Evaluation element if the 698 parameter value does not meet the constraint. 700 o If the Parameter element has a Max element, confirm that the 701 parameter value is greater than or equal to the according 702 parameter provided as input. Discard the Evaluation element if 703 the parameter value does not meet the constraint. 705 o If the Parameter has another constraint, confirm that the value of 706 the according parameter provided as input meets this constraint. 707 If it does not or if the constraint is unrecognized, discard the 708 Evaluation element. 710 If all Evaluation elements were rejected, the algorithm is not 711 suitable according the policy. 713 Any entries not rejected will be provided as output. 715 6.5. Output 717 If the algorithm is not in the policy, return an error "algorithm 718 unknown". 720 If no time of interest was provided as input, return the maximum End 721 time of the Evaluation elements that were not discarded. If at least 722 one End time of these Evaluation elements is absent, return 723 "algorithm has an indefinite end time". 725 Otherwise, if the algorithm is not suitable relative to the time of 726 interest, return an error "algorithm unsuitable". 728 If the algorithm is suitable relative to the time of interest, return 729 the Evaluation elements that were not discarded. 731 7. Security Considerations 733 The policy for algorithm's security suitability has great impact on 734 the quality of the results of signature generation and verification 735 operations. If an algorithm is incorrectly evaluated against a 736 policy, signatures with a low probative force could be created or 737 verification results could be incorrect. The following security 738 considerations have been identified: 740 1. Publishers MUST ensure unauthorized manipulation of any security 741 suitability is not possible prior to a policy being signed and 742 published. There is no mechanism provided to revoke a policy 743 after publication. Since the algorithm evaluations change 744 infrequently, the lifespan of a policy should be carefully 745 considered prior to publication. 747 2. Operators SHOULD only accept policies issued by a trusted 748 publisher. Furthermore, the validity of the certificate used to 749 sign the policy SHOULD be verifiable by CRL [RFC5280] or OCSP 750 [RFC2560]. The certificate used to sign the policy SHOULD be 751 revoked if the algorithms used in this certificate are not longer 752 suitable. It MUST NOT be possible to alter or replace a policy 753 once accepted by an operator. 755 3. Operators SHOULD periodically check to see if a new policy has 756 been published to avoid using obsolete policy information. For 757 publishers it is suggested not to omit the NextUpdate element in 758 order to give operators a hint, when the next policy will be 759 published. 761 4. When signing a policy, algorithms SHOULD be used which are 762 suitable according this policy. 764 5. The processing rule described in Section 6 is about one 765 cryptographic algorithm independently of the use case. Depending 766 upon the use case, an algorithm that is no more suitable at the 767 time of interest, does not necessarily mean that the data 768 structure where it is used is no more secure. For example, a 769 signature has been made with an RSA signer's key of 1024 bits. 770 This signature is time-stamped with a time-stamp token that uses 771 an RSA key of 2048 bits, before an RSA key size of 1024 bits will 772 be broken. The fact that the signature key of 1024 bits is no 773 more suitable at the time of interest does not mean that the 774 whole data structure is no more secure, if an RSA key size of 775 2048 bits is still suitable at the time of interest. 777 6. In addition to the key size considerations, other considerations 778 must be applied, like whether a time-stamp token has been 779 provided by a trusted authority. It means that the simple use of 780 a suitability policy is not the single element to consider when 781 evaluating the security of a complex data structure using several 782 cryptographic algorithms. 784 7. The policies described in this document are suitable to evaluate 785 basic cryptographic algorithms, like public key or hash 786 algorithms, as well as cryptographic schemes (e.g. the PKCS#1 787 v1.5 signature schemes [RFC3447]). But it MUST be kept in mind 788 that a basic cryptographic algorithm that is suitable according 789 to the policy, does not necessarily mean that any cryptographic 790 schemes based on this algorithm are also secure. For example, a 791 signature scheme based on RSA must not necessarily be secure if 792 RSA is suitable. In case of a complete signature verification 793 including validation of the certificate path, various algorithms 794 have to be checked against the policy (i.e. signature schemes of 795 signed data objects and revocation information, public key 796 algorithms of the involved certificates, etc.). Thus a policy 797 SHOULD contain evaluations of public key and hash algorithms as 798 well as signature schemes. 800 8. Re-encrypting documents that were originally encrypted using an 801 algorithm that is no more suitable, will not protect the 802 semantics of the document, if the document has been intercepted. 803 However, for documents stored in an encrypted form, re-encryption 804 must be considered, unless the document has lost its original 805 value. 807 8. IANA Considerations 809 This document defines the XML namespace "urn:ietf:params:xml:ns:dssc" 810 according to the guidelines in [RFC3688]. This namespace has been 811 registered in the IANA XML Registry. 813 This document defines an XML schema (see Appendix B) according to the 814 guidelines in [RFC3688]. This XML schema has been registered in the 815 IANA XML Registry and can be identified with the URN 816 "urn:ietf:params:xml:schema:dssc". 818 This document defines the MIME type "application/dssc+xml". This 819 MIME type has been registered by IANA under "MIME Media Types" 820 according to the procedures of [RFC4288]. 822 Type name: application 824 Subtype name: dssc+xml 826 Required parameters: none 828 Optional parameters: "charset" as specified for "application/xml" 829 in [RFC3023]. 831 Encoding considerations: Same as specified for "application/xml" 832 in [RFC3023]. 834 Security considerations: Same as specified for "application/xml" 835 in Section 10 of [RFC3023]. For further security consideration 836 see Section 7. 838 Interoperability considerations: Same as specified for 839 "application/xml" in [RFC3023]. 841 Published specification: This document 843 Applications which use this media: applications for long-term 844 archiving of signed data, applications for signing data / 845 verifying signed data, and applications for encrypting / 846 decrypting data 848 Additional information: 850 1. Magic number(s): none 852 2. File extension(s): .xdssc 853 3. Macintosh file type code: "TEXT" 855 4. Object Identifiers: none 857 Person to contact for further information: Thomas Kunz 858 (thomas.kunz@sit.fraunhofer.de) 860 Intended usage: COMMON 862 Restrictions on usage: none 864 Author/Change controller: IETF 866 This document defines the MIME type "application/dssc+der". This 867 MIME type has been registered by IANA under "MIME Media Types" 868 according to the procedures of [RFC4288]. 870 Type name: application 872 Subtype name: dssc+der 874 Required parameters: none 876 Optional parameters: none 878 Encoding considerations: binary 880 Security considerations: See Section 7. 882 Interoperability considerations: none 884 Published specification: This document 886 Applications which use this media: applications for long-term 887 archiving of signed data, applications for signing data / 888 verifying signed data, and applications for encrypting / 889 decrypting data 891 Additional information: 893 1. Magic number(s): none 895 2. File extension(s): .dssc 897 3. Macintosh file type code: none 899 4. Object Identifiers: none 900 Person to contact for further information: Thomas Kunz 901 (thomas.kunz@sit.fraunhofer.de) 903 Intended usage: COMMON 905 Restrictions on usage: none 907 Author/Change controller: IETF 909 This specification creates a new IANA registry entitled "Data 910 Structure for the Security Suitability of Cryptographic Algorithms 911 (DSSC)". This registry contains two sub-registries entitled 912 "Parameter Definitions" and "Cryptographic Algorithms". The policy 913 for future assignments to the sub-registry "Parameter Definitions" is 914 "RFC required". 916 [TO BE REMOVED: The initial values for the "Parameter Definitions" 917 sub-registry are: 919 Value Description Reference 920 -------------- ------------------------------- ------------------- 921 moduluslength Parameter for RSA [Ref. to this doc.] 922 (integer value) 923 plength Parameter for DSA [Ref. to this doc.] 924 (integer value, used together 925 with parameter "qlength") 926 qlength Parameter for DSA [Ref. to this doc.] 927 (integer value, used together 928 with parameter "plength") 930 ] 932 The sub-registry "Cryptographic Algorithms" contains textual names as 933 well as Object Identifiers (OIDs) and Uniform Resource Identifiers 934 (URIs) of cryptographic algorithms. It serves as assistance when 935 creating a new policy. The policy for future assignments is "First 936 Come First Served". When registering a new algorithm, the following 937 information MUST be provided: 939 o The textual name of the algorithm. 941 o The OID of the algorithm. 943 o A reference to a publicly available specification which defines 944 the algorithm and its identifiers. 946 Optionally, a URI MAY be provided if possible. 948 [TO BE REMOVED: The initial values for the "Cryptographic Algorithms" 949 sub-registry are: 951 Name OID / URI Reference 952 ----------------------- --------------------------------- ---------- 953 rsaEncryption 1.2.840.113549.1.1.1 [RFC3447] 955 dsa 1.2.840.10040.4.1 [RFC3279] 957 md2 1.2.840.113549.2.2 [RFC3279] 959 md5 1.2.840.113549.2.5 [RFC3279] 960 http://www.w3.org/2001/04/xmldsig-more#md5 [RFC4051] 962 sha-1 1.3.14.3.2.26 [RFC3279] 963 http://www.w3.org/2000/09/xmldsig#sha1 [RFC3275] 965 sha-224 2.16.840.1.101.3.4.2.4 [RFC4055] 966 http://www.w3.org/2001/04/xmldsig-more#sha224 [RFC4051] 968 sha-256 2.16.840.1.101.3.4.2.1 [RFC4055] 970 sha-384 2.16.840.1.101.3.4.2.2 [RFC4055] 971 http://www.w3.org/2001/04/xmldsig-more#sha384 [RFC4051] 973 sha-512 2.16.840.1.101.3.4.2.3 [RFC4055] 975 md2WithRSAEncryption 1.2.840.113549.1.1.2 [RFC3443] 977 md5WithRSAEncryption 1.2.840.113549.1.1.4 [RFC3443] 978 http://www.w3.org/2001/04/xmldsig-more#rsa-md5 [RFC4051] 980 sha1WithRSAEncryption 1.2.840.113549.1.1.5 [RFC3443] 981 http://www.w3.org/2000/09/xmldsig#rsa-sha1 [RFC3275] 983 sha256WithRSAEncryption 1.2.840.113549.1.1.11 [RFC3443] 984 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [RFC4051] 986 sha384WithRSAEncryption 1.2.840.113549.1.1.12 [RFC3443] 987 http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 [RFC4051] 989 sha512WithRSAEncryption 1.2.840.113549.1.1.13 [RFC3443] 990 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 [RFC4051] 992 sha1WithDSA 1.2.840.10040.4.3 [RFC3279] 993 http://www.w3.org/2000/09/xmldsig#dsa-sha1 [RFC3275] 995 ] 997 9. References 999 9.1. Normative References 1001 [CCITT.x680.2002] 1002 International Telephone and Telegraph Consultative 1003 Committee, "Abstract Syntax Notation One (ASN.1): 1004 Specification of basic notation", CCITT Recommendation 1005 X.680, July 2002. 1007 [CCITT.x690.2002] 1008 International Telephone and Telegraph Consultative 1009 Committee, "AASN.1 encoding rules: Specification of basic 1010 encoding Rules (BER), Canonical encoding rules (CER) and 1011 Distinguished encoding rules (DER)", CCITT Recommendation 1012 X.690, July 2002. 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, March 1997. 1017 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1019 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1020 Adams, "X.509 Internet Public Key Infrastructure Online 1021 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1023 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1024 Types", RFC 3023, January 2001. 1026 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1027 Language) XML-Signature Syntax and Processing", RFC 3275, 1028 March 2002. 1030 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1031 10646", STD 63, RFC 3629, November 2003. 1033 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1034 January 2004. 1036 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1037 RFC 3852, July 2004. 1039 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1040 Registration Procedures", BCP 13, RFC 4288, December 2005. 1042 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 1043 Languages", RFC 4646, September 2006. 1045 [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence 1046 Record Syntax (ERS)", RFC 4998, August 2007. 1048 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1049 Housley, R., and W. Polk, "Internet X.509 Public Key 1050 Infrastructure Certificate and Certificate Revocation List 1051 (CRL) Profile", RFC 5280, May 2008. 1053 [W3C.REC-xml-20081126] 1054 Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., 1055 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1056 Edition)", World Wide Web Consortium Recommendation REC- 1057 xml-20081126, November 2008, 1058 . 1060 [W3C.REC-xml-names-20060816] 1061 Layman, A., Hollander, D., Tobin, R., and T. Bray, 1062 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 1063 Consortium Recommendation REC-xml-names-20060816, 1064 August 2006, 1065 . 1067 [W3C.REC-xmlschema-1-20041028] 1068 Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, 1069 "XML Schema Part 1: Structures Second Edition", World Wide 1070 Web Consortium Recommendation REC-xmlschema-1-20041028, 1071 October 2004, 1072 . 1074 9.2. Informative References 1076 [BNetzAg.2008] 1077 Federal Network Agency for Electricity, Gas, 1078 Telecommunications, Post and Railway, "Bekanntmachung zur 1079 elektronischen Signatur nach dem Signaturgesetz und der 1080 Signaturverordnung (Uebersicht ueber geeignete 1081 Algorithmen)", December 2007, 1082 . 1084 [CCITT.x208.1988] 1085 International Telephone and Telegraph Consultative 1086 Committee, "Specification of Abstract Syntax Notation One 1087 (ASN.1)", CCITT Recommendation X.208, November 1988. 1089 [CCITT.x209.1988] 1090 International Telephone and Telegraph Consultative 1091 Committee, "Specification of Basic Encoding Rules for 1092 Abstract Syntax Notation One (ASN.1)", 1093 CCITT Recommendation X.209, November 1988. 1095 [ETSI-TS101903] 1096 European Telecommunication Standards Institute (ETSI), 1097 "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101 1098 903 V1.3.2, March 2006. 1100 [ETSI-TS102176-1-2005] 1101 European Telecommunication Standards Institute (ETSI), 1102 "Electronic Signatures and Infrastructures (ESI); 1103 "Algorithms and Parameters for Secure Electronic 1104 Signatures; Part 1: Hash functions and asymmetric 1105 algorithms"", ETSI TS 102 176-1 V2.0.0, November 2007. 1107 [FIPS186-2] 1108 National Institute of Standards and Technology, "Digital 1109 Signature Standard (DSS)", FIPS PUB 186-2 with Change 1110 Notice, January 2000. 1112 [NIST.800-57-Part1.2006] 1113 National Institute of Standards and Technology, 1114 "Recommendation for Key Management - Part 1: General 1115 (Revised)", NIST 800-57 Part1, May 2006. 1117 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1118 Standards (PKCS) #1: RSA Cryptography Specifications 1119 Version 2.1", RFC 3447, February 2003. 1121 [RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term 1122 Archive Service Requirements", RFC 4810, March 2007. 1124 Appendix A. DSSC and ERS 1126 A.1. Verification of Evidence Records using DSSC (informative) 1128 This section describes the verification of an Evidence Record 1129 according to the Evidence Record Syntax (ERS, [RFC4998]), using the 1130 presented data structure. 1132 An Evidence Record contains a sequence of archiveTimeStampChains 1133 which consist of ArchiveTimeStamps. For each archiveTimeStamp the 1134 hash algorithm used for the hash tree (digestAlgorithm) and the 1135 public key algorithm and hash algorithm in the timestamp signature 1136 have to be examined. The relevant date is the time information in 1137 the timestamp (date of issue). Starting with the first 1138 ArchiveTimestamp it has to be assured that 1140 1. The timestamp uses public key and hash algorithms which have been 1141 suitable at the date of issue. 1143 2. The hashtree was build with an hash algorithm that has been 1144 suitable at the date of issue as well. 1146 3. Algorithms for timestamp and hashtree in the preceding 1147 ArchiveTimestamp must have been suitable at the issuing date of 1148 considered ArchiveTimestamp. 1150 4. Algorithms in the last ArchiveTimstamp have to be suitable now. 1152 If the check of one of these items fails, this will lead to a failure 1153 of the verification. 1155 A.2. Storing DSSC Policies in Evidence Records (normative) 1157 This section describes how to store a policy in an Evidence Record. 1158 ERS provides the field cryptoInfos for the storage of additional 1159 verification data. For the integration of a security suitability 1160 policy in an Evidence Record the following content types are defined 1161 for both ASN.1 and XML representation: 1163 DSSC_ASN1 {iso(1) identified-organization(3) dod(6) 1164 internet(1) security(5) mechanisms(5) 1165 ltans(11) id-ct(1) id-ct-dssc-asn1(2) } 1167 DSSC_XML {iso(1) identified-organization(3) dod(6) 1168 internet(1) security(5) mechanisms(5) 1169 ltans(11) id-ct(1) id-ct-dssc-xml(3) } 1171 Appendix B. XML schema (normative) 1173 1174 1180 1182 1184 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1276 Appendix C. ASN.1 Module in 1988 Syntax (informative) 1278 ASN.1-Module 1280 DSSC {iso(1) identified-organization(3) dod(6) 1281 internet(1) security(5) mechanisms(5) 1282 ltans(11) id-mod(0) id-mod-dssc88(6) id-mod-dssc88-v1(1) } 1284 DEFINITIONS IMPLICIT TAGS ::= 1285 BEGIN 1287 -- EXPORT ALL -- 1289 IMPORTS 1291 -- Import from RFC 5280 [RFC5280] 1292 -- Delete following import statement 1293 -- if "new" types are supported 1295 UTF8String FROM PKIX1Explicit88 1296 { iso(1) identified-organization(3) dod(6) 1297 internet(1) security(5) mechanisms(5) pkix(7) 1298 mod(0) pkix1-explicit(18) } 1300 -- Import from RFC 3852 [RFC3852] 1302 ContentInfo FROM CryptographicMessageSyntax2004 1303 { iso(1) member-body(2) us(840) 1304 rsadsi(113549) pkcs(1) pkcs-9(9) 1305 smime(16) modules(0) cms-2004(24)} 1307 ; 1309 SecuritySuitabilityPolicy ::= ContentInfo 1311 -- contentType is id-signedData as defined in [RFC3852] 1312 -- content is SignedData as defined in [RFC3852] 1313 -- eContentType within SignedData is id-ct-dssc 1314 -- eContent within SignedData is TBSPolicy 1316 id-ct-dssc OBJECT IDENTIFIER ::= { 1317 iso(1) identified-organization(3) dod(6) 1318 internet(1) security(5) mechanisms(5) 1319 ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) } 1321 TBSPolicy ::= SEQUENCE { 1322 version INTEGER DEFAULT {v1(1)}, 1323 language UTF8String DEFAULT "en", 1324 policyName PolicyName, 1325 publisher Publisher, 1326 policyIssueDate GeneralizedTime, 1327 nextUpdate GeneralizedTime OPTIONAL, 1328 usage UTF8String OPTIONAL, 1329 algorithms SEQUENCE OF Algorithm 1330 } 1332 PolicyName ::= SEQUENCE { 1333 name UTF8String, 1334 oid OBJECT IDENTIFIER OPTIONAL, 1335 uri IA5String OPTIONAL 1336 } 1338 Publisher ::= SEQUENCE { 1339 name UTF8String, 1340 address [0] UTF8String OPTIONAL, 1341 uri [1] IA5String OPTIONAL 1342 } 1344 Algorithm ::= SEQUENCE { 1345 algorithmIdentifier AlgID, 1346 evaluations SEQUENCE OF Evaluation, 1347 information [0] SEQUENCE OF UTF8String OPTIONAL, 1348 other [1] Extension OPTIONAL 1349 } 1351 Extension ::= SEQUENCE { 1352 extensionType OBJECT IDENTIFIER, 1353 extension ANY DEFINED BY extensionType 1354 } 1356 AlgID ::= SEQUENCE { 1357 name UTF8String, 1358 oid [0] SEQUENCE OF OBJECT IDENTIFIER, 1359 uri [1] SEQUENCE OF IA5String OPTIONAL 1360 } 1362 Evaluation ::= SEQUENCE { 1363 parameters [0] SEQUENCE OF Parameter OPTIONAL, 1364 validity [1] Validity, 1365 other [2] Extension OPTIONAL 1366 } 1368 Parameter ::= SEQUENCE { 1369 name UTF8String, 1370 min [0] INTEGER OPTIONAL, 1371 max [1] INTEGER OPTIONAL, 1372 other [2] Extension OPTIONAL 1373 } 1375 Validity ::= SEQUENCE { 1376 start [0] GeneralizedTime OPTIONAL, 1377 end [1] GeneralizedTime OPTIONAL 1378 } 1380 END 1382 Appendix D. ASN.1 Module in 1997 Syntax (normative) 1384 ASN.1-Module 1386 DSSC {iso(1) identified-organization(3) dod(6) 1387 internet(1) security(5) mechanisms(5) 1388 ltans(11) id-mod(0) id-mod-dssc(7) id-mod-dssc-v1(1) } 1390 DEFINITIONS IMPLICIT TAGS ::= 1391 BEGIN 1393 -- EXPORT ALL -- 1395 IMPORTS 1397 -- Import from RFC 5280 [RFC5280] 1398 -- Delete following import statement 1399 -- if "new" types are supported 1401 UTF8String FROM PKIX1Explicit88 1402 { iso(1) identified-organization(3) dod(6) 1403 internet(1) security(5) mechanisms(5) pkix(7) 1404 mod(0) pkix1-explicit(18) } 1406 -- Import from RFC 3852 [RFC3852] 1408 ContentInfo FROM CryptographicMessageSyntax2004 1409 { iso(1) member-body(2) us(840) 1410 rsadsi(113549) pkcs(1) pkcs-9(9) 1411 smime(16) modules(0) cms-2004(24)} 1413 ; 1415 SecuritySuitabilityPolicy ::= ContentInfo 1417 -- contentType is id-signedData as defined in [RFC3852] 1418 -- content is SignedData as defined in [RFC3852] 1419 -- eContentType within SignedData is id-ct-dssc 1420 -- eContent within SignedData is TBSPolicy 1422 id-ct-dssc OBJECT IDENTIFIER ::= { 1423 iso(1) identified-organization(3) dod(6) 1424 internet(1) security(5) mechanisms(5) 1425 ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) } 1427 TBSPolicy ::= SEQUENCE { 1428 version INTEGER DEFAULT {v1(1)}, 1429 language UTF8String DEFAULT "en", 1430 policyName PolicyName, 1431 publisher Publisher, 1432 policyIssueDate GeneralizedTime, 1433 nextUpdate GeneralizedTime OPTIONAL, 1434 usage UTF8String OPTIONAL, 1435 algorithms SEQUENCE OF Algorithm 1436 } 1438 PolicyName ::= SEQUENCE { 1439 name UTF8String, 1440 oid OBJECT IDENTIFIER OPTIONAL, 1441 uri IA5String OPTIONAL 1442 } 1444 Publisher ::= SEQUENCE { 1445 name UTF8String, 1446 address [0] UTF8String OPTIONAL, 1447 uri [1] IA5String OPTIONAL 1448 } 1450 Algorithm ::= SEQUENCE { 1451 algorithmIdentifier AlgID, 1452 evaluations SEQUENCE OF Evaluation, 1453 information [0] SEQUENCE OF UTF8String OPTIONAL, 1454 other [1] Extension OPTIONAL 1455 } 1457 Extension ::= SEQUENCE { 1458 extensionType EXTENSION-TYPE.&id ({SupportedExtensions}), 1459 extension EXTENSION-TYPE.&Type 1460 ({SupportedExtensions}{@extensionType}) 1461 } 1463 EXTENSION-TYPE ::= TYPE-IDENTIFIER 1465 SupportedExtensions EXTENSION-TYPE ::= {...} 1467 AlgID ::= SEQUENCE { 1468 name UTF8String, 1469 oid [0] SEQUENCE OF OBJECT IDENTIFIER, 1470 uri [1] SEQUENCE OF IA5String OPTIONAL 1471 } 1473 Evaluation ::= SEQUENCE { 1474 parameters [0] SEQUENCE OF Parameter OPTIONAL, 1475 validity [1] Validity, 1476 other [2] Extension OPTIONAL 1477 } 1479 Parameter ::= SEQUENCE { 1480 name UTF8String, 1481 min [0] INTEGER OPTIONAL, 1482 max [1] INTEGER OPTIONAL, 1483 other [2] Extension OPTIONAL 1484 } 1486 Validity ::= SEQUENCE { 1487 start [0] GeneralizedTime OPTIONAL, 1488 end [1] GeneralizedTime OPTIONAL 1489 } 1491 END 1493 Appendix E. Example 1495 The following example shows a policy which may be used for signature 1496 verification. It contains hash algorithms, public key algorithms, 1497 and signature schemes. SHA-1 as well as RSA with modulus length of 1498 1024 are examples for expired algorithms. 1500 1502 1503 Evaluation of cryptographic algorithms 1504 1505 1506 Some Evaluation Authority 1507 1508 2009-01-01T00:00:00 1509 Digital signature verification 1510 1511 1512 SHA-1 1513 1.3.14.3.2.26 1514 1515 1516 1517 2008-06-30 1518 1519 1520 1521 1522 1523 SHA-256 1524 2.16.840.1.101.3.4.2.1 1525 1526 1527 1528 2014-12-31 1529 1530 1531 1532 1533 1534 SHA-512 1535 2.16.840.1.101.3.4.2.3 1536 1537 1538 1539 2014-12-31 1541 1542 1543 1544 1545 1546 RSA 1547 1.2.840.113549.1.1.1 1548 1549 1550 1551 1024 1552 1553 1554 2008-03-31 1555 1556 1557 1558 1559 2048 1560 1561 1562 2014-12-31 1563 1564 1565 1566 1567 1568 DSA 1569 1.2.840.10040.4.1 1570 1571 1572 1573 1024 1574 1575 1576 160 1577 1578 1579 2007-12-31 1580 1581 1582 1583 1584 2048 1585 1586 1587 224 1588 1589 1590 2014-12-31 1591 1592 1593 1594 1595 1596 PKCS#1 v1.5 SHA-1 with RSA 1597 1.2.840.113549.1.1.5 1598 1599 1600 1601 1024 1602 1603 1604 2008-03-31 1605 1606 1607 1608 1609 2048 1610 1611 1612 2008-06-30 1613 1614 1615 1616 1617 1618 PKCS#1 v1.5 SHA-256 with RSA 1619 1.2.840.113549.1.1.11 1620 1621 1622 1623 1024 1624 1625 1626 2008-03-31 1627 1628 1629 1630 1631 2048 1632 1633 1634 2014-12-31 1635 1636 1638 1639 1640 1641 PKCS#1 v1.5 SHA-512 with RSA 1642 1.2.840.113549.1.1.13 1643 1644 1645 1646 1024 1647 1648 1649 2008-03-31 1650 1651 1652 1653 1654 2048 1655 1656 1657 2014-12-31 1658 1659 1660 1661 1662 1663 SHA-1 with DSA 1664 1.2.840.10040.4.3 1665 1666 1667 1668 1024 1669 1670 1671 160 1672 1673 1674 2007-12-31 1675 1676 1677 1678 1679 2048 1680 1681 1682 224 1683 1684 1685 2008-06-30 1687 1688 1689 1690 1692 Appendix F. Disclaimer 1694 This document may contain material from IETF Documents or IETF 1695 Contributions published or made publicly available before November 1696 10, 2008. The person(s) controlling the copyright in some of this 1697 material may not have granted the IETF Trust the right to allow 1698 modifications of such material outside the IETF Standards Process. 1699 Without obtaining an adequate license from the person(s) controlling 1700 the copyright in such materials, this document may not be modified 1701 outside the IETF Standards Process, and derivative works of it may 1702 not be created outside the IETF Standards Process, except to format 1703 it for publication as an RFC or to translate it into languages other 1704 than English. 1706 Authors' Addresses 1708 Thomas Kunz 1709 Fraunhofer Institute for Secure Information Technology 1710 Rheinstrasse 75 1711 Darmstadt D-64295 1712 Germany 1714 Email: thomas.kunz@sit.fraunhofer.de 1716 Susanne Okunick 1717 pawisda systems GmbH 1718 Robert-Koch-Strasse 9 1719 Weiterstadt D-64331 1720 Germany 1722 Email: susanne.okunick@pawisda.de 1724 Ulrich Pordesch 1725 Fraunhofer Gesellschaft 1726 Rheinstrasse 75 1727 Darmstadt D-64295 1728 Germany 1730 Email: ulrich.pordesch@zv.fraunhofer.de