[Docs] [txt|pdf|xml] [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: April 3, 2010                              pawisda systems GmbH
                                                             U. Pordesch
                                                 Fraunhofer Gesellschaft
                                                      September 30, 2009


Data Structure for the Security Suitability of Cryptographic Algorithms
                                 (DSSC)
                      draft-ietf-ltans-dssc-12.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 April 3, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.




Kunz, et al.              Expires April 3, 2010                 [Page 1]

Internet-Draft                    DSSC                    September 2009


Abstract

   Since cryptographic algorithms can become weak over the years, it is
   necessary to evaluate their security suitability.  When signing or
   verifying data, or when encrypting or decrypting data, these
   evaluations must be considered.  This document specifies a data
   structure that enables an automated analysis of the security
   suitability of a given cryptographic algorithm at a given point of
   time which may be in the past, at the present time or in the future.










































Kunz, et al.              Expires April 3, 2010                 [Page 2]

Internet-Draft                    DSSC                    September 2009


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Kunz, et al.              Expires April 3, 2010                 [Page 3]

Internet-Draft                    DSSC                    September 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Requirements and Assumptions . . . . . . . . . . . . . . . . .  8
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Data Structures  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  SecuritySuitabilityPolicy  . . . . . . . . . . . . . . . . 10
     3.2.  PolicyName . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Publisher  . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.4.  PolicyIssueDate  . . . . . . . . . . . . . . . . . . . . . 12
     3.5.  NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.7.  Algorithm  . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.8.  AlgorithmIdentifier  . . . . . . . . . . . . . . . . . . . 13
     3.9.  Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.10. Parameter  . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.11. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.12. Information  . . . . . . . . . . . . . . . . . . . . . . . 15
     3.13. Signature  . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.  DSSC Policies  . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Definition of Parameters . . . . . . . . . . . . . . . . . . . 18
   6.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.2.  Verify policy  . . . . . . . . . . . . . . . . . . . . . . 19
     6.3.  Algorithm evaluation . . . . . . . . . . . . . . . . . . . 19
     6.4.  Evaluation of parameters . . . . . . . . . . . . . . . . . 20
     6.5.  Output . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Appendix A.  DSSC and ERS  . . . . . . . . . . . . . . . . . . . . 32
     A.1.  Verification of Evidence Records using DSSC
           (informative)  . . . . . . . . . . . . . . . . . . . . . . 32
     A.2.  Storing DSSC Policies in Evidence Records (normative)  . . 32
   Appendix B.  XML schema (normative)  . . . . . . . . . . . . . . . 33
   Appendix C.  ASN.1 Module in 1988 Syntax (informative) . . . . . . 36
   Appendix D.  ASN.1 Module in 1997 Syntax (normative) . . . . . . . 39
   Appendix E.  Example . . . . . . . . . . . . . . . . . . . . . . . 42
   Appendix F.  Disclaimer  . . . . . . . . . . . . . . . . . . . . . 47
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48





Kunz, et al.              Expires April 3, 2010                 [Page 4]

Internet-Draft                    DSSC                    September 2009


1.  Introduction

1.1.  Motivation

   Digital signatures can provide data integrity and authentication.
   They are based on cryptographic algorithms that are required to have
   certain security properties.  For example, hash algorithms must be
   resistant to collisions and in case of public key algorithms
   computation of the private key that corresponds to a given public key
   must be infeasible.  If algorithms lack the required properties,
   signatures could be forged, unless they are protected by a strong
   cryptographic algorithm.

   Cryptographic algorithms that are used in signatures shall be
   selected to resist such attacks during their period of use.  For
   signature keys included in public key certificates, it is the
   validity period of the certificate.  Cryptographic algorithms that
   are used for encryption shall resist during the time during which it
   is planned to keep the information confidential.

   Only very few algorithms satisfy the security requirements.  Besides,
   because of the increasing performance of computers and progresses in
   cryptography, algorithms or their parameters become insecure over the
   years.  The hash algorithm MD5, for example, is unsuitable today for
   many purposes.  A digital signature using a "weak" algorithm has no
   probative value, unless the "weak" algorithm has been protected by a
   strong algorithm before the time it was considered to be weak.  Many
   kinds of digital signed data, including signed documents, time
   stamps, certificates, and revocation lists, are affected, in
   particular in the case of long-term archiving.  Over long periods of
   time, it is assumed that the algorithms used in signatures become
   insecure.

   For this reason, it is important to periodically evaluate an
   algorithm's fitness and to consider the results of these evaluations
   when creating and verifying signatures, or when maintaining the
   validity of signatures made in the past.  One result is a projected
   validity period for the algorithm, i.e., a prediction of the period
   of time during which the algorithm is fit for use.  This prediction
   can help to detect whether a weak algorithm is used in a signature
   and whether that signature has been properly protected in due time by
   another signature made using an algorithm that is suitable at the
   present point of time.  Algorithm evaluations are made by expert
   committees.  In Germany the Federal Network Agency annually publishes
   evaluations of cryptographic algorithms [BNetzAg.2008].  Examples of
   other European and international evaluations are
   [ETSI-TS102176-1-2005] and [NIST.800-57-Part1.2006].




Kunz, et al.              Expires April 3, 2010                 [Page 5]

Internet-Draft                    DSSC                    September 2009


   These evaluations are published in documents intended to be read by
   humans.  Therefore it is necessary to define a data structure that
   expresses the content of the evaluations to enable automated
   processing.  This standardized data structure can be used for
   publication and can be interpreted by signature generation and
   verification tools.  Algorithm evaluations are pooled in a security
   suitability policy.  In this document a data structure for a security
   suitability policy is specified.  Therefore the document provides a
   framework for expressing evaluations of cryptographic algorithms.
   This document does not attempt to catalog the security properties of
   cryptographic algorithms.  Furthermore no guidelines are made about
   which kind of algorithms shall be evaluated: For example, security
   suitability policies may be used to evaluate public key and hash
   algorithms, signature schemes, and encryption schemes.

1.2.  Terminology

   Algorithm:  A cryptographic algorithm, i.e. a public key or hash
      algorithm.  For public key algorithms, this is the algorithm with
      its parameters, if any.  Furthermore, the term "algorithm" is used
      for cryptographic schemes, and actually padding functions.

   Operator:  Instance which uses and interprets a policy, e.g. a
      signature verification component.

   Policy:  An abbreviation for security suitability policy.

   Publisher:  Instance that publishes the policy containing the
      evaluation of algorithms.

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

   Suitable algorithm:  An algorithm which is evaluated against a policy
      and determined to be valid, i.e. resistant against attacks, at a
      particular point of time.

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



Kunz, et al.              Expires April 3, 2010                 [Page 6]

Internet-Draft                    DSSC                    September 2009


      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.

   Signing and verifying:  When signing documents, or certificates, it
      must be assured that the algorithms used for signing or verifying
      are suitable.  Accordingly, when verifying CMS [RFC3852] or XML
      signatures [RFC3275] [ETSI-TS101903], not only the validity of the
      certificates may be checked but also the validity of the
      algorithms.

   Re-encryption:  A security suitability policy can also be used to
      decide if encrypted documents must be re-encrypted because the
      encryption algorithm is no longer secure.



























Kunz, et al.              Expires April 3, 2010                 [Page 7]

Internet-Draft                    DSSC                    September 2009


2.  Requirements and Assumptions

   Section 2.1 describes general requirements for a data structure
   containing the security suitability of algorithms.  In Section 2.2
   assumptions are specified concerning both the design and the usage of
   the data structure.

   A policy contains a list of algorithms that have been evaluated by a
   publisher.  An algorithm evaluation is described by its identifier,
   security constraints and validity period.  By these constraints the
   requirements for algorithm properties must be defined, e.g. a public
   key algorithm is evaluated on the basis of its parameters.

2.1.  Requirements

   Automatic interpretation:  The data structure of the policy must
      allow automated evaluation of the security suitability of an
      algorithm.

   Flexibility:  The data structure must be flexible enough to support
      new algorithms.  Future policy publications may include
      evaluations of algorithms that are currently unknown.  It must be
      possible to add new algorithms with the corresponding security
      constraints in the data structure.  Additionally the data
      structure must be independent of the intended use, e.g.,
      encryption, signing, verifying, and signature renewing.  Thus, the
      data structure is usable in every use case.

   Source authentication:  Policies may be published by different
      institutions, e.g. on national or EU level, whereas one policy
      needs not to be in agreement with the other one.  Furthermore
      organizations may undertake their own evaluations for internal
      purposes.  For this reason a policy must be attributable to its
      publisher.

   Integrity and authenticity:  It must be possible to assure the
      integrity and authenticity of a published security suitability
      policy.  Additionally the date of issue must be identifiable.

2.2.  Assumptions

   It is assumed that a policy contains the evaluations of all currently
   known algorithms, including the expired ones.

   An algorithm is suitable at a time of interest if it is contained in
   the current policy and the time of interest is within the validity
   period.  Additionally, if the algorithm has any parameters, these
   parameters must meet the requirements defined in the security



Kunz, et al.              Expires April 3, 2010                 [Page 8]

Internet-Draft                    DSSC                    September 2009


   constraints.

   If an algorithm appears in a policy for the first time, it may be
   assumed that the algorithm has already been suitable in the past.
   Generally, algorithms are used in practice prior to evaluation.

   To avoid inconsistencies, multiple instances of the same algorithm
   are prohibited.  The publisher must take care about preventing
   conflicts within a policy.

   Assertions made in the policy are suitable at least until the next
   policy is published.

   Publishers may extend the lifetime of an algorithm prior to reaching
   the end of the algorithm's validity period by publishing a revised
   policy.  Publishers should not resurrect algorithms that are expired
   at the time a revised policy is published.


































Kunz, et al.              Expires April 3, 2010                 [Page 9]

Internet-Draft                    DSSC                    September 2009


3.  Data Structures

   This section describes the syntax of a security suitability policy
   defined as an XML schema [W3C.REC-xmlschema-1-20041028].  ASN.1
   modules are defined in Appendix C and Appendix D.  The schema uses
   the following XML namespace [W3C.REC-xml-names-20060816]:

      urn:ietf:params:xml:ns:dssc

   Within this document, the prefix "dssc" is used for this namespace.
   The schema starts with the following schema definition:


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:dssc="urn:ietf:params:xml:ns:dssc"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
              targetNamespace="urn:ietf:params:xml:ns:dssc"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified">
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
              schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
              schemaLocation="xmldsig-core-schema.xsd"/>


3.1.  SecuritySuitabilityPolicy

   The SecuritySuitabilityPolicy element is the root element of a
   policy.  It has an optional id attribute which MUST be used as a
   reference when signing the policy (Section 3.13).  The optional lang
   attribute defines the language according to [RFC4646].  The language
   is applied to all human readable text within the policy.  If the lang
   attribute is omitted, the default language is English (en).  The
   element is defined by the following schema:
















Kunz, et al.              Expires April 3, 2010                [Page 10]

Internet-Draft                    DSSC                    September 2009


   <xs:element name="SecuritySuitabilityPolicy"
               type="dssc:SecuritySuitabilityPolicyType"/>
   <xs:complexType name="SecuritySuitabilityPolicyType">
     <xs:sequence>
       <xs:element ref="dssc:PolicyName"/>
       <xs:element ref="dssc:Publisher"/>
       <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
       <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
       <xs:element name="Usage" type="xs:string" minOccurs="0"/>
       <xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
       <xs:element ref="ds:Signature" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="version" type="xs:string" default="1"/>
     <xs:attribute name="lang" default="en"/>
     <xs:attribute name="id" type="xs:ID"/>
   </xs:complexType>


3.2.  PolicyName

   The PolicyName element contains an arbitrary name for the policy.
   The optional elements Object Identifier (OID) and Uniform Resource
   Identifier (URI) MAY be used for the identification of the policy.
   OIDs MUST be expressed in the dot notation.


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

   <xs:element name="Name" type="xs:string"/>
   <xs:element name="ObjectIdentifier">
     <xs:simpleType>
       <xs:restriction base="xs:string">
         <xs:pattern value="(\d+\.)+\d+"/>
       </xs:restriction>
     </xs:simpleType>
   </xs:element>
   <xs:element name="URI" type="xs:anyURI"/>







Kunz, et al.              Expires April 3, 2010                [Page 11]

Internet-Draft                    DSSC                    September 2009


3.3.  Publisher

   The Publisher element contains information about the publisher of the
   policy.  It is composed of the name, e.g. name of institution, an
   optional address, and an optional URI.  The Address element contains
   arbitrary free-format text not intended for automatic processing.


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


3.4.  PolicyIssueDate

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

3.5.  NextUpdate

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

3.6.  Usage

   The optional Usage element determines the intended use of the policy
   (e.g. certificate validation, signing and verifying documents).  The
   element contains free-format text intended only for human
   readability.

3.7.  Algorithm

   A security suitability policy MUST contain at least one Algorithm
   element.  An algorithm is identified by an AlgorithmIdentifier
   element.  Additionally the Algorithm element contains all evaluations
   of the specific cryptographic algorithm.  More than one evaluation
   may be necessary if the evaluation depends on the parameter
   constraints.  An optional "any" element MAY be used to extend the
   Algorithm element.  The Algorithm element is defined by the following
   schema:






Kunz, et al.              Expires April 3, 2010                [Page 12]

Internet-Draft                    DSSC                    September 2009


   <xs:element name="Algorithm" type="dssc:AlgorithmType"/>
   <xs:complexType name="AlgorithmType">
     <xs:sequence>
       <xs:element ref="dssc:AlgorithmIdentifier"/>
       <xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
       <xs:element ref="dssc:Information" minOccurs="0"/>
       <xs:any namespace="##other" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>


3.8.  AlgorithmIdentifier

   The AlgorithmIdentifier element is used to identify a cryptographic
   algorithm.  It consists of the algorithm name, at least one OID, and
   optional URIs.  The algorithm name is not intended to be parsed by
   automatic processes.  It is only intended to be read by humans.  The
   OID MUST be expressed in dot notation (e.g. 1.3.14.3.2.26).  The
   element is defined as follows:


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


3.9.  Evaluation

   The Evaluation element contains the evaluation of one cryptographic
   algorithm in dependence of its parameter constraints.  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.  An optional "any" element MAY be used to extend the
   Evaluation element.







Kunz, et al.              Expires April 3, 2010                [Page 13]

Internet-Draft                    DSSC                    September 2009


   <xs:element name="Evaluation" type="dssc:EvaluationType"/>
   <xs:complexType name="EvaluationType">
     <xs:sequence>
       <xs:element ref="dssc:Parameter" minOccurs="0"
                                        maxOccurs="unbounded"/>
       <xs:element ref="dssc:Validity"/>
       <xs:any namespace="##other" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>


3.10.  Parameter

   The Parameter element is used to express constraints on algorithm
   specific parameters.

   The Parameter element has a name attribute which holds the name of
   the parameter (e.g. "moduluslength" for RSA [RFC3447]).  Section 5
   defines parameter names for currently known public key algorithms
   which SHOULD be used.  For the actual parameter, a range of values or
   an exact value may be defined.  These constraints are expressed by
   the following elements:

   Min:  The Min element defines the minimum value of the parameter.
      That means, values equal or greater than the given value meet the
      requirements.

   Max:  The Max element defines the maximum value the parameter may
      take.

   At least one of both elements MUST be set to define a range of
   values.  A range MAY also be specified by a combination of both
   elements, whereas the value of the Min element MUST be less than or
   equal to the value of the Max element.  The parameter may have any
   value within the defined range, including the minimum and maximum
   values.  An exact value is expressed by using the same value in both
   the Min and the Max element.

   These constraints are sufficient for all current algorithms.  If
   future algorithms 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.  A parameter MUST contain at least one
   constraint.  The schema for the Parameter element is as follows:







Kunz, et al.              Expires April 3, 2010                [Page 14]

Internet-Draft                    DSSC                    September 2009


   <xs:element name="Parameter" type="dssc:ParameterType"/>
   <xs:complexType name="ParameterType">
     <xs:sequence>
       <xs:element name="Min" type="xs:int" minOccurs="0"/>
       <xs:element name="Max" type="xs:int" minOccurs="0"/>
       <xs:any namespace="##other" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="required"/>
   </xs:complexType>


3.11.  Validity

   The Validity element is used to define the period of the (predicted)
   suitability of the algorithm.  It is composed of an optional start
   date and an optional end date.  Defining no end date means the
   algorithm has an open-end validity.  Of course this may be restricted
   by a future policy which sets an end date for the algorithm.  If the
   end of the validity period is in the past, the algorithm was suitable
   until that end date.  The element is defined by the following schema:


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


3.12.  Information

   The Information element MAY be used to give additional textual
   information about the algorithm or the evaluation, e.g. references on
   algorithm specifications.  The element is defined as follows:


   <xs:element name="Information" type="dssc:InformationType"/>
   <xs:complexType name="InformationType">
     <xs:sequence>
       <xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>







Kunz, et al.              Expires April 3, 2010                [Page 15]

Internet-Draft                    DSSC                    September 2009


3.13.  Signature

   The optional Signature element MAY be used to guarantee the integrity
   and authenticity of the policy.  It is an XML signature specified in
   [RFC3275].  The signature MUST relate to the
   SecuritySuitabilityPolicy element.  If the Signature element is set,
   the SecuritySuitabilityPolicy element MUST have the optional id
   attribute.  This attribute MUST be used to reference the
   SecuritySuitabilityPolicy element within the Signature element.
   Since it is an enveloped signature, the signature MUST use the
   transformation algorithm identified by the following URI:

      http://www.w3.org/2000/09/xmldsig#enveloped-signature






































Kunz, et al.              Expires April 3, 2010                [Page 16]

Internet-Draft                    DSSC                    September 2009


4.  DSSC Policies

   DSSC policies MUST be expressed either in XML or ASN.1.  However, in
   order to reach interoperability DSSC policies SHOULD be published in
   both XML and ASN.1.

   In the case of XML, a DSSC policy is an XML document that MUST be
   well-formed and SHOULD be valid.  XML encoded DSSC policies MUST be
   based on XML 1.0 [W3C.REC-xml-20081126] and MUST be encoded using
   UTF-8 [RFC3629].  This specification makes use of XML namespaces
   [W3C.REC-xml-names-20060816] for identifying DSSC policies.  The
   namespace URI for elements defined by this specification is a URN
   [RFC2141], using the namespace prefix "dssc".  This URN is:

      urn:ietf:params:xml:ns:dssc

   XML encoded DSSC policies are identified with the MIME type
   "application/dssc+xml" and are instances of the XML schema
   [W3C.REC-xmlschema-1-20041028] defined in Appendix B.

   A file containing a DSSC policy in ASN.1 representation (for
   specification of ASN.1 refer to [CCITT.x208.1988], [CCITT.x209.1988],
   [CCITT.x680.2002] and [CCITT.x690.2002]) MUST contain only the DER
   encoding of one DSSC policy, i.e. there MUST NOT be an extraneous
   header or trailer information in the file.  ASN.1 based DSSC policies
   are identified with the MIME type "application/dssc+der".
   Appropriate ASN.1 modules are defined in Appendix C (1988-ASN.1
   syntax) and Appendix D (1997-ASN.1 syntax).























Kunz, et al.              Expires April 3, 2010                [Page 17]

Internet-Draft                    DSSC                    September 2009


5.  Definition of Parameters

   This section defines the parameter names for the currently known
   public key algorithms.  The following parameters also refer to
   cryptographic schemes based on these public key algorithms (e.g. the
   PKCS#1 v1.5 signature scheme SHA-256 with RSA [RFC3447]).

      The parameter of RSA [RFC3447] SHOULD be named "moduluslength".

      The parameters for DSA [FIPS186-2] SHOULD be "plength" and
      "qlength".

   These parameter names are registered by IANA (see Section 8).  It may
   be necessary to register further algorithms not given in this section
   (in particular future algorithms).  The process for registering
   parameter names of further algorithms is described in Section 8.
   Publishers of policies SHOULD use these parameter names, so that the
   correct interpretation is guaranteed.

































Kunz, et al.              Expires April 3, 2010                [Page 18]

Internet-Draft                    DSSC                    September 2009


6.  Processing

   Evaluation of an algorithm's security suitability is described in
   three parts: verification of the policy, determination of algorithm
   validity, and evaluation of algorithm parameters, if any.

   In the following, a process is described

   o  to determine if an algorithm was suitable at a particular point of
      time

   o  and to determine until when an algorithm was or will be suitable.

6.1.  Inputs

   To determine the security suitability of an algorithm, the following
   information is required:

   o  Policy

   o  Current time

   o  Algorithm identifier and parameter constraints (if associated)

   o  Time of interest (optional).  Providing no time of interest means
      determination of the validity end date of algorithm.

6.2.  Verify policy

   The signature on the policy SHOULD be verified and a certification
   path from the policy signer's certificate to a current trust anchor
   SHOULD be constructed and validated [RFC5280].  The algorithms used
   to verify the digital signature and validate the certification path
   MUST be suitable per the contents of the policy being verified.  If
   signature verification fails, certification path validation fails or
   an unsuitable algorithm is required to perform these checks, then the
   policy MUST be rejected.

   The nextUpdate time in the policy MUST be greater than the current
   time or absent.  If the nextUpdate time is less than the current
   time, the policy MUST be rejected.

6.3.  Algorithm evaluation

   To determine the validity period of an algorithm, locate the
   Algorithm element in the policy that corresponds to the algorithm
   identifier provided as input.  The Algorithm element is located by
   comparing the OID in the element to the OID included in the algorithm



Kunz, et al.              Expires April 3, 2010                [Page 19]

Internet-Draft                    DSSC                    September 2009


   identifier provided as input.

   If no matching Algorithm element is found, then the algorithm is
   unknown.

   If the time of interest was provided as input, the validity of each
   Evaluation element MUST be checked in order to determine if the
   algorithm was suitable at the time of interest.  For each Evaluation
   element,

   o  Confirm the Start time is less than the time of interest or
      absent.  Discard the entry if the Start time is present and
      greater than the time of interest.

   o  Confirm the End time is greater than the time of interest or
      absent.  Discard the entry if the End time is present and less
      than the time of interest.

   If all Evaluation elements were rejected, the algorithm is not
   suitable according the policy.

   Any entries not rejected will be used for the evaluation of the
   parameters, if any.

6.4.  Evaluation of parameters

   Any necessary parameters of the entries not rejected MUST be
   evaluated within the context of the type and usage of the algorithm.
   Details of parameter evaluation are defined on a per algorithm basis.

   To evaluate the parameters, the Parameter elements of each Evaluation
   element that has not been rejected in the process described in
   Section 6.3 MUST be checked.  For each Parameter element,

   o  Confirm that the parameter was provided as input.  Discard the
      Evaluation element if the parameter does not match to any of the
      parameters provided as input.

   o  If the Parameter element has a Min element, confirm that the
      parameter value is less than or equal to the according parameter
      provided as input.  Discard the Evaluation element if the
      parameter value does not meet the constraint.

   o  If the Parameter element has a Max element, confirm that the
      parameter value is greater than or equal to the according
      parameter provided as input.  Discard the Evaluation element if
      the parameter value does not meet the constraint.




Kunz, et al.              Expires April 3, 2010                [Page 20]

Internet-Draft                    DSSC                    September 2009


   o  If the Parameter has another constraint, confirm that the value of
      the according parameter provided as input meets this constraint.
      If it does not or if the constraint is unrecognized, discard the
      Evaluation element.

   If all Evaluation elements were rejected, the algorithm is not
   suitable according the policy.

   Any entries not rejected will be provided as output.

6.5.  Output

   If the algorithm is not in the policy, return an error "algorithm
   unknown".

   If no time of interest was provided as input, return the maximum End
   time of the Evaluation elements that were not discarded.  If at least
   one End time of these Evaluation elements is absent, return
   "algorithm has an indefinite end time".

   Otherwise, if the algorithm is not suitable relative to the time of
   interest, return an error "algorithm unsuitable".

   If the algorithm is suitable relative to the time of interest, return
   the Evaluation elements that were not discarded.


























Kunz, et al.              Expires April 3, 2010                [Page 21]

Internet-Draft                    DSSC                    September 2009


7.  Security Considerations

   The policy for algorithm's security suitability has great impact on
   the quality of the results of signature generation and verification
   operations.  If an algorithm is incorrectly evaluated against a
   policy, signatures with a low probative force could be created or
   verification results could be incorrect.  The following security
   considerations have been identified:

   1.  Publishers MUST ensure unauthorized manipulation of any security
       suitability is not possible prior to a policy being signed and
       published.  There is no mechanism provided to revoke a policy
       after publication.  Since the algorithm evaluations change
       infrequently, the lifespan of a policy should be carefully
       considered prior to publication.

   2.  Operators SHOULD only accept policies issued by a trusted
       publisher.  Furthermore, the validity of the certificate used to
       sign the policy SHOULD be verifiable by CRL [RFC5280] or OCSP
       [RFC2560].  The certificate used to sign the policy SHOULD be
       revoked if the algorithms used in this certificate are not longer
       suitable.  It MUST NOT be possible to alter or replace a policy
       once accepted by an operator.

   3.  Operators SHOULD periodically check to see if a new policy has
       been published to avoid using obsolete policy information.  For
       publishers it is suggested not to omit the NextUpdate element in
       order to give operators a hint, when the next policy will be
       published.

   4.  When signing a policy, algorithms SHOULD be used which are
       suitable according this policy.

   5.  The processing rule described in Section 6 is about one
       cryptographic algorithm independently of the use case.  Depending
       upon the use case, an algorithm that is no more suitable at the
       time of interest, does not necessarily mean that the data
       structure where it is used is no more secure.  For example, a
       signature has been made with an RSA signer's key of 1024 bits.
       This signature is time-stamped with a time-stamp token that uses
       an RSA key of 2048 bits, before an RSA key size of 1024 bits will
       be broken.  The fact that the signature key of 1024 bits is no
       more suitable at the time of interest does not mean that the
       whole data structure is no more secure, if an RSA key size of
       2048 bits is still suitable at the time of interest.

   6.  In addition to the key size considerations, other considerations
       must be applied, like whether a time-stamp token has been



Kunz, et al.              Expires April 3, 2010                [Page 22]

Internet-Draft                    DSSC                    September 2009


       provided by a trusted authority.  It means that the simple use of
       a suitability policy is not the single element to consider when
       evaluating the security of a complex data structure using several
       cryptographic algorithms.

   7.  The policies described in this document are suitable to evaluate
       basic cryptographic algorithms, like public key or hash
       algorithms, as well as cryptographic schemes (e.g. the PKCS#1
       v1.5 signature schemes [RFC3447]).  But it MUST be kept in mind
       that a basic cryptographic algorithm that is suitable according
       to the policy, does not necessarily mean that any cryptographic
       schemes based on this algorithm are also secure.  For example, a
       signature scheme based on RSA must not necessarily be secure if
       RSA is suitable.  In case of a complete signature verification
       including validation of the certificate path, various algorithms
       have to be checked against the policy (i.e. signature schemes of
       signed data objects and revocation information, public key
       algorithms of the involved certificates, etc.).  Thus a policy
       SHOULD contain evaluations of public key and hash algorithms as
       well as signature schemes.

   8.  Re-encrypting documents that were originally encrypted using an
       algorithm that is no more suitable, will not protect the
       semantics of the document, if the document has been intercepted.
       However, for documents stored in an encrypted form, re-encryption
       must be considered, unless the document has lost its original
       value.
























Kunz, et al.              Expires April 3, 2010                [Page 23]

Internet-Draft                    DSSC                    September 2009


8.  IANA Considerations

   This document defines the XML namespace "urn:ietf:params:xml:ns:dssc"
   according to the guidelines in [RFC3688].  This namespace has been
   registered in the IANA XML Registry.

   This document defines an XML schema (see Appendix B) according to the
   guidelines in [RFC3688].  This XML schema has been registered in the
   IANA XML Registry and can be identified with the URN
   "urn:ietf:params:xml:schema:dssc".

   This document defines the MIME type "application/dssc+xml".  This
   MIME type has been registered by IANA under "MIME Media Types"
   according to the procedures of [RFC4288].

      Type name: application

      Subtype name: dssc+xml

      Required parameters: none

      Optional parameters: "charset" as specified for "application/xml"
      in [RFC3023].

      Encoding considerations: Same as specified for "application/xml"
      in [RFC3023].

      Security considerations: Same as specified for "application/xml"
      in Section 10 of [RFC3023].  For further security consideration
      see Section 7.

      Interoperability considerations: Same as specified for
      "application/xml" in [RFC3023].

      Published specification: This document

      Applications which use this media: applications for long-term
      archiving of signed data, applications for signing data /
      verifying signed data, and applications for encrypting /
      decrypting data

      Additional information:

      1.  Magic number(s): none

      2.  File extension(s): .xdssc





Kunz, et al.              Expires April 3, 2010                [Page 24]

Internet-Draft                    DSSC                    September 2009


      3.  Macintosh file type code: "TEXT"

      4.  Object Identifiers: none

      Person to contact for further information: Thomas Kunz
      (thomas.kunz@sit.fraunhofer.de)

      Intended usage: COMMON

      Restrictions on usage: none

      Author/Change controller: IETF

   This document defines the MIME type "application/dssc+der".  This
   MIME type has been registered by IANA under "MIME Media Types"
   according to the procedures of [RFC4288].

      Type name: application

      Subtype name: dssc+der

      Required parameters: none

      Optional parameters: none

      Encoding considerations: binary

      Security considerations: See Section 7.

      Interoperability considerations: none

      Published specification: This document

      Applications which use this media: applications for long-term
      archiving of signed data, applications for signing data /
      verifying signed data, and applications for encrypting /
      decrypting data

      Additional information:

      1.  Magic number(s): none

      2.  File extension(s): .dssc

      3.  Macintosh file type code: none

      4.  Object Identifiers: none




Kunz, et al.              Expires April 3, 2010                [Page 25]

Internet-Draft                    DSSC                    September 2009


      Person to contact for further information: Thomas Kunz
      (thomas.kunz@sit.fraunhofer.de)

      Intended usage: COMMON

      Restrictions on usage: none

      Author/Change controller: IETF

   This specification creates a new IANA registry entitled "Data
   Structure for the Security Suitability of Cryptographic Algorithms
   (DSSC)".  This registry contains two sub-registries entitled
   "Parameter Definitions" and "Cryptographic Algorithms".  The policy
   for future assignments to the sub-registry "Parameter Definitions" is
   "RFC required".

   [TO BE REMOVED: The initial values for the "Parameter Definitions"
   sub-registry are:


  Value              Description                     Reference
  --------------     ------------------------------- -------------------
  moduluslength      Parameter for RSA               [Ref. to this doc.]
                     (integer value)
  plength            Parameter for DSA               [Ref. to this doc.]
                     (integer value, used together
                     with parameter "qlength")
  qlength            Parameter for DSA               [Ref. to this doc.]
                     (integer value, used together
                     with parameter "plength")


   ]

   The sub-registry "Cryptographic Algorithms" contains textual names as
   well as Object Identifiers (OIDs) and Uniform Resource Identifiers
   (URIs) of cryptographic algorithms.  It serves as assistance when
   creating a new policy.  The policy for future assignments is "First
   Come First Served".  When registering a new algorithm, the following
   information MUST be provided:

   o  The textual name of the algorithm.

   o  The OID of the algorithm.

   o  A reference to a publicly available specification which defines
      the algorithm and its identifiers.




Kunz, et al.              Expires April 3, 2010                [Page 26]

Internet-Draft                    DSSC                    September 2009


   Optionally, a URI MAY be provided if possible.

   [TO BE REMOVED: The initial values for the "Cryptographic Algorithms"
   sub-registry are:


 Name                      OID / URI                           Reference
 -----------------------   ---------------------------------  ----------
 rsaEncryption             1.2.840.113549.1.1.1                [RFC3447]

 dsa                       1.2.840.10040.4.1                   [RFC3279]

 md2                       1.2.840.113549.2.2                  [RFC3279]

 md5                       1.2.840.113549.2.5                  [RFC3279]
             http://www.w3.org/2001/04/xmldsig-more#md5        [RFC4051]

 sha-1                     1.3.14.3.2.26                       [RFC3279]
             http://www.w3.org/2000/09/xmldsig#sha1            [RFC3275]

 sha-224                   2.16.840.1.101.3.4.2.4              [RFC4055]
             http://www.w3.org/2001/04/xmldsig-more#sha224     [RFC4051]

 sha-256                   2.16.840.1.101.3.4.2.1              [RFC4055]

 sha-384                   2.16.840.1.101.3.4.2.2              [RFC4055]
             http://www.w3.org/2001/04/xmldsig-more#sha384     [RFC4051]

 sha-512                   2.16.840.1.101.3.4.2.3              [RFC4055]

 md2WithRSAEncryption      1.2.840.113549.1.1.2                [RFC3443]

 md5WithRSAEncryption      1.2.840.113549.1.1.4                [RFC3443]
             http://www.w3.org/2001/04/xmldsig-more#rsa-md5    [RFC4051]

 sha1WithRSAEncryption     1.2.840.113549.1.1.5                [RFC3443]
             http://www.w3.org/2000/09/xmldsig#rsa-sha1        [RFC3275]

 sha256WithRSAEncryption   1.2.840.113549.1.1.11               [RFC3443]
             http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [RFC4051]

 sha384WithRSAEncryption   1.2.840.113549.1.1.12               [RFC3443]
             http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 [RFC4051]

 sha512WithRSAEncryption   1.2.840.113549.1.1.13               [RFC3443]
             http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 [RFC4051]

 sha1WithDSA               1.2.840.10040.4.3                   [RFC3279]



Kunz, et al.              Expires April 3, 2010                [Page 27]

Internet-Draft                    DSSC                    September 2009


             http://www.w3.org/2000/09/xmldsig#dsa-sha1        [RFC3275]



   ]














































Kunz, et al.              Expires April 3, 2010                [Page 28]

Internet-Draft                    DSSC                    September 2009


9.  References

9.1.  Normative References

   [CCITT.x680.2002]
              International Telephone and Telegraph Consultative
              Committee, "Abstract Syntax Notation One (ASN.1):
              Specification of basic notation", CCITT Recommendation
              X.680, July 2002.

   [CCITT.x690.2002]
              International Telephone and Telegraph Consultative
              Committee, "AASN.1 encoding rules:  Specification of basic
              encoding Rules (BER), Canonical encoding rules (CER) and
              Distinguished encoding rules (DER)", CCITT Recommendation
              X.690, July 2002.

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

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

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

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

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

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", RFC 4646, September 2006.




Kunz, et al.              Expires April 3, 2010                [Page 29]

Internet-Draft                    DSSC                    September 2009


   [RFC4998]  Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
              Record Syntax (ERS)", RFC 4998, August 2007.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [W3C.REC-xml-20081126]
              Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C.,
              and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, November 2008,
              <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [W3C.REC-xml-names-20060816]
              Layman, A., Hollander, D., Tobin, R., and T. Bray,
              "Namespaces in XML 1.0 (Second Edition)", World Wide Web
              Consortium Recommendation REC-xml-names-20060816,
              August 2006,
              <http://www.w3.org/TR/2006/REC-xml-names-20060816>.

   [W3C.REC-xmlschema-1-20041028]
              Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,
              "XML Schema Part 1: Structures Second Edition", World Wide
              Web Consortium Recommendation REC-xmlschema-1-20041028,
              October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

9.2.  Informative References

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

   [CCITT.x208.1988]
              International Telephone and Telegraph Consultative
              Committee, "Specification of Abstract Syntax Notation One
              (ASN.1)", CCITT Recommendation X.208, November 1988.

   [CCITT.x209.1988]
              International Telephone and Telegraph Consultative
              Committee, "Specification of Basic Encoding Rules for
              Abstract Syntax Notation One (ASN.1)",



Kunz, et al.              Expires April 3, 2010                [Page 30]

Internet-Draft                    DSSC                    September 2009


              CCITT Recommendation X.209, November 1988.

   [ETSI-TS101903]
              European Telecommunication Standards Institute (ETSI),
              "XML Advanced Electronic Signatures (XAdES)", ETSI TS 101
              903 V1.3.2, March 2006.

   [ETSI-TS102176-1-2005]
              European Telecommunication Standards Institute (ETSI),
              "Electronic Signatures and Infrastructures (ESI);
              "Algorithms and Parameters for Secure Electronic
              Signatures; Part 1: Hash functions and asymmetric
              algorithms"", ETSI TS 102 176-1 V2.0.0, November 2007.

   [FIPS186-2]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-2 with Change
              Notice, January 2000.

   [NIST.800-57-Part1.2006]
              National Institute of Standards and Technology,
              "Recommendation for Key Management - Part 1: General
              (Revised)", NIST 800-57 Part1, May 2006.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC4810]  Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
              Archive Service Requirements", RFC 4810, March 2007.





















Kunz, et al.              Expires April 3, 2010                [Page 31]

Internet-Draft                    DSSC                    September 2009


Appendix A.  DSSC and ERS

A.1.  Verification of Evidence Records using DSSC (informative)

   This section describes the verification of an Evidence Record
   according to the Evidence Record Syntax (ERS, [RFC4998]), using the
   presented data structure.

   An Evidence Record contains a sequence of archiveTimeStampChains
   which consist of ArchiveTimeStamps.  For each archiveTimeStamp the
   hash algorithm used for the hash tree (digestAlgorithm) 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.

A.2.  Storing DSSC Policies in Evidence Records (normative)

   This section describes how to store a policy in an Evidence Record.
   ERS provides the field cryptoInfos for the storage of additional
   verification data.  For the integration of a security suitability
   policy in an Evidence Record the following content types are defined
   for both ASN.1 and XML representation:


   DSSC_ASN1 {iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5)
           ltans(11) id-ct(1) id-ct-dssc-asn1(2) }


   DSSC_XML {iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5)
           ltans(11) id-ct(1) id-ct-dssc-xml(3) }



Kunz, et al.              Expires April 3, 2010                [Page 32]

Internet-Draft                    DSSC                    September 2009


Appendix B.  XML schema (normative)



  <?xml version="1.0" encoding="UTF-8"?>
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns:dssc="urn:ietf:params:xml:ns:dssc"
             xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
             targetNamespace="urn:ietf:params:xml:ns:dssc"
             elementFormDefault="qualified"
             attributeFormDefault="unqualified">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
               schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
               schemaLocation="xmldsig-core-schema.xsd"/>
    <xs:element name="SecuritySuitabilityPolicy"
                type="dssc:SecuritySuitabilityPolicyType"/>
    <xs:complexType name="SecuritySuitabilityPolicyType">
      <xs:sequence>
        <xs:element ref="dssc:PolicyName"/>
        <xs:element ref="dssc:Publisher"/>
        <xs:element name="PolicyIssueDate" type="xs:dateTime"/>
        <xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
        <xs:element name="Usage" type="xs:string" minOccurs="0"/>
        <xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
        <xs:element ref="ds:Signature" minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="version" type="xs:string" default="1"/>
      <xs:attribute name="lang" default="en"/>
      <xs:attribute name="id" type="xs:ID"/>
    </xs:complexType>
    <xs:element name="PolicyName" type="dssc:PolicyNameType"/>
    <xs:complexType name="PolicyNameType">
      <xs:sequence>
        <xs:element ref="dssc:Name"/>
        <xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
        <xs:element ref="dssc:URI" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Publisher" type="dssc:PublisherType"/>
    <xs:complexType name="PublisherType">
      <xs:sequence>
        <xs:element ref="dssc:Name"/>
        <xs:element name="Address" type="xs:string" minOccurs="0"/>
        <xs:element ref="dssc:URI" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Name" type="xs:string"/>



Kunz, et al.              Expires April 3, 2010                [Page 33]

Internet-Draft                    DSSC                    September 2009


    <xs:element name="ObjectIdentifier">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:pattern value="(\d+\.)+\d+"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
    <xs:element name="URI" type="xs:anyURI"/>
    <xs:element name="Algorithm" type="dssc:AlgorithmType"/>
    <xs:complexType name="AlgorithmType">
      <xs:sequence>
        <xs:element ref="dssc:AlgorithmIdentifier"/>
        <xs:element ref="dssc:Evaluation" maxOccurs="unbounded"/>
        <xs:element ref="dssc:Information" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="AlgorithmIdentifier"
                type="dssc:AlgorithmIdentifierType"/>
    <xs:complexType name="AlgorithmIdentifierType">
      <xs:sequence>
        <xs:element ref="dssc:Name"/>
        <xs:element ref="dssc:ObjectIdentifier" maxOccurs="unbounded"/>
        <xs:element ref="dssc:URI" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Validity" type="dssc:ValidityType"/>
    <xs:complexType name="ValidityType">
      <xs:sequence>
        <xs:element name="Start" type="xs:date" minOccurs="0"/>
        <xs:element name="End" type="xs:date" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Information" type="dssc:InformationType"/>
    <xs:complexType name="InformationType">
      <xs:sequence>
        <xs:element name="Text" type="xs:string" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
    <xs:element name="Evaluation" type="dssc:EvaluationType"/>
    <xs:complexType name="EvaluationType">
      <xs:sequence>
        <xs:element ref="dssc:Parameter" minOccurs="0"
                                         maxOccurs="unbounded"/>
        <xs:element ref="dssc:Validity"/>
        <xs:any namespace="##other" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>



Kunz, et al.              Expires April 3, 2010                [Page 34]

Internet-Draft                    DSSC                    September 2009


    <xs:element name="Parameter" type="dssc:ParameterType"/>
    <xs:complexType name="ParameterType">
      <xs:sequence>
        <xs:element name="Min" type="xs:int" minOccurs="0"/>
        <xs:element name="Max" type="xs:int" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="name" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:schema>









































Kunz, et al.              Expires April 3, 2010                [Page 35]

Internet-Draft                    DSSC                    September 2009


Appendix C.  ASN.1 Module in 1988 Syntax (informative)

   ASN.1-Module


   DSSC {iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5)
            ltans(11) id-mod(0) id-mod-dssc88(6) id-mod-dssc88-v1(1) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORT ALL --

   IMPORTS

   -- Import from RFC 5280 [RFC5280]
   -- Delete following import statement
   -- if "new" types are supported

   UTF8String FROM PKIX1Explicit88
               { iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7)
               mod(0) pkix1-explicit(18) }


   -- Import from RFC 3852 [RFC3852]

   ContentInfo FROM CryptographicMessageSyntax2004
               { iso(1) member-body(2) us(840)
               rsadsi(113549) pkcs(1) pkcs-9(9)
               smime(16) modules(0) cms-2004(24)}

   ;

   SecuritySuitabilityPolicy ::= ContentInfo

   -- contentType is id-signedData as defined in [RFC3852]
   -- content is SignedData as defined in [RFC3852]
   -- eContentType within SignedData is id-ct-dssc
   -- eContent within SignedData is TBSPolicy

   id-ct-dssc  OBJECT IDENTIFIER ::= {
               iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5)
               ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }

   TBSPolicy ::= SEQUENCE {



Kunz, et al.              Expires April 3, 2010                [Page 36]

Internet-Draft                    DSSC                    September 2009


        version          INTEGER               DEFAULT   {v1(1)},
        language         UTF8String            DEFAULT   "en",
        policyName       PolicyName,
        publisher        Publisher,
        policyIssueDate  GeneralizedTime,
        nextUpdate       GeneralizedTime       OPTIONAL,
        usage            UTF8String            OPTIONAL,
        algorithms       SEQUENCE OF Algorithm
   }

   PolicyName ::= SEQUENCE {
        name  UTF8String,
        oid   OBJECT IDENTIFIER OPTIONAL,
        uri   IA5String         OPTIONAL
   }

   Publisher ::= SEQUENCE {
        name        UTF8String,
        address [0] UTF8String  OPTIONAL,
        uri     [1] IA5String   OPTIONAL
   }

   Algorithm ::= SEQUENCE {
        algorithmIdentifier     AlgID,
        evaluations             SEQUENCE OF Evaluation,
        information         [0] SEQUENCE OF UTF8String  OPTIONAL,
        other               [1] Extension               OPTIONAL
   }

   Extension ::= SEQUENCE {
        extensionType           OBJECT IDENTIFIER,
        extension               ANY DEFINED BY extensionType
   }

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

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

   Parameter ::= SEQUENCE {
        name       UTF8String,



Kunz, et al.              Expires April 3, 2010                [Page 37]

Internet-Draft                    DSSC                    September 2009


        min    [0] INTEGER     OPTIONAL,
        max    [1] INTEGER     OPTIONAL,
        other  [2] Extension   OPTIONAL
   }

   Validity ::= SEQUENCE {
        start  [0] GeneralizedTime OPTIONAL,
        end    [1] GeneralizedTime OPTIONAL
   }

   END








































Kunz, et al.              Expires April 3, 2010                [Page 38]

Internet-Draft                    DSSC                    September 2009


Appendix D.  ASN.1 Module in 1997 Syntax (normative)

   ASN.1-Module


   DSSC {iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5)
            ltans(11) id-mod(0) id-mod-dssc(7) id-mod-dssc-v1(1) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORT ALL --

   IMPORTS

   -- Import from RFC 5280 [RFC5280]
   -- Delete following import statement
   -- if "new" types are supported

   UTF8String FROM PKIX1Explicit88
               { iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7)
               mod(0) pkix1-explicit(18) }


   -- Import from RFC 3852 [RFC3852]

   ContentInfo FROM CryptographicMessageSyntax2004
               { iso(1) member-body(2) us(840)
               rsadsi(113549) pkcs(1) pkcs-9(9)
               smime(16) modules(0) cms-2004(24)}

   ;

   SecuritySuitabilityPolicy ::= ContentInfo

   -- contentType is id-signedData as defined in [RFC3852]
   -- content is SignedData as defined in [RFC3852]
   -- eContentType within SignedData is id-ct-dssc
   -- eContent within SignedData is TBSPolicy

   id-ct-dssc  OBJECT IDENTIFIER ::= {
               iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5)
               ltans(11) id-ct(1) id-ct-dssc-tbsPolicy(6) }

   TBSPolicy ::= SEQUENCE {



Kunz, et al.              Expires April 3, 2010                [Page 39]

Internet-Draft                    DSSC                    September 2009


        version          INTEGER               DEFAULT   {v1(1)},
        language         UTF8String            DEFAULT   "en",
        policyName       PolicyName,
        publisher        Publisher,
        policyIssueDate  GeneralizedTime,
        nextUpdate       GeneralizedTime       OPTIONAL,
        usage            UTF8String            OPTIONAL,
        algorithms       SEQUENCE OF Algorithm
   }

   PolicyName ::= SEQUENCE {
        name  UTF8String,
        oid   OBJECT IDENTIFIER OPTIONAL,
        uri   IA5String         OPTIONAL
   }

   Publisher ::= SEQUENCE {
        name         UTF8String,
        address  [0] UTF8String  OPTIONAL,
        uri      [1] IA5String   OPTIONAL
   }

   Algorithm ::= SEQUENCE {
        algorithmIdentifier     AlgID,
        evaluations             SEQUENCE OF Evaluation,
        information         [0] SEQUENCE OF UTF8String  OPTIONAL,
        other               [1] Extension               OPTIONAL
   }

   Extension ::= SEQUENCE {
        extensionType  EXTENSION-TYPE.&id ({SupportedExtensions}),
        extension      EXTENSION-TYPE.&Type
                            ({SupportedExtensions}{@extensionType})
   }

   EXTENSION-TYPE ::= TYPE-IDENTIFIER

   SupportedExtensions EXTENSION-TYPE ::= {...}

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

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



Kunz, et al.              Expires April 3, 2010                [Page 40]

Internet-Draft                    DSSC                    September 2009


        other                [2] Extension             OPTIONAL
   }

   Parameter ::= SEQUENCE {
        name       UTF8String,
        min    [0] INTEGER     OPTIONAL,
        max    [1] INTEGER     OPTIONAL,
        other  [2] Extension   OPTIONAL
   }

   Validity ::= SEQUENCE {
        start  [0] GeneralizedTime OPTIONAL,
        end    [1] GeneralizedTime OPTIONAL
   }

   END



































Kunz, et al.              Expires April 3, 2010                [Page 41]

Internet-Draft                    DSSC                    September 2009


Appendix E.  Example

   The following example shows a policy which may be used for signature
   verification.  It contains hash algorithms, public key algorithms,
   and signature schemes.  SHA-1 as well as RSA with modulus length of
   1024 are examples for expired algorithms.


   <SecuritySuitabilityPolicy xmlns="urn:ietf:params:xml:ns:dssc"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <PolicyName>
     <Name>Evaluation of cryptographic algorithms</Name>
    </PolicyName>
    <Publisher>
     <Name>Some Evaluation Authority</Name>
    </Publisher>
    <PolicyIssueDate>2009-01-01T00:00:00</PolicyIssueDate>
    <Usage>Digital signature verification</Usage>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>SHA-1</Name>
      <ObjectIdentifier>1.3.14.3.2.26</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Validity>
       <End>2008-06-30</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>SHA-256</Name>
      <ObjectIdentifier>2.16.840.1.101.3.4.2.1</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Validity>
       <End>2014-12-31</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>SHA-512</Name>
      <ObjectIdentifier>2.16.840.1.101.3.4.2.3</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Validity>
       <End>2014-12-31</End>



Kunz, et al.              Expires April 3, 2010                [Page 42]

Internet-Draft                    DSSC                    September 2009


      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>RSA</Name>
      <ObjectIdentifier>1.2.840.113549.1.1.1</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>1024</Min>
      </Parameter>
      <Validity>
       <End>2008-03-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>2048</Min>
      </Parameter>
      <Validity>
       <End>2014-12-31</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>DSA</Name>
      <ObjectIdentifier>1.2.840.10040.4.1</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="plength">
       <Min>1024</Min>
      </Parameter>
      <Parameter name="qlength">
       <Min>160</Min>
      </Parameter>
      <Validity>
       <End>2007-12-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="plength">
       <Min>2048</Min>
      </Parameter>
      <Parameter name="qlength">
       <Min>224</Min>
      </Parameter>



Kunz, et al.              Expires April 3, 2010                [Page 43]

Internet-Draft                    DSSC                    September 2009


      <Validity>
       <End>2014-12-31</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>PKCS#1 v1.5 SHA-1 with RSA</Name>
      <ObjectIdentifier>1.2.840.113549.1.1.5</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>1024</Min>
      </Parameter>
      <Validity>
       <End>2008-03-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>2048</Min>
      </Parameter>
      <Validity>
       <End>2008-06-30</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>PKCS#1 v1.5 SHA-256 with RSA</Name>
      <ObjectIdentifier>1.2.840.113549.1.1.11</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>1024</Min>
      </Parameter>
      <Validity>
       <End>2008-03-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>2048</Min>
      </Parameter>
      <Validity>
       <End>2014-12-31</End>
      </Validity>
     </Evaluation>



Kunz, et al.              Expires April 3, 2010                [Page 44]

Internet-Draft                    DSSC                    September 2009


    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>PKCS#1 v1.5 SHA-512 with RSA</Name>
      <ObjectIdentifier>1.2.840.113549.1.1.13</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>1024</Min>
      </Parameter>
      <Validity>
       <End>2008-03-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="moduluslength">
       <Min>2048</Min>
      </Parameter>
      <Validity>
       <End>2014-12-31</End>
      </Validity>
     </Evaluation>
    </Algorithm>
    <Algorithm>
     <AlgorithmIdentifier>
      <Name>SHA-1 with DSA</Name>
      <ObjectIdentifier>1.2.840.10040.4.3</ObjectIdentifier>
     </AlgorithmIdentifier>
     <Evaluation>
      <Parameter name="plength">
       <Min>1024</Min>
      </Parameter>
      <Parameter name="qlength">
       <Min>160</Min>
      </Parameter>
      <Validity>
       <End>2007-12-31</End>
      </Validity>
     </Evaluation>
     <Evaluation>
      <Parameter name="plength">
       <Min>2048</Min>
      </Parameter>
      <Parameter name="qlength">
       <Min>224</Min>
      </Parameter>
      <Validity>
       <End>2008-06-30</End>



Kunz, et al.              Expires April 3, 2010                [Page 45]

Internet-Draft                    DSSC                    September 2009


      </Validity>
     </Evaluation>
    </Algorithm>
   </SecuritySuitabilityPolicy>















































Kunz, et al.              Expires April 3, 2010                [Page 46]

Internet-Draft                    DSSC                    September 2009


Appendix F.  Disclaimer

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.






































Kunz, et al.              Expires April 3, 2010                [Page 47]

Internet-Draft                    DSSC                    September 2009


Authors' Addresses

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

   Email: thomas.kunz@sit.fraunhofer.de


   Susanne Okunick
   pawisda systems GmbH
   Robert-Koch-Strasse 9
   Weiterstadt  D-64331
   Germany

   Email: susanne.okunick@pawisda.de


   Ulrich Pordesch
   Fraunhofer Gesellschaft
   Rheinstrasse 75
   Darmstadt  D-64295
   Germany

   Email: ulrich.pordesch@zv.fraunhofer.de
























Kunz, et al.              Expires April 3, 2010                [Page 48]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/