draft-ietf-lamps-cms-shakes-08.txt   draft-ietf-lamps-cms-shakes-09.txt 
LAMPS WG P. Kampanakis LAMPS WG P. Kampanakis
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Q. Dang Updates: RFC3370 (if approved) Q. Dang
Expires: September 9, 2019 NIST Intended status: Standards Track NIST
March 8, 2019 Expires: October 13, 2019 April 11, 2019
Use of the SHAKE One-way Hash Functions in the Cryptographic Message Use of the SHAKE One-way Hash Functions in the Cryptographic Message
Syntax (CMS) Syntax (CMS)
draft-ietf-lamps-cms-shakes-08 draft-ietf-lamps-cms-shakes-09
Abstract Abstract
This document describes the conventions for using the SHAKE family of This document describes the conventions for using the SHAKE family of
hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the Cryptographic Message Syntax (CMS) as one-way
hash functions with the RSA Probabilistic signature and ECDSA hash functions with the RSA Probabilistic signature and ECDSA
signature algorithms, as message digests and message authentication signature algorithms, as message digests and message authentication
codes. The conventions for the associated signer public keys in CMS codes. The conventions for the associated signer public keys in CMS
are also described. are also described.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019. This Internet-Draft will expire on October 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7
4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8
4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Message Authentication Codes . . . . . . . . . . . . . . 9 4.4. Message Authentication Codes . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Change Log 1. Change Log
[ EDNOTE: Remove this section before publication. ] [ EDNOTE: Remove this section before publication. ]
o draft-ietf-lamps-cms-shake-09:
* Fixed minor text nit.
* Updates in Sec Considerations section.
o draft-ietf-lamps-cms-shake-08: o draft-ietf-lamps-cms-shake-08:
* id-shake128-len and id-shake256-len were replaced with id- * id-shake128-len and id-shake256-len were replaced with id-
sha128 with 32 bytes output length and id-shake256 with 64 sha128 with 32 bytes output length and id-shake256 with 64
bytes output length. bytes output length.
* Fixed a discrepancy between section 3 and 4.4 about the KMAC * Fixed a discrepancy between section 3 and 4.4 about the KMAC
OIDs that have parameters as optional. OIDs that have parameters as optional.
o draft-ietf-lamps-cms-shake-07: o draft-ietf-lamps-cms-shake-07:
skipping to change at page 3, line 18 skipping to change at page 3, line 24
* Updated IANA considerations. * Updated IANA considerations.
o draft-ietf-lamps-cms-shake-04: o draft-ietf-lamps-cms-shake-04:
* Added RFC8174 reference and text. * Added RFC8174 reference and text.
* Explicitly explained why RSASSA-PSS-params are omitted in * Explicitly explained why RSASSA-PSS-params are omitted in
section 4.2.1. section 4.2.1.
* Simplified Public Keys section by removing redundand info from * Simplified Public Keys section by removing redundant info from
RFCs. RFCs.
o draft-ietf-lamps-cms-shake-03: o draft-ietf-lamps-cms-shake-03:
* Removed paragraph suggesting KMAC to be used in generating k in * Removed paragraph suggesting KMAC to be used in generating k in
Deterministric ECDSA. That should be RFC6979-bis. Deterministic ECDSA. That should be RFC6979-bis.
* Removed paragraph from Security Considerations that talks about * Removed paragraph from Security Considerations that talks about
randomness of k because we are using deterministric ECDSA. randomness of k because we are using deterministic ECDSA.
* Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's * Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's
feedback. feedback.
* Text fixes. * Text fixes.
o draft-ietf-lamps-cms-shake-02: o draft-ietf-lamps-cms-shake-02:
* Updates based on suggestions and clarifications by Jim. * Updates based on suggestions and clarifications by Jim.
skipping to change at page 5, line 31 skipping to change at page 5, line 33
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 12 } nistAlgorithm(4) 2 12 }
In this specification, when using the id-shake128 or id-shake256 In this specification, when using the id-shake128 or id-shake256
algorithm identifiers, the parameters MUST be absent. That is, the algorithm identifiers, the parameters MUST be absent. That is, the
identifier SHALL be a SEQUENCE of one component, the OID. identifier SHALL be a SEQUENCE of one component, the OID.
We define two new identifiers for RSASSA-PSS signatures using SHAKEs. We define two new identifiers for RSASSA-PSS signatures using SHAKEs.
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 }
[ EDNOTE: "TBD" will be specified by NIST later. ] [ EDNOTE: "TBD1", "TBD2" will be specified by NIST later. ]
The same RSASSA-PSS algorithm identifiers can be used for identifying The same RSASSA-PSS algorithm identifiers can be used for identifying
public keys and signatures. public keys and signatures.
We define two new algorithm identifiers of ECDSA signatures using We define two new algorithm identifiers of ECDSA signatures using
SHAKEs. SHAKEs.
id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 3 TBD } nistAlgorithm(4) 3 TBD3 }
id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 3 TBD } nistAlgorithm(4) 3 TBD4 }
[ EDNOTE: "TBD" will be specified by NIST. ] [ EDNOTE: "TBD3", "TBD4" will be specified by NIST. ]
The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be
absent. That is, each identifier SHALL be a SEQUENCE of one absent. That is, each identifier SHALL be a SEQUENCE of one
component, the OID. component, the OID.
Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are
defined below. defined below.
id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
skipping to change at page 7, line 9 skipping to change at page 7, line 16
In CMS, signature algorithm identifiers are located in the SignerInfo In CMS, signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData content type and signatureAlgorithm field of SignedData content type and
countersignature attribute. Signature values are located in the countersignature attribute. Signature values are located in the
SignerInfo signature field of SignedData and countersignature. SignerInfo signature field of SignedData and countersignature.
Conforming implementations that process RSASSA-PSS and ECDSA with Conforming implementations that process RSASSA-PSS and ECDSA with
SHAKE signatures when processing CMS data MUST recognize the SHAKE signatures when processing CMS data MUST recognize the
corresponding OIDs specified in Section 3. corresponding OIDs specified in Section 3.
When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA
curve order SHOULD be chosen in line with the SHAKE output length.
In the context of this document SHAKE128 OIDs are RECOMMENDED for
2048 or 3072-bit RSA modulus or curves with group order of 256-bits.
SHAKE256 OIDs are RECOMMENDED for 4096-bit RSA modulus and higher or
curves with group order of 384-bits and higher.
4.2.1. RSASSA-PSS Signatures 4.2.1. RSASSA-PSS Signatures
The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is
used, the encoding MUST omit the parameters field. That is, the used, the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA-
PSS-params that are used to define the algorithms and inputs to the PSS-params that are used to define the algorithms and inputs to the
algorithm. This specification does not use parameters because the algorithm. This specification does not use parameters because the
hash and mask generating algorithsm and trailer and salt are embedded hash and mask generating algorithm and trailer and salt are embedded
in the OID definition. in the OID definition.
The hash algorithm to hash a message being signed and the hash and The hash algorithm to hash a message being signed and the hash and
the hash algorithm as the mask generation function used in RSASSA-PSS the hash algorithm as the mask generation function used in RSASSA-PSS
MUST be the same, SHAKE128 or SHAKE256 respectively. The output- MUST be the same, SHAKE128 or SHAKE256 respectively. The output-
length of the hash algorithm which hashes the message SHALL be 32 or length of the hash algorithm which hashes the message SHALL be 32 or
64 bytes respectively. 64 bytes respectively.
The mask generation function takes an octet string of variable length The mask generation function takes an octet string of variable length
and a desired output length as input, and outputs an octet string of and a desired output length as input, and outputs an octet string of
the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be
used natively as the MGF function, instead of the MGF1 algorithm that used natively as the MGF function, instead of the MGF1 algorithm that
uses the hash function in multiple iterations as specified in uses the hash function in multiple iterations as specified in
Section B.2.1 of [RFC8017]. In other words, the MGF is defined as Section B.2.1 of [RFC8017]. In other words, the MGF is defined as
the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-
SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the
seed from which mask is generated, an octet string [RFC8017]. As seed from which mask is generated, an octet string [RFC8017]. As
explained in Step 9 of section 9.1.1 of [RFC8017], the output length explained in Step 9 of section 9.1.1 of [RFC8017], the output length
of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message
length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32
and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256
skipping to change at page 8, line 8 skipping to change at page 8, line 18
SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS-
SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively.
The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively.
Finally, the trailerField MUST be 1, which represents the trailer Finally, the trailerField MUST be 1, which represents the trailer
field with hexadecimal value 0xBC [RFC8017]. field with hexadecimal value 0xBC [RFC8017].
4.2.2. ECDSA Signatures 4.2.2. ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
[X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
(specified in Section 3) algorithm identifier appears, the respective (specified in Section 3) algorithm identifier appears, the respective
SHAKE function is used as the hash. The encoding MUST omit the SHAKE function is used as the hash. The encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id-
ecdsa-with-SHAKE256. ecdsa-with-shake256.
For simplicity and compliance with the ECDSA standard specification, For simplicity and compliance with the ECDSA standard specification,
the output size of the hash function must be explicitly determined. the output size of the hash function must be explicitly determined.
The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be
256 or 512 bits respectively. 256 or 512 bits respectively.
It is RECOMMENDED that conforming implementations that generate ECDSA It is RECOMMENDED that conforming implementations that generate ECDSA
with SHAKE signatures in CMS generate such signatures with a with SHAKE signatures in CMS generate such signatures with a
deterministically generated, non-random k in accordance with all the deterministically generated, non-random k in accordance with all the
requirements specified in [RFC6979]. They MAY also generate such requirements specified in [RFC6979]. They MAY also generate such
skipping to change at page 9, line 38 skipping to change at page 9, line 49
One object identifier for the ASN.1 module in Appendix A was assigned One object identifier for the ASN.1 module in Appendix A was assigned
in the SMI Security for S/MIME Module Identifiers in the SMI Security for S/MIME Module Identifiers
(1.2.840.113549.1.9.16.0) registry: (1.2.840.113549.1.9.16.0) registry:
CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-shakes-2019(TBD) } id-mod-cms-shakes-2019(TBD) }
6. Security Considerations 6. Security Considerations
The SHAKEs are deterministic functions. Like any other deterministic This document updates [RFC3370]. The security considerations section
function, executing each function with the same input multiple times of that document applies to this specification as well.
will produce the same output. Therefore, users should not expect
unrelated outputs (with the same or different output lengths) from NIST has defined appropriate use of the hash functions in terms of
excuting a SHAKE function with the same input multiple times. The the algorithm strengths and expected time frames for secure use in
shorter one of any 2 outputs produced from a SHAKE with the same Special Publications (SPs) [SP800-78-4] and [SP800-107]. These
input is a prefix of the longer one. It is a similar situation as documents can be used as guides to choose appropriate key sizes for
truncating a 512-bit output of SHA-512 by taking its 256 left-most various security scenarios.
bits. These 256 left-most bits are a prefix of the 512-bit output.
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC, therefore the
content could originate from any one of the parties. content could originate from any one of the parties.
When using ECDSA with SHAKEs, the ECDSA curve order SHOULD be chosen
in line with the SHAKE output length. NIST has defined appropriate
use of the hash functions in terms of the algorithm strengths and
expected time frames for secure use in Special Publications (SPs)
[SP800-78-4] and [SP800-107]. These documents can be used as guides
to choose appropriate key sizes for various security scenarios. In
the context of this document id-ecdsa-with-shake128 is RECOMMENDED
for curves with group order of 256-bits. id-ecdsa-with-shake256 is
RECOMMENDED for curves with group order of 384-bits or more.
7. Acknowledgements 7. Acknowledgements
This document is based on Russ Housley's draft This document is based on Russ Housley's draft
[I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions
by SHAKE128 and SHAKE256 as the LAMPS WG agreed. by SHAKE128 and SHAKE256 as the LAMPS WG agreed.
The authors would like to thank Russ Housley for his guidance and The authors would like to thank Russ Housley for his guidance and
very valuable contributions with the ASN.1 module. Valuable feedback very valuable contributions with the ASN.1 module. Valuable feedback
was also provided by Eric Rescorla. was also provided by Eric Rescorla.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<https://www.rfc-editor.org/info/rfc3370>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
skipping to change at page 13, line 49 skipping to change at page 13, line 49
-- One-Way Hash Functions -- One-Way Hash Functions
-- SHAKE128 -- SHAKE128
mda-shake128 DIGEST-ALGORITHM ::= { mda-shake128 DIGEST-ALGORITHM ::= {
IDENTIFIER id-shake128 -- with output length 32 bytes. IDENTIFIER id-shake128 -- with output length 32 bytes.
} }
id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) csor(3) nistAlgorithm(4)
hashAlgs(2) 11 } hashAlgs(2) 11 }
-- SHAKE-256 -- SHAKE256
mda-shake256 DIGEST-ALGORITHM ::= { mda-shake256 DIGEST-ALGORITHM ::= {
IDENTIFIER id-shake256 -- with output length 64 bytes. IDENTIFIER id-shake256 -- with output length 64 bytes.
} }
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) csor(3) nistAlgorithm(4)
hashAlgs(2) 12 } hashAlgs(2) 12 }
-- --
-- Public key algorithm identifiers located in the -- Public key algorithm identifiers located in the
skipping to change at page 14, line 22 skipping to change at page 14, line 22
-- And Signature identifiers used in SignerInfo -- And Signature identifiers used in SignerInfo
-- signatureAlgorithm field of SignedData content -- signatureAlgorithm field of SignedData content
-- type and countersignature attribute in CMS. -- type and countersignature attribute in CMS.
-- --
-- From RFC5280, for reference. -- From RFC5280, for reference.
-- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-- When the rsaEncryption algorithm identifier is used -- When the rsaEncryption algorithm identifier is used
-- for a public key, the AlgorithmIdentifier parameters -- for a public key, the AlgorithmIdentifier parameters
-- field MUST contain NULL. -- field MUST contain NULL.
-- --
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 }
-- When the id-RSASSA-PSS-* algorithm identifiers are used -- When the id-RSASSA-PSS-* algorithm identifiers are used
-- for a public key or signature in CMS, the AlgorithmIdentifier -- for a public key or signature in CMS, the AlgorithmIdentifier
-- parameters field MUST be absent. The message digest algorithm -- parameters field MUST be absent. The message digest algorithm
-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or
-- 64 byte outout length respectively. The mask generating -- 64 byte outout length respectively. The mask generating
-- function MUST be SHAKE128 or SHAKE256 with an output length -- function MUST be SHAKE128 or SHAKE256 with an output length
-- of (n - 264) or (n - 520) bits respectively, where n -- of (n - 264) or (n - 520) bits respectively, where n
-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST
-- be 32 or 64 bytes respectively. The trailerField MUST be 1, -- be 32 or 64 bytes respectively. The trailerField MUST be 1,
skipping to change at page 14, line 47 skipping to change at page 14, line 47
-- the RSA public key MUST be encoded using the RSAPublicKey -- the RSA public key MUST be encoded using the RSAPublicKey
-- type. -- type.
-- From RFC4055, for reference. -- From RFC4055, for reference.
-- RSAPublicKey ::= SEQUENCE { -- RSAPublicKey ::= SEQUENCE {
-- modulus INTEGER, -- -- n -- modulus INTEGER, -- -- n
-- publicExponent INTEGER } -- -- e -- publicExponent INTEGER } -- -- e
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
sigAlgs(3) TBD } sigAlgs(3) TBD3 }
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
sigAlgs(3) TBD } sigAlgs(3) TBD4 }
-- When the id-ecdsa-with-shake* algorithm identifiers are -- When the id-ecdsa-with-shake* algorithm identifiers are
-- used in CMS, the AlgorithmIdentifier parameters field -- used in CMS, the AlgorithmIdentifier parameters field
-- MUST be absent and the signature algorithm should be -- MUST be absent and the signature algorithm should be
-- deterministric ECDSA [RFC6979]. The message digest MUST -- deterministic ECDSA [RFC6979]. The message digest MUST
-- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout
-- length respectively. In both cases, the ECDSA public key, -- length respectively. In both cases, the ECDSA public key,
-- MUST be encoded using the id-ecPublicKey type. -- MUST be encoded using the id-ecPublicKey type.
-- From RFC5480, for reference. -- From RFC5480, for reference.
-- id-ecPublicKey OBJECT IDENTIFIER ::= { -- id-ecPublicKey OBJECT IDENTIFIER ::= {
-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
-- The id-ecPublicKey parameters must be absent or present -- The id-ecPublicKey parameters must be absent or present
-- and are defined as -- and are defined as
-- ECParameters ::= CHOICE { -- ECParameters ::= CHOICE {
-- namedCurve OBJECT IDENTIFIER -- namedCurve OBJECT IDENTIFIER
 End of changes. 29 change blocks. 
47 lines changed or deleted 53 lines changed or added

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