summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5698.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5698.txt')
-rw-r--r--doc/rfc/rfc5698.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc5698.txt b/doc/rfc/rfc5698.txt
new file mode 100644
index 0000000..235b027
--- /dev/null
+++ b/doc/rfc/rfc5698.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group T. Kunz
+Request for Comments: 5698 Fraunhofer SIT
+Category: Standards Track S. Okunick
+ pawisda systems GmbH
+ U. Pordesch
+ Fraunhofer Gesellschaft
+ November 2009
+
+
+ Data Structure for the Security Suitability
+ of Cryptographic Algorithms (DSSC)
+
+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, the present, or the future.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+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
+ (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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 1]
+
+RFC 5698 DSSC November 2009
+
+
+ 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. Standards Track [Page 2]
+
+RFC 5698 DSSC November 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Motivation .................................................4
+ 1.2. Terminology ................................................5
+ 1.2.1. Conventions Used in This Document ...................5
+ 1.3. Use Cases ..................................................5
+ 2. Requirements and Assumptions ....................................5
+ 2.1. Requirements ...............................................6
+ 2.2. Assumptions ................................................6
+ 3. Data Structures .................................................7
+ 3.1. SecuritySuitabilityPolicy ..................................7
+ 3.2. PolicyName .................................................8
+ 3.3. Publisher ..................................................9
+ 3.4. PolicyIssueDate ............................................9
+ 3.5. NextUpdate .................................................9
+ 3.6. Usage ......................................................9
+ 3.7. Algorithm ..................................................9
+ 3.8. AlgorithmIdentifier .......................................10
+ 3.9. Evaluation ................................................10
+ 3.10. Parameter ................................................11
+ 3.11. Validity .................................................12
+ 3.12. Information ..............................................12
+ 3.13. Signature ................................................12
+ 4. DSSC Policies ..................................................13
+ 5. Definition of Parameters .......................................13
+ 6. Processing .....................................................14
+ 6.1. Inputs ....................................................14
+ 6.2. Verify Policy .............................................14
+ 6.3. Algorithm Evaluation ......................................15
+ 6.4. Evaluation of Parameters ..................................15
+ 6.5. Output ....................................................16
+ 7. Security Considerations ........................................16
+ 8. IANA Considerations ............................................18
+ 9. References .....................................................23
+ 9.1. Normative References ......................................23
+ 9.2. Informative References ....................................24
+ Appendix A. DSSC and ERS .........................................27
+ A.1. Verification of Evidence Records Using DSSC
+ (Informative) .............................................27
+ A.2. Storing DSSC Policies in Evidence Records (Normative) .....27
+ Appendix B. XML Schema (Normative) ...............................28
+ Appendix C. ASN.1 Module in 1988 Syntax (Informative) ............30
+ Appendix D. ASN.1 Module in 1997 Syntax (Normative) ..............32
+ Appendix E. Example ..............................................34
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 3]
+
+RFC 5698 DSSC November 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, this period of
+ use is the validity period of the certificate. Cryptographic
+ algorithms that are used for encryption shall resist such attacks
+ during the period 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, timestamps,
+ certificates, and revocation lists) are affected, particularly 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. Standards Track [Page 4]
+
+RFC 5698 DSSC November 2009
+
+
+ These evaluations are published in documents intended to be read by
+ humans. Therefore, to enable automated processing, it is necessary
+ to define a data structure that expresses the content of the
+ evaluations. 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 for actually padding functions.
+
+ Operator: Instance that 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 that is evaluated against a policy
+ and determined to be valid, i.e., resistant against attacks, at a
+ particular point of time.
+
+1.2.1. 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. Standards Track [Page 5]
+
+RFC 5698 DSSC November 2009
+
+
+1.3. Use Cases
+
+ Some use cases for a security suitability policy are presented here.
+
+ Long-term archiving: The most important use case is long-term
+ archiving of signed data. Algorithms or their parameters become
+ insecure over long periods of time. Therefore, signatures of
+ archived data and timestamps have to be periodically renewed. A
+ policy provides information about suitable and threatened
+ algorithms. Additionally, the policy assists in verifying
+ archived as well as re-signed documents.
+
+ Services: Services may provide information about cryptographic
+ algorithms. On the basis of a policy, a service is able to
+ provide the date when an algorithm became insecure or presumably
+ will become insecure, as well as information regarding which
+ algorithms 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 Cryptographic Message
+ Syntax (CMS) [RFC5652] or XML signatures ([RFC3275],
+ [ETSI-TS101903]), not only the validity of the certificates but
+ also the validity of all involved algorithms may be checked.
+
+ 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.
+
+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.
+
+
+
+
+
+Kunz, et al. Standards Track [Page 6]
+
+RFC 5698 DSSC November 2009
+
+
+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 the national or European Union (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
+ 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 to prevent conflicts
+ within a policy.
+
+ Assertions made in the policy are suitable at least until the next
+ policy is published.
+
+
+
+
+Kunz, et al. Standards Track [Page 7]
+
+RFC 5698 DSSC November 2009
+
+
+ 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.
+
+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 [RFC5646]. 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. Standards Track [Page 8]
+
+RFC 5698 DSSC November 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. Standards Track [Page 9]
+
+RFC 5698 DSSC November 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. The optional Information element MAY be used
+ to provide additional information like references on algorithm
+ specifications. In order to give the option to extend the Algorithm
+ element, it additionally contains a wildcard. The Algorithm element
+ is defined by the following schema:
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 10]
+
+RFC 5698 DSSC November 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. For example,
+ 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 wildcard MAY be used to extend the
+ Evaluation element.
+
+
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 11]
+
+RFC 5698 DSSC November 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;
+ these parameter names 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 need constraints that cannot be expressed by the
+ elements above, an arbitrary XML structure MAY be inserted that meets
+ the new constraints. For this reason, the Parameter element contains
+ a wildcard. A parameter MUST contain at least one constraint. The
+ schema for the Parameter element is as follows:
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 12]
+
+RFC 5698 DSSC November 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 that 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. Standards Track [Page 13]
+
+RFC 5698 DSSC November 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
+
+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 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 Appendices C (1988-ASN.1
+ syntax) and D (1997-ASN.1 syntax).
+
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 14]
+
+RFC 5698 DSSC November 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 the Digital Signature Algorithm (DSA)
+ [FIPS186-2] SHOULD be "plength" and "qlength".
+
+ These parameter names have been 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.
+
+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 sections, a process is described
+
+ o to determine if an algorithm was suitable at a particular point of
+ time, and
+
+ o to determine until what time 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 the algorithm.
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 15]
+
+RFC 5698 DSSC November 2009
+
+
+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 either 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
+ 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 either 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 either 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 to the policy.
+
+ Any entries not rejected will be used for the evaluation of the
+ parameters, if any.
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 16]
+
+RFC 5698 DSSC November 2009
+
+
+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 corresponding
+ 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 corresponding
+ parameter provided as input. Discard the Evaluation element if
+ the parameter value does not meet the constraint.
+
+ o If the Parameter has another constraint, confirm that the value of
+ the corresponding 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 to 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".
+
+
+
+
+
+Kunz, et al. Standards Track [Page 17]
+
+RFC 5698 DSSC November 2009
+
+
+ If the algorithm is suitable relative to the time of interest, return
+ the Evaluation elements that were not discarded.
+
+7. Security Considerations
+
+ The policy for an algorithm's security suitability has a 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 Certificate Revocation
+ List (CRL) [RFC5280] or Online Certificate Status Protocol (OCSP)
+ [RFC2560]. The certificate used to sign the policy SHOULD be
+ revoked if the algorithms used in this certificate are no 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 regarding when the next policy
+ will be published.
+
+ 4. When signing a policy, algorithms that are suitable according to
+ this policy SHOULD be used.
+
+ 5. The processing rule described in Section 6 is about one
+ cryptographic algorithm independent of the use case. Depending
+ upon the use case, an algorithm that is no longer suitable at the
+ time of interest, does not necessarily mean that the data
+ structure where it is used is no longer secure. For example, a
+ signature has been made with an RSA signer's key of 1024 bits.
+ This signature is timestamped with a timestamp 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
+ longer suitable at the time of interest does not mean that the
+
+
+
+
+Kunz, et al. Standards Track [Page 18]
+
+RFC 5698 DSSC November 2009
+
+
+ whole data structure is no longer 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 timestamp token has been provided
+ by a trusted authority. This 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 that uses
+ 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 of signature schemes.
+
+ 8. Re-encrypting documents that were originally encrypted using an
+ algorithm that is no longer 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.
+
+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].
+
+
+
+
+Kunz, et al. Standards Track [Page 19]
+
+RFC 5698 DSSC November 2009
+
+
+ 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 considerations,
+ see Section 7 of this document.
+
+ Interoperability considerations: Same as specified for
+ "application/xml" in [RFC3023].
+
+ Published specification: This document.
+
+ Applications that 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:
+
+ Magic number(s): none
+
+ File extension(s): .xdssc
+
+ Macintosh file type code: "TEXT"
+
+ 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].
+
+
+
+Kunz, et al. Standards Track [Page 20]
+
+RFC 5698 DSSC November 2009
+
+
+ Type name: application
+
+ Subtype name: dssc+der
+
+ Required parameters: none
+
+ Optional parameters: none
+
+ Encoding considerations: binary
+
+ Security considerations: See Section 7 of this document.
+
+ Interoperability considerations: none
+
+ Published specification: This document.
+
+ Applications that 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:
+
+ Magic number(s): none
+
+ File extension(s): .dssc
+
+ Macintosh file type code: none
+
+ 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 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".
+
+
+
+
+
+Kunz, et al. Standards Track [Page 21]
+
+RFC 5698 DSSC November 2009
+
+
+ The initial values for the "Parameter Definitions" sub-registry are:
+
+ Value Description Reference
+ -------------- ------------------------------- ------------------
+ moduluslength Parameter for RSA RFC 5698
+ (integer value)
+ plength Parameter for DSA RFC 5698
+ (integer value, used together
+ with parameter "qlength")
+ qlength Parameter for DSA RFC 5698
+ (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 that defines the
+ algorithm and its identifiers.
+
+ Optionally, a URI MAY be provided if possible.
+
+ The initial values for the "Cryptographic Algorithms" sub-registry
+ are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 22]
+
+RFC 5698 DSSC November 2009
+
+
+ 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]
+ http://www.w3.org/2000/09/xmldsig#dsa-sha1 [RFC3275]
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 23]
+
+RFC 5698 DSSC November 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.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+ [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
+ Record Syntax (ERS)", RFC 4998, August 2007.
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 24]
+
+RFC 5698 DSSC November 2009
+
+
+ [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.
+
+ [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 5646, September 2009.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
+ RFC 5652, September 2009.
+
+ [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]
+ Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney,
+ "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.
+
+
+
+
+
+Kunz, et al. Standards Track [Page 25]
+
+RFC 5698 DSSC November 2009
+
+
+ [CCITT.x209.1988]
+ International Telephone and Telegraph Consultative
+ Committee, "Specification of Basic Encoding Rules for
+ Abstract Syntax Notation One (ASN.1)",
+ 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 Part 1, May 2006.
+
+ [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 3279, April 2002.
+
+ [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+ in Multi-Protocol Label Switching (MPLS) Networks", RFC
+ 3443, January 2003.
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
+ Identifiers (URIs)", RFC 4051, April 2005.
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 26]
+
+RFC 5698 DSSC November 2009
+
+
+ [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
+ Algorithms and Identifiers for RSA Cryptography for use in
+ the Internet X.509 Public Key Infrastructure Certificate
+ and Certificate Revocation List (CRL) Profile", RFC 4055,
+ June 2005.
+
+ [RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
+ Archive Service Requirements", RFC 4810, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 27]
+
+RFC 5698 DSSC November 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) as well as
+ 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 that were
+ suitable at the date of issue.
+
+ 2. The hashtree was built with a hash algorithm that was 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 ArchiveTimeStamp 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. Standards Track [Page 28]
+
+RFC 5698 DSSC November 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"/>
+ <xs:element name="ObjectIdentifier">
+ <xs:simpleType>
+
+
+
+Kunz, et al. Standards Track [Page 29]
+
+RFC 5698 DSSC November 2009
+
+
+ <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>
+ <xs:element name="Parameter" type="dssc:ParameterType"/>
+ <xs:complexType name="ParameterType">
+
+
+
+Kunz, et al. Standards Track [Page 30]
+
+RFC 5698 DSSC November 2009
+
+
+ <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>
+
+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 5652 [RFC5652]
+
+ 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 [RFC5652]
+ -- content is SignedData as defined in [RFC5652]
+ -- eContentType within SignedData is id-ct-dssc
+ -- eContent within SignedData is TBSPolicy
+
+
+
+Kunz, et al. Standards Track [Page 31]
+
+RFC 5698 DSSC November 2009
+
+
+ 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 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,
+
+
+
+Kunz, et al. Standards Track [Page 32]
+
+RFC 5698 DSSC November 2009
+
+
+ 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
+
+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 5652 [RFC5652]
+
+ ContentInfo FROM CryptographicMessageSyntax2004
+ { iso(1) member-body(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs-9(9)
+ smime(16) modules(0) cms-2004(24)}
+
+
+
+Kunz, et al. Standards Track [Page 33]
+
+RFC 5698 DSSC November 2009
+
+
+ ;
+
+ SecuritySuitabilityPolicy ::= ContentInfo
+
+ -- contentType is id-signedData as defined in [RFC5652]
+ -- content is SignedData as defined in [RFC5652]
+ -- 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 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})
+
+
+
+Kunz, et al. Standards Track [Page 34]
+
+RFC 5698 DSSC November 2009
+
+
+ }
+
+ 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,
+ 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
+
+Appendix E. Example
+
+ The following example shows a policy that 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>
+
+
+
+Kunz, et al. Standards Track [Page 35]
+
+RFC 5698 DSSC November 2009
+
+
+ <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>
+ </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>
+
+
+
+Kunz, et al. Standards Track [Page 36]
+
+RFC 5698 DSSC November 2009
+
+
+ <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>
+ <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>
+
+
+
+Kunz, et al. Standards Track [Page 37]
+
+RFC 5698 DSSC November 2009
+
+
+ </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>
+ </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>
+
+
+
+Kunz, et al. Standards Track [Page 38]
+
+RFC 5698 DSSC November 2009
+
+
+ </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>
+ </Validity>
+ </Evaluation>
+ </Algorithm>
+ </SecuritySuitabilityPolicy>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunz, et al. Standards Track [Page 39]
+
+RFC 5698 DSSC November 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. Standards Track [Page 40]
+