[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [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)                                              S. Okunick
Internet-Draft                           Fraunhofer Institute for Secure
Intended status: Standards Track                  Information Technology
Expires: December 24, 2007                                   U. Pordesch
                                                 Fraunhofer Gesellschaft
                                                           June 22, 2007


 Data Structure for Security Suitabilities of Cryptographic Algorithms
                                 (DSSC)
                      draft-ietf-ltans-dssc-00.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 December 24, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).










Kunz, et al.            Expires December 24, 2007               [Page 1]


Internet-Draft                    DSSC                         June 2007


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 December 24, 2007               [Page 2]


Internet-Draft                    DSSC                         June 2007


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.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Requirements and Assumptions . . . . . . . . . . . . . . . . .  7
     3.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Data Structures  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  SecuritySuitabilityPolicy  . . . . . . . . . . . . . . . .  9
     4.2.  PolicyName . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Publisher  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Address  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.5.  PolicyIssueDate  . . . . . . . . . . . . . . . . . . . . . 11
     4.6.  NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.7.  SuitableAlgorithm  . . . . . . . . . . . . . . . . . . . . 11
     4.8.  AlgorithmIdentifier  . . . . . . . . . . . . . . . . . . . 12
     4.9.  ParameterConstraints . . . . . . . . . . . . . . . . . . . 12
       4.9.1.  RSAConstraints . . . . . . . . . . . . . . . . . . . . 13
       4.9.2.  DSAConstraints . . . . . . . . . . . . . . . . . . . . 13
     4.10. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.11. Information  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.12. Signature  . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Proceeding . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Verification of Evidence Records using DSSC . . . . . 21
   Appendix B.  XML schema  . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27











Kunz, et al.            Expires December 24, 2007               [Page 3]


Internet-Draft                    DSSC                         June 2007


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

   Only some algorithms satisfy the security requirements and are
   suitable for usage in signatures.  Besides, because of the increasing
   performance of computers and progresses in cryptography, algorithms
   or their parameters become insecure over the years.  E.g. the hash
   algorithm MD5 is impractical by now.  A digital signature using such
   "weak" algorithms may lose its probative value.  Every kind of
   digital signed data like signed documents, time stamps, certificates,
   and revocation lists is affected, in particular in the case of long-
   term archiving.  Over long periods of time, it is realistic to assume
   that the algorithms used in signatures become insecure.

   For this reason, it is important to periodically reevaluate
   algorithms regarding their security properties and to consider these
   evaluations when creating, verifying or renewing signatures.  Such
   evaluations will give a prognosis how long an algorithm will be
   presumably secure and help to detect, whether insecure algorithms are
   used in a signature or whether signatures have been timely renewed.
   The evaluation of security suitabilites of algorithms cannot be done
   by the user itself.  They are made by expert committees after long
   scientific discussion and published by specific evaluation
   institutions.  In Germany the Federal Network Agency annually
   publishes a current evaluation of cryptografic algorithms
   [BNetzAg.2007].  Examples for European and international evaluations
   are [NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005].

   These publications evaluate algorithms in a textual form and are not
   interpretable by computer programs.  Therefore it is necessary to
   define an automatically interpretable data structure holding the
   algorithm evaluations.  In this way evaluation institutions are able
   use the standardized form for publication.  Such policies can be
   interpreted by e.g. signing and verification tools.  In the
   following, such evaluations are called security suitability policy.
   This document specifies a data structure for security suitability
   policies.





Kunz, et al.            Expires December 24, 2007               [Page 4]


Internet-Draft                    DSSC                         June 2007


1.2.  Use Cases

   In the following we present some use cases for security suitability
   policies.

   Long-term archiving:  The most important use case for security
      suitability policies is long-term archiving of signed data.
      Algorithms or their parameters will become insecure over very long
      periods of time.  Policies are used to determine whether
      signatures have to be renewed.  That means, the policies must
      provide information, which algorithms are currently suitable and
      which are not.  Additionally the policies assist in verifying
      archived documents since it has to be checked whether all
      signatures were timely renewed by time stamping, i.e. before
      algorithms became insecure.

   Signing and verifying:  When signing documents or certificates 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.

   Services:  Services may provide information about cryptographic
      algorithms.  E.g. such services can use these policies to provide
      the date when an algorithm became insecure or probably will become
      insecure or to provide all algorithms which are presently valid.
      Such services could be used by verification tools or long-term
      archiving systems so that they do not need to deal with the
      algorithm security by themselves.
      Long-term archive services supporting LTAP ([I-D.ietf-ltans-ltap])
      for providing evidence records ([I-D.ietf-ltans-ers]) may use the
      policies for signature renewal.  Additionally the policies may be
      integrated in the ERS as further validation data.

   Reencryption:  Security suitability policies can also be used to
      decide if encrypted documents must be reencrypted because the
      encryption algorithm is no longer secure.













Kunz, et al.            Expires December 24, 2007               [Page 5]


Internet-Draft                    DSSC                         June 2007


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 corresponding
      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 analyzes and evaluates algorithms and
      publishes them in the form of policies.

   Security suitability policy:  The evaluation of cryptographic
      algorithms according to their security in a specific application
      area, e.g. signing or verifying data.  The evaluation is published
      in an electronic format.

   Suitable algorithm:  An algorithm which is evaluated in a policy,
      i.e. is rated to be valid.




























Kunz, et al.            Expires December 24, 2007               [Page 6]


Internet-Draft                    DSSC                         June 2007


3.  Requirements and Assumptions

   This section first describes general requirements for a data
   structure containing the securitiy suitabilities of algorithms.
   Afterwards model assumptions are specified concerning both the design
   and the usage of the data structure.

   An evaluation of the security suitability of algorithms results in a
   policy.  It contains a list of the evaluated algorithms.  An
   evaluated algorithm 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.

3.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 purpose, e.g. signing, verification,
      signature renewal.

   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.

   Considering old algorithm suitabilities:  Policies may be
      periodically published, e.g. annually.  For some applications it
      may be desirable to interpret older policies.  To automatically
      verify an old signature, the security suitability of the used
      algorithms at the signing time must be determinable.  Therefore
      that policy is relevant which has been valid at signing time.  The
      date of publishing must be part of the policy.



Kunz, et al.            Expires December 24, 2007               [Page 7]


Internet-Draft                    DSSC                         June 2007


3.2.  Assumptions

   Only the latest policy is significant to decide whether an algorithm
   is currently suitable.  Is an algorithm listed in the current
   security suitability policy it is valid now, otherwise not.

   To decide whether an algorithm was suitable at a date in the past,
   you have to find a policy published between this date and today.
   This method also contains the following case: If an algorithm has not
   been existent at a date in the past and evaluated in a later policy
   for the first time, it will be assumed that the algorithm has then
   already been suitable.  Generally an algorithm is used in practice
   before it is evaluated.

   An algorithm is suitable only if it meets all requirements made in
   the relevant policy.

   Algorithms listed in the policy are suitable at least until the next
   policy is published.

   An algorithm once removed from a policy, is invalid and must not
   appear in a future policy.  There must not be any gaps in the
   validity periods.




























Kunz, et al.            Expires December 24, 2007               [Page 8]


Internet-Draft                    DSSC                         June 2007


4.  Data Structures

   This section describes the syntax of a security suitability policy.
   The syntax is defined as an XML schema.  The schema uses the
   following namespace:

      http://www.sit.fraunhofer.de/ssp

   Within this document, the prefix "ssp" 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:ssp="http://www.sit.fraunhofer.de/ssp"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
              targetNamespace="http://www.sit.fraunhofer.de/ssp"
              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"/>


4.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 4.12).  The element is
   defined by the following schema:


   <xs:element name="SecuritySuitabilityPolicy"
               type="ssp:SecuritySuitabilityPolicyType"/>
   <xs:complexType name="SecuritySuitabilityPolicyType">
     <xs:sequence>
       <xs:element ref="ssp:PolicyName"/>
       <xs:element ref="ssp:Publisher"/>
       <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
       <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
       <xs:element ref="ssp:SecuritySuitability" 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 December 24, 2007               [Page 9]


Internet-Draft                    DSSC                         June 2007


4.2.  PolicyName

   The PolicyName element contains the name of the policy.  It consists
   of the actual name and an optional URI.


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

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


4.3.  Publisher

   The Publisher element contains information about the publisher of the
   policy.  It is composed of the name, an optional address, and an
   optional URI.


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


4.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 December 24, 2007              [Page 10]


Internet-Draft                    DSSC                         June 2007


 <xs:element name="Address" type="ssp: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>


4.5.  PolicyIssueDate

   The PolicyIssueDate element indicates the point of time when the
   policy was issued.

4.6.  NextUpdate

   The optional NextUpdate element may be used to indicate when the next
   policy will be issued.

4.7.  SuitableAlgorithm

   A security suitability policy must contain at least one
   SuitableAlgorithm element.  A SuitableAlgorithm element describes the
   evaluation of one suitable cryptographic algorithm.  An algorithm can
   be identified by a name, object identifiers, and URIs.  Additionally
   specific parameter constraints, e.g. a required modulus length, can
   be specified.  The suitability of the algorithm is expressed by a
   validity period.  An algorithm is suitable according to the
   respective policy if it complies with the security suitability
   defined by the respective SuitableAlgorithm element.  The
   SuitableAlgorithm element is defined by the following schema:

















Kunz, et al.            Expires December 24, 2007              [Page 11]


Internet-Draft                    DSSC                         June 2007


 <xs:element name="SuitableAlgorithm" type="ssp:SuitableAlgorithmType"/>
 <xs:complexType name="SuitableAlgorithmType">
   <xs:sequence>
     <xs:element ref="ssp:AlgorithmIdentifier"/>
     <xs:element name="ParameterConstraints" minOccurs="0">
       <xs:complexType>
         <xs:sequence>
           <xs:any namespace="##any"/>
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI"/>
       </xs:complexType>
     </xs:element>
     <xs:element ref="ssp:Validity"/>
     <xs:element ref="ssp:Information" minOccurs="0"/>
   </xs:sequence>
 </xs:complexType>


4.8.  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="ssp:AlgorithmIdentifierType"/>
   <xs:complexType name="AlgorithmIdentifierType">
     <xs:sequence>
       <xs:element ref="ssp:Name"/>
       <xs:element name="ObjectIdentifier" type="xs:string"
                   minOccurs="0" maxOccurs="unbounded"/>
       <xs:element ref="ssp:URI" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>


4.9.  ParameterConstraints

   By the ParameterConstraints element, constraints on algorithm
   specific parameters can be expressed.  E.g. the suitability of the
   RSA algorithm depends on the "modulus" parameter (RSA with modulus =
   1024 may have another suitability period as RSA with modulus = 2048).
   Since the parameters depend on the actual algorithm, it is impossible
   to specify one data structure covering all algorithms.  Instead, an
   "any" element is used in the schema to express that an arbitrary XML
   structure can be inserted.  The following two sections define XML
   schemas for RSA and DSA parameters.  Parameter constraints needed for



Kunz, et al.            Expires December 24, 2007              [Page 12]


Internet-Draft                    DSSC                         June 2007


   other algorithms may be specified in separate XML schemas.  Note that
   not all algorithm suitabilities depend on parameter constraints, e.g.
   current hash algorithms like SHA-1 or RIPE-MD 160 do not have any
   parameters.

4.9.1.  RSAConstraints

   The RSAConstraints element must be used as parameter constraint in
   all RSA security suitabilities.  It contains the bit length of the
   RSA modulus [RFC2437].  The element is defined by the following
   schema:


  <xs:element name="RSAConstraints" type="ssp:RSAConstraintsType"/>
  <xs:complexType name="RSAConstraintsType">
    <xs:sequence>
      <xs:element name="modulus">
        <xs:complexType>
          <xs:attribute name="length" type="xs:integer" use="required"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>


4.9.2.  DSAConstraints

   The DSAConstraints element must be used as parameter constraint in
   all DSA security suitabilities.  It is composed of the bit lengths of
   the two public DSA parameters "p" (prime modulus) and "q" (prime
   divisor of p-1), both meeting the requirements defined in
   [FIPS.186-1.1998].  The element is defined by the following schema:


  <xs:element name="DSAConstraints" type="ssp:DSAConstraintsType"/>
  <xs:complexType name="DSAConstraintsType">
    <xs:sequence>
      <xs:element name="p">
        <xs:complexType>
          <xs:attribute name="length" type="xs:integer" use="required"/>
        </xs:complexType>
      </xs:element>
      <xs:element name="q">
        <xs:complexType>
          <xs:attribute name="length" type="xs:integer" use="required"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>



Kunz, et al.            Expires December 24, 2007              [Page 13]


Internet-Draft                    DSSC                         June 2007


  </xs:complexType>


4.10.  Validity

   The Validity element is used to define the period of the (estimated)
   suitability of the algorithm.  It is composed of a start date and an
   end date.  The element is defined by the following schema:


   <xs:element name="Validity" type="ssp:ValidityType"/>
   <xs:complexType name="ValidityType">
     <xs:sequence>
       <xs:element name="Start" type="xs:date"/>
       <xs:element name="End" type="xs:date"/>
     </xs:sequence>
   </xs:complexType>


4.11.  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="ssp: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>


4.12.  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,



Kunz, et al.            Expires December 24, 2007              [Page 14]


Internet-Draft                    DSSC                         June 2007


   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 December 24, 2007              [Page 15]


Internet-Draft                    DSSC                         June 2007


5.  Proceeding

   This section shows which information must be gathered in the
   different use cases and how to proceed to get this information.

   1.  Is an algorithm currently valid?
       Procedure: Take the current policy and check whether this
       algorithm is listed in it.  If it is, the algorithm is currently
       suitable.
       Input: algorithm
       Response: true or false

   2.  Did an algorithm have been valid at a particular date in the
       past?
       Procedure: Find the latest policy published after this particular
       date containing this algorithm.  If such a policy exists, the
       algorithm has been suitable at the specified date.
       Input: algorithm and date
       Response: true or false

   3.  Until which date in the future an algorithm is predicted to be
       valid?
       Procedure: Take the current policy and get the predicted validity
       end date of this algorithm, if the algorithm exists in the
       policy.
       Input: algorithm
       Response: date or error, if the algorithm does not exist

   4.  At which date became an algorithm invalid?
       Procedure: First it has to be assured, that the given algorithm
       has been valid at any time in the past.  Find the last policy
       containing this algorithm and generate the minimum of the
       predicted validity end date and the publication date of the
       following policy.
       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.
       Response: list of algorithms

   6.  Which algorithms have been valid at a particular date in the
       past?
       Procedure: All algorithms in a policy published at this date have
       been valid.  Additionally any algorithm newly added in one
       following policy has been valid.



Kunz, et al.            Expires December 24, 2007              [Page 16]


Internet-Draft                    DSSC                         June 2007


       Input: date
       Response: list of algorithms

















































Kunz, et al.            Expires December 24, 2007              [Page 17]


Internet-Draft                    DSSC                         June 2007


6.  Security Considerations

   The used policies for security suitabilities have 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 new
       policies are 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 December 24, 2007              [Page 18]


Internet-Draft                    DSSC                         June 2007


7.  References

7.1.  Normative References

   [ETSI-TS101903]
              European Telecommunication Standards Institute (ETSI),
              "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101
              903, Feb 2002.

   [I-D.ietf-ltans-ltap]
              Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)",
              draft-ietf-ltans-ltap-04 (work in progress), March 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

7.2.  Informative References

   [BNetzAg.2007]
              Federal Network Agency for Electricity, Gas,
              Telecommunications, Post and Railway, "Bekanntmachung zur
              elektronischen Signatur nach dem Signaturgesetz und der
              Signaturverordnung (Uebersicht ueber geeignete
              Algorithmen)", April 2007,
              <http://www.bundesnetzagentur.de/media/archive/9655.pdf>.

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

   [I-D.ietf-ltans-ers]
              Brandner, R., "Evidence Record Syntax (ERS)",
              draft-ietf-ltans-ers-15 (work in progress), June 2007.



Kunz, et al.            Expires December 24, 2007              [Page 19]


Internet-Draft                    DSSC                         June 2007


   [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 December 24, 2007              [Page 20]


Internet-Draft                    DSSC                         June 2007


Appendix A.  Verification of Evidence Records using DSSC

   This section describes the verification of an Evidence Record
   according to the Evidence Record Syntax [I-D.ietf-ltans-ers] by using
   the presented data structure.  Because Evidence Records contain
   hashtrees secured with time stamps and both the security of hashtrees
   and time stamp signatures depend on the used algorithms this is a
   suitable example to demonstrate a verification.  Precondition of the
   procedure is that at least one policy is present.

   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 time stamp signature
   have to be examined.  The definitive date is the time information in
   the time stamp (date of issue).  Starting with the first
   ArchiveTimestamp it has to be assured that

   1.  The time stamp 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 as well.

   3.  Algorithms for time stamp and hashtree in the preceding
       ArchiveTimestamp must have been suitable at date of considered
       ArchiveTimestamp.

   4.  Algorithms in the last ArchiveTimstamp have to be suitable now.

   If the check of one of these item fails, this will lead to a failure
   of the verification.



















Kunz, et al.            Expires December 24, 2007              [Page 21]


Internet-Draft                    DSSC                         June 2007


Appendix B.  XML schema



 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:ssp="http://www.sit.fraunhofer.de/ssp"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            targetNamespace="http://www.sit.fraunhofer.de/ssp"
            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="ssp:SecuritySuitabilityPolicyType"/>

 <xs:complexType name="SecuritySuitabilityPolicyType">
   <xs:sequence>
     <xs:element ref="ssp:PolicyName"/>
     <xs:element ref="ssp:Publisher"/>
     <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
     <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
     <xs:element ref="ssp:SuitableAlgorithm" 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="ssp:PolicyNameType"/>

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

 <xs:element name="Publisher" type="ssp:PublisherType"/>

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



Kunz, et al.            Expires December 24, 2007              [Page 22]


Internet-Draft                    DSSC                         June 2007


   </xs:sequence>
 </xs:complexType>

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

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

 <xs:element name="Address" type="ssp: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>

 <xs:element name="SuitableAlgorithm" type="ssp:SuitableAlgorithmType"/>

 <xs:complexType name="SuitableAlgorithmType">
   <xs:sequence>
     <xs:element ref="ssp:AlgorithmIdentifier"/>
     <xs:element name="ParameterConstraints" minOccurs="0">
       <xs:complexType>
         <xs:sequence>
           <xs:any namespace="##any"/>
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI"/>
       </xs:complexType>
     </xs:element>
     <xs:element ref="ssp:Validity"/>
     <xs:element ref="ssp:Information" minOccurs="0"/>
   </xs:sequence>
 </xs:complexType>

 <xs:element name="AlgorithmIdentifier"
             type="ssp:AlgorithmIdentifierType"/>

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



Kunz, et al.            Expires December 24, 2007              [Page 23]


Internet-Draft                    DSSC                         June 2007


 <xs:element name="Validity" type="ssp:ValidityType"/>

 <xs:complexType name="ValidityType">
   <xs:sequence>
     <xs:element name="Start" type="xs:date"/>
     <xs:element name="End" type="xs:date"/>
   </xs:sequence>
 </xs:complexType>

 <xs:element name="Information" type="ssp: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>

 <xs:element name="RSAConstraints" type="ssp:RSAConstraintsType"/>

 <xs:complexType name="RSAConstraintsType">
   <xs:sequence>
     <xs:element name="modulus">
       <xs:complexType>
         <xs:attribute name="length" type="xs:integer" use="required"/>
       </xs:complexType>
     </xs:element>
   </xs:sequence>
 </xs:complexType>

 <xs:element name="DSAConstraints" type="ssp:DSAConstraintsType"/>

 <xs:complexType name="DSAConstraintsType">
   <xs:sequence>
     <xs:element name="p">
       <xs:complexType>
         <xs:attribute name="length" type="xs:integer" use="required"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="q">
       <xs:complexType>



Kunz, et al.            Expires December 24, 2007              [Page 24]


Internet-Draft                    DSSC                         June 2007


         <xs:attribute name="length" type="xs:integer" use="required"/>
       </xs:complexType>
     </xs:element>
   </xs:sequence>
 </xs:complexType>
 </xs:schema>













































Kunz, et al.            Expires December 24, 2007              [Page 25]


Internet-Draft                    DSSC                         June 2007


Authors' Addresses

   Thomas Kunz
   Fraunhofer Institute for Secure Information Technology
   Rheinstrasse 75
   Darmstadt  D-64295
   Germany

   Email: thomas.kunz@sit.fraunhofer.de


   Susanne Okunick
   Fraunhofer Institute for Secure Information Technology
   Rheinstrasse 75
   Darmstadt  D-64295
   Germany

   Email: susanne.okunick@sit.fraunhofer.de


   Ulrich Pordesch
   Fraunhofer Gesellschaft
   Rheinstrasse 75
   Darmstadt  D-64295
   Germany

   Email: ulrich.pordesch@zv.fraunhofer.de
























Kunz, et al.            Expires December 24, 2007              [Page 26]


Internet-Draft                    DSSC                         June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kunz, et al.            Expires December 24, 2007              [Page 27]


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