RFC 5698
Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
RFC 5698: Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) 🦋
okay bestie, this one is a Standards Track spec from the Network Working Group 💅 published in November 2009. The authors are T. Kunz (Fraunhofer SIT), S. Okunick (pawisda systems GmbH), and U. Pordesch (Fraunhofer Gesellschaft). There's no Obsoletes or Updates line in the header, so it doesn't replace or update any earlier RFC 🌸
Abstract ✨
okay so crypto algorithms can get weak over the years 💀 which means we have to keep checking how secure they still are. when you're signing or verifying data, or encrypting or decrypting it, these evaluations must be considered 🔐 this doc defines a data structure that lets a machine automatically analyze how security suitable a given crypto algorithm is at a given point in time. that time can be in the past, the present, or the future ⏳ it's giving time travel, no cap 🧚
Status of This Memo 🌈
this document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 if you want to know where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 distribution of this memo is unlimited, so share it with whoever 🫶
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) as they were in effect on the date this document was published. please read these carefully, because they explain your rights and restrictions for this document 📜 any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the BSD License 🎀
this document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🙈 the people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. without an adequate license from those copyright holders, 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. the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
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 ..............................................341. Introduction ✨
1.1. Motivation 🔍
digital signatures can give you data integrity and authentication 🫶 they're built on cryptographic algorithms that are required to have certain security properties. for example, hash algorithms have to be resistant to collisions, and for public key algorithms, working out the private key from a given public key has to be infeasible 🧠 if an algorithm lacks those properties, signatures could be forged, unless they're protected by a strong cryptographic algorithm 😭
algorithms used in signatures shall be selected so they resist such attacks during their period of use. for signature keys in public key certificates, that period of use is the certificate's validity period 📅 algorithms used for encryption shall resist such attacks for as long as the information is planned to stay confidential 🔒
only a very small number of algorithms meet the security requirements, and it gets worse 💀 as computers get faster and cryptography makes progress, algorithms or their parameters become insecure over the years. take MD5, the hash algorithm, which is unsuitable today for many purposes 🙃 a digital signature made with a "weak" algorithm has no probative value, unless that "weak" algorithm was protected by a strong algorithm before it was considered weak 🥲 lots of signed data is affected (signed documents, timestamps, certificates, and revocation lists), especially for long-term archiving. over long periods of time, the algorithms used in signatures are assumed to become insecure 😵💫
so it's important to evaluate an algorithm's fitness periodically 📆 and to take those results into account when creating and verifying signatures, or when keeping signatures made in the past valid 🛡️ one result of an evaluation is a projected validity period for the algorithm, which is a prediction of how long the algorithm is fit for use ⏰ that prediction can help you spot whether a weak algorithm was used in a signature, and whether that signature was properly protected in time by another signature made with an algorithm that's still suitable right now 🦸♀️ algorithm evaluations are done by expert committees. in Germany, the Federal Network Agency publishes evaluations of cryptographic algorithms every year [BNetzAg.2008]. other European and international examples are [ETSI-TS102176-1-2005] and [NIST.800-57-Part1.2006] 🇪🇺
these evaluations are published in documents meant for humans to read 📄 so to enable automated processing, we need a data structure that expresses what the evaluations say 🤖 this standardized structure can be used for publication and can be interpreted by signature generation and verification tools 🛠️ algorithm evaluations are pooled into a security suitability policy, and this document specifies the data structure for that policy 💜 so the document is basically a framework for expressing evaluations of cryptographic algorithms ✨ it does not try to catalog the security properties of cryptographic algorithms 📚 and it doesn't make any guidelines about which kinds of algorithms should 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 📖
here are the key terms, bestie 💅
- Algorithm: a cryptographic algorithm, meaning a public key or hash algorithm. for public key algorithms, this is the algorithm together with its parameters, if it has any. the term "algorithm" is also used for cryptographic schemes and for padding functions 🧩
- Operator: the instance that uses and interprets a policy, for example a signature-verification component 🕵️♀️
- Policy: short for security suitability policy 🫧
- Publisher: the 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, such as 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, meaning resistant against attacks, at a particular point in 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]. no vibes-based interpretation, it's all in RFC 2119 💅✨
1.3. Use Cases ✨
okay so let's look at where a security suitability policy actually gets used 💅 there are a few big ones, bestie
Long-term archiving: this is the most important use case 🗄️💖 algorithms or their parameters become insecure over long periods of time, so the signatures on archived data and the timestamps have to be renewed regularly 😭 a policy tells you which algorithms are suitable and which are threatened, and it also helps you verify archived documents as well as re-signed ones. main character energy ✨
Services: services can provide info about cryptographic algorithms 🔮 with a policy, a service can tell you the date an algorithm became insecure (or presumably will become insecure), plus which algorithms are valid right now. verification tools and long-term archiving systems can ask these services, so they don't have to deal with algorithm security by themselves 🙌
Long-term Archive Services (LTA) as defined in [RFC4810] may use the policy for signature renewal 🧚
Signing and verifying: when you sign documents or certificates, it's a must that the algorithms used for signing or verifying are suitable 🔐 so when you verify Cryptographic Message Syntax (CMS) [RFC5652] or XML signatures ([RFC3275], [ETSI-TS101903]), you can check not only the validity of the certificates but also the validity of all involved algorithms 🦋
Re-encryption: a security suitability policy can also help decide if encrypted documents need to be re-encrypted, because the encryption algorithm is no longer secure 🔁
2. Requirements and Assumptions 🎀
Section 2.1 covers the general requirements for a data structure that holds the security suitability of algorithms 📋 then Section 2.2 lays out the assumptions about both the design and the usage of that data structure 🧠
so a policy is basically a list of algorithms that a publisher has evaluated 📜 each evaluation is described by its identifier, its security constraints, and its validity period. those constraints are how you define the requirements for algorithm properties, e.g., a public key algorithm gets evaluated based on its parameters 🔑
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 unknown right now, so it must be possible to add new algorithms with their security constraints. also, the data structure must be independent of the intended use (encryption, signing, verifying, and signature renewing, for example), which means it works in every use case 🙌
Source authentication: policies may be published by different institutions, like on the national or European Union (EU) level 🏛️ and one policy needs not to be in agreement with another one. organizations can also do their own evaluations for internal purposes. because of all that, 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 🔒 and the date of issue must be identifiable too 🗓️
2.2. Assumptions 🧠
it's 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's contained in the current policy and the time of interest falls within the validity period ✨ and if the algorithm has any parameters, those parameters must meet the requirements defined in the security constraints 🎯
if an algorithm shows up in a policy for the first time, it may be assumed that it was already suitable in the past 🕰️ honestly, algorithms are usually used in practice before they get evaluated 🙈
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 📅
publishers may extend the lifetime of an algorithm before it reaches the end of its validity period, by publishing a revised policy 🔄 but 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, which is defined as an XML schema [W3C.REC-xmlschema-1-20041028] 🪄 the ASN.1 modules live in Appendix C and Appendix D. the schema uses this XML namespace [W3C.REC-xml-names-20060816]:
urn:ietf:params:xml:ns:dsscinside this document, the prefix "dssc" is used for that namespace 💜 the schema kicks off with this 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 sets the language according to [RFC5646], and that language gets applied to all the human-readable text in the policy 🌍 if lang is left out, the default language is English ("en") 🇬🇧 here's the schema for it:
<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 holds an arbitrary name for the policy ✏️ the optional Object Identifier (OID) and Uniform Resource Identifier (URI) elements MAY be used to identify the policy 🔖 and 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"/>3.3. Publisher 🏢
the Publisher element has info about who published the policy 📮 it's made up of the name (e.g., the name of an institution), an optional address, and an optional URI. the Address element holds arbitrary free-format text that isn't meant 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 tells you the point in 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 says what the policy is meant to be used for (e.g., certificate validation, or signing and verifying documents) 🖊️ it's free-format text meant 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, and the Algorithm element holds all the evaluations of that specific cryptographic algorithm. you might need more than one evaluation if the evaluation depends on the parameter constraints 🤓 the optional Information element MAY be used to give extra info, like references to algorithm specifications 📖 and since the option to extend the Algorithm element is important, it also contains a wildcard 🃏 here's the schema:
<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 how you identify a cryptographic algorithm 🔍 it's made up of the algorithm name, at least one OID, and optional URIs. the algorithm name isn't meant to be parsed by automatic processes, it's only for humans to read 🧑💻 the OID MUST be expressed in dot notation (e.g., "1.3.14.3.2.26") 💖 here's how the element is defined:
<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 ✨
okay so the Evaluation element holds the verdict for ONE crypto algorithm, but the verdict depends on its parameter constraints 🧠 like, RSA with a 1024 modulus might have a totally different suitability period than RSA with a 2048 modulus (not the same vibes, bestie 💀). Current hash algorithms like SHA-1 or RIPEMD-160 don't have any parameters, so the Parameter element is optional 🌸. The suitability is expressed as a validity period, which the Validity element defines. An optional wildcard MAY be used to extend the Evaluation element 💅.
<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, and these parameter names SHOULD be used 🫶. For the actual parameter, you can define a range of values or an exact value. These constraints are expressed by the following elements:
- Min: The Min element defines the minimum value of the parameter. That means values equal to 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, and in that case 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. That's why the Parameter element contains a wildcard 🧚. A parameter MUST contain at least one constraint. The schema for the Parameter element is as follows:
<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 defines the period of the (predicted) suitability of the algorithm 🔮. It's made up of an optional start date and an optional end date. Defining no end date means the algorithm has an open-end validity, which is giving "forever" energy 🌈. Of course, a future policy could restrict this by setting 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, like 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>3.13. Signature 🔐
The optional Signature element MAY be used to guarantee the integrity and authenticity of the policy 🛡️. It's 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's an enveloped signature, the signature MUST use the transformation algorithm identified by the following URI:
http://www.w3.org/2000/09/xmldsig#enveloped-signature4. DSSC Policies 🌸
DSSC policies MUST be expressed either in XML or ASN.1. However, 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:dsscXML-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. In other words, 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) 🧾.
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 🔍
Evaluating an algorithm's security suitability happens in three parts: verifying the policy, determining algorithm validity, and evaluating algorithm parameters, if any 🧩.
In the following sections, a process is described:
- to determine if an algorithm was suitable at a particular point of time, and
- 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:
- Policy
- Current time
- Algorithm identifier and parameter constraints (if associated)
- Time of interest (optional). Providing no time of interest means determining the validity end date of the algorithm.
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 to determine if the algorithm was suitable at the time of interest. For each Evaluation element:
- 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.
- 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 ✅.
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:
- Confirm that the parameter was provided as input. Discard the Evaluation element if the parameter does not match any of the parameters provided as input.
- 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.
- 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.
- 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 ✨
okay so this is the grand finale of the algorithm check 💅 If the algorithm isn't in the policy at all, you get the error "algorithm unknown". 🙈
If no time of interest was given as input, you return the maximum End time of the Evaluation elements that weren't discarded. But if even one of those Evaluation elements has no End time, you return "algorithm has an indefinite End time" instead. 🧚
Otherwise, if the algorithm isn't suitable relative to the time of interest, you return the error "algorithm unsuitable". 😭
And if it is suitable relative to the time of interest, you return the Evaluation elements that weren't discarded. Iconic, no notes 👑
7. Security Considerations 🔥
bestie, this part is SERIOUS, so read it with your whole chest 🫶 The policy for an algorithm's security suitability hugely affects how good the results of signature generation and verification are. If an algorithm gets evaluated wrong against a policy, you could end up with signatures that have low probative force, or verification results that are just wrong. 💀 Here are the security considerations that have been identified:
- Publishers MUST ensure unauthorized manipulation of any security suitability is not possible before a policy gets signed and published. There's no mechanism to revoke a policy after it's been published, so 😳 since the algorithm evaluations don't change very often, think carefully about how long a policy should live before you publish it. ⏳
- Operators SHOULD only accept policies from a trusted publisher. Also, 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 that certificate are no longer suitable. And it MUST NOT be possible to alter or replace a policy once an operator has accepted it. 🔒
- Operators SHOULD check periodically to see if a new policy has been published, so they don't end up using obsolete policy info. For publishers, it's suggested not to leave out the NextUpdate element, since it gives operators a hint about when the next policy will come out. 📅
- When signing a policy, algorithms that are suitable according to this policy SHOULD be used. 🎀
- The processing rule in Section 6 is about one cryptographic algorithm, independent of the use case. Depending on the use case, an algorithm that's no longer suitable at the time of interest does not necessarily mean the data structure where it's used is no longer secure. Let's say a signature was made with a 1024-bit RSA signer's key. That signature is timestamped with a timestamp token that uses a 2048-bit RSA key, and that happens before a 1024-bit RSA key size gets broken. The fact that the 1024-bit signature key is no longer suitable at the time of interest doesn't mean the whole data structure is insecure, as long as a 2048-bit RSA key size is still suitable at the time of interest. 🦋
- Beyond the key size considerations, other things need checking too, like whether a timestamp token was provided by a trusted authority. So using a suitability policy is NOT the only thing to look at when you're evaluating the security of a complex data structure that uses several cryptographic algorithms. 🧐
- The policies in this document are suitable for evaluating basic cryptographic algorithms, like public key or hash algorithms, and also cryptographic schemes (for example, the PKCS#1 v1.5 signature schemes [RFC3447]). But MUST keep in mind that a basic cryptographic algorithm that's suitable according to the policy doesn't necessarily mean that any cryptographic scheme based on it is secure too. For example, a signature scheme based on RSA doesn't have to be secure just because RSA is suitable. For a complete signature verification, including validation of the certificate path, various algorithms have to be checked against the policy (signature schemes of signed data objects and revocation information, public key algorithms of the involved certificates, and so on). So a policy SHOULD contain evaluations of public key and hash algorithms as well as of signature schemes. 🌈
- Re-encrypting documents that were originally encrypted with an algorithm that's no longer suitable won't protect the semantics of the document if the document has been intercepted. However, for documents stored in 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]. Here's the registration template, copied exactly:
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: IETFThis 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]. Its template:
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: IETFThis specification creates a new IANA registry called "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)". This registry has two sub-registries, "Parameter Definitions" and "Cryptographic Algorithms". The policy for future assignments to the "Parameter Definitions" sub-registry is "RFC Required". ✨
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 "Cryptographic Algorithms" sub-registry holds textual names as well as Object Identifiers (OIDs) and Uniform Resource Identifiers (URIs) of cryptographic algorithms. It helps when you're 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:
- The textual name of the algorithm.
- The OID of the algorithm.
- 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:
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]9. References 📚
9.1. Normative References
Okay bestie, these are the normative refs 📚💖 Basically the docs you have to have read to actually get this spec, no skipping 🫶
[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. ✨
[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
Now the informative ones 🦋 These are the extra reading that's nice to have but not required to get the spec.
[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.
[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.
[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.
Appendix A. DSSC and ERS ✨
A.1. Verification of Evidence Records Using DSSC (Informative)
Okay so this bit is about checking an Evidence Record using DSSC 🫶 It follows the Evidence Record Syntax (ERS, [RFC4998]) and uses the data structure we just looked at.
An Evidence Record holds a sequence of ArchiveTimeStampChains, and those are made up of ArchiveTimeStamps. For each ArchiveTimeStamp you have to look at the hash algorithm used for the hash tree (digestAlgorithm), plus the public key algorithm and hash algorithm in the timestamp signature. The date that matters is the time info in the timestamp (date of issue). Starting from the first ArchiveTimeStamp, you have to make sure that:
- The timestamp uses public key and hash algorithms that were suitable at the date of issue.
- The hashtree was built with a hash algorithm that was suitable at the date of issue as well.
- Algorithms for timestamp and hashtree in the preceding ArchiveTimeStamp must have been suitable at the issuing date of considered ArchiveTimeStamp.
- Algorithms in the last ArchiveTimeStamp have to be suitable now.
If any one of these checks fails, the whole verification fails too 💀
A.2. Storing DSSC Policies in Evidence Records (Normative)
This part explains how to store a policy inside an Evidence Record 🎀 ERS gives you the field cryptoInfos for stashing extra verification data. To fit a security suitability policy into an Evidence Record, these content types are defined for both the ASN.1 and XML representations:
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) }Appendix B. XML Schema (Normative) 💅
okay bestie, this is the XML schema 🎀 it's the exact blueprint for the policy structure, so every bit is copied over word for word ✨
<?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>
<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">
<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) 🧚
this one's the ASN.1 version in the 1988 syntax, and it's marked informative, so it's here for reference 🌸
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
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,
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
}
ENDAppendix D. ASN.1 Module in 1997 Syntax (Normative) 🌈
and last but not least, the 1997 syntax version. this one's normative, so it's the official one ⭐
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)}
;
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})
}
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
}
ENDAppendix E. Example 🎀
okay so bestie, this one is a real-life example policy 💅 It's a policy you could use to check digital signatures, and it lists hash algorithms, public key algorithms, and signature schemes all together. Heads up: SHA-1 and RSA with a 1024-bit modulus are used here as examples of 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>
<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>
<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>
</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>
</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>Authors' Addresses ✨
Here are the authors' details, so you know exactly who to thank (or ask) about this 🫶
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.deThat's the whole RFC, bestie! 🌈👑 Iconic work from all three authors 💜
📦 where this page comes from
- ietf: rfc5698 2009-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms