Long-term Archive And Notary T. Kunz Services (LTANS) Fraunhofer Institute for Secure Internet-Draft Information Technology Intended status: Standards Track S. Okunick Expires: September 11, 2008 pawisda systems GmbH U. Pordesch Fraunhofer Gesellschaft March 10, 2008 Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) draft-ietf-ltans-dssc-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 11, 2008. Kunz, et al. Expires September 11, 2008 [Page 1] Internet-Draft DSSC March 2008 Abstract In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the used cryptographic algorithms. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure for security suitabilities of cryptographic algorithms which may be automatically interpreted. Kunz, et al. Expires September 11, 2008 [Page 2] Internet-Draft DSSC March 2008 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements and Assumptions . . . . . . . . . . . . . . . . . 7 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. SecuritySuitabilityPolicy . . . . . . . . . . . . . . . . 9 3.2. PolicyName . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Publisher . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. PolicyIssueDate . . . . . . . . . . . . . . . . . . . . . 11 3.6. NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. AlgorithmIdentifier . . . . . . . . . . . . . . . . . . . 12 3.10. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 12 3.11. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.12. Information . . . . . . . . . . . . . . . . . . . . . . . 14 3.13. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Definition of Parameters . . . . . . . . . . . . . . . . . . . 15 5. Proceeding . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Example of a Policy . . . . . . . . . . . . . . . . . 21 Appendix B. Verification of Evidence Records using DSSC . . . . . 27 Appendix C. XML schema . . . . . . . . . . . . . . . . . . . . . 28 Appendix D. ASN.1 Module in 1988 Syntax . . . . . . . . . . . . . 31 Appendix E. ASN.1 Module in 1997 Syntax . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 38 Kunz, et al. Expires September 11, 2008 [Page 3] Internet-Draft DSSC March 2008 1. Introduction 1.1. Motivation Digital signatures are means to provide data integrity and authentication. They are based on cryptographic algorithms, which must have certain security properties. For example, hash algorithms have to be resistant to collisions and in case of public key algorithms it must not be possible to compute the private key of a given public key. If algorithms did not have the required properties, signatures could be forged. Very few algorithms satisfy the security requirements and are suitable for usage in signatures. Besides, because of the increasing performance of computers and progresses in cryptography, algorithms or their parameters become insecure over the years. E.g. the hash algorithm MD5 is impractical by now. A digital signature using a "weak" algorithm has no probative value. Every kind of digital signed data like signed documents, time stamps, certificates, and revocation lists is affected, in particular in the case of long-term archiving. Over long periods of time, it is realistic to assume that the algorithms used in signatures become insecure. For this reason, it is important to periodically reevaluate algorithms regarding their security properties and to consider these evaluations when creating, verifying or renewing signatures. Such evaluations will give a prognosis how long an algorithm will be presumably secure and help to detect, whether insecure algorithms are used in a signature or whether signatures have been timely renewed. The evaluation of security suitabilites of algorithms cannot be performed by the user itself. They are made by expert committees after long scientific discussion and published by specific evaluation institutions. In Germany the Federal Network Agency annually publishes a evaluation of cryptografic algorithms [BNetzAg.2008]. Examples for European and international evaluations are [NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005]. These evaluations are published in written text and are not interpretable by computer programs. Therefore it is necessary to define an automatically interpretable data structure holding the algorithm evaluations. A standardized data structure can be used for publication and can be interpreted by e.g. signing and verification tools. In the following, an evaluation is called security suitability policy. In this document a data structure for a security suitability policy is specified. Kunz, et al. Expires September 11, 2008 [Page 4] Internet-Draft DSSC March 2008 1.2. Terminology Algorithm: In the context of this document, a cryptographic algorithm, i.e. a public key or hash algorithm. For public key algorithms this is the algorithm with its parameters. Operator: Instance which uses and interprets a policy, e.g. a signature component. Policy: In this document, an abbreviation for security suitability policy. Publisher: Instance that publishes the evaluation of algorithms as a policy. Security suitability policy: The evaluation of cryptographic algorithms with regard to their security in a specific application area, e.g. signing or verifying data. The evaluation is published in an electronic format. Suitable algorithm: An algorithm which is evaluated in a policy, i.e. is rated to be valid. 1.3. Use Cases In the following some use cases are presented for a security suitability policy. Long-term archiving: The most important use case is long-term archiving of signed data. Algorithms or their parameters become insecure over very long periods of time. Therefore signatures of archived data and timestamps have to be periodically renewed. A policy provides information about suitable and threatened algorithms. Additionally the policy assists in verifying archived and re-signed documents. Services: Services may provide information about cryptographic algorithms. On the basis of a policy a service is able to provide the date when an algorithm became insecure or presumably will become insecure or to provide all algorithms which are presently valid. Verification tools or long-term archiving systems can request such services and therefore do not need to deal with the algorithm security by themselves. Long-term Archive Services (LTA) as defined in [RFC4810]) may use the policy for signature renewal. Kunz, et al. Expires September 11, 2008 [Page 5] Internet-Draft DSSC March 2008 Signing and verifying: When signing documents, certificates or attestations, e.g. within an LTAP transaction ([I-D.ietf-ltans-ltap]), it has to be assured that the algorithms which will be used for signing are suitable. Accordingly when verifying e.g CMS ([RFC3852]) or XML signatures ([RFC3275], [ETSI-TS101903]), not only the validity of the certificates may be checked, but also the validity of the used algorithms. Reencryption: A security suitability policy can also be used to decide if encrypted documents must be reencrypted because the encryption algorithm is no longer secure. Kunz, et al. Expires September 11, 2008 [Page 6] Internet-Draft DSSC March 2008 2. Requirements and Assumptions This section first describes general requirements for a data structure containing the security suitabilities of algorithms. Afterwards model assumptions are specified concerning both the design and the usage of the data structure. A policy contains a list of evaluated algorithms. An algorithm evaluation is described by its identifier, security constraints and predicted validity period. By these constraints the requirements for algorithm properties must be defined, e.g. a public key algorithm is evaluated on the basis of its parameter. 2.1. Requirements Automatic interpretation: The data structure of the policy must allow an automatic interpretation in order to consider the security suitabilities of algorithms when signing, verifying or renewing signatures. Flexibility: The data structure must be flexible enough to support new algorithms. In a future policy publication an algorithm could be included, that is currently unknown. It must be possible to add new algorithms with the corresponding security constraints in the data structure. Besides, the data structure must be independent of the intended use, e.g. signing, verifying, and signature renewing. Considering different policies: Policies may be published by different institutions, e.g. on national or EU level, whereas one policy needs not to be in agreement with the other one. Furthermore organizations may undertake own evaluations for internal purposes. For this reason a policy must be attributable to its publisher. Integrity and authenticity: The integrity and authenticity of a published security suitability policy should be assured. The publisher must be able to sign the policy so that operators may prove the identity and trustworthiness of a policy. 2.2. Assumptions It is assumed that a policy contains the evaluations of all currently known algorithms, including the expired ones. An algorithm is valid now if it is contained in the current policy and the end of the validity period is in the future, respectivly open-end. Kunz, et al. Expires September 11, 2008 [Page 7] Internet-Draft DSSC March 2008 If an algorithm appears in a policy for the first time, it will be assumed that the algorithm has already been suitable in the past. Generally an algorithm is used in practice before it is evaluated. To avoid inconsistencies, multiple instances of the same algorithm definition as well as validity overlaps for one algorithm are prohibited. It is up to the publisher to take care about preventing conflicts within a policy. Assertions made in the policy are suitable at least until the next policy is published. An algorithm once expired must not get valid again in a future policy. There must not be any gaps in the validity periods. Kunz, et al. Expires September 11, 2008 [Page 8] Internet-Draft DSSC March 2008 3. Data Structures This section describes the syntax of a security suitability policy defined as an XML schema. The ASN.1 modules are defined in Appendix D and Appendix E. The schema uses the following namespace: http://www.sit.fraunhofer.de/dssc Within this document, the prefix "dssc" is used for this namespace. The schema starts with the following schema definition: 3.1. SecuritySuitabilityPolicy The SecuritySuitabilityPolicy element is the root element of a policy. It has an optional id attribute which must be used as a reference when signing the policy (Section 3.13). The element is defined by the following schema: Kunz, et al. Expires September 11, 2008 [Page 9] Internet-Draft DSSC March 2008 3.2. PolicyName The PolicyName element contains the name of the policy. It consists of an arbitrary name and an optional Uniform Resource Identifier (URI). 3.3. Publisher The Publisher element contains information about the publisher of the policy. It is composed of the name, e.g. name of institution, an optional address, and an optional URI. 3.4. Address The Address element consists of the street, the locality, the optional state or province, the postal code, and the country. Kunz, et al. Expires September 11, 2008 [Page 10] Internet-Draft DSSC March 2008 3.5. PolicyIssueDate The PolicyIssueDate element indicates the point of time when the policy was issued. 3.6. NextUpdate The optional NextUpdate element may be used to indicate when the next policy will be issued. 3.7. Usage The optional Usage element determines the intended use of the policy (e.g. certificate validation, signing and verifying documents). 3.8. Algorithm A security suitability policy must contain at least one Algorithm element. An Algorithm element describes the evaluation of one cryptographic algorithm. An algorithm is identified by an AlgorithmIdentifier element. Additionally specific parameter constraints, e.g. a modulus length, may be specified. The suitability of the algorithm is expressed by a validity period. The Algorithm element is defined by the following schema: Kunz, et al. Expires September 11, 2008 [Page 11] Internet-Draft DSSC March 2008 3.9. AlgorithmIdentifier The AlgorithmIdentifier element is used to identify a cryptographic algorithm. It consists of the algorithm name and optionally one or more object identifers and URIs. The element is defined as follows: 3.10. Parameter By the Parameter element, constraints on algorithm specific parameters are expressed. E.g. the suitability of the RSA algorithm depends on the "moduluslength" parameter (RSA with a modulus length of 1024 may have another suitability period as RSA with a modulus length of 2048). Note that not all algorithm suitabilities depend on parameter constraints, e.g. current hash algorithms like SHA-1 or RIPEMD-160 do not have any parameters. The Parameter element has a name attribute which holds the name of the parameter (e.g. "moduluslength" for RSA [RFC2437]). Besides a better readability of the policy, the attribute may be used by implementations for output messages. In Section 4 the parameter names of currently known signature algorithms are defined. For the actual parameter, an exact value or a range of values can be defined. These constraints are expressed by the following elements: Exact: The Exact element specifies the exact value of the parameter. Min: The Min element defines the minimum value of the parameter. That means, also all other values greater than the given one meet the requirements. Max: The Max element defines the maximum value the parameter may take. Kunz, et al. Expires September 11, 2008 [Page 12] Internet-Draft DSSC March 2008 Range: The Range element is used to define a range of values, consisting of a minimum and a maximum value. The parameter may have any value within the defined range. For one algorithm it is recommended not to mix these elements in order to avoid inconsistencies. These constraints are sufficient for all current algorithms. If future algorithms will need constraints which cannot be expressed by the elements above, an arbitrary XML structure may be inserted which meets the new constraints. For this reason, the Parameter element contains an "any" element. The schema for the Parameter element is as follows: 3.11. Validity The Validity element is used to define the period of the (predicted) suitability of the algorithm. It is composed of an optional start date and an optional end date. Defining no end date means the algorithm has an open-end validity. Of course this may be restricted by a future policy which sets an end date for the algorithm. If the end of the validity period is in the past, the algorithm is not suitable. The element is defined by the following schema: Kunz, et al. Expires September 11, 2008 [Page 13] Internet-Draft DSSC March 2008 3.12. Information The Information element may be used to give additional textual information about the algorithm or the evaluation, e.g. references on algorithm specifications. The element is defined as follows: 3.13. Signature The optional Signature element may be used to guarantee the integrity and authenticity of the policy. It is an XML signature specified in [RFC3275]. The signature must relate to the SecuritySuitabilityPolicy element. If the Signature element is set, the SecuritySuitabilityPolicy element must have the optional id attribute. This attribute must be used to reference the SecuritySuitabilityPolicy element within the Signature element. Since it is an enveloped signature, the signature must use the transformation algorithm identified by the following URI: http://www.w3.org/2000/09/xmldsig#enveloped-signature Kunz, et al. Expires September 11, 2008 [Page 14] Internet-Draft DSSC March 2008 4. Definition of Parameters This section defines the parameter names for the currently known public key algorithms. The signature algorithms RSA [RFC2437] and DSA [FIPS.186-1.1998] are always used in conjunction with a one-way hash algorithm. RSA with RIPEMD-160 is such a combined algorithm with its own object identifier. RSA and DSA may be combined with the suitable hash algorithms SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and RIPEMD-160. The following parameters refer to the appropriate combined algorithms as well. The parameter of RSA should be named "moduluslength". The parameters for DSA should be "plength" and "qlength". Publisher of policies must use the same parameter names, so that the correct interpretation is guaranteed. Kunz, et al. Expires September 11, 2008 [Page 15] Internet-Draft DSSC March 2008 5. Proceeding This section describes how to analyze a policy, i.e. how to extract the information out of the policy needed by the different use cases. To get these information, the latest policy containing all algorithms is relevant. 1. Is an algorithm currently valid? Procedure: The wanted algorithm has to be listed in the current policy. The algorithm is valid, if its validity end date is in the future or not defined. Input: algorithm Response: true or false 2. Did an algorithm have been valid at a particular date in the past? Procedure: The algorithm is valid, if it is listed in the current policy and the end of the validity period is after the particular date or is not defined. Input: algorithm and date Response: true or false 3. Until which date in the future an algorithm is predicted to be valid? Procedure: The wanted algorithm has to be listed in the current policy. If the end date of the algorithm is in the future, this is the predicted date. If the validity end date is not defined, the algorithm is valid open-end. Input: algorithm Response: date or null (open-end) or error, if the algorithm does not exist or the validity end date is in the past 4. At which date an algorithm became invalid? Procedure: The wanted algorithm has to be listed in the current policy. The particular date is the validity end date of the listed algorithm, which has to be in the past. Input: algorithm Response: date or error, if date has never been valid or is valid now 5. Which algorithms are currently valid? Procedure: All algorithms included in the current policy are valid whose validity end date is in the future or is not defined. Response: list of algorithms 6. Which algorithms have been valid at a particular date in the past? Procedure: All algorithms included in the current policy are Kunz, et al. Expires September 11, 2008 [Page 16] Internet-Draft DSSC March 2008 valid whose validity end date is after the particular date or is not defined. Additionally any algorithm newly added in one following policy has been valid. Input: date Response: list of algorithms To determine the validity of a particular algorithm, first the algorithm definition has to be found in the policy. Therefore, the algorithm identifier has to match and the parameter constraints have to be fulfilled. To fulfill means, the exact value is given or a parameter fulfills the constraint definition if its value matches the exactly defined value or is in the defined range. Kunz, et al. Expires September 11, 2008 [Page 17] Internet-Draft DSSC March 2008 6. Security Considerations The used policy for security suitabilities has great impact on the quality of signatures and verification results. If evaluations of algorithms are wrong, signatures with a low probative force could be created and verification results could be incorrect. The following security considerations have been identified: 1. An institution publishing a policy must take care via organizational measures that unauthorized manipulation of security suitabilities is impossible before a policy is signed and published. 2. A client should only accept signed policies issued by a trusted institution. It must not be possible to unnoticeably manipulate or replace security suitabilities once accepted by the client. 3. A threat arises when a client downloads a policy too late although the policy has already been published. In this case, the client would work with obsolete security suitabilities. To minimize this risk, the client should periodically check if a new policy is published. This check could be done automatically by signature and verification components. 4. When signing a policy, only algorithms should be used which are suitable according this policy. Kunz, et al. Expires September 11, 2008 [Page 18] Internet-Draft DSSC March 2008 7. References 7.1. Normative References [ETSI-TS101903] European Telecommunication Standards Institute (ETSI), "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101 903, Feb 2002. [I-D.ietf-ltans-ltap] Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)", draft-ietf-ltans-ltap-05 (work in progress), July 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007. [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007. 7.2. Informative References [BNetzAg.2008] Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway, "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Uebersicht ueber geeignete Algorithmen)", December 2007, . [ETSI-TS102176-1-2005] European Telecommunication Standards Institute (ETSI), "Electronic Signatures and Infrastructures (ESI); "Algorithms and Parameters for Secure Electronic Kunz, et al. Expires September 11, 2008 [Page 19] Internet-Draft DSSC March 2008 Signatures; Part 1: Hash functions and asymmetric algorithms"", ETSI TS 102 176-1 V1.2.1, July 2005. [FIPS.186-1.1998] National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186-1, December 1998, . [NIST.800-57-Part1.2006] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST 800-57 Part1, May 2006. [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. Kunz, et al. Expires September 11, 2008 [Page 20] Internet-Draft DSSC March 2008 Appendix A. Example of a Policy In the following an example of a policy is presented. It is generated on the basis of the last evaluation of the German Federal Network Agency ([BNetzAg.2008]). The policy consists on hash algorithms as well as public key algorithms. RSA with modulus length of 768 is an example for an expired algorithm. Evaluation of suitable signature algorithms 2008 Federal Network Agency 2007-12-17T00:00:00 Qualified electronic signatures SHA-1 1.3.14.3.2.26 2008-06-31 RIPEMD-160 1.3.36.3.2.1 2010-12-31 SHA-224 2.16.840.1.101.3.4.2.4 2014-12-31 Kunz, et al. Expires September 11, 2008 [Page 21] Internet-Draft DSSC March 2008 SHA-256 2.16.840.1.101.3.4.2.1 2014-12-31 SHA-384 2.16.840.1.101.3.4.2.2 2014-12-31 SHA-512 2.16.840.1.101.3.4.2.3 2014-12-31 RSA 768 1.2.840.113549.1.1.1 768 2000-12-31 RSA 1024 1.2.840.113549.1.1.1 1024 2008-03-31 Kunz, et al. Expires September 11, 2008 [Page 22] Internet-Draft DSSC March 2008 RSA 1280 1.2.840.113549.1.1.1 1280 2008-12-31 RSA 1536 1.2.840.113549.1.1.1 1536 2009-12-31 RSA 1728 1.2.840.113549.1.1.1 1728 2010-12-31 RSA 1976 1.2.840.113549.1.1.1 1976 2014-12-31 Kunz, et al. Expires September 11, 2008 [Page 23] Internet-Draft DSSC March 2008 RSA 2048 1.2.840.113549.1.1.1 2048 2014-12-31 DSA 1024 1.2.840.10040.4.1 1024 160 2007-12-31 DSA 1280 1.2.840.10040.4.1 1280 160 2008-12-31 DSA 1536 1.2.840.10040.4.1 Kunz, et al. Expires September 11, 2008 [Page 24] Internet-Draft DSSC March 2008 1536 160 2009-12-31 DSA 2048 1.2.840.10040.4.1 2048 160 2009-12-31 DSA 2048-224 1.2.840.10040.4.1 2048 224 2014-12-31 Combined algorithms should also be part of the policy since some programs know the object identifiers of combined algorithms instead of the general public key algorithm. The following excerpt describes a combined algorithm. The validity end date is given by the end dates of RSA and RIPEMD-160, in particular it is the former one. Kunz, et al. Expires September 11, 2008 [Page 25] Internet-Draft DSSC March 2008 Combined algorithms could replace the public key algorithms in the policy example. They could also be listed together with public key algorithms. RIPEMD-160 with RSA 2048 1.3.36.3.3.1.2 2048 2010-12-31 Kunz, et al. Expires September 11, 2008 [Page 26] Internet-Draft DSSC March 2008 Appendix B. Verification of Evidence Records using DSSC This section describes the verification of an Evidence Record according to the Evidence Record Syntax (ERS, [RFC4998]) by using the presented data structure. An Evidence Record contains a sequence of archiveTimeStampChains which consist of ArchiveTimeStamps. For each archiveTimeStamp the hash algorithm used for the hash tree (digestAlgorithm) and the public key algorithm and hash algorithm in the timestamp signature have to be examined. The definitive date is the time information in the timestamp (date of issue). Starting with the first ArchiveTimestamp it has to be assured that 1. The timestamp uses public key and hash algorithms which have been suitable at the date of issue. 2. The hashtree was build with an hash algorithm that has been suitable at the date of issue as well. 3. Algorithms for timestamp and hashtree in the preceding ArchiveTimestamp must have been suitable at the issuing date of considered ArchiveTimestamp. 4. Algorithms in the last ArchiveTimstamp have to be suitable now. If the check of one of these item fails, this will lead to a failure of the verification. ERS provides the field cryptoInfos for the storage of additional verification data. For the integration of a security suitability policy in an Evidence Record the following content types are defined for both ASN.1 and XML representation: DSSC_ASN1 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-ct(1) id-ct-dssc-asn1(2) } DSSC_XML {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-ct(1) id-ct-dssc-xml(3) } Kunz, et al. Expires September 11, 2008 [Page 27] Internet-Draft DSSC March 2008 Appendix C. XML schema Kunz, et al. Expires September 11, 2008 [Page 28] Internet-Draft DSSC March 2008 Kunz, et al. Expires September 11, 2008 [Page 29] Internet-Draft DSSC March 2008 Kunz, et al. Expires September 11, 2008 [Page 30] Internet-Draft DSSC March 2008 Appendix D. ASN.1 Module in 1988 Syntax ASN.1-Module DSSC {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-dssc88(6) id-mod-dssc88-v1(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORT ALL -- IMPORTS -- Imports from RFC 3280 [RFC3280], Appendix A.1 UTF8String, AlgorithmIdentifier, Certificate FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ; SecuritySuitabilityPolicy ::= SEQUENCE { tbsPolicy TBSPolicy, signature Signature OPTIONAL } TBSPolicy ::= SEQUENCE { version INTEGER { v1(1) } OPTIONAL, policyName PolicyName, publisher Publisher, policyIssueDate GeneralizedTime, nextUpdate GeneralizedTime OPTIONAL, usage UTF8String OPTIONAL, algorithms SEQUENCE OF Algorithm } PolicyName ::= SEQUENCE { name UTF8String, oid OBJECT IDENTIFIER OPTIONAL } Publisher ::= SEQUENCE { name UTF8String, Kunz, et al. Expires September 11, 2008 [Page 31] Internet-Draft DSSC March 2008 address [0] Address OPTIONAL, uri [1] IA5String OPTIONAL } Address ::= SEQUENCE { street [0] UTF8String, locality [1] UTF8String, stateOrProvince [2] UTF8String OPTIONAL, postalCode [3] UTF8String, country [4] UTF8String } Algorithm ::= SEQUENCE { algorithmIdentifier AlgID, parameters [0] SEQUENCE OF Parameter OPTIONAL, validity [1] Validity, information [2] SEQUENCE OF UTF8String OPTIONAL } AlgID ::= SEQUENCE { name UTF8String, oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, uri [1] SEQUENCE OF IA5String OPTIONAL } Parameter ::= SEQUENCE { name UTF8String, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints } } OtherConstraints ::= SEQUENCE { otherConstraintType OBJECT IDENTIFIER, otherConstraint ANY DEFINED BY otherConstraintType } Range ::= SEQUENCE { min [0] OCTET STRING, max [1] OCTET STRING } Validity ::= SEQUENCE { start [0] GeneralizedTime OPTIONAL, Kunz, et al. Expires September 11, 2008 [Page 32] Internet-Draft DSSC March 2008 end [1] GeneralizedTime OPTIONAL } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature OCTET STRING, certificates SEQUENCE OF Certificate OPTIONAL } END Kunz, et al. Expires September 11, 2008 [Page 33] Internet-Draft DSSC March 2008 Appendix E. ASN.1 Module in 1997 Syntax ASN.1-Module DSSC {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-dssc(7) id-mod-dssc-v1(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORT ALL -- IMPORTS -- Imports from AuthenticationFramework AlgorithmIdentifier, Certificate FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4} ; SecuritySuitabilityPolicy ::= SEQUENCE { tbsPolicy TBSPolicy, signature Signature OPTIONAL } TBSPolicy ::= SEQUENCE { version INTEGER { v1(1) } OPTIONAL, policyName PolicyName, publisher Publisher, policyIssueDate GeneralizedTime, nextUpdate GeneralizedTime OPTIONAL, usage UTF8String OPTIONAL, algorithms SEQUENCE OF Algorithm } PolicyName ::= SEQUENCE { name UTF8String, oid OBJECT IDENTIFIER OPTIONAL } Publisher ::= SEQUENCE { name UTF8String, address [0] Address OPTIONAL, Kunz, et al. Expires September 11, 2008 [Page 34] Internet-Draft DSSC March 2008 uri [1] IA5String OPTIONAL } Address ::= SEQUENCE { street [0] UTF8String, locality [1] UTF8String, stateOrProvince [2] UTF8String OPTIONAL, postalCode [3] UTF8String, country [4] UTF8String } Algorithm ::= SEQUENCE { algorithmIdentifier AlgID, parameters [0] SEQUENCE OF Parameter OPTIONAL, validity [1] Validity, information [2] SEQUENCE OF UTF8String OPTIONAL } AlgID ::= SEQUENCE { name UTF8String, oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, uri [1] SEQUENCE OF IA5String OPTIONAL } Parameter ::= SEQUENCE { name UTF8String, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints } } OtherConstraints ::= SEQUENCE { otherConstraintType CONSTRAINT-TYPE.&id ({SupportedConstraints}), otherConstraint CONSTRAINT-TYPE.&Type ({SupportedConstraints}{@otherConstraintType}) } CONSTRAINT-TYPE ::= TYPE-IDENTIFIER SupportedConstraints CONSTRAINT-TYPE ::= {...} Range ::= SEQUENCE { min [0] OCTET STRING, max [1] OCTET STRING Kunz, et al. Expires September 11, 2008 [Page 35] Internet-Draft DSSC March 2008 } Validity ::= SEQUENCE { start [0] GeneralizedTime OPTIONAL, end [1] GeneralizedTime OPTIONAL } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature OCTET STRING, certificates SEQUENCE OF Certificate OPTIONAL } END Kunz, et al. Expires September 11, 2008 [Page 36] Internet-Draft DSSC March 2008 Authors' Addresses Thomas Kunz Fraunhofer Institute for Secure Information Technology Rheinstrasse 75 Darmstadt D-64295 Germany Email: thomas.kunz@sit.fraunhofer.de Susanne Okunick pawisda systems GmbH Robert-Koch-Strasse 9 Weiterstadt D-64331 Germany Email: susanne.okunick@pawisda.de Ulrich Pordesch Fraunhofer Gesellschaft Rheinstrasse 75 Darmstadt D-64295 Germany Email: ulrich.pordesch@zv.fraunhofer.de Kunz, et al. Expires September 11, 2008 [Page 37] Internet-Draft DSSC March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kunz, et al. Expires September 11, 2008 [Page 38]