| Long-term Archive And Notary Services (LTANS) | T. Kunz |
| Internet-Draft | Fraunhofer Institute for Secure Information Technology |
| Intended status: Standards Track | S. Okunick |
| pawisda systems GmbH | |
| U. Pordesch | |
| Fraunhofer Gesellschaft | |
| 2009 |
Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
draft-ietf-ltans-dssc-10.txt
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.
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].
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
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."
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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].
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. This document does not attempt to catalog the security properties of cryptographic algorithms.
In the following some use cases for a security suitability policy are presented.
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.
It is assumed that a policy contains the evaluations of all currently known algorithms, including the expired ones.
An algorithm is suitable at a time of interest if it is contained in the current policy and the time of interest is within the validity period. Additionally, if the algorithm has any parameters, these parameters must meet the requirements defined in the security constraints.
If an algorithm appears in a policy for the first time, it may be assumed that the algorithm has already been suitable in the past. Generally, algorithms are used in practice prior to evaluation.
To avoid inconsistencies, multiple instances of the same algorithm are prohibited. The publisher must take care 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.
<?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"/>
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 Appendix C and Appendix Appendix D. The schema uses the following XML namespace [W3C.REC-xml-names-20060816]:
Within this document, the prefix "dssc" is used for this namespace. The schema starts with the following schema definition:
<xs:element name="SecuritySuitabilityPolicy"
type="dssc:SecuritySuitabilityPolicyType"/>
<xs:complexType name="SecuritySuitabilityPolicyType">
<xs:sequence>
<xs:element ref="dssc:PolicyName"/>
<xs:element ref="dssc:Publisher"/>
<xs:element name="PolicyIssueDate" type="xs:dateTime"/>
<xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Usage" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:Algorithm" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
The SecuritySuitabilityPolicy element is the root element of a policy. It has an optional id attribute which MUST be used as a reference when signing the policy (Section 3.13). The element is defined by the following schema:
<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" type="xs:string"/>
<xs:element name="URI" type="xs:anyURI"/>
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.
<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>
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.
The PolicyIssueDate element indicates the point of time when the policy was issued.
The optional NextUpdate element MAY be used to indicate when the next policy will be issued.
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.
<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>
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:
<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>
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 element is defined as follows:
<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>
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.
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:
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.
<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>
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:
<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>
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="Information" type="dssc:InformationType"/>
<xs:complexType name="InformationType">
<xs:sequence>
<xs:element name="Text" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
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:
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:
DSSC policies MUST be expressed either in XML or 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: [W3C.REC-xmlschema-1-20041028] defined in Appendix Appendix B.
XML encoded DSSC policies are identified with the MIME type "application/dssc+xml" and are instances of the XML schema
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 Appendix C (1988-ASN.1 syntax) and Appendix Appendix D (1997-ASN.1 syntax).
This section defines the parameter names for the currently known public key algorithms. The signature algorithms RSA [RFC3447] and DSA [FIPS186-2] are generally used in conjunction with a one-way hash algorithm. Examples of such combined algorithms are SHA-256 with RSA and SHA-1 with DSA. The following parameters refer to the appropriate combined algorithms as well. 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.
These parameter names are registered by IANA (see
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
To determine the security suitability of an algorithm, the following information is required:
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.
To determine the validity period of an algorithm, locate the Algorithm element in the policy that corresponds to the algorithm identifier provided as input. The Algorithm element is located by comparing the OID in the element to the OID included in the algorithm identifier provided as input.
If no matching Algorithm element is found, then the algorithm is unknown.
If the time of interest was provided as input, the validity of each Evaluation element MUST be checked in order to determine if the algorithm was suitable at the time of interest. For each Evaluation element,
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.
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,
If all Evaluation elements were rejected, the algorithm is not suitable according the policy.
Any entries not rejected will be provided as 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.
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:
This document defines the XML namespace "urn:ietf:params:xml:ns:dssc". This namespace has been registered in the IANA XML Registry.
This document defines an XML schema (see Appendix Appendix B). 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 following MIME types: "application/dssc+xml", "application/dssc+der". These MIME types have been registered by IANA under "MIME Media Types".
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". Future assignments to the sub-registry "Parameter Definitions" are to be made through IETF Standards Action.
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")
[TO BE REMOVED: The initial values for the "Parameter Definitions" sub-registry are:
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:
Optionally, a URI MAY be provided if possible.
Name OID / URI Reference
----------------------- --------------------------------- ----------
rsaEncryption 1.2.840.113549.1.1.1 [RFC3447]
md2 1.2.840.113549.2.2 [RFC3279]
md5 1.2.840.113549.2.5 [RFC3279]
http://www.w3.org/2001/04/xmldsig-more#md5 [RFC4051]
sha-1 1.3.14.3.2.26 [RFC3279]
http://www.w3.org/2000/09/xmldsig#sha1 [RFC3275]
sha-224 2.16.840.1.101.3.4.2.4 [RFC4055]
http://www.w3.org/2001/04/xmldsig-more#sha224 [RFC4051]
sha-256 2.16.840.1.101.3.4.2.1 [RFC4055]
sha-384 2.16.840.1.101.3.4.2.2 [RFC4055]
http://www.w3.org/2001/04/xmldsig-more#sha384 [RFC4051]
sha-512 2.16.840.1.101.3.4.2.3 [RFC4055]
md2WithRSAEncryption 1.2.840.113549.1.1.2 [RFC3443]
md5WithRSAEncryption 1.2.840.113549.1.1.4 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-md5 [RFC4051]
sha1WithRSAEncryption 1.2.840.113549.1.1.5 [RFC3443]
http://www.w3.org/2000/09/xmldsig#rsa-sha1 [RFC3275]
sha256WithRSAEncryption 1.2.840.113549.1.1.11 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [RFC4051]
sha384WithRSAEncryption 1.2.840.113549.1.1.12 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 [RFC4051]
sha512WithRSAEncryption 1.2.840.113549.1.1.13 [RFC3443]
http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 [RFC4051]
sha1WithDSA 1.2.840.10040.4.3 [RFC3279]
http://www.w3.org/2000/09/xmldsig#dsa-sha1 [RFC3275]
[TO BE REMOVED: The initial values for the "Cryptographic Algorithms" sub-registry are:
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
If the check of one of these items fails, this will lead to a failure of the verification.
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) }
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:
<?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="id" type="xs:ID"/>
</xs:complexType>
<xs:element name="PolicyName" type="dssc:PolicyNameType"/>
<xs:complexType name="PolicyNameType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element ref="dssc:ObjectIdentifier" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Publisher" type="dssc:PublisherType"/>
<xs:complexType name="PublisherType">
<xs:sequence>
<xs:element ref="dssc:Name"/>
<xs:element name="Address" type="xs:string" minOccurs="0"/>
<xs:element ref="dssc:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Name" type="xs:string"/>
<xs:element name="ObjectIdentifier" type="xs:string"/>
<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" 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="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" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<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>
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 {
version INTEGER { v1(1) } OPTIONAL,
policyName PolicyName,
publisher Publisher,
policyIssueDate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
usage UTF8String OPTIONAL,
algorithms SEQUENCE OF Algorithm
}
PolicyName ::= SEQUENCE {
name UTF8String,
oid OBJECT IDENTIFIER OPTIONAL,
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] Information OPTIONAL,
other [1] Extension OPTIONAL
}
Information ::= SEQUENCE {
language [0] UTF8String OPTIONAL,
text [1] SEQUENCE OF UTF8String
}
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,
min [0] INTEGER OPTIONAL,
max [1] INTEGER OPTIONAL,
other [2] Extension OPTIONAL
}
Validity ::= SEQUENCE {
start [0] GeneralizedTime OPTIONAL,
end [1] GeneralizedTime OPTIONAL
}
END
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 {
version INTEGER { v1(1) } OPTIONAL,
policyName PolicyName,
publisher Publisher,
policyIssueDate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
usage UTF8String OPTIONAL,
algorithms SEQUENCE OF Algorithm
}
PolicyName ::= SEQUENCE {
name UTF8String,
oid OBJECT IDENTIFIER OPTIONAL,
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] Information 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 ::= {...}
Information ::= SEQUENCE {
language [0] UTF8String OPTIONAL,
text [1] SEQUENCE OF UTF8String
}
AlgID ::= SEQUENCE {
name UTF8String,
oid [0] SEQUENCE OF OBJECT IDENTIFIER,
uri [1] SEQUENCE OF IA5String OPTIONAL
}
Evaluation ::= SEQUENCE {
parameters [0] SEQUENCE OF Parameter OPTIONAL,
validity [1] Validity,
other [2] Extension OPTIONAL
}
Parameter ::= SEQUENCE {
name UTF8String,
min [0] INTEGER OPTIONAL,
max [1] INTEGER OPTIONAL,
other [2] Extension OPTIONAL
}
Validity ::= SEQUENCE {
start [0] GeneralizedTime OPTIONAL,
end [1] GeneralizedTime OPTIONAL
}
END
ASN.1-Module
<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>Qualified electronic signatures</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>RIPEMD-160</Name>
<ObjectIdentifier>1.3.36.3.2.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2010-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-224</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.4</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-256</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-384</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.2</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-512</Name>
<ObjectIdentifier>2.16.840.1.101.3.4.2.3</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>RSA</Name>
<ObjectIdentifier>1.2.840.113549.1.1.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>768</Min>
</Parameter>
<Validity>
<End>2000-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>1024</Min>
</Parameter>
<Validity>
<End>2008-03-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>1280</Min>
</Parameter>
<Validity>
<End>2008-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>1536</Min>
</Parameter>
<Validity>
<End>2009-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>1728</Min>
</Parameter>
<Validity>
<End>2010-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>1976</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
<Algorithm>
<AlgorithmIdentifier>
<Name>DSA</Name>
<ObjectIdentifier>1.2.840.10040.4.1</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="plength">
<Min>1024</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2007-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>1280</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2008-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>1536</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2009-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>2048</Min>
</Parameter>
<Parameter name="qlength">
<Min>160</Min>
</Parameter>
<Validity>
<End>2009-12-31</End>
</Validity>
</Evaluation>
<Evaluation>
<Parameter name="plength">
<Min>2048</Min>
</Parameter>
<Parameter name="qlength">
<Min>224</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
</SecuritySuitabilityPolicy>
In the following an example of a policy is presented. The policy consists on hash algorithms as well as public key algorithms. SHA-1 and RSA with modulus lengths of 768 and 1024 are examples for expired algorithms.
<Algorithm>
<AlgorithmIdentifier>
<Name>SHA-256 with RSA 2048</Name>
<ObjectIdentifier>1.2.840.113549.1.1.11</ObjectIdentifier>
</AlgorithmIdentifier>
<Evaluation>
<Parameter name="moduluslength">
<Min>2048</Min>
</Parameter>
<Validity>
<End>2014-12-31</End>
</Validity>
</Evaluation>
</Algorithm>
Combined algorithms should also be part of the policy since some applications know the OIDs of combined algorithms instead of the general public key algorithm. The following excerpt describes a combined algorithm. The validity end date is given by the end dates of RSA and SHA-256. Combined algorithms could replace the public key algorithms in the policy example. They could also be listed together with public key algorithms.
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.