Long-term Archive And Notary T. Kunz
Services (LTANS) S. Okunick
Internet-Draft Fraunhofer Institute for Secure
Intended status: Standards Track Information Technology
Expires: December 24, 2007 U. Pordesch
Fraunhofer Gesellschaft
June 22, 2007
Data Structure for Security Suitabilities of Cryptographic Algorithms
(DSSC)
draft-ietf-ltans-dssc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kunz, et al. Expires December 24, 2007 [Page 1]
Internet-Draft DSSC June 2007
Abstract
In many application areas it must be possible to prove the existence
and integrity of digital signed data. This proof depends on the
security suitability of the used cryptographic algorithms. Because
algorithms can become weak over the years, it is necessary to
periodically evaluate these security suitabilities. When signing or
verifying data, these evaluations must be considered. This document
specifies a data structure for security suitabilities of
cryptographic algorithms which may be automatically interpreted.
Kunz, et al. Expires December 24, 2007 [Page 2]
Internet-Draft DSSC June 2007
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements and Assumptions . . . . . . . . . . . . . . . . . 7
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8
4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. SecuritySuitabilityPolicy . . . . . . . . . . . . . . . . 9
4.2. PolicyName . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Publisher . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. PolicyIssueDate . . . . . . . . . . . . . . . . . . . . . 11
4.6. NextUpdate . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. SuitableAlgorithm . . . . . . . . . . . . . . . . . . . . 11
4.8. AlgorithmIdentifier . . . . . . . . . . . . . . . . . . . 12
4.9. ParameterConstraints . . . . . . . . . . . . . . . . . . . 12
4.9.1. RSAConstraints . . . . . . . . . . . . . . . . . . . . 13
4.9.2. DSAConstraints . . . . . . . . . . . . . . . . . . . . 13
4.10. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.11. Information . . . . . . . . . . . . . . . . . . . . . . . 14
4.12. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Proceeding . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Verification of Evidence Records using DSSC . . . . . 21
Appendix B. XML schema . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Kunz, et al. Expires December 24, 2007 [Page 3]
Internet-Draft DSSC June 2007
1. Introduction
1.1. Motivation
Digital signatures are means to provide data integrity and
authentication. They are based on cryptographic algorithms, which
must have certain security properties. For example, hash algorithms
have to be resistant to collisions and in the case of public key
algorithms it must not be possible to compute the private key of a
given public key. If algorithms did not have the required
properties, signatures could be forged.
Only some algorithms satisfy the security requirements and are
suitable for usage in signatures. Besides, because of the increasing
performance of computers and progresses in cryptography, algorithms
or their parameters become insecure over the years. E.g. the hash
algorithm MD5 is impractical by now. A digital signature using such
"weak" algorithms may lose its probative value. Every kind of
digital signed data like signed documents, time stamps, certificates,
and revocation lists is affected, in particular in the case of long-
term archiving. Over long periods of time, it is realistic to assume
that the algorithms used in signatures become insecure.
For this reason, it is important to periodically reevaluate
algorithms regarding their security properties and to consider these
evaluations when creating, verifying or renewing signatures. Such
evaluations will give a prognosis how long an algorithm will be
presumably secure and help to detect, whether insecure algorithms are
used in a signature or whether signatures have been timely renewed.
The evaluation of security suitabilites of algorithms cannot be done
by the user itself. They are made by expert committees after long
scientific discussion and published by specific evaluation
institutions. In Germany the Federal Network Agency annually
publishes a current evaluation of cryptografic algorithms
[BNetzAg.2007]. Examples for European and international evaluations
are [NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005].
These publications evaluate algorithms in a textual form and are not
interpretable by computer programs. Therefore it is necessary to
define an automatically interpretable data structure holding the
algorithm evaluations. In this way evaluation institutions are able
use the standardized form for publication. Such policies can be
interpreted by e.g. signing and verification tools. In the
following, such evaluations are called security suitability policy.
This document specifies a data structure for security suitability
policies.
Kunz, et al. Expires December 24, 2007 [Page 4]
Internet-Draft DSSC June 2007
1.2. Use Cases
In the following we present some use cases for security suitability
policies.
Long-term archiving: The most important use case for security
suitability policies is long-term archiving of signed data.
Algorithms or their parameters will become insecure over very long
periods of time. Policies are used to determine whether
signatures have to be renewed. That means, the policies must
provide information, which algorithms are currently suitable and
which are not. Additionally the policies assist in verifying
archived documents since it has to be checked whether all
signatures were timely renewed by time stamping, i.e. before
algorithms became insecure.
Signing and verifying: When signing documents or certificates it has
to be assured that the algorithms which will be used for signing
are suitable. Accordingly when verifying e.g CMS ([RFC3852]) or
XML signatures ([RFC3275], [ETSI-TS101903]), not only the validity
of the certificates may be checked, but also the validity of the
used algorithms.
Services: Services may provide information about cryptographic
algorithms. E.g. such services can use these policies to provide
the date when an algorithm became insecure or probably will become
insecure or to provide all algorithms which are presently valid.
Such services could be used by verification tools or long-term
archiving systems so that they do not need to deal with the
algorithm security by themselves.
Long-term archive services supporting LTAP ([I-D.ietf-ltans-ltap])
for providing evidence records ([I-D.ietf-ltans-ers]) may use the
policies for signature renewal. Additionally the policies may be
integrated in the ERS as further validation data.
Reencryption: Security suitability policies can also be used to
decide if encrypted documents must be reencrypted because the
encryption algorithm is no longer secure.
Kunz, et al. Expires December 24, 2007 [Page 5]
Internet-Draft DSSC June 2007
2. Terminology
Algorithm: In the context of this document, a cryptographic
algorithm, i.e. a public key or hash algorithm. For public key
algorithms this is the algorithm with its corresponding
parameters.
Operator: Instance which uses and interprets a policy, e.g. a
signature component.
Policy: In this document, an abbreviation for security suitability
policy.
Publisher: Instance that analyzes and evaluates algorithms and
publishes them in the form of policies.
Security suitability policy: The evaluation of cryptographic
algorithms according to their security in a specific application
area, e.g. signing or verifying data. The evaluation is published
in an electronic format.
Suitable algorithm: An algorithm which is evaluated in a policy,
i.e. is rated to be valid.
Kunz, et al. Expires December 24, 2007 [Page 6]
Internet-Draft DSSC June 2007
3. Requirements and Assumptions
This section first describes general requirements for a data
structure containing the securitiy suitabilities of algorithms.
Afterwards model assumptions are specified concerning both the design
and the usage of the data structure.
An evaluation of the security suitability of algorithms results in a
policy. It contains a list of the evaluated algorithms. An
evaluated algorithm is described by its identifier, security
constraints and predicted validity period. By these constraints the
requirements for algorithm properties must be defined, e.g. a public
key algorithm is evaluated on the basis of its parameter.
3.1. Requirements
Automatic interpretation: The data structure of the policy must
allow an automatic interpretation in order to consider the
security suitabilities of algorithms when signing, verifying or
renewing signatures.
Flexibility: The data structure must be flexible enough to support
new algorithms. In a future policy publication an algorithm could
be included, that is currently unknown. It must be possible to
add new algorithms with the corresponding security constraints in
the data structure. Besides, the data structure must be
independent of the intended purpose, e.g. signing, verification,
signature renewal.
Considering different policies: Policies may be published by
different institutions, e.g. on national or EU level, whereas one
policy needs not to be in agreement with the other one.
Furthermore organizations may undertake own evaluations for
internal purposes. For this reason a policy must be attributable
to its publisher.
Integrity and authenticity: The integrity and authenticity of a
published security suitability policy should be assured. The
publisher must be able to sign the policy so that operators may
prove the identity and trustworthiness of a policy.
Considering old algorithm suitabilities: Policies may be
periodically published, e.g. annually. For some applications it
may be desirable to interpret older policies. To automatically
verify an old signature, the security suitability of the used
algorithms at the signing time must be determinable. Therefore
that policy is relevant which has been valid at signing time. The
date of publishing must be part of the policy.
Kunz, et al. Expires December 24, 2007 [Page 7]
Internet-Draft DSSC June 2007
3.2. Assumptions
Only the latest policy is significant to decide whether an algorithm
is currently suitable. Is an algorithm listed in the current
security suitability policy it is valid now, otherwise not.
To decide whether an algorithm was suitable at a date in the past,
you have to find a policy published between this date and today.
This method also contains the following case: If an algorithm has not
been existent at a date in the past and evaluated in a later policy
for the first time, it will be assumed that the algorithm has then
already been suitable. Generally an algorithm is used in practice
before it is evaluated.
An algorithm is suitable only if it meets all requirements made in
the relevant policy.
Algorithms listed in the policy are suitable at least until the next
policy is published.
An algorithm once removed from a policy, is invalid and must not
appear in a future policy. There must not be any gaps in the
validity periods.
Kunz, et al. Expires December 24, 2007 [Page 8]
Internet-Draft DSSC June 2007
4. Data Structures
This section describes the syntax of a security suitability policy.
The syntax is defined as an XML schema. The schema uses the
following namespace:
http://www.sit.fraunhofer.de/ssp
Within this document, the prefix "ssp" is used for this namespace.
The schema starts with the following schema definition:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ssp="http://www.sit.fraunhofer.de/ssp"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="http://www.sit.fraunhofer.de/ssp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
4.1. SecuritySuitabilityPolicy
The SecuritySuitabilityPolicy element is the root element of a
policy. It has an optional id attribute which must be used as a
reference when signing the policy (Section 4.12). The element is
defined by the following schema:
<xs:element name="SecuritySuitabilityPolicy"
type="ssp:SecuritySuitabilityPolicyType"/>
<xs:complexType name="SecuritySuitabilityPolicyType">
<xs:sequence>
<xs:element ref="ssp:PolicyName"/>
<xs:element ref="ssp:Publisher"/>
<xs:element name="PolicyIssueDate" type="xs:dateTime"/>
<xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
<xs:element ref="ssp:SecuritySuitability" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
Kunz, et al. Expires December 24, 2007 [Page 9]
Internet-Draft DSSC June 2007
4.2. PolicyName
The PolicyName element contains the name of the policy. It consists
of the actual name and an optional URI.
<xs:element name="PolicyName" type="ssp:PolicyNameType"/>
<xs:complexType name="PolicyNameType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element ref="ssp:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Name" type="xs:string"/>
<xs:element name="URI" type="xs:anyURI"/>
4.3. Publisher
The Publisher element contains information about the publisher of the
policy. It is composed of the name, an optional address, and an
optional URI.
<xs:element name="Publisher" type="ssp:PublisherType"/>
<xs:complexType name="PublisherType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element ref="ssp:Address" minOccurs="0"/>
<xs:element ref="ssp:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
4.4. Address
The Address element consists of the street, the locality, the
optional state or province, the postal code, and the country.
Kunz, et al. Expires December 24, 2007 [Page 10]
Internet-Draft DSSC June 2007
<xs:element name="Address" type="ssp:AddressType"/>
<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="Street" type="xs:string"/>
<xs:element name="Locality" type="xs:string"/>
<xs:element name="StateOrProvince" type="xs:string" minOccurs="0"/>
<xs:element name="PostalCode" type="xs:string"/>
<xs:element name="Country" type="xs:string"/>
</xs:sequence>
</xs:complexType>
4.5. PolicyIssueDate
The PolicyIssueDate element indicates the point of time when the
policy was issued.
4.6. NextUpdate
The optional NextUpdate element may be used to indicate when the next
policy will be issued.
4.7. SuitableAlgorithm
A security suitability policy must contain at least one
SuitableAlgorithm element. A SuitableAlgorithm element describes the
evaluation of one suitable cryptographic algorithm. An algorithm can
be identified by a name, object identifiers, and URIs. Additionally
specific parameter constraints, e.g. a required modulus length, can
be specified. The suitability of the algorithm is expressed by a
validity period. An algorithm is suitable according to the
respective policy if it complies with the security suitability
defined by the respective SuitableAlgorithm element. The
SuitableAlgorithm element is defined by the following schema:
Kunz, et al. Expires December 24, 2007 [Page 11]
Internet-Draft DSSC June 2007
<xs:element name="SuitableAlgorithm" type="ssp:SuitableAlgorithmType"/>
<xs:complexType name="SuitableAlgorithmType">
<xs:sequence>
<xs:element ref="ssp:AlgorithmIdentifier"/>
<xs:element name="ParameterConstraints" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
<xs:element ref="ssp:Validity"/>
<xs:element ref="ssp:Information" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
4.8. AlgorithmIdentifier
The AlgorithmIdentifier element is used to identify a cryptographic
algorithm. It consists of the algorithm name and optionally one or
more object identifers and URIs. The element is defined as follows:
<xs:element name="AlgorithmIdentifier"
type="ssp:AlgorithmIdentifierType"/>
<xs:complexType name="AlgorithmIdentifierType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element name="ObjectIdentifier" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ssp:URI" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
4.9. ParameterConstraints
By the ParameterConstraints element, constraints on algorithm
specific parameters can be expressed. E.g. the suitability of the
RSA algorithm depends on the "modulus" parameter (RSA with modulus =
1024 may have another suitability period as RSA with modulus = 2048).
Since the parameters depend on the actual algorithm, it is impossible
to specify one data structure covering all algorithms. Instead, an
"any" element is used in the schema to express that an arbitrary XML
structure can be inserted. The following two sections define XML
schemas for RSA and DSA parameters. Parameter constraints needed for
Kunz, et al. Expires December 24, 2007 [Page 12]
Internet-Draft DSSC June 2007
other algorithms may be specified in separate XML schemas. Note that
not all algorithm suitabilities depend on parameter constraints, e.g.
current hash algorithms like SHA-1 or RIPE-MD 160 do not have any
parameters.
4.9.1. RSAConstraints
The RSAConstraints element must be used as parameter constraint in
all RSA security suitabilities. It contains the bit length of the
RSA modulus [RFC2437]. The element is defined by the following
schema:
<xs:element name="RSAConstraints" type="ssp:RSAConstraintsType"/>
<xs:complexType name="RSAConstraintsType">
<xs:sequence>
<xs:element name="modulus">
<xs:complexType>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
4.9.2. DSAConstraints
The DSAConstraints element must be used as parameter constraint in
all DSA security suitabilities. It is composed of the bit lengths of
the two public DSA parameters "p" (prime modulus) and "q" (prime
divisor of p-1), both meeting the requirements defined in
[FIPS.186-1.1998]. The element is defined by the following schema:
<xs:element name="DSAConstraints" type="ssp:DSAConstraintsType"/>
<xs:complexType name="DSAConstraintsType">
<xs:sequence>
<xs:element name="p">
<xs:complexType>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="q">
<xs:complexType>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
Kunz, et al. Expires December 24, 2007 [Page 13]
Internet-Draft DSSC June 2007
</xs:complexType>
4.10. Validity
The Validity element is used to define the period of the (estimated)
suitability of the algorithm. It is composed of a start date and an
end date. The element is defined by the following schema:
<xs:element name="Validity" type="ssp:ValidityType"/>
<xs:complexType name="ValidityType">
<xs:sequence>
<xs:element name="Start" type="xs:date"/>
<xs:element name="End" type="xs:date"/>
</xs:sequence>
</xs:complexType>
4.11. Information
The Information element may be used to give additional textual
information about the algorithm or the evaluation, e.g. references on
algorithm specifications. The element is defined as follows:
<xs:element name="Information" type="ssp:InformationType"/>
<xs:complexType name="InformationType">
<xs:sequence>
<xs:element name="Text" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
4.12. Signature
The optional Signature element may be used to guarantee the integrity
and authenticity of the policy. It is an XML signature specified in
[RFC3275]. The signature must relate to the
SecuritySuitabilityPolicy element. If the Signature element is set,
Kunz, et al. Expires December 24, 2007 [Page 14]
Internet-Draft DSSC June 2007
the SecuritySuitabilityPolicy element must have the optional id
attribute. This attribute must be used to reference the
SecuritySuitabilityPolicy element within the Signature element.
Since it is an enveloped signature, the signature must use the
transformation algorithm identified by the following URI:
http://www.w3.org/2000/09/xmldsig#enveloped-signature
Kunz, et al. Expires December 24, 2007 [Page 15]
Internet-Draft DSSC June 2007
5. Proceeding
This section shows which information must be gathered in the
different use cases and how to proceed to get this information.
1. Is an algorithm currently valid?
Procedure: Take the current policy and check whether this
algorithm is listed in it. If it is, the algorithm is currently
suitable.
Input: algorithm
Response: true or false
2. Did an algorithm have been valid at a particular date in the
past?
Procedure: Find the latest policy published after this particular
date containing this algorithm. If such a policy exists, the
algorithm has been suitable at the specified date.
Input: algorithm and date
Response: true or false
3. Until which date in the future an algorithm is predicted to be
valid?
Procedure: Take the current policy and get the predicted validity
end date of this algorithm, if the algorithm exists in the
policy.
Input: algorithm
Response: date or error, if the algorithm does not exist
4. At which date became an algorithm invalid?
Procedure: First it has to be assured, that the given algorithm
has been valid at any time in the past. Find the last policy
containing this algorithm and generate the minimum of the
predicted validity end date and the publication date of the
following policy.
Input: algorithm
Response: date or error, if date has never been valid or is valid
now
5. Which algorithms are currently valid?
Procedure: All algorithms included in the current policy are
valid.
Response: list of algorithms
6. Which algorithms have been valid at a particular date in the
past?
Procedure: All algorithms in a policy published at this date have
been valid. Additionally any algorithm newly added in one
following policy has been valid.
Kunz, et al. Expires December 24, 2007 [Page 16]
Internet-Draft DSSC June 2007
Input: date
Response: list of algorithms
Kunz, et al. Expires December 24, 2007 [Page 17]
Internet-Draft DSSC June 2007
6. Security Considerations
The used policies for security suitabilities have great impact on the
quality of signatures and verification results. If evaluations of
algorithms are wrong, signatures with a low probative force could be
created and verification results could be incorrect. The following
security considerations have been identified:
1. An institution publishing a policy must take care via
organizational measures that unauthorized manipulation of
security suitabilities is impossible before a policy is signed
and published.
2. A client should only accept signed policies issued by a trusted
institution. It must not be possible to unnoticeably manipulate
or replace security suitabilities once accepted by the client.
3. A threat arises when a client downloads a policy too late
although the policy has already been published. In this case,
the client would work with obsolete security suitabilities. To
minimize this risk, the client should periodically check if new
policies are published. This check could be done automatically
by signature and verification components.
4. When signing a policy, only algorithms should be used which are
suitable according this policy.
Kunz, et al. Expires December 24, 2007 [Page 18]
Internet-Draft DSSC June 2007
7. References
7.1. Normative References
[ETSI-TS101903]
European Telecommunication Standards Institute (ETSI),
"XML Advanced Electronic Signatures (XAdES)", ETSI TS 101
903, Feb 2002.
[I-D.ietf-ltans-ltap]
Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)",
draft-ietf-ltans-ltap-04 (work in progress), March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
7.2. Informative References
[BNetzAg.2007]
Federal Network Agency for Electricity, Gas,
Telecommunications, Post and Railway, "Bekanntmachung zur
elektronischen Signatur nach dem Signaturgesetz und der
Signaturverordnung (Uebersicht ueber geeignete
Algorithmen)", April 2007,
<http://www.bundesnetzagentur.de/media/archive/9655.pdf>.
[ETSI-TS102176-1-2005]
European Telecommunication Standards Institute (ETSI),
Electronic Signatures and Infrastructures (ESI);,
"Algorithms and Parameters for Secure Electronic
Signatures; Part 1: Hash functions and asymmetric
algorithms", ETSI TS 102 176-1 V1.2.1, July 2005.
[FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>.
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-15 (work in progress), June 2007.
Kunz, et al. Expires December 24, 2007 [Page 19]
Internet-Draft DSSC June 2007
[NIST.800-57-Part1.2006]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST 800-57 Part1, May 2006.
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
Kunz, et al. Expires December 24, 2007 [Page 20]
Internet-Draft DSSC June 2007
Appendix A. Verification of Evidence Records using DSSC
This section describes the verification of an Evidence Record
according to the Evidence Record Syntax [I-D.ietf-ltans-ers] by using
the presented data structure. Because Evidence Records contain
hashtrees secured with time stamps and both the security of hashtrees
and time stamp signatures depend on the used algorithms this is a
suitable example to demonstrate a verification. Precondition of the
procedure is that at least one policy is present.
An Evidence Record contains a sequence of archiveTimeStampChains
which consist of ArchiveTimeStamps. For each archiveTimeStamp the
hash algorithm used for the hash tree (digestAlgorithm) and the
public key algorithm and hash algorithm in the time stamp signature
have to be examined. The definitive date is the time information in
the time stamp (date of issue). Starting with the first
ArchiveTimestamp it has to be assured that
1. The time stamp uses public key and hash algorithms which have
been suitable at the date of issue.
2. The hashtree was build with an hash algorithm that has been
suitable as well.
3. Algorithms for time stamp and hashtree in the preceding
ArchiveTimestamp must have been suitable at date of considered
ArchiveTimestamp.
4. Algorithms in the last ArchiveTimstamp have to be suitable now.
If the check of one of these item fails, this will lead to a failure
of the verification.
Kunz, et al. Expires December 24, 2007 [Page 21]
Internet-Draft DSSC June 2007
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ssp="http://www.sit.fraunhofer.de/ssp"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="http://www.sit.fraunhofer.de/ssp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
<xs:element name="SecuritySuitabilityPolicy"
type="ssp:SecuritySuitabilityPolicyType"/>
<xs:complexType name="SecuritySuitabilityPolicyType">
<xs:sequence>
<xs:element ref="ssp:PolicyName"/>
<xs:element ref="ssp:Publisher"/>
<xs:element name="PolicyIssueDate" type="xs:dateTime"/>
<xs:element name="NextUpdate" type="xs:dateTime" minOccurs="0"/>
<xs:element ref="ssp:SuitableAlgorithm" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
<xs:element name="PolicyName" type="ssp:PolicyNameType"/>
<xs:complexType name="PolicyNameType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element ref="ssp:URI" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Publisher" type="ssp:PublisherType"/>
<xs:complexType name="PublisherType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element ref="ssp:Address" minOccurs="0"/>
<xs:element ref="ssp:URI" minOccurs="0"/>
Kunz, et al. Expires December 24, 2007 [Page 22]
Internet-Draft DSSC June 2007
</xs:sequence>
</xs:complexType>
<xs:element name="Name" type="xs:string"/>
<xs:element name="URI" type="xs:anyURI"/>
<xs:element name="Address" type="ssp:AddressType"/>
<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="Street" type="xs:string"/>
<xs:element name="Locality" type="xs:string"/>
<xs:element name="StateOrProvince" type="xs:string" minOccurs="0"/>
<xs:element name="PostalCode" type="xs:string"/>
<xs:element name="Country" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="SuitableAlgorithm" type="ssp:SuitableAlgorithmType"/>
<xs:complexType name="SuitableAlgorithmType">
<xs:sequence>
<xs:element ref="ssp:AlgorithmIdentifier"/>
<xs:element name="ParameterConstraints" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
<xs:element ref="ssp:Validity"/>
<xs:element ref="ssp:Information" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="AlgorithmIdentifier"
type="ssp:AlgorithmIdentifierType"/>
<xs:complexType name="AlgorithmIdentifierType">
<xs:sequence>
<xs:element ref="ssp:Name"/>
<xs:element name="ObjectIdentifier" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ssp:URI" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Kunz, et al. Expires December 24, 2007 [Page 23]
Internet-Draft DSSC June 2007
<xs:element name="Validity" type="ssp:ValidityType"/>
<xs:complexType name="ValidityType">
<xs:sequence>
<xs:element name="Start" type="xs:date"/>
<xs:element name="End" type="xs:date"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Information" type="ssp:InformationType"/>
<xs:complexType name="InformationType">
<xs:sequence>
<xs:element name="Text" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="RSAConstraints" type="ssp:RSAConstraintsType"/>
<xs:complexType name="RSAConstraintsType">
<xs:sequence>
<xs:element name="modulus">
<xs:complexType>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="DSAConstraints" type="ssp:DSAConstraintsType"/>
<xs:complexType name="DSAConstraintsType">
<xs:sequence>
<xs:element name="p">
<xs:complexType>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="q">
<xs:complexType>
Kunz, et al. Expires December 24, 2007 [Page 24]
Internet-Draft DSSC June 2007
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
Kunz, et al. Expires December 24, 2007 [Page 25]
Internet-Draft DSSC June 2007
Authors' Addresses
Thomas Kunz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
Darmstadt D-64295
Germany
Email: thomas.kunz@sit.fraunhofer.de
Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
Darmstadt D-64295
Germany
Email: susanne.okunick@sit.fraunhofer.de
Ulrich Pordesch
Fraunhofer Gesellschaft
Rheinstrasse 75
Darmstadt D-64295
Germany
Email: ulrich.pordesch@zv.fraunhofer.de
Kunz, et al. Expires December 24, 2007 [Page 26]
Internet-Draft DSSC June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kunz, et al. Expires December 24, 2007 [Page 27]
