doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc5698.txt b/doc/rfc/rfc5698.txt
new file mode 100644
index 0000000..235b027
--- /dev/null
+++ b/doc/rfc/rfc5698.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group                                            T. Kunz
+Request for Comments: 5698                                Fraunhofer SIT
+Category: Standards Track                                     S. Okunick
+                                                    pawisda systems GmbH
+                                                             U. Pordesch
+                                                 Fraunhofer Gesellschaft
+                                                           November 2009
+
+
+              Data Structure for the Security Suitability
+                   of Cryptographic Algorithms (DSSC)
+
+Abstract
+
+   Since cryptographic algorithms can become weak over the years, it is
+   necessary to evaluate their security suitability.  When signing or
+   verifying data, or when encrypting or decrypting data, these
+   evaluations must be considered.  This document specifies a data
+   structure that enables an automated analysis of the security
+   suitability of a given cryptographic algorithm at a given point of
+   time, which may be in the past, the present, or the future.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 1]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 2]
+
+RFC 5698                          DSSC                     November 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Motivation .................................................4
+      1.2. Terminology ................................................5
+           1.2.1. Conventions Used in This Document ...................5
+      1.3. Use Cases ..................................................5
+   2. Requirements and Assumptions ....................................5
+      2.1. Requirements ...............................................6
+      2.2. Assumptions ................................................6
+   3. Data Structures .................................................7
+      3.1. SecuritySuitabilityPolicy ..................................7
+      3.2. PolicyName .................................................8
+      3.3. Publisher ..................................................9
+      3.4. PolicyIssueDate ............................................9
+      3.5. NextUpdate .................................................9
+      3.6. Usage ......................................................9
+      3.7. Algorithm ..................................................9
+      3.8. AlgorithmIdentifier .......................................10
+      3.9. Evaluation ................................................10
+      3.10. Parameter ................................................11
+      3.11. Validity .................................................12
+      3.12. Information ..............................................12
+      3.13. Signature ................................................12
+   4. DSSC Policies ..................................................13
+   5. Definition of Parameters .......................................13
+   6. Processing .....................................................14
+      6.1. Inputs ....................................................14
+      6.2. Verify Policy .............................................14
+      6.3. Algorithm Evaluation ......................................15
+      6.4. Evaluation of Parameters ..................................15
+      6.5. Output ....................................................16
+   7. Security Considerations ........................................16
+   8. IANA Considerations ............................................18
+   9. References .....................................................23
+      9.1. Normative References ......................................23
+      9.2. Informative References ....................................24
+   Appendix A.  DSSC and ERS .........................................27
+     A.1.  Verification of Evidence Records Using DSSC
+           (Informative) .............................................27
+     A.2.  Storing DSSC Policies in Evidence Records (Normative) .....27
+   Appendix B.  XML Schema (Normative) ...............................28
+   Appendix C.  ASN.1 Module in 1988 Syntax (Informative) ............30
+   Appendix D.  ASN.1 Module in 1997 Syntax (Normative) ..............32
+   Appendix E.  Example ..............................................34
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 3]
+
+RFC 5698                          DSSC                     November 2009
+
+
+1.  Introduction
+
+1.1.  Motivation
+
+   Digital signatures can provide data integrity and authentication.
+   They are based on cryptographic algorithms that are required to have
+   certain security properties.  For example, hash algorithms must be
+   resistant to collisions, and in case of public key algorithms,
+   computation of the private key that corresponds to a given public key
+   must be infeasible.  If algorithms lack the required properties,
+   signatures could be forged, unless they are protected by a strong
+   cryptographic algorithm.
+
+   Cryptographic algorithms that are used in signatures shall be
+   selected to resist such attacks during their period of use.  For
+   signature keys included in public key certificates, this period of
+   use is the validity period of the certificate.  Cryptographic
+   algorithms that are used for encryption shall resist such attacks
+   during the period it is planned to keep the information confidential.
+
+   Only very few algorithms satisfy the security requirements.  Besides,
+   because of the increasing performance of computers and progresses in
+   cryptography, algorithms or their parameters become insecure over the
+   years.  The hash algorithm MD5, for example, is unsuitable today for
+   many purposes.  A digital signature using a "weak" algorithm has no
+   probative value, unless the "weak" algorithm has been protected by a
+   strong algorithm before the time it was considered to be weak.  Many
+   kinds of digital signed data (including signed documents, timestamps,
+   certificates, and revocation lists) are affected, particularly in the
+   case of long-term archiving.  Over long periods of time, it is
+   assumed that the algorithms used in signatures become insecure.
+
+   For this reason, it is important to periodically evaluate an
+   algorithm's fitness and to consider the results of these evaluations
+   when creating and verifying signatures, or when maintaining the
+   validity of signatures made in the past.  One result is a projected
+   validity period for the algorithm, i.e., a prediction of the period
+   of time during which the algorithm is fit for use.  This prediction
+   can help to detect whether a weak algorithm is used in a signature
+   and whether that signature has been properly protected in due time by
+   another signature made using an algorithm that is suitable at the
+   present point of time.  Algorithm evaluations are made by expert
+   committees.  In Germany, the Federal Network Agency annually
+   publishes evaluations of cryptographic algorithms [BNetzAg.2008].
+   Examples of other European and international evaluations are
+   [ETSI-TS102176-1-2005] and [NIST.800-57-Part1.2006].
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 4]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   These evaluations are published in documents intended to be read by
+   humans.  Therefore, to enable automated processing, it is necessary
+   to define a data structure that expresses the content of the
+   evaluations.  This standardized data structure can be used for
+   publication and can be interpreted by signature generation and
+   verification tools.  Algorithm evaluations are pooled in a security
+   suitability policy.  In this document, a data structure for a
+   security suitability policy is specified.  Therefore, the document
+   provides a framework for expressing evaluations of cryptographic
+   algorithms.  This document does not attempt to catalog the security
+   properties of cryptographic algorithms.  Furthermore, no guidelines
+   are made about which kind of algorithms shall be evaluated, for
+   example, security suitability policies may be used to evaluate public
+   key and hash algorithms, signature schemes, and encryption schemes.
+
+1.2.  Terminology
+
+   Algorithm:  A cryptographic algorithm, i.e., a public key or hash
+      algorithm.  For public key algorithms, this is the algorithm with
+      its parameters, if any.  Furthermore, the term "algorithm" is used
+      for cryptographic schemes and for actually padding functions.
+
+   Operator:  Instance that uses and interprets a policy, e.g., a
+      signature-verification component.
+
+   Policy:  An abbreviation for security suitability policy.
+
+   Publisher:  Instance that publishes the policy containing the
+      evaluation of algorithms.
+
+   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 that is evaluated against a policy
+      and determined to be valid, i.e., resistant against attacks, at a
+      particular point of time.
+
+1.2.1.  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].
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 5]
+
+RFC 5698                          DSSC                     November 2009
+
+
+1.3.  Use Cases
+
+   Some use cases for a security suitability policy are presented here.
+
+   Long-term archiving:  The most important use case is long-term
+      archiving of signed data.  Algorithms or their parameters become
+      insecure over 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 as well as 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, as well as information regarding which
+      algorithms 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.
+
+   Signing and verifying:  When signing documents or certificates, it
+      must be assured that the algorithms used for signing or verifying
+      are suitable.  Accordingly, when verifying Cryptographic Message
+      Syntax (CMS) [RFC5652] or XML signatures ([RFC3275],
+      [ETSI-TS101903]), not only the validity of the certificates but
+      also the validity of all involved algorithms may be checked.
+
+   Re-encryption:  A security suitability policy can also be used to
+      decide if encrypted documents must be re-encrypted because the
+      encryption algorithm is no longer secure.
+
+2.  Requirements and Assumptions
+
+   Section 2.1 describes general requirements for a data structure
+   containing the security suitability of algorithms.  In Section 2.2,
+   assumptions are specified concerning both the design and the usage of
+   the data structure.
+
+   A policy contains a list of algorithms that have been evaluated by a
+   publisher.  An algorithm evaluation is described by its identifier,
+   security constraints, and 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 parameters.
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 6]
+
+RFC 5698                          DSSC                     November 2009
+
+
+2.1.  Requirements
+
+   Automatic interpretation:  The data structure of the policy must
+      allow automated evaluation of the security suitability of an
+      algorithm.
+
+   Flexibility:  The data structure must be flexible enough to support
+      new algorithms.  Future policy publications may include
+      evaluations of algorithms that are currently unknown.  It must be
+      possible to add new algorithms with the corresponding security
+      constraints in the data structure.  Additionally, the data
+      structure must be independent of the intended use, e.g.,
+      encryption, signing, verifying, and signature renewing.  Thus, the
+      data structure is usable in every use case.
+
+   Source authentication:  Policies may be published by different
+      institutions, e.g., on the national or European Union (EU) level,
+      whereas one policy needs not to be in agreement with the other
+      one.  Furthermore, organizations may undertake their own
+      evaluations for internal purposes.  For this reason a policy must
+      be attributable to its publisher.
+
+   Integrity and authenticity:  It must be possible to assure the
+      integrity and authenticity of a published security suitability
+      policy.  Additionally, the date of issue must be identifiable.
+
+2.2.  Assumptions
+
+   It is assumed that a policy contains the evaluations of all currently
+   known algorithms, including the expired ones.
+
+   An algorithm is suitable at a time of interest if it is contained in
+   the current policy and the time of interest is within the validity
+   period.  Additionally, if the algorithm has any parameters, these
+   parameters must meet the requirements defined in the security
+   constraints.
+
+   If an algorithm appears in a policy for the first time, it may be
+   assumed that the algorithm has already been suitable in the past.
+   Generally, algorithms are used in practice prior to evaluation.
+
+   To avoid inconsistencies, multiple instances of the same algorithm
+   are prohibited.  The publisher must take care to prevent conflicts
+   within a policy.
+
+   Assertions made in the policy are suitable at least until the next
+   policy is published.
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 7]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   Publishers may extend the lifetime of an algorithm prior to reaching
+   the end of the algorithm's validity period by publishing a revised
+   policy.  Publishers should not resurrect algorithms that are expired
+   at the time a revised policy is published.
+
+3.  Data Structures
+
+   This section describes the syntax of a security suitability policy
+   defined as an XML schema [W3C.REC-xmlschema-1-20041028].  ASN.1
+   modules are defined in Appendix C and Appendix D.  The schema uses
+   the following XML namespace [W3C.REC-xml-names-20060816]:
+
+      urn:ietf:params:xml:ns:dssc
+
+   Within this document, the prefix "dssc" is used for this namespace.
+   The schema starts with the following schema definition:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+              xmlns:dssc="urn:ietf:params:xml:ns:dssc"
+              xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+              targetNamespace="urn:ietf:params:xml:ns:dssc"
+              elementFormDefault="qualified"
+              attributeFormDefault="unqualified">
+   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+              schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
+              schemaLocation="xmldsig-core-schema.xsd"/>
+
+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 optional lang
+   attribute defines the language according to [RFC5646].  The language
+   is applied to all human-readable text within the policy.  If the lang
+   attribute is omitted, the default language is English ("en").  The
+   element is defined by the following schema:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 8]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   <xs:element name="SecuritySuitabilityPolicy"
+               type="dssc:SecuritySuitabilityPolicyType"/>
+   <xs:complexType name="SecuritySuitabilityPolicyType">
+     <xs:sequence>
+       <xs:element ref="dssc:PolicyName"/>
+       <xs:element ref="dssc:Publisher"/>
+       <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
+       <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
+       <xs:element name="Usage" type="xs:string" minOccurs="0"/>
+       <xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
+       <xs:element ref="ds:Signature" minOccurs="0"/>
+     </xs:sequence>
+     <xs:attribute name="version" type="xs:string" default="1"/>
+     <xs:attribute name="lang" default="en"/>
+     <xs:attribute name="id" type="xs:ID"/>
+   </xs:complexType>
+
+3.2.  PolicyName
+
+   The PolicyName element contains an arbitrary name for the policy.
+   The optional elements Object Identifier (OID) and Uniform Resource
+   Identifier (URI) MAY be used for the identification of the policy.
+   OIDs MUST be expressed in the dot notation.
+
+   <xs:element name="PolicyName" type="dssc:PolicyNameType"/>
+   <xs:complexType name="PolicyNameType">
+     <xs:sequence>
+       <xs:element ref="dssc:Name"/>
+       <xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
+       <xs:element ref="dssc:URI" minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+   <xs:element name="Name" type="xs:string"/>
+   <xs:element name="ObjectIdentifier">
+     <xs:simpleType>
+       <xs:restriction base="xs:string">
+         <xs:pattern value="(\d+\.)+\d+"/>
+       </xs:restriction>
+     </xs:simpleType>
+   </xs:element>
+   <xs:element name="URI" type="xs:anyURI"/>
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                     [Page 9]
+
+RFC 5698                          DSSC                     November 2009
+
+
+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.  The Address element contains
+   arbitrary free-format text not intended for automatic processing.
+
+   <xs:element name="Publisher" type="dssc:PublisherType"/>
+   <xs:complexType name="PublisherType">
+     <xs:sequence>
+       <xs:element ref="dssc:Name"/>
+       <xs:element name="Address" type="xs:string" minOccurs="0"/>
+       <xs:element ref="dssc:URI" minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+3.4.  PolicyIssueDate
+
+   The PolicyIssueDate element indicates the point of time when the
+   policy was issued.
+
+3.5.  NextUpdate
+
+   The optional NextUpdate element MAY be used to indicate when the next
+   policy will be issued.
+
+3.6.  Usage
+
+   The optional Usage element determines the intended use of the policy
+   (e.g., certificate validation, signing and verifying documents).  The
+   element contains free-format text intended only for human
+   readability.
+
+3.7.  Algorithm
+
+   A security suitability policy MUST contain at least one Algorithm
+   element.  An algorithm is identified by an AlgorithmIdentifier
+   element.  Additionally, the Algorithm element contains all
+   evaluations of the specific cryptographic algorithm.  More than one
+   evaluation may be necessary if the evaluation depends on the
+   parameter constraints.  The optional Information element MAY be used
+   to provide additional information like references on algorithm
+   specifications.  In order to give the option to extend the Algorithm
+   element, it additionally contains a wildcard.  The Algorithm element
+   is defined by the following schema:
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 10]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   <xs:element name="Algorithm" type="dssc:AlgorithmType"/>
+   <xs:complexType name="AlgorithmType">
+     <xs:sequence>
+       <xs:element ref="dssc:AlgorithmIdentifier"/>
+       <xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
+       <xs:element ref="dssc:Information" minOccurs="0"/>
+       <xs:any namespace="##other" minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+3.8.  AlgorithmIdentifier
+
+   The AlgorithmIdentifier element is used to identify a cryptographic
+   algorithm.  It consists of the algorithm name, at least one OID, and
+   optional URIs.  The algorithm name is not intended to be parsed by
+   automatic processes.  It is only intended to be read by humans.  The
+   OID MUST be expressed in dot notation (e.g., "1.3.14.3.2.26").  The
+   element is defined as follows:
+
+   <xs:element name="AlgorithmIdentifier"
+               type="dssc:AlgorithmIdentifierType"/>
+   <xs:complexType name="AlgorithmIdentifierType">
+     <xs:sequence>
+       <xs:element ref="dssc:Name"/>
+       <xs:element ref="dssc:ObjectIdentifier" maxOccurs="unbounded"/>
+       <xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
+     </xs:sequence>
+   </xs:complexType>
+
+3.9.  Evaluation
+
+   The Evaluation element contains the evaluation of one cryptographic
+   algorithm in dependence of its parameter constraints.  For example,
+   the suitability of the RSA algorithm depends on the modulus length
+   (RSA with a modulus length of 1024 may have another suitability
+   period as RSA with a modulus length of 2048).  Current hash
+   algorithms like SHA-1 or RIPEMD-160 do not have any parameters.
+   Therefore, the Parameter element is optional.  The suitability of the
+   algorithm is expressed by a validity period, which is defined by the
+   Validity element.  An optional wildcard MAY be used to extend the
+   Evaluation element.
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 11]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   <xs:element name="Evaluation" type="dssc:EvaluationType"/>
+   <xs:complexType name="EvaluationType">
+     <xs:sequence>
+       <xs:element ref="dssc:Parameter" minOccurs="0"
+                                        maxOccurs="unbounded"/>
+       <xs:element ref="dssc:Validity"/>
+       <xs:any namespace="##other" minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+3.10.  Parameter
+
+   The Parameter element is used to express constraints on algorithm-
+   specific parameters.
+
+   The Parameter element has a name attribute, which holds the name of
+   the parameter (e.g., "moduluslength" for RSA [RFC3447]).  Section 5
+   defines parameter names for currently known public key algorithms;
+   these parameter names SHOULD be used.  For the actual parameter, a
+   range of values or an exact value may be defined.  These constraints
+   are expressed by the following elements:
+
+   Min:  The Min element defines the minimum value of the parameter.
+      That means values equal or greater than the given value meet the
+      requirements.
+
+   Max:  The Max element defines the maximum value the parameter may
+      take.
+
+   At least one of both elements MUST be set to define a range of
+   values.  A range MAY also be specified by a combination of both
+   elements, whereas the value of the Min element MUST be less than or
+   equal to the value of the Max element.  The parameter may have any
+   value within the defined range, including the minimum and maximum
+   values.  An exact value is expressed by using the same value in both
+   the Min and the Max element.
+
+   These constraints are sufficient for all current algorithms.  If
+   future algorithms need constraints that cannot be expressed by the
+   elements above, an arbitrary XML structure MAY be inserted that meets
+   the new constraints.  For this reason, the Parameter element contains
+   a wildcard.  A parameter MUST contain at least one constraint.  The
+   schema for the Parameter element is as follows:
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 12]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   <xs:element name="Parameter" type="dssc:ParameterType"/>
+   <xs:complexType name="ParameterType">
+     <xs:sequence>
+       <xs:element name="Min" type="xs:int" minOccurs="0"/>
+       <xs:element name="Max" type="xs:int" minOccurs="0"/>
+       <xs:any namespace="##other" minOccurs="0"/>
+     </xs:sequence>
+     <xs:attribute name="name" type="xs:string" use="required"/>
+   </xs:complexType>
+
+
+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 that sets an end date for the
+   algorithm.  If the end of the validity period is in the past, the
+   algorithm was suitable until that end date.  The element is defined
+   by the following schema:
+
+   <xs:element name="Validity" type="dssc:ValidityType"/>
+   <xs:complexType name="ValidityType">
+     <xs:sequence>
+       <xs:element name="Start" type="xs:date" minOccurs="0"/>
+       <xs:element name="End" type="xs:date" minOccurs="0"/>
+     </xs:sequence>
+   </xs:complexType>
+
+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:
+
+   <xs:element name="Information" type="dssc:InformationType"/>
+   <xs:complexType name="InformationType">
+     <xs:sequence>
+       <xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
+     </xs:sequence>
+   </xs:complexType>
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 13]
+
+RFC 5698                          DSSC                     November 2009
+
+
+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
+
+4.  DSSC Policies
+
+   DSSC policies MUST be expressed either in XML or ASN.1.  However, in
+   order to reach interoperability, DSSC policies SHOULD be published in
+   both XML and ASN.1.
+
+   In the case of XML, a DSSC policy is an XML document that MUST be
+   well-formed and SHOULD be valid.  XML-encoded DSSC policies MUST be
+   based on XML 1.0 [W3C.REC-xml-20081126] and MUST be encoded using
+   UTF-8 [RFC3629].  This specification makes use of XML namespaces
+   [W3C.REC-xml-names-20060816] for identifying DSSC policies.  The
+   namespace URI for elements defined by this specification is a URN
+   [RFC2141] using the namespace prefix "dssc".  This URN is:
+
+      urn:ietf:params:xml:ns:dssc
+
+   XML-encoded DSSC policies are identified with the MIME type
+   "application/dssc+xml" and are instances of the XML schema
+   [W3C.REC-xmlschema-1-20041028] defined in Appendix B.
+
+   A file containing a DSSC policy in ASN.1 representation (for
+   specification of ASN.1 refer to [CCITT.x208.1988], [CCITT.x209.1988],
+   [CCITT.x680.2002] and [CCITT.x690.2002]) MUST contain only the DER
+   encoding of one DSSC policy, i.e., there MUST NOT be extraneous
+   header or trailer information in the file.  ASN.1-based DSSC policies
+   are identified with the MIME type "application/dssc+der".
+   Appropriate ASN.1 modules are defined in Appendices C (1988-ASN.1
+   syntax) and D (1997-ASN.1 syntax).
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 14]
+
+RFC 5698                          DSSC                     November 2009
+
+
+5.  Definition of Parameters
+
+   This section defines the parameter names for the currently known
+   public key algorithms.  The following parameters also refer to
+   cryptographic schemes based on these public key algorithms (e.g., the
+   PKCS#1 v1.5 signature scheme SHA-256 with RSA [RFC3447]).
+
+      The parameter of RSA [RFC3447] SHOULD be named "moduluslength".
+
+      The parameters for the Digital Signature Algorithm (DSA)
+      [FIPS186-2] SHOULD be "plength" and "qlength".
+
+   These parameter names have been registered by IANA (see Section 8).
+   It may be necessary to register further algorithms not given in this
+   section (in particular, future algorithms).  The process for
+   registering parameter names of further algorithms is described in
+   Section 8.  Publishers of policies SHOULD use these parameter names
+   so that the correct interpretation is guaranteed.
+
+6.  Processing
+
+   Evaluation of an algorithm's security suitability is described in
+   three parts: verification of the policy, determination of algorithm
+   validity, and evaluation of algorithm parameters, if any.
+
+   In the following sections, a process is described
+
+   o  to determine if an algorithm was suitable at a particular point of
+      time, and
+
+   o  to determine until what time an algorithm was or will be suitable.
+
+6.1.  Inputs
+
+   To determine the security suitability of an algorithm, the following
+   information is required:
+
+   o  Policy
+
+   o  Current time
+
+   o  Algorithm identifier and parameter constraints (if associated)
+
+   o  Time of interest (optional).  Providing no time of interest means
+      determination of the validity end date of the algorithm.
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 15]
+
+RFC 5698                          DSSC                     November 2009
+
+
+6.2.  Verify Policy
+
+   The signature on the policy SHOULD be verified and a certification
+   path from the policy signer's certificate to a current trust anchor
+   SHOULD be constructed and validated [RFC5280].  The algorithms used
+   to verify the digital signature and validate the certification path
+   MUST be suitable per the contents of the policy being verified.  If
+   signature verification fails, certification path validation fails or
+   an unsuitable algorithm is required to perform these checks, then the
+   policy MUST be rejected.
+
+   The nextUpdate time in the policy MUST be either greater than the
+   current time or absent.  If the nextUpdate time is less than the
+   current time, the policy MUST be rejected.
+
+6.3.  Algorithm Evaluation
+
+   To determine the validity period of an algorithm, locate the
+   Algorithm element in the policy that corresponds to the algorithm
+   identifier provided as input.  The Algorithm element is located by
+   comparing the OID in the element to the OID included in the algorithm
+   identifier provided as input.
+
+   If no matching Algorithm element is found, then the algorithm is
+   unknown.
+
+   If the time of interest was provided as input, the validity of each
+   Evaluation element MUST be checked in order to determine if the
+   algorithm was suitable at the time of interest.  For each Evaluation
+   element:
+
+   o  Confirm the Start time is either less than the time of interest or
+      absent.  Discard the entry if the Start time is present and
+      greater than the time of interest.
+
+   o  Confirm the End time is either greater than the time of interest
+      or absent.  Discard the entry if the End time is present and less
+      than the time of interest.
+
+   If all Evaluation elements were rejected, the algorithm is not
+   suitable according to the policy.
+
+   Any entries not rejected will be used for the evaluation of the
+   parameters, if any.
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 16]
+
+RFC 5698                          DSSC                     November 2009
+
+
+6.4.  Evaluation of Parameters
+
+   Any necessary parameters of the entries not rejected MUST be
+   evaluated within the context of the type and usage of the algorithm.
+   Details of parameter evaluation are defined on a per-algorithm basis.
+
+   To evaluate the parameters, the Parameter elements of each Evaluation
+   element that has not been rejected in the process described in
+   Section 6.3 MUST be checked.  For each Parameter element:
+
+   o  Confirm that the parameter was provided as input.  Discard the
+      Evaluation element if the parameter does not match to any of the
+      parameters provided as input.
+
+   o  If the Parameter element has a Min element, confirm that the
+      parameter value is less than or equal to the corresponding
+      parameter provided as input.  Discard the Evaluation element if
+      the parameter value does not meet the constraint.
+
+   o  If the Parameter element has a Max element, confirm that the
+      parameter value is greater than or equal to the corresponding
+      parameter provided as input.  Discard the Evaluation element if
+      the parameter value does not meet the constraint.
+
+   o  If the Parameter has another constraint, confirm that the value of
+      the corresponding parameter provided as input meets this
+      constraint.  If it does not or if the constraint is unrecognized,
+      discard the Evaluation element.
+
+   If all Evaluation elements were rejected, the algorithm is not
+   suitable according to the policy.
+
+   Any entries not rejected will be provided as output.
+
+6.5.  Output
+
+   If the algorithm is not in the policy, return an error "algorithm
+   unknown".
+
+   If no time of interest was provided as input, return the maximum End
+   time of the Evaluation elements that were not discarded.  If at least
+   one End time of these Evaluation elements is absent, return
+   "algorithm has an indefinite End time".
+
+   Otherwise, if the algorithm is not suitable relative to the time of
+   interest, return an error "algorithm unsuitable".
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 17]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   If the algorithm is suitable relative to the time of interest, return
+   the Evaluation elements that were not discarded.
+
+7.  Security Considerations
+
+   The policy for an algorithm's security suitability has a great impact
+   on the quality of the results of signature generation and
+   verification operations.  If an algorithm is incorrectly evaluated
+   against a policy, signatures with a low probative force could be
+   created or verification results could be incorrect.  The following
+   security considerations have been identified:
+
+   1.  Publishers MUST ensure unauthorized manipulation of any security
+       suitability is not possible prior to a policy being signed and
+       published.  There is no mechanism provided to revoke a policy
+       after publication.  Since the algorithm evaluations change
+       infrequently, the lifespan of a policy should be carefully
+       considered prior to publication.
+
+   2.  Operators SHOULD only accept policies issued by a trusted
+       publisher.  Furthermore, the validity of the certificate used to
+       sign the policy SHOULD be verifiable by Certificate Revocation
+       List (CRL) [RFC5280] or Online Certificate Status Protocol (OCSP)
+       [RFC2560].  The certificate used to sign the policy SHOULD be
+       revoked if the algorithms used in this certificate are no longer
+       suitable.  It MUST NOT be possible to alter or replace a policy
+       once accepted by an operator.
+
+   3.  Operators SHOULD periodically check to see if a new policy has
+       been published to avoid using obsolete policy information.  For
+       publishers, it is suggested not to omit the NextUpdate element in
+       order to give operators a hint regarding when the next policy
+       will be published.
+
+   4.  When signing a policy, algorithms that are suitable according to
+       this policy SHOULD be used.
+
+   5.  The processing rule described in Section 6 is about one
+       cryptographic algorithm independent of the use case.  Depending
+       upon the use case, an algorithm that is no longer suitable at the
+       time of interest, does not necessarily mean that the data
+       structure where it is used is no longer secure.  For example, a
+       signature has been made with an RSA signer's key of 1024 bits.
+       This signature is timestamped with a timestamp token that uses an
+       RSA key of 2048 bits, before an RSA key size of 1024 bits will be
+       broken.  The fact that the signature key of 1024 bits is no
+       longer suitable at the time of interest does not mean that the
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 18]
+
+RFC 5698                          DSSC                     November 2009
+
+
+       whole data structure is no longer secure, if an RSA key size of
+       2048 bits is still suitable at the time of interest.
+
+   6.  In addition to the key size considerations, other considerations
+       must be applied, like whether a timestamp token has been provided
+       by a trusted authority.  This means that the simple use of a
+       suitability policy is not the single element to consider when
+       evaluating the security of a complex data structure that uses
+       several cryptographic algorithms.
+
+   7.  The policies described in this document are suitable to evaluate
+       basic cryptographic algorithms, like public key or hash
+       algorithms, as well as cryptographic schemes (e.g., the PKCS#1
+       v1.5 signature schemes [RFC3447]).  But it MUST be kept in mind
+       that a basic cryptographic algorithm that is suitable according
+       to the policy does not necessarily mean that any cryptographic
+       schemes based on this algorithm are also secure.  For example, a
+       signature scheme based on RSA must not necessarily be secure if
+       RSA is suitable.  In case of a complete signature verification,
+       including validation of the certificate path, various algorithms
+       have to be checked against the policy (i.e., signature schemes of
+       signed data objects and revocation information, public key
+       algorithms of the involved certificates, etc.).  Thus, a policy
+       SHOULD contain evaluations of public key and hash algorithms as
+       well as of signature schemes.
+
+   8.  Re-encrypting documents that were originally encrypted using an
+       algorithm that is no longer suitable will not protect the
+       semantics of the document if the document has been intercepted.
+       However, for documents stored in an encrypted form, re-encryption
+       must be considered, unless the document has lost its original
+       value.
+
+8.  IANA Considerations
+
+   This document defines the XML namespace "urn:ietf:params:xml:ns:dssc"
+   according to the guidelines in [RFC3688].  This namespace has been
+   registered in the IANA XML Registry.
+
+   This document defines an XML schema (see Appendix B) according to the
+   guidelines in [RFC3688].  This XML schema has been registered in the
+   IANA XML Registry and can be identified with the URN
+   "urn:ietf:params:xml:schema:dssc".
+
+   This document defines the MIME type "application/dssc+xml".  This
+   MIME type has been registered by IANA under "MIME Media Types"
+   according to the procedures of [RFC4288].
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 19]
+
+RFC 5698                          DSSC                     November 2009
+
+
+      Type name: application
+
+      Subtype name: dssc+xml
+
+      Required parameters: none
+
+      Optional parameters: "charset" as specified for "application/xml"
+      in [RFC3023].
+
+      Encoding considerations: Same as specified for "application/xml"
+      in [RFC3023].
+
+      Security considerations: Same as specified for "application/xml"
+      in Section 10 of [RFC3023].  For further security considerations,
+      see Section 7 of this document.
+
+      Interoperability considerations: Same as specified for
+      "application/xml" in [RFC3023].
+
+      Published specification: This document.
+
+      Applications that use this media: Applications for long-term
+      archiving of signed data, applications for signing data /
+      verifying signed data, and applications for encrypting /
+      decrypting data.
+
+      Additional information:
+
+         Magic number(s): none
+
+         File extension(s): .xdssc
+
+         Macintosh file type code: "TEXT"
+
+         Object Identifiers: none
+
+      Person to contact for further information: Thomas Kunz
+      (thomas.kunz@sit.fraunhofer.de)
+
+      Intended usage: COMMON
+
+      Restrictions on usage: none
+
+      Author/Change controller: IETF
+
+   This document defines the MIME type "application/dssc+der".  This
+   MIME type has been registered by IANA under "MIME Media Types"
+   according to the procedures of [RFC4288].
+
+
+
+Kunz, et al.                Standards Track                    [Page 20]
+
+RFC 5698                          DSSC                     November 2009
+
+
+      Type name: application
+
+      Subtype name: dssc+der
+
+      Required parameters: none
+
+      Optional parameters: none
+
+      Encoding considerations: binary
+
+      Security considerations: See Section 7 of this document.
+
+      Interoperability considerations: none
+
+      Published specification: This document.
+
+      Applications that use this media: Applications for long-term
+      archiving of signed data, applications for signing data /
+      verifying signed data, and applications for encrypting /
+      decrypting data.
+
+      Additional information:
+
+         Magic number(s): none
+
+         File extension(s): .dssc
+
+         Macintosh file type code: none
+
+         Object Identifiers: none
+
+      Person to contact for further information: Thomas Kunz
+      (thomas.kunz@sit.fraunhofer.de)
+
+      Intended usage: COMMON
+
+      Restrictions on usage: none
+
+      Author/Change controller: IETF
+
+   This specification creates a new IANA registry entitled "Data
+   Structure for the Security Suitability of Cryptographic Algorithms
+   (DSSC)".  This registry contains two sub-registries entitled
+   "Parameter Definitions" and "Cryptographic Algorithms".  The policy
+   for future assignments to the sub-registry "Parameter Definitions" is
+   "RFC Required".
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 21]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   The initial values for the "Parameter Definitions" sub-registry are:
+
+   Value              Description                     Reference
+   --------------     ------------------------------- ------------------
+   moduluslength      Parameter for RSA               RFC 5698
+                      (integer value)
+   plength            Parameter for DSA               RFC 5698
+                      (integer value, used together
+                      with parameter "qlength")
+   qlength            Parameter for DSA               RFC 5698
+                      (integer value, used together
+                      with parameter "plength")
+
+   The sub-registry "Cryptographic Algorithms" contains textual names as
+   well as Object Identifiers (OIDs) and Uniform Resource Identifiers
+   (URIs) of cryptographic algorithms.  It serves as assistance when
+   creating a new policy.  The policy for future assignments is "First
+   Come First Served".  When registering a new algorithm, the following
+   information MUST be provided:
+
+   o  The textual name of the algorithm.
+
+   o  The OID of the algorithm.
+
+   o  A reference to a publicly available specification that defines the
+      algorithm and its identifiers.
+
+   Optionally, a URI MAY be provided if possible.
+
+   The initial values for the "Cryptographic Algorithms" sub-registry
+   are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 22]
+
+RFC 5698                          DSSC                     November 2009
+
+
+  Name                      OID / URI                         Reference
+  -----------------------   --------------------------------- ----------
+  rsaEncryption             1.2.840.113549.1.1.1              [RFC3447]
+
+  dsa                       1.2.840.10040.4.1                 [RFC3279]
+
+  md2                       1.2.840.113549.2.2                [RFC3279]
+
+  md5                       1.2.840.113549.2.5                [RFC3279]
+            http://www.w3.org/2001/04/xmldsig-more#md5        [RFC4051]
+
+  sha-1                     1.3.14.3.2.26                     [RFC3279]
+            http://www.w3.org/2000/09/xmldsig#sha1            [RFC3275]
+
+  sha-224                   2.16.840.1.101.3.4.2.4            [RFC4055]
+            http://www.w3.org/2001/04/xmldsig-more#sha224     [RFC4051]
+
+  sha-256                   2.16.840.1.101.3.4.2.1            [RFC4055]
+
+  sha-384                   2.16.840.1.101.3.4.2.2            [RFC4055]
+            http://www.w3.org/2001/04/xmldsig-more#sha384     [RFC4051]
+
+  sha-512                   2.16.840.1.101.3.4.2.3            [RFC4055]
+
+  md2WithRSAEncryption      1.2.840.113549.1.1.2              [RFC3443]
+
+  md5WithRSAEncryption      1.2.840.113549.1.1.4              [RFC3443]
+            http://www.w3.org/2001/04/xmldsig-more#rsa-md5    [RFC4051]
+
+  sha1WithRSAEncryption     1.2.840.113549.1.1.5              [RFC3443]
+            http://www.w3.org/2000/09/xmldsig#rsa-sha1        [RFC3275]
+
+  sha256WithRSAEncryption   1.2.840.113549.1.1.11             [RFC3443]
+            http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [RFC4051]
+
+  sha384WithRSAEncryption   1.2.840.113549.1.1.12             [RFC3443]
+            http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 [RFC4051]
+
+  sha512WithRSAEncryption   1.2.840.113549.1.1.13             [RFC3443]
+            http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 [RFC4051]
+
+  sha1WithDSA               1.2.840.10040.4.3                 [RFC3279]
+            http://www.w3.org/2000/09/xmldsig#dsa-sha1        [RFC3275]
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 23]
+
+RFC 5698                          DSSC                     November 2009
+
+
+9.  References
+
+9.1.  Normative References
+
+   [CCITT.x680.2002]
+              International Telephone and Telegraph Consultative
+              Committee, "Abstract Syntax Notation One (ASN.1):
+              Specification of basic notation", CCITT Recommendation
+              X.680, July 2002.
+
+   [CCITT.x690.2002]
+              International Telephone and Telegraph Consultative
+              Committee, "AASN.1 encoding rules:  Specification of basic
+              encoding Rules (BER), Canonical encoding rules (CER) and
+              Distinguished encoding rules (DER)", CCITT Recommendation
+              X.690, July 2002.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+              Types", RFC 3023, January 2001.
+
+   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
+              Language) XML-Signature Syntax and Processing", RFC 3275,
+              March 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [RFC4998]  Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
+              Record Syntax (ERS)", RFC 4998, August 2007.
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 24]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
+              Languages", BCP 47, RFC 5646, September 2009.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 5652, September 2009.
+
+   [W3C.REC-xml-20081126]
+              Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C.,
+              and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
+              Edition)", World Wide Web Consortium Recommendation REC-
+              xml-20081126, November 2008,
+              <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+   [W3C.REC-xml-names-20060816]
+              Layman, A., Hollander, D., Tobin, R., and T. Bray,
+              "Namespaces in XML 1.0 (Second Edition)", World Wide Web
+              Consortium Recommendation REC-xml-names-20060816,
+              August 2006,
+              <http://www.w3.org/TR/2006/REC-xml-names-20060816>.
+
+   [W3C.REC-xmlschema-1-20041028]
+              Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney,
+              "XML Schema Part 1: Structures Second Edition", World Wide
+              Web Consortium Recommendation REC-xmlschema-1-20041028,
+              October 2004,
+              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+9.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,
+              <http://www.bundesnetzagentur.de/media/archive/12198.pdf>.
+
+   [CCITT.x208.1988]
+              International Telephone and Telegraph Consultative
+              Committee, "Specification of Abstract Syntax Notation One
+              (ASN.1)", CCITT Recommendation X.208, November 1988.
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 25]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   [CCITT.x209.1988]
+              International Telephone and Telegraph Consultative
+              Committee, "Specification of Basic Encoding Rules for
+              Abstract Syntax Notation One (ASN.1)",
+              CCITT Recommendation X.209, November 1988.
+
+   [ETSI-TS101903]
+              European Telecommunication Standards Institute (ETSI),
+              "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101
+              903 V1.3.2, March 2006.
+
+   [ETSI-TS102176-1-2005]
+              European Telecommunication Standards Institute (ETSI),
+              "Electronic Signatures and Infrastructures (ESI);
+              "Algorithms and Parameters for Secure Electronic
+              Signatures; Part 1: Hash functions and asymmetric
+              algorithms"", ETSI TS 102 176-1 V2.0.0, November 2007.
+
+   [FIPS186-2]
+              National Institute of Standards and Technology, "Digital
+              Signature Standard (DSS)", FIPS PUB 186-2 with Change
+              Notice, January 2000.
+
+   [NIST.800-57-Part1.2006]
+              National Institute of Standards and Technology,
+              "Recommendation for Key Management - Part 1: General
+              (Revised)", NIST 800-57 Part 1, May 2006.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+              in Multi-Protocol Label Switching (MPLS) Networks", RFC
+              3443, January 2003.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC4051]  Eastlake, D., "Additional XML Security Uniform Resource
+              Identifiers (URIs)", RFC 4051, April 2005.
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 26]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
+              Algorithms and Identifiers for RSA Cryptography for use in
+              the Internet X.509 Public Key Infrastructure Certificate
+              and Certificate Revocation List (CRL) Profile", RFC 4055,
+              June 2005.
+
+   [RFC4810]  Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
+              Archive Service Requirements", RFC 4810, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 27]
+
+RFC 5698                          DSSC                     November 2009
+
+
+Appendix A.  DSSC and ERS
+
+A.1.  Verification of Evidence Records Using DSSC (Informative)
+
+   This section describes the verification of an Evidence Record
+   according to the Evidence Record Syntax (ERS, [RFC4998]), 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) as well as
+   the public key algorithm and hash algorithm in the timestamp
+   signature have to be examined.  The relevant 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 that were
+       suitable at the date of issue.
+
+   2.  The hashtree was built with a hash algorithm that was 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 ArchiveTimeStamp have to be suitable now.
+
+   If the check of one of these items fails, this will lead to a failure
+   of the verification.
+
+A.2.  Storing DSSC Policies in Evidence Records (Normative)
+
+   This section describes how to store a policy in an Evidence Record.
+   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.                Standards Track                    [Page 28]
+
+RFC 5698                          DSSC                     November 2009
+
+
+Appendix B.  XML Schema (Normative)
+
+  <?xml version="1.0" encoding="UTF-8"?>
+  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+             xmlns:dssc="urn:ietf:params:xml:ns:dssc"
+             xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+             targetNamespace="urn:ietf:params:xml:ns:dssc"
+             elementFormDefault="qualified"
+             attributeFormDefault="unqualified">
+    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+               schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
+               schemaLocation="xmldsig-core-schema.xsd"/>
+    <xs:element name="SecuritySuitabilityPolicy"
+                type="dssc:SecuritySuitabilityPolicyType"/>
+    <xs:complexType name="SecuritySuitabilityPolicyType">
+      <xs:sequence>
+        <xs:element ref="dssc:PolicyName"/>
+        <xs:element ref="dssc:Publisher"/>
+        <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
+        <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
+        <xs:element name="Usage" type="xs:string" minOccurs="0"/>
+        <xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
+        <xs:element ref="ds:Signature" minOccurs="0"/>
+      </xs:sequence>
+      <xs:attribute name="version" type="xs:string" default="1"/>
+      <xs:attribute name="lang" default="en"/>
+      <xs:attribute name="id" type="xs:ID"/>
+    </xs:complexType>
+    <xs:element name="PolicyName" type="dssc:PolicyNameType"/>
+    <xs:complexType name="PolicyNameType">
+      <xs:sequence>
+        <xs:element ref="dssc:Name"/>
+        <xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
+        <xs:element ref="dssc:URI" minOccurs="0"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Publisher" type="dssc:PublisherType"/>
+    <xs:complexType name="PublisherType">
+      <xs:sequence>
+        <xs:element ref="dssc:Name"/>
+        <xs:element name="Address" type="xs:string" minOccurs="0"/>
+        <xs:element ref="dssc:URI" minOccurs="0"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Name" type="xs:string"/>
+    <xs:element name="ObjectIdentifier">
+      <xs:simpleType>
+
+
+
+Kunz, et al.                Standards Track                    [Page 29]
+
+RFC 5698                          DSSC                     November 2009
+
+
+        <xs:restriction base="xs:string">
+          <xs:pattern value="(\d+\.)+\d+"/>
+        </xs:restriction>
+      </xs:simpleType>
+    </xs:element>
+    <xs:element name="URI" type="xs:anyURI"/>
+    <xs:element name="Algorithm" type="dssc:AlgorithmType"/>
+    <xs:complexType name="AlgorithmType">
+      <xs:sequence>
+        <xs:element ref="dssc:AlgorithmIdentifier"/>
+        <xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
+        <xs:element ref="dssc:Information" minOccurs="0"/>
+        <xs:any namespace="##other" minOccurs="0"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="AlgorithmIdentifier"
+                type="dssc:AlgorithmIdentifierType"/>
+    <xs:complexType name="AlgorithmIdentifierType">
+      <xs:sequence>
+        <xs:element ref="dssc:Name"/>
+        <xs:element ref="dssc:ObjectIdentifier" maxOccurs="unbounded"/>
+        <xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Validity" type="dssc:ValidityType"/>
+    <xs:complexType name="ValidityType">
+      <xs:sequence>
+        <xs:element name="Start" type="xs:date" minOccurs="0"/>
+        <xs:element name="End" type="xs:date" minOccurs="0"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Information" type="dssc:InformationType"/>
+    <xs:complexType name="InformationType">
+      <xs:sequence>
+        <xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Evaluation" type="dssc:EvaluationType"/>
+    <xs:complexType name="EvaluationType">
+      <xs:sequence>
+        <xs:element ref="dssc:Parameter" minOccurs="0"
+                                         maxOccurs="unbounded"/>
+        <xs:element ref="dssc:Validity"/>
+        <xs:any namespace="##other" minOccurs="0"/>
+      </xs:sequence>
+    </xs:complexType>
+    <xs:element name="Parameter" type="dssc:ParameterType"/>
+    <xs:complexType name="ParameterType">
+
+
+
+Kunz, et al.                Standards Track                    [Page 30]
+
+RFC 5698                          DSSC                     November 2009
+
+
+      <xs:sequence>
+        <xs:element name="Min" type="xs:int" minOccurs="0"/>
+        <xs:element name="Max" type="xs:int" minOccurs="0"/>
+        <xs:any namespace="##other" minOccurs="0"/>
+      </xs:sequence>
+      <xs:attribute name="name" type="xs:string" use="required"/>
+    </xs:complexType>
+  </xs:schema>
+
+Appendix C.  ASN.1 Module in 1988 Syntax (Informative)
+
+   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
+
+   -- Import from RFC 5280 [RFC5280]
+   -- Delete following import statement
+   -- if "new" types are supported
+
+   UTF8String FROM PKIX1Explicit88
+               { iso(1) identified-organization(3) dod(6)
+               internet(1) security(5) mechanisms(5) pkix(7)
+               mod(0) pkix1-explicit(18) }
+
+   -- Import from RFC 5652 [RFC5652]
+
+   ContentInfo FROM CryptographicMessageSyntax2004
+               { iso(1) member-body(2) us(840)
+               rsadsi(113549) pkcs(1) pkcs-9(9)
+               smime(16) modules(0) cms-2004(24)}
+
+   ;
+
+   SecuritySuitabilityPolicy ::= ContentInfo
+
+   -- contentType is id-signedData as defined in [RFC5652]
+   -- content is SignedData as defined in [RFC5652]
+   -- eContentType within SignedData is id-ct-dssc
+   -- eContent within SignedData is TBSPolicy
+
+
+
+Kunz, et al.                Standards Track                    [Page 31]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   id-ct-dssc  OBJECT IDENTIFIER ::= {
+               iso(1) identified-organization(3) dod(6)
+               internet(1) security(5) mechanisms(5)
+               ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }
+
+   TBSPolicy ::= SEQUENCE {
+        version          INTEGER               DEFAULT   {v1(1)},
+        language         UTF8String            DEFAULT   "en",
+        policyName       PolicyName,
+        publisher        Publisher,
+        policyIssueDate  GeneralizedTime,
+        nextUpdate       GeneralizedTime       OPTIONAL,
+        usage            UTF8String            OPTIONAL,
+        algorithms       SEQUENCE OF Algorithm
+   }
+
+   PolicyName ::= SEQUENCE {
+        name  UTF8String,
+        oid   OBJECT IDENTIFIER OPTIONAL,
+        uri   IA5String         OPTIONAL
+   }
+
+   Publisher ::= SEQUENCE {
+        name        UTF8String,
+        address [0] UTF8String  OPTIONAL,
+        uri     [1] IA5String   OPTIONAL
+   }
+
+   Algorithm ::= SEQUENCE {
+        algorithmIdentifier     AlgID,
+        evaluations             SEQUENCE OF Evaluation,
+        information         [0] SEQUENCE OF UTF8String  OPTIONAL,
+        other               [1] Extension               OPTIONAL
+   }
+
+   Extension ::= SEQUENCE {
+        extensionType           OBJECT IDENTIFIER,
+        extension               ANY DEFINED BY extensionType
+   }
+
+   AlgID ::= SEQUENCE {
+        name      UTF8String,
+        oid   [0] SEQUENCE OF OBJECT IDENTIFIER,
+        uri   [1] SEQUENCE OF IA5String          OPTIONAL
+   }
+
+   Evaluation ::= SEQUENCE {
+        parameters           [0] SEQUENCE OF Parameter OPTIONAL,
+
+
+
+Kunz, et al.                Standards Track                    [Page 32]
+
+RFC 5698                          DSSC                     November 2009
+
+
+        validity             [1] Validity,
+        other                [2] Extension             OPTIONAL
+   }
+
+   Parameter ::= SEQUENCE {
+        name       UTF8String,
+        min    [0] INTEGER     OPTIONAL,
+        max    [1] INTEGER     OPTIONAL,
+        other  [2] Extension   OPTIONAL
+   }
+
+   Validity ::= SEQUENCE {
+        start  [0] GeneralizedTime OPTIONAL,
+        end    [1] GeneralizedTime OPTIONAL
+   }
+
+   END
+
+Appendix D.  ASN.1 Module in 1997 Syntax (Normative)
+
+   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
+
+   -- Import from RFC 5280 [RFC5280]
+   -- Delete following import statement
+   -- if "new" types are supported
+
+   UTF8String FROM PKIX1Explicit88
+               { iso(1) identified-organization(3) dod(6)
+               internet(1) security(5) mechanisms(5) pkix(7)
+               mod(0) pkix1-explicit(18) }
+
+   -- Import from RFC 5652 [RFC5652]
+
+   ContentInfo FROM CryptographicMessageSyntax2004
+               { iso(1) member-body(2) us(840)
+               rsadsi(113549) pkcs(1) pkcs-9(9)
+               smime(16) modules(0) cms-2004(24)}
+
+
+
+Kunz, et al.                Standards Track                    [Page 33]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   ;
+
+   SecuritySuitabilityPolicy ::= ContentInfo
+
+   -- contentType is id-signedData as defined in [RFC5652]
+   -- content is SignedData as defined in [RFC5652]
+   -- eContentType within SignedData is id-ct-dssc
+   -- eContent within SignedData is TBSPolicy
+
+   id-ct-dssc  OBJECT IDENTIFIER ::= {
+               iso(1) identified-organization(3) dod(6)
+               internet(1) security(5) mechanisms(5)
+               ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }
+
+   TBSPolicy ::= SEQUENCE {
+        version          INTEGER               DEFAULT   {v1(1)},
+        language         UTF8String            DEFAULT   "en",
+        policyName       PolicyName,
+        publisher        Publisher,
+        policyIssueDate  GeneralizedTime,
+        nextUpdate       GeneralizedTime       OPTIONAL,
+        usage            UTF8String            OPTIONAL,
+        algorithms       SEQUENCE OF Algorithm
+   }
+
+   PolicyName ::= SEQUENCE {
+        name  UTF8String,
+        oid   OBJECT IDENTIFIER OPTIONAL,
+        uri   IA5String         OPTIONAL
+   }
+
+   Publisher ::= SEQUENCE {
+        name         UTF8String,
+        address  [0] UTF8String  OPTIONAL,
+        uri      [1] IA5String   OPTIONAL
+   }
+
+   Algorithm ::= SEQUENCE {
+        algorithmIdentifier     AlgID,
+        evaluations             SEQUENCE OF Evaluation,
+        information         [0] SEQUENCE OF UTF8String  OPTIONAL,
+        other               [1] Extension               OPTIONAL
+   }
+
+   Extension ::= SEQUENCE {
+        extensionType  EXTENSION-TYPE.&id ({SupportedExtensions}),
+        extension      EXTENSION-TYPE.&Type
+                            ({SupportedExtensions}{@extensionType})
+
+
+
+Kunz, et al.                Standards Track                    [Page 34]
+
+RFC 5698                          DSSC                     November 2009
+
+
+   }
+
+   EXTENSION-TYPE ::= TYPE-IDENTIFIER
+
+   SupportedExtensions EXTENSION-TYPE ::= {...}
+
+   AlgID ::= SEQUENCE {
+        name      UTF8String,
+        oid   [0] SEQUENCE OF OBJECT IDENTIFIER,
+        uri   [1] SEQUENCE OF IA5String          OPTIONAL
+   }
+
+   Evaluation ::= SEQUENCE {
+        parameters           [0] SEQUENCE OF Parameter OPTIONAL,
+        validity             [1] Validity,
+        other                [2] Extension             OPTIONAL
+   }
+
+   Parameter ::= SEQUENCE {
+        name       UTF8String,
+        min    [0] INTEGER     OPTIONAL,
+        max    [1] INTEGER     OPTIONAL,
+        other  [2] Extension   OPTIONAL
+   }
+
+   Validity ::= SEQUENCE {
+        start  [0] GeneralizedTime OPTIONAL,
+        end    [1] GeneralizedTime OPTIONAL
+   }
+
+   END
+
+Appendix E.  Example
+
+   The following example shows a policy that may be used for signature
+   verification.  It contains hash algorithms, public key algorithms,
+   and signature schemes.  SHA-1 as well as RSA with modulus length of
+   1024 are examples for expired algorithms.
+
+   <SecuritySuitabilityPolicy xmlns="urn:ietf:params:xml:ns:dssc"
+     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+    <PolicyName>
+     <Name>Evaluation of cryptographic algorithms</Name>
+    </PolicyName>
+    <Publisher>
+     <Name>Some Evaluation Authority</Name>
+    </Publisher>
+    <PolicyIssueDate>2009-01-01T00:00:00</PolicyIssueDate>
+
+
+
+Kunz, et al.                Standards Track                    [Page 35]
+
+RFC 5698                          DSSC                     November 2009
+
+
+    <Usage>Digital signature verification</Usage>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>SHA-1</Name>
+      <ObjectIdentifier>1.3.14.3.2.26</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Validity>
+       <End>2008-06-30</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>SHA-256</Name>
+      <ObjectIdentifier>2.16.840.1.101.3.4.2.1</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>SHA-512</Name>
+      <ObjectIdentifier>2.16.840.1.101.3.4.2.3</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>RSA</Name>
+      <ObjectIdentifier>1.2.840.113549.1.1.1</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>1024</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-03-31</End>
+      </Validity>
+     </Evaluation>
+     <Evaluation>
+
+
+
+Kunz, et al.                Standards Track                    [Page 36]
+
+RFC 5698                          DSSC                     November 2009
+
+
+      <Parameter name="moduluslength">
+       <Min>2048</Min>
+      </Parameter>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>DSA</Name>
+      <ObjectIdentifier>1.2.840.10040.4.1</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="plength">
+       <Min>1024</Min>
+      </Parameter>
+      <Parameter name="qlength">
+       <Min>160</Min>
+      </Parameter>
+      <Validity>
+       <End>2007-12-31</End>
+      </Validity>
+     </Evaluation>
+     <Evaluation>
+      <Parameter name="plength">
+       <Min>2048</Min>
+      </Parameter>
+      <Parameter name="qlength">
+       <Min>224</Min>
+      </Parameter>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>PKCS#1 v1.5 SHA-1 with RSA</Name>
+      <ObjectIdentifier>1.2.840.113549.1.1.5</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>1024</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-03-31</End>
+      </Validity>
+
+
+
+Kunz, et al.                Standards Track                    [Page 37]
+
+RFC 5698                          DSSC                     November 2009
+
+
+     </Evaluation>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>2048</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-06-30</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>PKCS#1 v1.5 SHA-256 with RSA</Name>
+      <ObjectIdentifier>1.2.840.113549.1.1.11</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>1024</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-03-31</End>
+      </Validity>
+     </Evaluation>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>2048</Min>
+      </Parameter>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>PKCS#1 v1.5 SHA-512 with RSA</Name>
+      <ObjectIdentifier>1.2.840.113549.1.1.13</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>1024</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-03-31</End>
+      </Validity>
+     </Evaluation>
+     <Evaluation>
+      <Parameter name="moduluslength">
+       <Min>2048</Min>
+
+
+
+Kunz, et al.                Standards Track                    [Page 38]
+
+RFC 5698                          DSSC                     November 2009
+
+
+      </Parameter>
+      <Validity>
+       <End>2014-12-31</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+    <Algorithm>
+     <AlgorithmIdentifier>
+      <Name>SHA-1 with DSA</Name>
+      <ObjectIdentifier>1.2.840.10040.4.3</ObjectIdentifier>
+     </AlgorithmIdentifier>
+     <Evaluation>
+      <Parameter name="plength">
+       <Min>1024</Min>
+      </Parameter>
+      <Parameter name="qlength">
+       <Min>160</Min>
+      </Parameter>
+      <Validity>
+       <End>2007-12-31</End>
+      </Validity>
+     </Evaluation>
+     <Evaluation>
+      <Parameter name="plength">
+       <Min>2048</Min>
+      </Parameter>
+      <Parameter name="qlength">
+       <Min>224</Min>
+      </Parameter>
+      <Validity>
+       <End>2008-06-30</End>
+      </Validity>
+     </Evaluation>
+    </Algorithm>
+   </SecuritySuitabilityPolicy>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al.                Standards Track                    [Page 39]
+
+RFC 5698                          DSSC                     November 2009
+
+
+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.                Standards Track                    [Page 40]
+