< draft-housley-cms-mts-hash-sig-04.txt   draft-housley-cms-mts-hash-sig-05.txt >
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Intended Status: Proposed Standard Vigil Security Intended Status: Proposed Standard Vigil Security
Expires: 21 September 2016 21 March 2016 Expires: 22 June 2017 19 December 2016
Use of the Hash-based Merkle Tree Signature (MTS) Algorithm Use of the Hash-based Merkle Tree Signature (MTS) Algorithm
in the Cryptographic Message Syntax (CMS) in the Cryptographic Message Syntax (CMS)
<draft-housley-cms-mts-hash-sig-04> <draft-housley-cms-mts-hash-sig-05>
Abstract Abstract
This document specifies the conventions for using the Merkle Tree This document specifies the conventions for using the Merkle Tree
Signatures (MTS) digital signature algorithm with the Cryptographic Signatures (MTS) digital signature algorithm with the Cryptographic
Message Syntax (CMS). The MTS algorithm is one form of hash-based Message Syntax (CMS). The MTS algorithm is one form of hash-based
digital signature. digital signature.
Status of this Memo Status of this Memo
skipping to change at page 2, line 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. MTS Digital Signature Algorithm . . . . . . . . . . . . . 3 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. LM-OTS One-time Signature Algorithm . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. MTS Digital Signature Algorithm Overview . . . . . . . . . . . 3
2. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 4 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 3
3. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 5 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 5
4.1. Implementation Security Considerations . . . . . . . . . . 6 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6
4.2. Algorithm Security Considerations . . . . . . . . . . . . 6 4. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 5.1. Implementation Security Considerations . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . . 7 5.2. Algorithm Security Considerations . . . . . . . . . . . . 7
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document specifies the conventions for using the Merkle Tree This document specifies the conventions for using the Merkle Tree
Signatures (MTS) digital signature algorithm with the Cryptographic Signatures (MTS) digital signature algorithm with the Cryptographic
Message Syntax (CMS) [CMS] signed-data content type. The MTS Message Syntax (CMS) [CMS] signed-data content type. The MTS
algorithm is one form of hash-based digital signature that can only algorithm is one form of hash-based digital signature that can only
be used for a fixed number of signatures. The MTS algorithm is be used for a fixed number of signatures. The MTS algorithm is
described in [HASHSIG]. The MTS algorithm uses small private and described in [HASHSIG]. The MTS algorithm uses small private and
public keys, and it has low computational cost; however, the public keys, and it has low computational cost; however, the
signatures are quite large. signatures are quite large.
CMS values are generated using ASN.1 [ASN1-02], using the Basic 1.1. ASN.1
Encoding Rules (BER) and the Distinguished Encoding Rules (DER).
1.1. MTS Digital Signature Algorithm CMS values are generated using ASN.1 [ASN1-B], using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[ASN1-E].
Merkle Tree Signatures (MTS) are a method for signing a large but 1.2. Terminology
fixed number of messages. An MTS system is an N-time signature
system, meaning that the private key can be used to generate at most
N signatures.
An MTS system uses two cryptographic components: a one-time signature The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
method and a collision-resistant hash function. Each MTS "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
public/private key pair is associated with a k-way tree. Each leaf document are to be interpreted as described in RFC 2119 [KEYWORDS].
of the tree can be used to generate a one-time signature (OTS), which
can be used to securely sign exactly one message, but cannot securely 2. MTS Digital Signature Algorithm Overview
sign more than one.
Merkle Tree Signatures (MTS) are a method for signing a large but
fixed number of messages. An MTS system depends on a one-time
signature method and a collision-resistant hash function. An MTS
system is an N-time signature system, meaning that the private key
can be used to generate at most N signatures.
This specification makes use of the MTS algorithm specified in This specification makes use of the MTS algorithm specified in
[HASHSIG], which is the Leighton and Micali adaptation [LM] of the [HASHSIG], which is the Leighton and Micali adaptation [LM] of the
original Lamport-Diffie-Winternitz-Merkle one-time signature system original Lamport-Diffie-Winternitz-Merkle one-time signature system
[M1979][M1987][M1989a][M1989b]. It makes use of the LM-OTS one-time [M1979][M1987][M1989a][M1989b]. It makes use of the LM-OTS one-time
signature scheme and the SHA-256 [SHS] one-way hash function. signature scheme and the SHA-256 one-way hash function [SHS].
An LMS system has two parameters. The height of the tree, h, which 2.1. Hierarchical Signature System (HSS)
is the number of levels in the tree minus one. The [HASHSIG]
specification supports three values for this parameter: h=20; h=10;
and h=5. The number of bytes associated with each node in the tree,
n, is defined by the hash function. The [HASHSIG] specification
supports two hash functions: SHA-256 [SHS], with n=32; and
SHA-256-16, which is the same as SHA-256, except that the hash result
is truncated to 16 bytes, with n=16. Note that there are 2^h leaves
in the tree.
Six tree sizes are specified in [HASHSIG]: The MTS system specified in [HASHSIG] uses a hierarchy of trees. The
lms_sha256_n32_h20; Hierarchical N-time Signature System (HSS) allows subordinate trees
lms_sha256_n32_h10; to be generated when they are needed by the signer. Otherwise,
lms_sha256_n32_h5; generation of the entire tree might take weeks or longer.
lms_sha256_n16_h20;
lms_sha256_n16_h10; and
lms_sha256_n16_h5.
An LMS signature consists of three things: a typecode indicating the An HSS signature as specified in specified in [HASHSIG] carries the
particular LMS algorithm, an LM-OTS signature, and an array of values number of levels minus one, followed by that number of signed public
that is associated with the path through the tree from the leaf keys, followed by the LMS signature as described in Section 2.2.
associated with the LM-OTS signature to the root. The array of Each signed public key is represented by the hash value at the root
values contains the siblings of the nodes on the path from the leaf of the tree, and the signature over that public key is an LMS
to the root but does not contain the nodes on the path itself. The signature as described in Section 2.2.
array for a tree with height h will have h values. The first value
is the sibling of the leaf, the next value is the sibling of the
parent of the leaf, and so on up the path to the root.
1.2. LM-OTS One-time Signature Algorithm The elements of the HSS signature value for a stand-alone tree can be
summarized as:
u32str(0) ||
lms_signature_on_message
The elements of the HSS signature value for a tree with L levels can
be summarized as:
u32str(L-1) ||
lms_signature_on_public_key[0] || public_key[1] ||
lms_signature_on_public_key[1] || public_key[2] ||
...
lms_signature_on_public_key[L-2] || public_key[L-1] ||
lms_signature_on_message
2.2. Leighton-Micali Signature (LMS)
Each tree in the system specified in [HASHSIG] uses the Leighton-
Micali Signature (LMS) system. LMS systems have two parameters. The
first parameter is the height of the tree, h, which is the number of
levels in the tree minus one. The [HASHSIG] specification supports
four values for this parameter: h=20; h=15; h=10; and h=5. Note that
there are 2^h leaves in the tree. The second parameter is the number
of bytes output by the hash function, n, which the amount of data
associated with each node in the tree. The [HASHSIG] specification
supports only the SHA-256 hash function [SHS], with n=32.
Four tree sizes are specified in [HASHSIG]:
LMS_SHA256_M32_H20;
LMS_SHA256_M32_H15
LMS_SHA256_M32_H10; and
LMS_SHA256_M32_H5.
An LMS signature consists of four elements: a typecode indicating the
particular LMS algorithm, the number of the leaf associated with the
LM-OTS signature, an LM-OTS signature as described in Section 2.3,
and an array of values that is associated with the path through the
tree from the leaf associated with the LM-OTS signature to the root.
The array of values contains the siblings of the nodes on the path
from the leaf to the root but does not contain the nodes on the path
itself. The array for a tree with height h will have h values. The
first value is the sibling of the leaf, the next value is the sibling
of the parent of the leaf, and so on up the path to the root.
The four elements of the LMS signature value can be summarized as:
u32str(type) ||
u32str(q) ||
ots_signature ||
path[0] || path[1] || ... || path[h-1]
2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)
Merkle Tree Signatures (MTS) depend on a LM-OTS one-time signature Merkle Tree Signatures (MTS) depend on a LM-OTS one-time signature
method. An LM-OTS has four parameters. method. An LM-OTS has four parameters.
n - The number of bytes associated with the hash function, which n - The number of bytes associated with the hash function, which
is the same as the LMS parameter. The [HASHSIG] is the same as the LMS parameter. The [HASHSIG]
specification supports two hash functions: SHA-256 [SHS], specification supports only one hash function: SHA-256 [SHS],
with n=32; and SHA-256-16, with n=16. with n=32.
w - The the Winternitz parameter. The [HASHSIG] specification w - The width in bits of the Winternitz coefficients. The
supports four values for this parameter: w=1; w=2; w=4; and [HASHSIG] specification supports four values for this
w=8. parameter: w=1; w=2; w=4; and w=8.
p - The number of n-byte string elements that make up the LM-OTS p - The number of n-byte string elements that make up the LM-OTS
signature. signature.
ls - The number of left-shift bits used in the checksum function. ls - The number of left-shift bits used in the checksum function.
The values of p and ls are dependent on the choices of the parameters The values of p and ls are dependent on the choices of the parameters
n and w, as described in Appendix A of [HASHSIG]. n and w, as described in Appendix A of [HASHSIG].
Eight LM-OTS variants are defined in [HASHSIG]: Four LM-OTS variants are defined in [HASHSIG]:
LMOTS_SHA256_N32_W1; LMOTS_SHA256_N32_W1;
LMOTS_SHA256_N32_W2; LMOTS_SHA256_N32_W2;
LMOTS_SHA256_N32_W4; LMOTS_SHA256_N32_W4; and
LMOTS_SHA256_N32_W8; LMOTS_SHA256_N32_W8.
LMOTS_SHA256_N16_W1;
LMOTS_SHA256_N16_W2;
LMOTS_SHA256_N16_W4; and
LMOTS_SHA256_N16_W8.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Signing involves the generation of C, an n-byte random value.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
2. Algorithm Identifiers and Parameters The LM-OTS signature value can be summarized as:
The algorithm identifier for an MTS signature is id-alg-mts-hashsig: u32str(type) || C || y[0] || ... || y[p-1]
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3. Algorithm Identifiers and Parameters
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-alg OBJECT IDENTIFIER ::= { id-smime 3 } The algorithm identifier for an MTS signature is id-alg-mts-hashsig:
id-alg-mts-hashsig OBJECT IDENTIFIER ::= { id-alg 17 } id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }
When the id-alg-mts-hashsig algorithm identifier is used for a When the id-alg-mts-hashsig algorithm identifier is used for a
signature, the AlgorithmIdentifier parameters field MUST be absent. signature, the AlgorithmIdentifier parameters field MUST be absent.
The first 4 bytes of the signature value contains the The signature values is a large OCTET STRING. The signature format
mls_algorithm_type as defined in Section 5.5 of [HASHSIG]. This type is designed for easy parsing. Each format includes a counter and
tells how to parse the remaining parts of the signature value, which type codes that indirectly providing all of the information that is
is composed of an LM-OTS signature and an array of values that is needed to parse the value during signature validation. The first 4
associated with the path through the tree from the leaf associated octets of the signature value contains a count of levels minus one in
with the LM-OTS signature to the root. the HSS. The first 4 octets of each LMS signature value contains
type code, which tells how to parse the remaining parts of the
The first 4 bytes of the LM-OTS signature value contains the signature value. The first 4 octets of each LM-OTS signature value
ots_algorithm_type as defined in Section 4.10 of [HASHSIG]. This contains type code, which tells how to parse the remaining parts of
type is followed by n*p bytes of signature value. the signature value.
The signature format is designed for easy parsing. Each format
starts with a 4-byte enumeration value that indicates all of the
details of the signature algorithm, indirectly providing all of the
information that is needed to parse the value during signature
validation.
3. Signed-data Conventions 4. Signed-data Conventions
digestAlgorithms SHOULD contain the one-way hash function used to digestAlgorithms SHOULD contain the one-way hash function used to
compute the message digest on the eContent value. Since the hash- compute the message digest on the eContent value. Since the hash-
based signature algorithms all depend on SHA-256, it is strongly based signature algorithms all depend on SHA-256, it is strongly
RECOMMENDED that SHA-256 also be used to compute the message digest RECOMMENDED that SHA-256 also be used to compute the message digest
on the content. on the content.
Further, the same one-way hash function SHOULD be used to compute the Further, the same one-way hash function SHOULD be used to compute the
message digest on both the eContent and the signedAttributes value if message digest on both the eContent and the signedAttributes value if
signedAttributes exist. Again, since the hash-based signature signedAttributes are present. Again, since the hash-based signature
algorithms all depend on SHA-256, it is strongly RECOMMENDED that algorithms all depend on SHA-256, it is strongly RECOMMENDED that
SHA-256 be used. SHA-256 be used.
signatureAlgorithm MUST contain id-alg-mts-hashsig. The algorithm signatureAlgorithm MUST contain id-alg-mts-hashsig. The algorithm
parameters field MUST be absent. parameters field MUST be absent.
signature contains the single value resulting from the signing signature contains the single HSS signature value resulting from the
operation as specified in [HASHSIG]. signing operation as specified in [HASHSIG].
4. Security Considerations 5. Security Considerations
4.1. Implementation Security Considerations 5.1. Implementation Security Considerations
Implementations must protect the private keys. Compromise of the Implementations must protect the private keys. Compromise of the
private keys may result in the ability to forge signatures. Along private keys may result in the ability to forge signatures. Along
with the private key, the implementation must maintain a counter with the private key, the implementation must keep track of which
value that indicates which leaf nodes in the tree have been used. leaf nodes in the tree have been used. Loss of integrity of this
Loss of integrity of this counter can cause an one-time key to be tracking data can cause an one-time key to be used more than once.
used more than once. As a result, when a private key and an As a result, when a private key and the tracking data are stored on
associated counter value are stored on non-volatile media or stored non-volatile media or stored in a virtual machine environment, care
in a virtual machine environment, care must be taken to preserve must be taken to preserve confidentiality and integrity.
these properties.
An implementation must ensure that a LDWM private key is used only An implementation must ensure that a LM-OTS private key is used to
one time, and ensure that the LDWM private key cannot be used for any generate a signature only one time, and ensure that it cannot be used
other purpose. for any other purpose.
The generation of private keys relies on random numbers. The use of The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these inadequate pseudo-random number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities, rather than brute
force searching the whole key space. The generation of quality force searching the whole key space. The generation of quality
random numbers is difficult. RFC 4086 [RANDOM] offers important random numbers is difficult. RFC 4086 [RANDOM] offers important
guidance in this area. guidance in this area.
When computing signatures, the same hash function SHOULD be used for When computing signatures, the same hash function SHOULD be used for
all operations. This reduces the number of failure points in the all operations. In this specification, only SHA-256 is used. Using
only SHA-256 reduces the number of possible failure points in the
signature process. signature process.
4.2. Algorithm Security Considerations 5.2. Algorithm Security Considerations
At Black Hat USA 2013, some researchers gave a presentation on the At Black Hat USA 2013, some researchers gave a presentation on the
current sate of public key cryptography. They said: "Current current sate of public key cryptography. They said: "Current
cryptosystems depend on discrete logarithm and factoring which has cryptosystems depend on discrete logarithm and factoring which has
seen some major new developments in the past 6 months" [BH2013]. seen some major new developments in the past 6 months" [BH2013].
They encouraged preparation for a day when RSA and DSA cannot be They encouraged preparation for a day when RSA and DSA cannot be
depended upon. depended upon.
A post-quantum cryptosystem is a system that is secure against A post-quantum cryptosystem is a system that is secure against
quantum computers that have more than a trivial number of quantum quantum computers that have more than a trivial number of quantum
bits. It is open to conjecture whether it is feasible to build such bits. It is open to conjecture when it will be feasible to build
a machine. RSA, DSA, and ECDSA are not post-quantum secure. such a machine. RSA, DSA, and ECDSA are not post-quantum secure.
The LM-OTP one-time signature and LMS do not depend on discrete The LM-OTP one-time signature, LMS, and HSS do not depend on discrete
logarithm or factoring, and these algorithms are considered to be logarithm or factoring, as a result these algorithms are considered
post-quantum secure. to be post-quantum secure.
Today, RSA is often used to digitally sign software updates. This Today, RSA is often used to digitally sign software updates. This
means that the distribution of software updates could be compromised means that the distribution of software updates could be compromised
if a significant advance is made in factoring or a quantum computer if a significant advance is made in factoring or a quantum computer
is invented. The use of MTS signatures to protect software update is invented. The use of MTS signatures to protect software update
distribution, perhaps using the format described in [FWPROT], will distribution, perhaps using the format described in [FWPROT], will
allow the deployment of software that implements new cryptosystems. allow the deployment of software that implements new cryptosystems.
5. IANA Considerations 6. IANA Considerations
{{ RFC Editor: Please remove this section prior to publication. }} {{ RFC Editor: Please remove this section prior to publication. }}
This document has no actions for IANA. This document has no actions for IANA.
6. Normative References 7. Normative References
[ASN1-02] ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation
X.683", ITU-T X.680, X.681, X.682, and X.683, 2002. One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, 2015.
[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[HASHSIG] McGrew, D., and M. Curcio, "Hash-Based Signatures", Work [HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based
in progress. <draft-mcgrew-hash-sigs-03> Signatures", Work in progress. <draft-mcgrew-hash-
sigs-05>
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc- 10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[SHS] National Institute of Standards and Technology (NIST), [SHS] National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard, October FIPS Publication 180-3: Secure Hash Standard, October
2008. 2008.
7. Informative References 8. Informative References
[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The [BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The
Factoring Dead: Preparing for the Cryptopocalypse", August Factoring Dead: Preparing for the Cryptopocalypse", August
2013. <https://media.blackhat.com/us-13/us-13-Stamos-The- 2013. <https://media.blackhat.com/us-13/us-13-Stamos-The-
Factoring-Dead.pdf> Factoring-Dead.pdf>
[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for [CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010, <http://www.rfc- DOI 10.17487/RFC5911, June 2010, <http://www.rfc-
editor.org/info/rfc5911>. editor.org/info/rfc5911>.
skipping to change at page 10, line 11 skipping to change at page 10, line 11
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <http://www.rfc- DOI 10.17487/RFC4086, June 2005, <http://www.rfc-
editor.org/info/rfc4086>. editor.org/info/rfc4086>.
Appendix: ASN.1 Module Appendix: ASN.1 Module
MTS-HashSig-2013 MTS-HashSig-2013
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
SIGNATURE-ALGORITHM PUBLIC-KEY SIGNATURE-ALGORITHM PUBLIC-KEY
FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } id-mod-algorithmInformation-02(58) }
mda-sha256 mda-sha256
FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1] FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1]
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) } ; id-mod-pkix1-rsa-pkalgs-02(54) } ;
-- --
-- Object Identifiers -- Object Identifiers
-- --
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }
id-alg OBJECT IDENTIFIER ::= { id-smime 3 }
id-alg-mts-hashsig OBJECT IDENTIFIER ::= { id-alg 17 }
-- --
-- Signature Algorithm and Public Key -- Signature Algorithm and Public Key
-- --
sa-MTS-HashSig SIGNATURE-ALGORITHM ::= { sa-MTS-HashSig SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-mts-hashsig IDENTIFIER id-alg-mts-hashsig
HASHES { mda-sha256, ... } HASHES { mda-sha256, ... }
PUBLIC-KEYS { pk-MTS-HashSig } } PUBLIC-KEYS { pk-MTS-HashSig } }
 End of changes. 44 change blocks. 
135 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/