draft-ietf-lamps-pkix-shake-02.txt | draft-ietf-lamps-pkix-shake-03.txt | |||
---|---|---|---|---|

LAMPS WG P. Kampanakis | LAMPS WG P. Kampanakis | |||

Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||

Intended status: Standards Track Q. Dang | Intended status: Standards Track Q. Dang | |||

Expires: December 31, 2018 NIST | Expires: April 22, 2019 NIST | |||

June 29, 2018 | October 19, 2018 | |||

Internet X.509 Public Key Infrastructure: Additional Algorithm | Internet X.509 Public Key Infrastructure: Additional Algorithm | |||

Identifiers for RSASSA-PSS and ECDSA using SHAKEs as Hash Functions | Identifiers for RSASSA-PSS and ECDSA using SHAKEs as Hash Functions | |||

draft-ietf-lamps-pkix-shake-02 | draft-ietf-lamps-pkix-shake-03 | |||

Abstract | Abstract | |||

Digital signatures are used to sign messages, X.509 certificates and | Digital signatures are used to sign messages, X.509 certificates and | |||

CRLs (Certificate Revocation Lists). This document describes the | CRLs (Certificate Revocation Lists). This document describes the | |||

conventions for using the SHAKE family of hash functions in the | conventions for using the SHAKE family of hash functions in the | |||

Internet X.509 as one-way hash functions with the RSA Probabilistic | Internet X.509 as one-way hash functions with the RSA Probabilistic | |||

Signature Scheme and ECDSA signature algorithms. The conventions for | Signature Scheme and ECDSA signature algorithms. The conventions for | |||

the associated subject public keys are also described. | the associated subject public keys 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 December 31, 2018. | This Internet-Draft will expire on April 22, 2019. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||

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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

4. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

4.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 4 | 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

4.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 5 | 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

4.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 5 | 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 5 | |||

4.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 6 | 5.1.2. Deterministic ECDSA Signatures . . . . . . . . . . . 6 | |||

4.2.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 6 | 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

4.2.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 7 | 5.2.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 7 | |||

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5.2.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 8 | |||

6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||

7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||

8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||

8.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

8.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||

Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 10 | 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 11 | |||

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-pkix-shake-03: | ||||

* Updates based on suggestions and clarifications by Jim. | ||||

* Added ASN.1. | ||||

o draft-ietf-lamps-pkix-shake-02: | o draft-ietf-lamps-pkix-shake-02: | |||

* Significant reorganization of the sections to simplify the | * Significant reorganization of the sections to simplify the | |||

introduction, the new OIDs and their use in PKIX. | introduction, the new OIDs and their use in PKIX. | |||

* Added new OIDs for RSASSA-PSS that hardcode hash, salt and MFG, | * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, | |||

according the WG consensus. | according the WG consensus. | |||

* Updated Public Key section to use the new RSASSA-PSS OIDs and | * Updated Public Key section to use the new RSASSA-PSS OIDs and | |||

clarify the algorithm identifier usage. | clarify the algorithm identifier usage. | |||

* Removed the no longer used SHAKE OIDs from section 3.1. | * Removed the no longer used SHAKE OIDs from section 3.1. | |||

* Consolidated subsection for message digest algorithms. | * Consolidated subsection for message digest algorithms. | |||

* Text fixes. | * Text fixes. | |||

skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 35 ¶ | |||

* Initial version | * Initial version | |||

2. Introduction | 2. Introduction | |||

This document describes several cryptographic algorithm identifiers | This document describes several cryptographic algorithm identifiers | |||

for several cryptographic algorithms which use variable length output | for several cryptographic algorithms which use variable length output | |||

SHAKE functions introduced in [SHA3] which can be used with the | SHAKE functions introduced in [SHA3] which can be used with the | |||

Internet X.509 Certificate and CRL profile [RFC5280]. | Internet X.509 Certificate and CRL profile [RFC5280]. | |||

The SHA-3 family of one-way hash functions is specified in [SHA3]. | The SHA-3 family of one-way hash functions is specified in [SHA3]. | |||

In the SHA-3 family, two extendable-output functions, called SHAKE128 | In the SHA-3 family, two extendable-output functions (SHAKEs): | |||

and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, | SHAKE128 and SHAKE256, are defined. Four other hash function | |||

SHA3-384, and SHA3-512 are also defined but are out of scope for this | instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also | |||

document. A SHAKE is a variable length hash function. The output | defined but are out of scope for this document. A SHAKE is a | |||

lengths, in bits, of the SHAKE hash functions are defined by the d | variable length hash function. The output length, in bits, of a | |||

parameter. The corresponding collision and preimage resistance | SHAKE is defined by the d parameter. The corresponding collision and | |||

security levels for SHAKE128 and SHAKE256 are respectively | second preimage resistance strengths for SHAKE128 are min(d/2,128) | |||

min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits. | and min(d,128) bits respectively. And, the corresponding collision | |||

and second preimage resistance strengths for SHAKE256 are | ||||

min(d/2,256) and min(d,256) bits respectively. | ||||

SHAKEs can be used as the message digest function (to hash the | A SHAKE can be used as the message digest function (to hash the | |||

message to be signed) and as the hash function in the mask generating | message to be signed) in RSASSA-PSS and ECDSA and as the hash in the | |||

functions in RSASSA-PSS and ECDSA. In this document, we define four | mask generating function in RSASSA-PSS. In Section 4, we define four | |||

new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 are used | new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 are | |||

as hash functions. The same algorithm identifiers are used for | used. The same algorithm identifiers are used for identifying a | |||

identifying a public key, and identifying a signature. | public key, and identifying a signature. | |||

3. Identifiers | 3. Terminology | |||

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]. | ||||

4. Identifiers | ||||

The new identifiers for RSASSA-PSS signatures using SHAKEs are below. | The new identifiers for RSASSA-PSS signatures using SHAKEs are below. | |||

id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } | id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } | |||

id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } | id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } | |||

[ EDNOTE: "TBD" will be specified by NIST later. ] | [ EDNOTE: "TBD" will be specified by NIST later. ] | |||

The new algorithm identifiers of ECDSA signatures using SHAKEs are | The new algorithm identifiers of ECDSA signatures using SHAKEs are | |||

below. | below. | |||

id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | |||

country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) | country(16) us(840) organization(1) gov(101) | |||

id-ecdsa-with-shake(3) TBD } | csor(3) algorithms(4) id-ecdsa-with-shake(3) | |||

TBD } | ||||

id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | |||

country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) | country(16) us(840) organization(1) gov(101) | |||

id-ecdsa-with-shake(3) TBD } | csor(3) algorithms(4) id-ecdsa-with-shake(3) | |||

TBD } | ||||

[ EDNOTE: "TBD" will be specified by NIST later. ] | [ EDNOTE: "TBD" will be specified by NIST later. ] | |||

The parameters for these four identifiers above MUST be absent. That | The parameters for these four identifiers above MUST be absent. That | |||

is, the identifier SHALL be a SEQUENCE of one component, the OID. | is, the identifier SHALL be a SEQUENCE of one component, the OID. | |||

4. Use in PKIX | Section 5.1.1 and Section 5.1.2 specify the required output length | |||

for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In | ||||

summary, when hashing messages to be signed, output lengths of | ||||

SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the | ||||

SHAKEs are used as mask generation functions, their output lengths | ||||

are (n - 264) or (n - 520) bits respectively, where n is a RSA | ||||

modulus size in bits. | ||||

4.1. Signatures | 5. Use in PKIX | |||

5.1. Signatures | ||||

Signatures can be placed in a number of different ASN.1 structures. | Signatures can be placed in a number of different ASN.1 structures. | |||

The top level structure for an X.509 certificate, to illustrate how | The top level structure for an X.509 certificate, to illustrate how | |||

signatures are frequently encoded with an algorithm identifier and a | signatures are frequently encoded with an algorithm identifier and a | |||

location for the signature, is | location for the signature, is | |||

Certificate ::= SEQUENCE { | Certificate ::= SEQUENCE { | |||

tbsCertificate TBSCertificate, | tbsCertificate TBSCertificate, | |||

signatureAlgorithm AlgorithmIdentifier, | signatureAlgorithm AlgorithmIdentifier, | |||

signatureValue BIT STRING } | signatureValue BIT STRING } | |||

The identifiers defined in Section 3 can be used as the | The identifiers defined in Section 4 can be used as the | |||

AlgorithmIdentifier in the signatureAlgorithm field in the sequence | AlgorithmIdentifier in the signatureAlgorithm field in the sequence | |||

Certificate and the signature field in the sequence tbsCertificate in | Certificate and the signature field in the sequence tbsCertificate in | |||

X.509 [RFC3280]. | X.509 [RFC5280]. | |||

Conforming CA implementations MUST specify the algorithms explicitly | Conforming CA implementations MUST specify the algorithms explicitly | |||

by using the OIDs specified in Section 3 when encoding RSASSA-PSS and | by using the OIDs specified in Section 4 when encoding RSASSA-PSS and | |||

ECDSA with SHAKE signatures, and public keys in certificates and | ECDSA with SHAKE signatures in certificates and CRLs. Encoding rules | |||

CRLs. Encoding rules for RSASSA-PSS and ECDSA signature values are | for RSASSA-PSS and ECDSA signature values are specified in [RFC4055] | |||

specified in [RFC4055] and [RFC5480] respectively. | and [RFC5480] respectively. | |||

Conforming client implementations that process RSASSA-PSS and ECDSA | Conforming client implementations that process RSASSA-PSS and ECDSA | |||

with SHAKE signatures when processing certificates and CRLs MUST | with SHAKE signatures when processing certificates and CRLs MUST | |||

recognize the corresponding OIDs. | recognize the corresponding OIDs. | |||

4.1.1. RSASSA-PSS Signatures | 5.1.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 4 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. | PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. | |||

The hash algorithm to hash a message being signed and the hash | The hash algorithm to hash a message being signed and the hash | |||

algorithm in the maskGenAlgorithm used in RSASSA-PSS MUST be the | algorithm as the mask generation function "MGF(H, emLen - hLen - 1)" | |||

same, SHAKE128 or SHAKE256 respectively. The output-length of the | [RFC8017] used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 | |||

hash algorithm which hashes the message SHALL be 32 or 64 bytes | respectively. The output-length of the hash algorithm which hashes | |||

respectively. | the message SHALL be 32 or 64 bytes respectively. | |||

The maskGenAlgorithm is the MGF1 specified in Section B.2.1 of | In RSASSA-PSS, a mask generation function takes an octet string of | |||

[RFC8017]. The output length for SHAKE128 or SHAKE256 being used as | variable length and a desired output length as input, and outputs an | |||

the hash function in MGF1 is (n - 264)/8 or (n - 520)/8 bytes | octet string of the desired length. In RSASSA-PSS with SHAKES, the | |||

respectively, where n is the RSA modulus in bits. For example, when | SHAKEs MUST be used natively as the MGF function, instead of the MGF1 | |||

RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 in | algorithm that uses the hash function in multiple iterations as | |||

the MGF1 will be 223 or 191 when id-RSASSA-PSS-SHAKE128 or id-RSASSA- | specified in Section B.2.1 of [RFC8017]. In other words, the MGF is | |||

PSS-SHAKE256 is used respectively. | defined as | |||

SHAKE128(mgfSeed, maskLen) | ||||

and | ||||

SHAKE256(mgfSeed, maskLen) | ||||

respectively for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256. | ||||

The mgfSeed is the seed from which mask is generated, an octet | ||||

string. The maskLen for SHAKE128 or SHAKE256 being used as the MGF | ||||

is (n - 264)/8 or (n - 520)/8 bytes respectively, where n is the RSA | ||||

modulus in bits. For example, when RSA modulus n is 2048, the output | ||||

length of SHAKE128 or SHAKE256 as the MGF will be 223 or 191 when id- | ||||

RSASSA-PSS-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.1.2. ECDSA Signatures | 5.1.2. Deterministic 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 4) algorithm identifier appears, the respective | |||

SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The | SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The | |||

encoding MUST omit the parameters field. That is, the | encoding MUST omit the parameters field. That is, the | |||

AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- | AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- | |||

ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. | ecdsa-with-SHAKE128 or id-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. | |||

Conforming CA implementations that generate ECDSA with SHAKE | Conforming CA implementations that generate ECDSA with SHAKE | |||

signatures in certificates or CRLs MUST generate such signatures in | signatures in certificates or CRLs MUST generate such signatures with | |||

accordance with all the requirements specified in Sections 7.2 and | a deterministicly generated, non-random k in accordance with all the | |||

7.3 of [X9.62] or with all the requirements specified in | requirements specified in [RFC6979]. They MAY also generate such | |||

Section 4.1.3 of [SEC1]. They MAY also generate such signatures in | signatures in accordance with all other recommendations in [X9.62] or | |||

accordance with all the recommendations in [X9.62] or [SEC1] if they | [SEC1] if they have a stated policy that requires conformance to | |||

have a stated policy that requires conformance to these standards. | these standards. These standards may have not specified SHAKE128 and | |||

These standards may have not specified SHAKE128 and SHAKE256 as hash | SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 | |||

algorithm options. However, SHAKE128 and SHAKE256 with output length | with output length being 32 and 64 octets respectively are | |||

being 32 and 64 octets respectively are subtitutions for 256 and | subtitutions for 256 and 512-bit output hash algorithms such as | |||

512-bit output hash algorithms such as SHA256 and SHA512 used in the | SHA256 and SHA512 used in the standards. | |||

standards. | ||||

4.2. Public Keys | In Section 3.2 "Generation of k" of [RFC6979], HMAC is used to derive | |||

the deterministic k. Conforming implementations that generate | ||||

deterministic ECDSA with SHAKE signatures in X.509 MUST use KMAC with | ||||

SHAKE128 or KMAC with SHAKE256 as specfied in [SP800-185] when | ||||

SHAKE128 or SHAKE256 is used as the message hashing algorithm, | ||||

respectively. In this situation, KMAC with SHAKE128 and KMAC with | ||||

SHAKE256 have 256-bit and 512-bit outputs respectively, and the | ||||

optional customization bit string S is an empty string. | ||||

5.2. Public Keys | ||||

Certificates conforming to [RFC5280] can convey a public key for any | Certificates conforming to [RFC5280] can convey a public key for any | |||

public key algorithm. The certificate indicates the algorithm | public key algorithm. The certificate indicates the algorithm | |||

through an algorithm identifier. This algorithm identifier is an OID | through an algorithm identifier. This algorithm identifier is an OID | |||

and optionally associated parameters. | and optionally associated parameters. | |||

In the X.509 certificate, the subjectPublicKeyInfo field has the | In the X.509 certificate, the subjectPublicKeyInfo field has the | |||

SubjectPublicKeyInfo type, which has the following ASN.1 syntax: | SubjectPublicKeyInfo type, which has the following ASN.1 syntax: | |||

SubjectPublicKeyInfo ::= SEQUENCE { | SubjectPublicKeyInfo ::= SEQUENCE { | |||

skipping to change at page 6, line 38 ¶ | skipping to change at page 7, line 38 ¶ | |||

The fields in SubjectPublicKeyInfo have the following meanings: | The fields in SubjectPublicKeyInfo have the following meanings: | |||

o algorithm is the algorithm identifier and parameters for the | o algorithm is the algorithm identifier and parameters for the | |||

public key. | public key. | |||

o subjectPublicKey contains the byte stream of the public key. The | o subjectPublicKey contains the byte stream of the public key. The | |||

algorithms defined in this document always encode the public key | algorithms defined in this document always encode the public key | |||

as an exact multiple of 8-bits. | as an exact multiple of 8-bits. | |||

The conventions for RSASSA-PSS and ECDSA public keys algorithm | Conforming CA implementations MUST specify the algorithms explicitly | |||

by using the OIDs specified in Section 4 when encoding RSASSA-PSS and | ||||

ECDSA with SHAKE public keys in certificates and CRLs. The | ||||

conventions for RSASSA-PSS and ECDSA public keys algorithm | ||||

identifiers are as specified in [RFC3279], [RFC4055] and [RFC5480] , | identifiers are as specified in [RFC3279], [RFC4055] and [RFC5480] , | |||

but we include them below for convenience. | but we include them below for convenience. | |||

4.2.1. RSASSA-PSS Public Keys | 5.2.1. RSASSA-PSS Public Keys | |||

[RFC3279] defines the following OID for RSA AlgorithmIdentifier in | [RFC3279] defines the following OID for RSA AlgorithmIdentifier in | |||

the SubjectPublicKeyInfo with NULL parameters. | the SubjectPublicKeyInfo with NULL parameters. | |||

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} | rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} | |||

Additionally, when the RSA private key owner wishes to limit the use | Additionally, when the RSA private key owner wishes to limit the use | |||

of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifiers | of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifiers | |||

for RSASSA-PSS defined in Section 3 can be used as the algorithm | for RSASSA-PSS defined in Section 4 can be used as the algorithm | |||

field in the SubjectPublicKeyInfo sequence [RFC3280]. The identifier | field in the SubjectPublicKeyInfo sequence [RFC5280]. The identifier | |||

parameters, as explained in section Section 3, MUST be absent. | parameters, as explained in section Section 4, MUST be absent. | |||

Regardless of what public key algorithm identifier is used, the RSA | Regardless of what public key algorithm identifier is used, the RSA | |||

public key, which is composed of a modulus and a public exponent, | public key, which is composed of a modulus and a public exponent, | |||

MUST be encoded using the RSAPublicKey type [RFC4055]. The output of | MUST be encoded using the RSAPublicKey type [RFC4055]. The output of | |||

this encoding is carried in the certificate subjectPublicKey. | this encoding is carried in the certificate subjectPublicKey. | |||

RSAPublicKey ::= SEQUENCE { | RSAPublicKey ::= SEQUENCE { | |||

modulus INTEGER, -- n | modulus INTEGER, -- n | |||

publicExponent INTEGER -- e | publicExponent INTEGER -- e | |||

} | } | |||

4.2.2. ECDSA Public Keys | 5.2.2. ECDSA Public Keys | |||

For ECDSA, when id-ecdsa-with-shake128 or id-ecdsa-with-shake256 is | For ECDSA, the public key identifier defined in [RFC5480] is | |||

used as the AlgorithmIdentifier in the algorithm field of | ||||

SubjectPublicKeyInfo, the parameters, as explained in section | id-ecPublicKey OBJECT IDENTIFIER ::= { | |||

Section 3, MUST be absent. | iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } | |||

Additionally, the mandatory EC SubjectPublicKey is defined in | Additionally, the mandatory EC SubjectPublicKey is defined in | |||

Section 2.1.1 and its syntax is in Section 2.2 of [RFC5480]. We also | Section 2.1.1 and its syntax is in Section 2.2 of [RFC5480]. We also | |||

include them here for convenience: | include them here for convenience: | |||

id-ecPublicKey OBJECT IDENTIFIER ::= { | ||||

iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } | ||||

The id-ecPublicKey parameters MUST be present and are defined as | The id-ecPublicKey parameters MUST be present and are defined as | |||

ECParameters ::= CHOICE { | ECParameters ::= CHOICE { | |||

namedCurve OBJECT IDENTIFIER | namedCurve OBJECT IDENTIFIER | |||

-- implicitCurve NULL | -- implicitCurve NULL | |||

-- specifiedCurve SpecifiedECDomain | -- specifiedCurve SpecifiedECDomain | |||

} | } | |||

The ECParameters associated with the ECDSA public key in the signer's | The ECParameters associated with the ECDSA public key in the signer's | |||

certificate SHALL apply to the verification of the signature. | certificate SHALL apply to the verification of the signature. | |||

5. IANA Considerations | 6. IANA Considerations | |||

This document uses several new registries [ EDNOTE: Update here. ] | [ EDNOTE: Update here only if there are OID allocations by IANA. ] | |||

6. Security Considerations | This document has no IANA actions. | |||

7. Security Considerations | ||||

The SHAKEs are deterministic functions. Like any other deterministic | The SHAKEs are deterministic functions. Like any other deterministic | |||

functions, executing each function with the same input multiple times | functions, executing each function with the same input multiple times | |||

will produce the same output. Therefore, users should not expect | will produce the same output. Therefore, users should not expect | |||

unrelated outputs (with the same or different output lengths) from | unrelated outputs (with the same or different output lengths) from | |||

excuting a SHAKE function with the same input multiple times. | excuting a SHAKE function with the same input multiple times.The | |||

shorter one of any 2 outputs produced from a SHAKE with the same | ||||

input is a prefix of the longer one. It is a similar situation as | ||||

truncating a 512-bit output of SHA-512 by taking its 256 left-most | ||||

bits. These 256 left-most bits are a prefix of the 512-bit output. | ||||

Implementations must protect the signer's private key. Compromise of | Implementations must protect the signer's private key. Compromise of | |||

the signer's private key permits masquerade. | the signer's private key permits masquerade. | |||

Implementations must randomly generate one-time values, such as the k | Implementations must randomly generate one-time values, such as the k | |||

value when generating a ECDSA signature. In addition, the generation | value when generating a ECDSA signature. In addition, the generation | |||

of public/private key pairs relies on random numbers. The use of | of public/private key pairs relies on random numbers. The use of | |||

inadequate pseudo-random number generators (PRNGs) to generate such | inadequate pseudo-random number generators (PRNGs) to generate such | |||

cryptographic values can result in little or no security. The | cryptographic values can result in little or no security. The | |||

generation of quality random numbers is difficult. [RFC4086] offers | generation of quality random numbers is difficult. [RFC4086] offers | |||

skipping to change at page 8, line 28 ¶ | skipping to change at page 9, line 38 ¶ | |||

Implementers should be aware that cryptographic algorithms may become | Implementers should be aware that cryptographic algorithms may become | |||

weaker with time. As new cryptanalysis techniques are developed and | weaker with time. As new cryptanalysis techniques are developed and | |||

computing power increases, the work factor or time required to break | computing power increases, the work factor or time required to break | |||

a particular cryptographic algorithm may decrease. Therefore, | a particular cryptographic algorithm may decrease. Therefore, | |||

cryptographic algorithm implementations should be modular allowing | cryptographic algorithm implementations should be modular allowing | |||

new algorithms to be readily inserted. That is, implementers should | new algorithms to be readily inserted. That is, implementers should | |||

be prepared to regularly update the set of algorithms in their | be prepared to regularly update the set of algorithms in their | |||

implementations. | implementations. | |||

7. Acknowledgements | 8. Acknowledgements | |||

We would like to thank Sean Turner for his valuable contributions to | We would like to thank Sean Turner and Jim Schaad for his valuable | |||

this document. | contributions to this document. | |||

8. References | 9. References | |||

8.1. Normative References | 9.1. Normative References | |||

[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

X.509 Public Key Infrastructure Certificate and | Requirement Levels", BCP 14, RFC 2119, | |||

Certificate Revocation List (CRL) Profile", RFC 3280, | DOI 10.17487/RFC2119, March 1997, | |||

DOI 10.17487/RFC3280, April 2002, | <https://www.rfc-editor.org/info/rfc2119>. | |||

<https://www.rfc-editor.org/info/rfc3280>. | ||||

[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>. | |||

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||

Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||

skipping to change at page 9, line 27 ¶ | skipping to change at page 10, line 34 ¶ | |||

"PKCS #1: RSA Cryptography Specifications Version 2.2", | "PKCS #1: RSA Cryptography Specifications Version 2.2", | |||

RFC 8017, DOI 10.17487/RFC8017, November 2016, | RFC 8017, DOI 10.17487/RFC8017, November 2016, | |||

<https://www.rfc-editor.org/info/rfc8017>. | <https://www.rfc-editor.org/info/rfc8017>. | |||

[SHA3] National Institute of Standards and Technology, "SHA-3 | [SHA3] National Institute of Standards and Technology, "SHA-3 | |||

Standard - Permutation-Based Hash and Extendable-Output | Standard - Permutation-Based Hash and Extendable-Output | |||

Functions FIPS PUB 202", August 2015, | Functions FIPS PUB 202", August 2015, | |||

<https://www.nist.gov/publications/sha-3-standard- | <https://www.nist.gov/publications/sha-3-standard- | |||

permutation-based-hash-and-extendable-output-functions>. | permutation-based-hash-and-extendable-output-functions>. | |||

8.2. Informative References | 9.2. Informative References | |||

[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and | [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and | |||

Identifiers for the Internet X.509 Public Key | Identifiers for the Internet X.509 Public Key | |||

Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||

(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April | (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April | |||

2002, <https://www.rfc-editor.org/info/rfc3279>. | 2002, <https://www.rfc-editor.org/info/rfc3279>. | |||

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||

"Randomness Requirements for Security", BCP 106, RFC 4086, | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||

DOI 10.17487/RFC4086, June 2005, | DOI 10.17487/RFC4086, June 2005, | |||

<https://www.rfc-editor.org/info/rfc4086>. | <https://www.rfc-editor.org/info/rfc4086>. | |||

[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | ||||

Algorithm (DSA) and Elliptic Curve Digital Signature | ||||

Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | ||||

2013, <https://www.rfc-editor.org/info/rfc6979>. | ||||

[SEC1] Standards for Efficient Cryptography Group, "SEC 1: | [SEC1] Standards for Efficient Cryptography Group, "SEC 1: | |||

Elliptic Curve Cryptography", May 2009, | Elliptic Curve Cryptography", May 2009, | |||

<http://www.secg.org/sec1-v2.pdf>. | <http://www.secg.org/sec1-v2.pdf>. | |||

[SP800-185] | ||||

National Institute of Standards and Technology, "SHA-3 | ||||

Derived Functions: cSHAKE, KMAC, TupleHash and | ||||

ParallelHash. NIST SP 800-185", December 2016, | ||||

<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | ||||

NIST.SP.800-185.pdf>. | ||||

[SP800-90A] | [SP800-90A] | |||

National Institute of Standards and Technology, | National Institute of Standards and Technology, | |||

"Recommendation for Random Number Generation Using | "Recommendation for Random Number Generation Using | |||

Deterministic Random Bit Generators. NIST SP 800-90A", | Deterministic Random Bit Generators. NIST SP 800-90A", | |||

June 2015, | June 2015, | |||

<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | |||

NIST.SP.800-90Ar1.pdf>. | NIST.SP.800-90Ar1.pdf>. | |||

[X9.62] American National Standard for Financial Services (ANSI), | [X9.62] American National Standard for Financial Services (ANSI), | |||

"X9.62-2005 Public Key Cryptography for the Financial | "X9.62-2005 Public Key Cryptography for the Financial | |||

Services Industry: The Elliptic Curve Digital Signature | Services Industry: The Elliptic Curve Digital Signature | |||

Standard (ECDSA)", November 2005. | Standard (ECDSA)", November 2005. | |||

Appendix A. ASN.1 module | Appendix A. ASN.1 module | |||

[ EDNOTE: More here. ] | This appendix includes the ASN.1 modules for SHAKEs in X.509. This | |||

module does not come from any existing RFC. | ||||

PKIXAlgsForSHAKE-2018 { iso(1) identified-organization(3) dod(6) | ||||

internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) | ||||

id-mod-pkix1-shake-2018(TBD) } | ||||

DEFINITIONS EXPLICIT TAGS ::= | ||||

BEGIN | ||||

-- EXPORTS ALL; | ||||

IMPORTS | ||||

-- FROM [RFC5912] | ||||

PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, MAC-ALGORITHM, | ||||

SMIME-CAPS | ||||

FROM AlgorithmInformation-2009 | ||||

{ iso(1) identified-organization(3) dod(6) internet(1) security(5) | ||||

mechanisms(5) pkix(7) id-mod(0) | ||||

id-mod-algorithmInformation-02(58) } | ||||

-- FROM [RFC5912] | ||||

id-RSASSA-PSS, RSAPublicKey, rsaEncryption, id-ecPublicKey, | ||||

ECPoint, ECDSA-Sig-Value | ||||

FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) | ||||

internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) | ||||

id-mod-pkix1-algorithms2008-02(56) } | ||||

-- | ||||

-- One-Way Hash Functions | ||||

-- SHAKE128 | ||||

mda-shake128 DIGEST-ALGORITHM ::= { | ||||

IDENTIFIER id-shake128 -- with output length 32 bytes. | ||||

} | ||||

id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | ||||

us(840) organization(1) gov(101) | ||||

csor(3) nistAlgorithm(4) | ||||

hashAlgs(2) 11 } | ||||

-- SHAKE-256 | ||||

mda-shake256 DIGEST-ALGORITHM ::= { | ||||

IDENTIFIER id-shake256 -- with output length 64 bytes. | ||||

} | ||||

id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | ||||

us(840) organization(1) gov(101) | ||||

csor(3) nistAlgorithm(4) | ||||

hashAlgs(2) 12 } | ||||

-- | ||||

-- Public Key (pk-) Algorithms | ||||

-- | ||||

PublicKeys PUBLIC-KEY ::= { | ||||

..., | ||||

pk-rsaSSA-PSS-SHAKE128 | | ||||

pk-rsaSSA-PSS-SHAKE256 | | ||||

pk-ec, | ||||

... | ||||

} | ||||

-- From [RFC5912] - Here so it compiles. | ||||

pk-rsa PUBLIC-KEY ::= { | ||||

IDENTIFIER rsaEncryption | ||||

KEY RSAPublicKey | ||||

PARAMS TYPE NULL ARE absent | ||||

-- Private key format not in this module -- | ||||

CERT-KEY-USAGE {digitalSignature, nonRepudiation, | ||||

keyEncipherment, dataEncipherment, keyCertSign, cRLSign} | ||||

} | ||||

-- The hashAlgorithm is mda-shake128 | ||||

-- The maskGenAlgorithm is mda-shake128 | ||||

-- Mask Gen Algorithm is SHAKE128 with output length | ||||

-- (n - 264)/8, where n is the RSA modulus in bits. | ||||

-- the saltLength is 32 | ||||

-- the trailerField is 1 | ||||

pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { | ||||

IDENTIFIER id-RSASSA-PSS-SHAKE128 | ||||

KEY RSAPublicKey | ||||

PARAMS TYPE NULL ARE absent | ||||

-- Private key format not in this module -- | ||||

CERT-KEY-USAGE { nonRepudiation, digitalSignature, | ||||

keyCertSign, cRLSign } | ||||

} | ||||

-- The hashAlgorithm is mda-shake256 | ||||

-- The maskGenAlgorithm is mda-shake256 | ||||

-- Mask Gen Algorithm is SHAKE256 with output length | ||||

-- (n - 520)/8, where n is the RSA modulus in bits. | ||||

-- the saltLength is 64 | ||||

-- the trailerField is 1 | ||||

pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { | ||||

IDENTIFIER id-RSASSA-PSS-SHAKE256 | ||||

KEY RSAPublicKey | ||||

PARAMS TYPE NULL ARE absent | ||||

-- Private key format not in this module -- | ||||

CERT-KEY-USAGE { nonRepudiation, digitalSignature, | ||||

keyCertSign, cRLSign } | ||||

} | ||||

pk-ec PUBLIC-KEY ::= { | ||||

IDENTIFIER id-ecPublicKey | ||||

KEY ECPoint | ||||

PARAMS TYPE ECParameters ARE required | ||||

-- Private key format not in this module -- | ||||

CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyAgreement, | ||||

keyCertSign, cRLSign } | ||||

} | ||||

ECParameters ::= CHOICE { | ||||

namedCurve CURVE.&id({NamedCurve}) | ||||

-- implicitCurve NULL | ||||

-- implicitCurve MUST NOT be used in PKIX | ||||

-- specifiedCurve SpecifiedCurve | ||||

-- specifiedCurve MUST NOT be used in PKIX | ||||

-- Details for specifiedCurve can be found in [X9.62] | ||||

-- Any future additions to this CHOICE should be coordinated | ||||

-- with ANSI X.9. | ||||

} | ||||

-- | ||||

-- Signature Algorithms (sa-) | ||||

-- | ||||

SignatureAlgs SIGNATURE-ALGORITHM ::= { | ||||

..., | ||||

-- This expands SignatureAlgorithms from [RFC5912] | ||||

sa-rsassapssWithSHAKE128 | | ||||

sa-rsassapssWithSHAKE256 | | ||||

sa-ecdsaWithSHAKE128 | | ||||

sa-ecdsaWithSHAKE256 | ||||

} | ||||

-- | ||||

-- SMIME Capabilities (sa-) | ||||

-- | ||||

SMimeCaps SMIME-CAPS ::= { | ||||

..., | ||||

-- The expands SMimeCaps from [RFC5912] | ||||

sa-rsassapssWithSHAKE128.&smimeCaps | | ||||

sa-rsassapssWithSHAKE256.&smimeCaps | | ||||

sa-ecdsaWithSHAKE128.&smimeCaps | | ||||

sa-ecdsaWithSHAKE256.&smimeCaps | ||||

} | ||||

-- RSASSA-PSS with SHAKE128 | ||||

sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { | ||||

IDENTIFIER id-RSASSA-PSS-SHAKE128 | ||||

PARAMS TYPE NULL ARE absent | ||||

-- The hashAlgorithm is mda-shake128 | ||||

-- The maskGenAlgorithm is mda-shake128 | ||||

-- Mask Gen Algorithm is SHAKE128 with output length | ||||

-- (n - 264)/8, where n is the RSA modulus in bits. | ||||

-- the saltLength is 32 | ||||

-- the trailerField is 1 | ||||

HASHES {mda-shake128} -- omitting mda-shake128-params | ||||

PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } | ||||

SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } | ||||

} | ||||

id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } | ||||

-- RSASSA-PSS with SHAKE256 | ||||

sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { | ||||

IDENTIFIER id-RSASSA-PSS-SHAKE256 | ||||

PARAMS TYPE NULL ARE absent | ||||

-- The hashAlgorithm is mda-shake256 | ||||

-- The maskGenAlgorithm is mda-shake256 | ||||

-- Mask Gen Algorithm is SHAKE256 with output length | ||||

-- (n - 520)/8, where n is the RSA modulus in bits. | ||||

-- the saltLength is 64 | ||||

-- the trailerField is 1 | ||||

HASHES {mda-shake256} -- omitting mda-shake256-params | ||||

PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } | ||||

SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } | ||||

} | ||||

id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } | ||||

-- Determinstic ECDSA with SHAKE128 | ||||

-- Generating k by using KMAC with SHAKE128 as the hash | ||||

-- [SP800-185] instead of HMAC with output length 256-bits | ||||

-- that is equal to or slightly less than the elliptic | ||||

-- curve group order. S is set to an empty string. | ||||

sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { | ||||

IDENTIFIER id-ecdsa-with-shake128 | ||||

VALUE ECDSA-Sig-Value | ||||

PARAMS TYPE NULL ARE absent | ||||

HASHES { mda-shake128 } | ||||

PUBLIC-KEYS { pk-ec } | ||||

SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } | ||||

} | ||||

id-ecdsa-with-shake128 ::= { joint-iso-itu-t(2) country(16) | ||||

us(840) organization(1) gov(101) | ||||

csor(3) nistAlgorithm(4) | ||||

sigAlgs(3) TBD } | ||||

-- Determinstic ECDSA with SHAKE256 | ||||

-- Generating k by using KMAC with SHAKE256 as the hash | ||||

-- [SP800-185] instead of HMAC with output length 512-bits | ||||

-- truncated to equal to or slightly less than the elliptic | ||||

-- curve group order. S is set to an empty string. | ||||

sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { | ||||

IDENTIFIER id-ecdsa-with-shake256 | ||||

VALUE ECDSA-Sig-Value | ||||

PARAMS TYPE NULL ARE absent | ||||

HASHES { mda-shake256 } | ||||

PUBLIC-KEYS { pk-ec } | ||||

SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } | ||||

} | ||||

id-ecdsa-with-shake256 ::= { joint-iso-itu-t(2) country(16) | ||||

us(840) organization(1) gov(101) | ||||

csor(3) nistAlgorithm(4) | ||||

sigAlgs(3) TBD } | ||||

END | ||||

Authors' Addresses | Authors' Addresses | |||

Panos Kampanakis | Panos Kampanakis | |||

Cisco Systems | Cisco Systems | |||

Email: pkampana@cisco.com | Email: pkampana@cisco.com | |||

Quynh Dang | Quynh Dang | |||

NIST | NIST | |||

End of changes. 45 change blocks. | ||||

107 lines changed or deleted | | 387 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/ |