Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
Extracted elements (30)
Algorithm evaluations are pooled in a security suitability policy expressed as a machine-readable data structure to enable automated processing, since expert committee evaluations are traditionally published as human-readable documents (e.g., Germany's Federal Network Agency annual publications). This allows signature generation and verification tools to interpret them programmatically.
Multiple Evaluation elements are allowed within a single Algorithm element to handle parameter-dependent suitability periods. For example, RSA with a 1024-bit modulus may have a different (shorter) validity period than RSA with a 2048-bit modulus, requiring separate evaluation entries for each range.
Parameter constraints use Min/Max integer ranges rather than exact values to allow flexible expression of security floors. An exact value is expressed by setting Min equal to Max; a wildcard extension point is included for future algorithms whose constraints cannot be expressed as integer ranges.
To store a DSSC policy in an ERS Evidence Record (RFC 4998), two content type OIDs are defined: DSSC_ASN1 (id-ct-dssc-asn1(2)) and DSSC_XML (id-ct-dssc-xml(3)) under the ltans arc, for use in the ERS cryptoInfos field.
An ASN.1 DER-encoded DSSC policy file MUST contain only the DER encoding of one DSSC policy with no extraneous header or trailer information. ASN.1-based policies are identified with MIME type 'application/dssc+der'.
DSSC policies MUST be expressed in either XML or ASN.1. To achieve interoperability, policies SHOULD be published in both formats. XML policies MUST be well-formed and SHOULD be valid against the schema.
During policy verification, the policy signature SHOULD be verified and a certification path to a current trust anchor SHOULD be constructed and validated. The algorithms used for this verification MUST themselves be suitable per the policy being verified; if not, the policy MUST be rejected.
OIDs in the PolicyName and AlgorithmIdentifier elements MUST be expressed in dot notation (e.g., '1.3.14.3.2.26').
Parameter constraints of non-rejected Evaluation elements MUST be evaluated: confirm the parameter was provided as input, check Min/Max bounds, and discard an Evaluation element if any constraint is not met or is unrecognized. If all Evaluation elements are rejected, the algorithm is not suitable.
The enveloped XML signature on a policy MUST use the transformation algorithm identified by 'http://www.w3.org/2000/09/xmldsig#enveloped-signature', and MUST reference the SecuritySuitabilityPolicy element via its 'id' attribute.
The NextUpdate time in the policy MUST be either greater than the current time or absent. If NextUpdate is less than the current time, the policy MUST be rejected as expired.
The RSA parameter SHOULD be named 'moduluslength'; DSA parameters SHOULD be named 'plength' and 'qlength'. Publishers SHOULD use these registered names to ensure correct interoperability.
XML-encoded DSSC policies MUST be based on XML 1.0 and MUST be encoded using UTF-8. They use the namespace URI 'urn:ietf:params:xml:ns:dssc' and are identified with MIME type 'application/dssc+xml'.
The Algorithm element identifies a cryptographic algorithm via an AlgorithmIdentifier and contains one or more Evaluation elements describing suitability periods. A policy MUST contain at least one Algorithm element.
The AlgorithmIdentifier element identifies a cryptographic algorithm by human-readable name, one or more OIDs in dot notation (e.g., '1.3.14.3.2.26'), and optional URIs. The OID is the machine-processable identifier; the name is for human readers only.
The Evaluation element expresses the suitability of an algorithm for a specific set of parameter constraints, defined by optional Parameter elements and a mandatory Validity period. Multiple Evaluation elements within one Algorithm allow different suitability windows for different parameter ranges (e.g., RSA-1024 vs RSA-2048).
The optional Signature element provides integrity and authenticity for the policy using an enveloped XML digital signature (RFC 3275). When present, the SecuritySuitabilityPolicy element MUST have an 'id' attribute used as the signature reference.
The Parameter element constrains algorithm-specific parameters using Min and/or Max integer elements, plus an optional wildcard for future constraints. At least one constraint (Min, Max, or other) MUST be present; an exact value is expressed by setting Min equal to Max.
The SecuritySuitabilityPolicy element is the root XML element of a DSSC policy. It contains PolicyName, Publisher, PolicyIssueDate, optional NextUpdate, optional Usage, one or more Algorithm elements, and an optional Signature element. It carries optional 'id', 'lang', and 'version' attributes.
The Validity element defines the predicted suitability period of an algorithm with optional Start and End xs:date fields. Omitting End means open-ended validity; an End in the past means the algorithm was suitable only until that date.
The IANA XML Registry receives two registrations: the XML namespace 'urn:ietf:params:xml:ns:dssc' and the XML schema identified by URN 'urn:ietf:params:xml:schema:dssc', both per RFC 3688 guidelines.
This document creates the IANA registry 'Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)' with two sub-registries: 'Parameter Definitions' (policy: RFC Required) and 'Cryptographic Algorithms' (policy: First Come First Served). Initial parameter entries are 'moduluslength' (RSA), 'plength' (DSA), and 'qlength' (DSA).
Two new MIME types are registered: 'application/dssc+xml' (file extension .xdssc) for XML-encoded DSSC policies, and 'application/dssc+der' (file extension .dssc) for ASN.1 DER-encoded policies, per RFC 4288 procedures.
A suitable basic algorithm (e.g., RSA) does not guarantee that all cryptographic schemes based on it are also secure. Complete signature verification requires checking all involved algorithms (signature schemes, public key algorithms of certificates, revocation information, etc.) against the policy.
An algorithm that is no longer suitable at a time of interest does not necessarily mean the entire data structure is insecure. For example, a 1024-bit RSA signature timestamped with a 2048-bit RSA key before 1024-bit RSA was broken may still be valid if 2048-bit RSA remains suitable.
Operators SHOULD only accept policies from trusted publishers and SHOULD verify the signing certificate's validity via CRL or OCSP. It MUST NOT be possible to alter or replace a policy once accepted by an operator.
Publishers MUST ensure policies cannot be tampered with before signing and publication. There is no revocation mechanism for published policies, so the lifespan of a policy must be carefully considered prior to publication.
Re-encrypting documents originally encrypted with a no-longer-suitable algorithm does not protect against already-intercepted copies. For stored encrypted documents, re-encryption should be considered unless the document has lost its original value.
The ASN.1 Parameter SEQUENCE contains: name (UTF8String), optional min [0] (INTEGER), optional max [1] (INTEGER), and optional other [2] (Extension). The Parameter name attribute is required and carries the algorithm-specific parameter name.
The ASN.1 TBSPolicy SEQUENCE contains: version (INTEGER, default v1), language (UTF8String, default 'en'), policyName (PolicyName), publisher (Publisher), policyIssueDate (GeneralizedTime), optional nextUpdate (GeneralizedTime), optional usage (UTF8String), and algorithms (SEQUENCE OF Algorithm). The outer SecuritySuitabilityPolicy wraps TBSPolicy in a CMS SignedData ContentInfo.