| TOC |
|
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 27, 2007.
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.
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
1.1.
Motivation
1.2.
Use Cases
2.
Terminology
3.
Requirements and Assumptions
3.1.
Requirements
3.2.
Assumptions
4.
Data Structures
4.1.
SecuritySuitabilityPolicy
4.2.
PolicyName
4.3.
Publisher
4.4.
Address
4.5.
PolicyIssueDate
4.6.
NextUpdate
4.7.
SuitableAlgorithm
4.8.
AlgorithmIdentifier
4.9.
ParameterConstraints
4.9.1.
RSAConstraints
4.9.2.
DSAConstraints
4.10.
Validity
4.11.
Information
4.12.
Signature
5.
Proceeding
6.
Security Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
Appendix A.
Verification of Evidence Records using DSSC
Appendix B.
XML schema
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
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] (Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway, “Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen),” April 2007.). Examples for European and international evaluations are [NIST.800‑57‑Part1.2006] (National Institute of Standards and Technology, “Recommendation for Key Management – Part 1: General (Revised),” May 2006.) and [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,” July 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.
| TOC |
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] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.)) or XML signatures ([RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.), [ETSI‑TS101903] (European Telecommunication Standards Institute (ETSI), “XML Advanced Electronic Signatures (XAdES),” Feb 2002.)), 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] (Jerman-Blazic, A., “Long-term Archive Protocol (LTAP),” March 2007.)) for providing evidence records ([I‑D.ietf‑ltans‑ers] (Brandner, R., “Evidence Record Syntax (ERS),” June 2007.)) 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.
| TOC |
- 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.
| TOC |
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.
| TOC |
- 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.
| TOC |
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.
| TOC |
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"/>
| TOC |
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 (Signature)). 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>
| TOC |
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"/>
| TOC |
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>
| TOC |
The Address element consists of the street, the locality, the optional state or province, the postal code, and the country.
<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>
| TOC |
The PolicyIssueDate element indicates the point of time when the policy was issued.
| TOC |
The optional NextUpdate element may be used to indicate when the next policy will be issued.
| TOC |
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:
<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>
| TOC |
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>
| TOC |
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 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.
| TOC |
The RSAConstraints element must be used as parameter constraint in all RSA security suitabilities. It contains the bit length of the RSA modulus [RFC2437] (Kaliski, B. and J. Staddon, “PKCS #1: RSA Cryptography Specifications Version 2.0,” October 1998.). 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>
| TOC |
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] (National Institute of Standards and Technology, “Digital Signature Standard,” December 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>
</xs:complexType>
| TOC |
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>
| TOC |
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>
| TOC |
The optional Signature element may be used to guarantee the integrity and authenticity of the policy. It is an XML signature specified in [RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.). 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
| TOC |
This section shows which information must be gathered in the different use cases and how to proceed to get this information.
| TOC |
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:
| TOC |
| TOC |
| [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 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3275] | Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” RFC 3275, March 2002 (TXT). |
| [RFC3852] | Housley, R., “Cryptographic Message Syntax (CMS),” RFC 3852, July 2004 (TXT). |
| TOC |
| [BNetzAg.2007] | Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway, “Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen),” April 2007. |
| [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. |
| [I-D.ietf-ltans-ers] | Brandner, R., “Evidence Record Syntax (ERS),” draft-ietf-ltans-ers-15 (work in progress), June 2007 (TXT). |
| [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 (TXT, HTML, XML). |
| TOC |
This section describes the verification of an Evidence Record according to the Evidence Record Syntax [I‑D.ietf‑ltans‑ers] (Brandner, R., “Evidence Record Syntax (ERS),” June 2007.) 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
If the check of one of these item fails, this will lead to a failure of the verification.
| TOC |
<?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"/>
</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>
<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>
<xs:attribute name="length" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
| TOC |
| 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 |
| TOC |
Copyright © 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.
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.