[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5698

Long-term Archive And Notary                                     T. Kunz
Services (LTANS)                         Fraunhofer Institute for Secure
Internet-Draft                                    Information Technology
Intended status: Standards Track                              S. Okunick
Expires: November 20, 2008                          pawisda systems GmbH
                                                             U. Pordesch
                                                 Fraunhofer Gesellschaft
                                                            May 19, 2008


 Data Structure for Security Suitabilities of Cryptographic Algorithms
                                 (DSSC)
                      draft-ietf-ltans-dssc-03.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 November 20, 2008.













Kunz, et al.            Expires November 20, 2008               [Page 1]


Internet-Draft                    DSSC                          May 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 November 20, 2008               [Page 2]


Internet-Draft                    DSSC                          May 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. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.11. Parameter  . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.12. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.13. Information  . . . . . . . . . . . . . . . . . . . . . . . 14
     3.14. Signature  . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Definition of Parameters . . . . . . . . . . . . . . . . . . . 16
   5.  Proceeding . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Example of a Policy . . . . . . . . . . . . . . . . . 22
   Appendix B.  DSSC and ERS  . . . . . . . . . . . . . . . . . . . . 27
     B.1.  Verification of Evidence Records using DSSC  . . . . . . . 27
     B.2.  Storing DSSC Policies in Evidence Records  . . . . . . . . 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 November 20, 2008               [Page 3]


Internet-Draft                    DSSC                          May 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.  The hash
   algorithm MD5, for example, is unsuitable today.  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.  Since
   algorithm evaluations contain (predicted) validity periods of
   algorithms, they help to detect, whether an insecure algorithm is
   used in a signature or whether a signature has been renewed in time.
   Algorithm evaluations are made by expert committees after long
   scientific discussion and are published by specific evaluation
   institutions.  In Germany the Federal Network Agency annually
   publishes evaluations of cryptographic 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 them.  A
   standardized data structure can be used for publication and can be
   interpreted by e.g. signing and verification tools.  Algorithm
   evaluations are pooled in a so-called security suitability policy.
   In this document a data structure for a security suitability policy
   is specified.







Kunz, et al.            Expires November 20, 2008               [Page 4]


Internet-Draft                    DSSC                          May 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 to
      be valid.

1.3.  Use Cases

   In the following some use cases for a security suitability policy are
   presented.

   Long-term archiving:  The most important use case is long-term
      archiving of signed data.  Algorithms or their parameters become
      insecure over long time periods.  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 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 November 20, 2008               [Page 5]


Internet-Draft                    DSSC                          May 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 November 20, 2008               [Page 6]


Internet-Draft                    DSSC                          May 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 November 20, 2008               [Page 7]


Internet-Draft                    DSSC                          May 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 November 20, 2008               [Page 8]


Internet-Draft                    DSSC                          May 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:


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:dssc="http://www.sit.fraunhofer.de/dssc"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
              targetNamespace="http://www.sit.fraunhofer.de/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.14).  The element is
   defined by the following schema:


   <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="id" type="xs:ID"/>
   </xs:complexType>



Kunz, et al.            Expires November 20, 2008               [Page 9]


Internet-Draft                    DSSC                          May 2008


3.2.  PolicyName

   The PolicyName element consists of an arbitrary name of the policy
   and an optional Uniform Resource Identifier (URI).


   <xs:element name="PolicyName" type="dssc:PolicyNameType"/>
   <xs:complexType name="PolicyNameType">
     <xs:sequence>
       <xs:element ref="dssc:Name"/>
       <xs:element ref="dssc:URI" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

   <xs:element name="Name" type="xs:string"/>
   <xs:element name="URI" type="xs:anyURI"/>


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.


   <xs:element name="Publisher" type="dssc:PublisherType"/>
   <xs:complexType name="PublisherType">
     <xs:sequence>
       <xs:element ref="dssc:Name"/>
       <xs:element ref="dssc:Address" minOccurs="0"/>
       <xs:element ref="dssc:URI" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>


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 November 20, 2008              [Page 10]


Internet-Draft                    DSSC                          May 2008


 <xs:element name="Address" type="dssc:AddressType"/>
 <xs:complexType name="AddressType">
   <xs:sequence>
     <xs:element name="Street" type="xs:string"/>
     <xs:element name="Locality" type="xs:string"/>
     <xs:element name="StateOrProvince" type="xs:string" minOccurs="0"/>
     <xs:element name="PostalCode" type="xs:string"/>
     <xs:element name="Country" type="xs:string"/>
   </xs:sequence>
 </xs:complexType>


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 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 Algorithm element is defined by the following
   schema:


   <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:sequence>
   </xs:complexType>





Kunz, et al.            Expires November 20, 2008              [Page 11]


Internet-Draft                    DSSC                          May 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:


   <xs:element name="AlgorithmIdentifier"
               type="dssc:AlgorithmIdentifierType"/>
   <xs:complexType name="AlgorithmIdentifierType">
     <xs:sequence>
       <xs:element ref="dssc:Name"/>
       <xs:element name="ObjectIdentifier" type="xs:string"
                   minOccurs="0" maxOccurs="unbounded"/>
       <xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>


3.10.  Evaluation

   The evaluation element contains the evaluation of one cryptographic
   algorithm in dependence of its parameter contraints.  E.g. 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.


   <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:sequence>
   </xs:complexType>


3.11.  Parameter

   The Parameter element is used to express constraints on algorithm
   specific parameters like the "moduluslength" parameter in case of
   RSA.




Kunz, et al.            Expires November 20, 2008              [Page 12]


Internet-Draft                    DSSC                          May 2008


   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 may 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.

   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:





















Kunz, et al.            Expires November 20, 2008              [Page 13]


Internet-Draft                    DSSC                          May 2008


   <xs:element name="Parameter" type="dssc:ParameterType"/>
   <xs:complexType name="ParameterType">
     <xs:choice>
       <xs:element name="Exact" type="xs:string"/>
       <xs:element ref="dssc:Min"/>
       <xs:element ref="dssc:Max"/>
       <xs:element name="Range">
         <xs:complexType>
           <xs:sequence>
             <xs:element ref="dssc:Min"/>
             <xs:element ref="dssc:Max"/>
           </xs:sequence>
         </xs:complexType>
       </xs:element>
       <xs:any namespace="##other"/>
     </xs:choice>
     <xs:attribute name="name" type="xs:string" use="required"/>
   </xs:complexType>
   <xs:element name="Min" type="xs:string"/>
   <xs:element name="Max" type="xs:string"/>


3.12.  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:


   <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.13.  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:




Kunz, et al.            Expires November 20, 2008              [Page 14]


Internet-Draft                    DSSC                          May 2008


   <xs:element name="Information" type="dssc:InformationType"/>
   <xs:complexType name="InformationType">
     <xs:sequence>
       <xs:element name="Text" maxOccurs="unbounded">
         <xs:complexType>
           <xs:simpleContent>
             <xs:extension base="xs:string">
               <xs:attribute name="lang"/>
             </xs:extension>
           </xs:simpleContent>
         </xs:complexType>
       </xs:element>
     </xs:sequence>
   </xs:complexType>


3.14.  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 November 20, 2008              [Page 15]


Internet-Draft                    DSSC                          May 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".

   Publishers of policies must use the same parameter names, so that the
   correct interpretation is guaranteed.


































Kunz, et al.            Expires November 20, 2008              [Page 16]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 17]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 18]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 19]


Internet-Draft                    DSSC                          May 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., Sylvester, P., and C. Wallace, "Long-
              term Archive Protocol (LTAP)", draft-ietf-ltans-ltap-06
              (work in progress), February 2008.

   [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,
              <http://www.bundesnetzagentur.de/media/archive/12198.pdf>.

   [ETSI-TS102176-1-2005]
              European Telecommunication Standards Institute (ETSI),
              "Electronic Signatures and Infrastructures (ESI);



Kunz, et al.            Expires November 20, 2008              [Page 20]


Internet-Draft                    DSSC                          May 2008


              "Algorithms and Parameters for Secure Electronic
              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,
              <http://csrc.nist.gov/fips/fips1861.pdf>.

   [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 November 20, 2008              [Page 21]


Internet-Draft                    DSSC                          May 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.


   <SecuritySuitabilityPolicy xmlns="http://www.sit.fraunhofer.de/dssc"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <PolicyName>
       <name>Evaluation of suitable signature algorithms 2008</Name>
     </PolicyName>
     <Publisher>
       <Name>Federal Network Agency</Name>
     </Publisher>
     <PolicyIssueDate>2007-12-17T00:00:00</PolicyIssueDate>
     <Usage>Qualified electronic signatures</Usage>
     <Algorithm>
       <AlgorithmIdentifier>
         <Name>SHA-1</Name>
         <ObjectIdentifier>1.3.14.3.2.26</ObjectIdentifier>
       </AlgorithmIdentifier>
       <Evaluation>
         <Validity>
           <End>2008-06-31</End>
         </Validity>
       </Evaluation>
     </Algorithm>
     <Algorithm>
       <AlgorithmIdentifier>
         <Name>RIPEMD-160</Name>
         <ObjectIdentifier>1.3.36.3.2.1</ObjectIdentifier>
       </AlgorithmIdentifier>
       <Evaluation>
         <Validity>
           <End>2010-12-31</End>
         </Validity>
       </Evaluation>
     </Algorithm>
     <Algorithm>
       <AlgorithmIdentifier>
         <Name>SHA-224</Name>
         <ObjectIdentifier>2.16.840.1.101.3.4.2.4</ObjectIdentifier>
       </AlgorithmIdentifier>
       <Evaluation>
         <Validity>



Kunz, et al.            Expires November 20, 2008              [Page 22]


Internet-Draft                    DSSC                          May 2008


           <End>2014-12-31</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-384</Name>
         <ObjectIdentifier>2.16.840.1.101.3.4.2.2</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>768</Min>
         </Parameter>
         <Validity>
           <End>2000-12-31</End>



Kunz, et al.            Expires November 20, 2008              [Page 23]


Internet-Draft                    DSSC                          May 2008


         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>1024</Min>
         </Parameter>
         <Validity>
           <End>2008-03-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>1280</Min>
         </Parameter>
         <Validity>
           <End>2008-12-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>1536</Min>
         </Parameter>
         <Validity>
           <End>2009-12-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>1728</Min>
         </Parameter>
         <Validity>
           <End>2010-12-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>1976</Min>
         </Parameter>
         <Validity>
           <End>2014-12-31</End>
         </Validity>'
       </Evaluation>
       <Evaluation>
         <Parameter name="moduluslength">
           <Min>2048</Min>
         </Parameter>
         <Validity>
           <End>2014-12-31</End>



Kunz, et al.            Expires November 20, 2008              [Page 24]


Internet-Draft                    DSSC                          May 2008


         </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>1280</Min>
         </Parameter>
         <Parameter name="qlength">
           <Min>160</Min>
         </Parameter>
         <Validity>
           <End>2008-12-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="plength">
           <Min>1536</Min>
         </Parameter>
         <Parameter name="qlength">
           <Min>160</Min>
         </Parameter>
         <Validity>
           <End>2009-12-31</End>
         </Validity>
       </Evaluation>
       <Evaluation>
         <Parameter name="plength">
           <Min>2048</Min>
         </Parameter>
         <Parameter name="qlength">
           <Min>160</Min>
         </Parameter>



Kunz, et al.            Expires November 20, 2008              [Page 25]


Internet-Draft                    DSSC                          May 2008


         <Validity>
           <End>2009-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>
   </SecuritySuitabilityPolicy>


   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.
   Combined algorithms could replace the public key algorithms in the
   policy example.  They could also be listed together with public key
   algorithms.


   <Algorithm>
     <AlgorithmIdentifier>
       <Name>RIPEMD-160 with RSA 2048</Name>
       <ObjectIdentifier>1.3.36.3.3.1.2</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
       <Parameter name="moduluslength">
         <Min>2048</Min>
       </Parameter>
       <Validity>
         <End>2010-12-31</End>
       </Validity>
     </Evaluation>
   </Algorithm>








Kunz, et al.            Expires November 20, 2008              [Page 26]


Internet-Draft                    DSSC                          May 2008


Appendix B.  DSSC and ERS

B.1.  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 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 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 items fails, this will lead to a failure
   of the verification.

B.2.  Storing DSSC Policies in Evidence Records

   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 November 20, 2008              [Page 27]


Internet-Draft                    DSSC                          May 2008


Appendix C.  XML schema



  <?xml version="1.0" encoding="UTF-8"?>
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns:dssc="http://www.sit.fraunhofer.de/dssc"
             xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
             targetNamespace="http://www.sit.fraunhofer.de/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="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: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 ref="dssc:Address" minOccurs="0"/>
        <xs:element ref="dssc:URI" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Name" type="xs:string"/>
    <xs:element name="URI" type="xs:anyURI"/>
    <xs:element name="Address" type="dssc:AddressType"/>



Kunz, et al.            Expires November 20, 2008              [Page 28]


Internet-Draft                    DSSC                          May 2008


    <xs:complexType name="AddressType">
      <xs:sequence>
        <xs:element name="Street" type="xs:string"/>
        <xs:element name="Locality" type="xs:string"/>
        <xs:element name="StateOrProvince" type="xs:string"
                    minOccurs="0"/>
        <xs:element name="PostalCode" type="xs:string"/>
        <xs:element name="Country" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
    <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:sequence>
    </xs:complexType>
    <xs:element name="AlgorithmIdentifier"
                type="dssc:AlgorithmIdentifierType"/>
    <xs:complexType name="AlgorithmIdentifierType">
      <xs:sequence>
        <xs:element ref="dssc:Name"/>
        <xs:element name="ObjectIdentifier" type="xs:string"
                    minOccurs="0" 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" maxOccurs="unbounded">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:string">
                <xs:attribute name="lang"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>



Kunz, et al.            Expires November 20, 2008              [Page 29]


Internet-Draft                    DSSC                          May 2008


    </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:sequence>
    </xs:complexType>
    <xs:element name="Parameter" type="dssc:ParameterType"/>
    <xs:complexType name="ParameterType">
      <xs:choice>
        <xs:element name="Exact" type="xs:string"/>
        <xs:element ref="dssc:Min"/>
        <xs:element ref="dssc:Max"/>
        <xs:element name="Range">
          <xs:complexType>
            <xs:sequence>
              <xs:element ref="dssc:Min"/>
              <xs:element ref="dssc:Max"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:any namespace="##other"/>
      </xs:choice>
      <xs:attribute name="name" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:element name="Min" type="xs:string"/>
    <xs:element name="Max" type="xs:string"/>
  </xs:schema>





















Kunz, et al.            Expires November 20, 2008              [Page 30]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 31]


Internet-Draft                    DSSC                          May 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,
        evaluations             SEQUENCE OF Evaluation,
        information         [0] SEQUENCE OF UTF8String OPTIONAL
   }

   AlgID ::= SEQUENCE {
        name      UTF8String,
        oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
        uri   [1] SEQUENCE OF IA5String OPTIONAL
   }

   Evaluation ::= SEQUENCE {
        parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
        validity             [1] Validity
   }

   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



Kunz, et al.            Expires November 20, 2008              [Page 32]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 33]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 34]


Internet-Draft                    DSSC                          May 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,
      evaluations             SEQUENCE OF Evaluation,
      information         [0] SEQUENCE OF UTF8String OPTIONAL
 }

 AlgID ::= SEQUENCE {
      name      UTF8String,
      oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
      uri   [1] SEQUENCE OF IA5String         OPTIONAL
 }

 Evaluation ::= SEQUENCE {
      parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
      validity             [1] Validity
 }

 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 ::= {...}



Kunz, et al.            Expires November 20, 2008              [Page 35]


Internet-Draft                    DSSC                          May 2008


 Range ::= SEQUENCE {
      min  [0] OCTET STRING,
      max  [1] OCTET STRING
 }

 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 November 20, 2008              [Page 36]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 37]


Internet-Draft                    DSSC                          May 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 November 20, 2008              [Page 38]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/