Internet DRAFT - draft-pereira-pq-signature-oids
draft-pereira-pq-signature-oids
Network Working Group G. C. F. Pereira
Internet-Draft evolutionQ / IQC, UWaterloo
Updates: 3279 (if approved) November 20, 2019
Intended status: Informational
Expires: May 23, 2020
Internet X.509 Public Key Infrastructure: Additional Post-Quantum
Signature Algorithms and Identifiers
draft-pereira-pq-signature-oids-00
Abstract
This document updates RFC 3279 by specifying additional algorithm
identifiers and ASN.1 encoding rules for the nine selected post-
quantum digital signature algorithms running in the second round of
NIST standardization process when using SHA3 or SHAKE as the
underlying hashing algorithms. This specification applies (but it is
not limited to) to the Internet X.509 Public Key infrastructure (PKI)
and its post-quantum counterpart (not yet standardized), when post-
quantum digital signatures are used to sign certificates and
certificate revocation lists (CRLs).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 23, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
C. F. Pereira Expires May 23, 2020 [Page 1]
Internet-Draft pereira-pq-signature-oids November 2019
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Hash Functions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Post-quantum Digital Signature Algorithms . . . . . . . . . . 5
3.1. CRYSTALS-Dilithium Signature . . . . . . . . . . . . . . 5
3.2. FALCON Signature . . . . . . . . . . . . . . . . . . . . 5
3.3. GeMSS Signature . . . . . . . . . . . . . . . . . . . . . 6
3.4. LUOV Signature . . . . . . . . . . . . . . . . . . . . . 7
3.5. MQDSS Signature . . . . . . . . . . . . . . . . . . . . . 7
3.6. PICNIC Signature . . . . . . . . . . . . . . . . . . . . 8
3.7. qTesla Signatures . . . . . . . . . . . . . . . . . . . . 8
3.8. Rainbow Signatures . . . . . . . . . . . . . . . . . . . 9
3.9. SPHINCS+ Signature . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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].
This document profiles material under standardization by the NIST
Post-Quantum Cryptography standardization process [NIST-PQ]. In
particular, it provides the definition of algorithm identifiers and
ASN.1 encoding formats for post-quantum digital signatures and
subject public keys used in a post-quantum setting (not yet
standardized) of the Internet X.509 Public Key Infrastructure (PKI)
[RFC5280]. The nine digital signature algorithm candidates in the
second round of the NIST process are considered along with their
multiple security categories. Although not all nine algorithms may
become actual standards, this specification will certainly cover the
standardized ones. This way, implementors can run experiments with
C. F. Pereira Expires May 23, 2020 [Page 2]
Internet-Draft pereira-pq-signature-oids November 2019
interoperable OIDs in order to evaluate the new post-quantum
algorithms.
Precisely, this document defines additional contents for the
"signatureAlgorithm", "signatureValue", "signature" and
"subjectPublicKeyInfo" fields within Internet X.509 certificates and
CRLs [RFC5280] when these objects are signed using pure post-quantum
signature algorithms with SHA3 or SHAKE hash algorithms [FIPS202].
The SHA3 and SHAKE instances explicitly used in the object
identifiers (OID) definitions are the ones adopted by the NIST second
round candidates.
This document does not identify (optional) parameters for each
algorithm identifier. This is because the ongoing candidates are
likely to change parameter sets in the coming years and this document
rather focuses on high-level identifiers.
The OIDs provided are suggested to go under the NIST signature
algorithm arc in the OID tree [NIST-OIDS], i.e.:
joint-iso-itu-t(2) - country(16) - us(840) - organization(1) -
gov(101) - csor(3) - nistAlgorithm(4) - sigAlgs(4).
Note that the field sigAlgs already contains identifiers ranging from
1 to 16, allocated for (EC)DSA and RSA. In this specification
identifiers starting from 20 and above are reserved for the post-
quantum signatures with their different parameter sets.
This document extends [RFC3279] that defines algorithm identifiers
for classical signatures, and complements the update [RFC5758], which
focuses on the specification of OIDs for extra classical signatures.
1.1. Terminology
o B: bytes
o CRL: Certificate Revocation List
o KiB: Kibibytes
o MiB: Mibibytes
o NIST: National Institute of Standards and Technology.
o OID: Object Identifier
o SHA3: Secure Hash Algorithm-3
C. F. Pereira Expires May 23, 2020 [Page 3]
Internet-Draft pereira-pq-signature-oids November 2019
o XOF: eXtendable-Output hash Function
2. Hash Functions
This section identifies hash functions for use with post-quantum
digital signature algorithms. The hash functions SHA3-256, SHA3-384,
SHA3-512 produce 256-bit, 384-bit and 512-bit outputs, respectively.
On the other hand, functions SHAKE-128 and SHAKE-256 provide
extendable (and thus variable) output sizes. They are all described
in the "Secure Hash Standard" [FIPS202]. It is important to note
that most of signature candidates in the NIST process adopt SHAKE
which is the eXtendable-Output Function (XOF) of SHA3. The OIDs for
SHAKE instances are retrieved from [NIST-OIDS]. The hash functions
adopted by the NIST candidates have the following OIDs:
id-sha3-256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2)
8 }
id-sha3-384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2)
9 }
id-sha3-512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2)
10 }
id-shake-128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2)
11} }
id-shake-256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2)
12} }
Where id-sha3-<output size> refers to the Permutation-Based Hash
functions and id-shake-<output size> to the eXtendable-Output Hash
functions defined in [FIPS202]. When one of these OIDs appears in an
AlgorithmIdentifier, all implementations MUST accept both NULL and
absent parameters as legal and equivalent encodings. Conforming
certification authority (CA) implementations SHOULD use SHA3-256,
SHA3-384, SHA3-512, SHAKE-128 or SHAKE-256 when generating post-
quantum certificates or CRLs.
C. F. Pereira Expires May 23, 2020 [Page 4]
Internet-Draft pereira-pq-signature-oids November 2019
3. Post-quantum Digital Signature Algorithms
This section defines OIDs for the following signature algorithms:
Crystals-Dilithium, Falcon, GeMSS, LUOV, MQDSS, PICNIC, qTESLA,
Rainbow and SPHINCS+ when instantiated with SHA3-256, SHA3-384,
SHA3-512, SHAKE-128 or SHAKE-256. Note that each algorithm can offer
parameter sets for at most five quantum security categories (numbered
1 to 5), as suggested by NIST [NIST-PQ]. Moreover, different
category parameters may use the same hash output size, differently
from conventional elliptic curve-based signatures where the hash size
indicates the security level.
3.1. CRYSTALS-Dilithium Signature
CRYSTALS-Dilithium is a digital signature whose security is based on
the hardness of lattice problems [CRYSTALS-Dilithium]. It provides
four parameter sets for the security categories 1, 2, 3 and 4, and
offers a comparatively small footprint for the public key + signature
size combination, which ranges from 2 to 5 KiB. All operations
(KeyGen, Sign and Verify) are relatively quite efficient to compute
(hundreds of Kcycles using AVX2 instructions). CRYSTALS-Dilithium
SHALL be used in conjunction with SHAKE-256 for all security
categories above.
When SHAKE-256 is used, the OIDs are:
id-dilithium-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dilithium-shake(3) 20 }.
When the id-dilithium-shake256 identifier appears in the algorithm
field as an AlgorithmIdentifier, the encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-dilithium-shake256.
3.2. FALCON Signature
FALCON is a digital signature whose security is based on the hardness
of lattice problems [FALCON-ref]. Authors provide two parameter sets
for security categories 1 and somewhere between 4-5. FALCON offers
relatively small footprints for the public key + signature size
metric, which ranges from about 1.5-3.0 KiB. In terms of
computational efficiency, KeyGen is relatively slow (tens of
Mcycles), Sign is moderate (hundreds of Kcycles) and Verify is
relatively fast (hundreds of Kcycles). FALCON SHALL be used in
conjunction with SHAKE-256 for all security categories above.
When SHAKE-256 is used, the OIDs are:
C. F. Pereira Expires May 23, 2020 [Page 5]
Internet-Draft pereira-pq-signature-oids November 2019
id-falcon-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-falcon-shake(3) 21 }.
When the id-falcon-shake256 algorithm identifier appears in the
algorithm field as an AlgorithmIdentifier, the encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-falcon-shake256.
3.3. GeMSS Signature
GeMSS is a digital signature whose security is based on the hardness
of solving non-linear systems of multivariate equations over finite
fields [GeMSS-ref]. It provides nine parameter sets, three for each
one of the security categories 1, 3 and 5. GeMSS uses a name
convention to distinguish between the three parameter sets within a
category, i.e., GeMSS, BlueGeMSS and RedGeMSS. In terms of space,
public-keys are relatively large (about 400 KiB - 3 MiB) but
signatures are very small (about 33-75 B). In terms of computational
efficiency, KeyGen is relatively slow (hundreds of Mcycles), Sign is
moderate (few million cycles) and Verify is relatively fast (hundreds
of Kcycles). GeMSS SHALL be used in conjunction with a SHA3 hash
function with output sizes of 256, 384 and 512 bits for matching the
three security categories above, respectively.
When SHA3 is used, the OIDs are:
id-gemss-sha3-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-gemss-sha3(3) 22 }.
id-gemss-sha3-384 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-gemss-sha3(3) 23 }.
id-gemss-sha3-512 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-gemss-sha3(3) 24 }.
When the id-gemss-sha3-256, id-gemss-sha3-384 or id-gemss-sha3-512
algorithm identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding MUST omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
component, the OID id-gemss-sha3-256, id-gemss-sha3-384, or id-gemss-
sha3-512.
C. F. Pereira Expires May 23, 2020 [Page 6]
Internet-Draft pereira-pq-signature-oids November 2019
3.4. LUOV Signature
LUOV is a digital signature whose security is based on the hardness
of solving non-linear systems of multivariate equations over finite
fields [LUOV]. Authors provide 6 parameter sets, two for each one of
the security categories 2, 4 and 5. In order to differentiate
parameter sets within the same category, LUOV uses the name
convention LUOV-r-m-v, where r, m, and v are integers indicating the
extension degree, number of equations and number of vinegar
variables, respectively. Note that it is likely that values for r, m
and v may slightly change over time as cryptanalysis evolve and
adopting these parameters in the OIDs is likely to make this
specification obsolete in a near future. In terms of space, LUOV
public keys have moderate size (12-75 KiB) and signatures are small
(300-4400 B). In terms of computational efficiency, KeyGey, Sign and
Verify have moderate speed (a few Mcycles, hundreds of Kcycles and
hundreds of Kcycles, respectively). LUOV SHALL be used in
conjunction with SHAKE-128 for matching category 2 or SHAKE-256 for
categories 4 and 5.
When SHAKE is used, the OIDs are:
id-luov-shake-128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-luov-shake(3) 25 }.
id-luov-shake-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-luov-shake(3) 26 }.
When the id-luov-shake-128 or id-luov-shake-256 algorithm identifier
appears in the algorithm field as an AlgorithmIdentifier, the
encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
luov-shake-128, or id-luov-shake-256.
3.5. MQDSS Signature
MQDSS is a digital signature whose security is based on the hardness
of solving non-linear systems of multivariate equations over finite
fields [MQDSS]. It provides two parameter sets, one for a security
category 1-2 (in between) and another for category 3-4 (in between).
In terms of space, public keys are small (46-64 B) and signatures are
moderate (about 2.6-5.5 KB). From a computational efficiency point
of view, KeyGen, Sign and Verify have moderate speed (few million
cycles). MQDSS SHALL be used in conjunction with SHAKE-256 for
matching the security categories above.
C. F. Pereira Expires May 23, 2020 [Page 7]
Internet-Draft pereira-pq-signature-oids November 2019
When SHAKE is used, the OIDs are:
id-mqdss-shake-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-mqdss-shake(3) 27 }.
When the id-mqdss-shake-256 algorithm identifier appears in the
algorithm field as an AlgorithmIdentifier, the encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-mqdss-shake-256.
3.6. PICNIC Signature
PICNIC is a digital signature whose security is based on the hardness
of breaking symmetric primitives such as block ciphers and hash
functions [PICNIC]. Authors provide nine parameter sets, three for
each one of the security categories 1, 3 and 5. In terms of space,
PICNIC public keys are small (32-64 B) and signatures have moderate
sizes (1.7-26.2 KiB). From the computational efficiency point of
view, KeyGen is fast (tens of Kcycles), Sign and Verify have moderate
speed (a few up to hundreds of Mcycles). PICNIC SHALL be used in
conjunction with SHAKE-128 for matching category 1 or SHAKE-256 for
categories 3 and 5.
When SHAKE is used, the OIDs are:
id-picnic-shake-128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-picnic-shake(3) 28 }.
id-picnic-shake-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-picnic-shake(3) 29 }.
When the id-picnic-shake-128 or id-picnic-shake-256 algorithm
identifier appears in the algorithm field as an AlgorithmIdentifier,
the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
picnic-shake-128 or id-picnic-shake-256.
3.7. qTesla Signatures
qTesla is a digital signature whose security is based on the hardness
of lattice problems [qTesla]. qTesla features two types of design
with respect to security, i.e., provable and heuristic security. The
heuristic parameters were recently considered weaker and are being
removed. For the provably-secure versions, two parameter sets
achieving categories 1 and 3 are provided. qTesla SHALL be used in
C. F. Pereira Expires May 23, 2020 [Page 8]
Internet-Draft pereira-pq-signature-oids November 2019
conjunction with SHAKE-128 for matching category 1 or SHAKE-256 for
matching category 3.
When SHAKE is used, the OIDs are:
id-qtesla-shake-128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-qtesla-shake(3) 30 }.
id-qtesla-shake-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-qtesla-shake(3) 31 }.
When the id-qtesla-shake-128 or id-qtesla-shake-256 algorithm
identifier appears in the algorithm field as an AlgorithmIdentifier,
the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
qtesla-shake-128 or id-qtesla-shake-256.
3.8. Rainbow Signatures
Rainbow is a digital signature whose security is based on the
hardness of solving non-linear systems of multivariate equations over
finite fields [RAINBOW]. Authors provide 6 parameter sets, two for
each one of the security categories 1, 3 and 5. Half of the
parameter sets are intended for a compressed key variant of Rainbow.
In terms of space, Rainbow public keys are moderate to large (58-492
KiB for the compressed versions) and signatures are small (64-204 B).
From a computational efficiency point of view, KeyGen has moderate
speed (tens of Mcyles), Sign and Verify are fast (hundreds of
Kcycles). Rainbow SHALL be used in conjunction with SHA3-256,
SHA3-384 and SHA3-512 for matching categories 1, 3 and 5,
respectively.
When SHA3 is used, the OIDs are:
id-rainbow-sha3-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-rainbow-sha3(3) 32 }.
id-rainbow-sha3-384 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-rainbow-sha3(3) 33 }.
id-rainbow-sha3-512 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-rainbow-sha3(3) 34 }.
C. F. Pereira Expires May 23, 2020 [Page 9]
Internet-Draft pereira-pq-signature-oids November 2019
When the id-rainbow-sha3-256, id-rainbow-sha3-384 or id-rainbow-
sha3-512 algorithm identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding MUST omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
component, the OID id-rainbow-sha3-256, id-rainbow-sha3-384 or id-
rainbow-sha3-512.
3.9. SPHINCS+ Signature
SPHINCS+ is a digital signature whose security is based on problems
related to hash functions [SPHINCS-PLUS]. Authors provide multiple
parameter sets per security category covering categories 1, 3 and 5.
In terms of space, SPHINCS+ public keys are small (32-64 B) and
signatures have moderate sizes (8-50 KiB). From a computational
efficiency point of view, KeyGen, Sign and Verify have moderate to
slow speed (ranging from a few to hundreds of Mcycles). This
document considers only instances based on the NIST standardized hash
functions [FIPS202], i.e., SHAKE and SHA3.
When SHAKE or SHA3 is used, the OIDs are:
id-sphincsp-shake-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-sphincsp-shake(3) 35 }.
id-sphincsp-sha3-256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-sphincsp-sha3(3) 36 }.
When the id-sphincsp-shake-256 or id-sphincsp-sha3-256 algorithm
identifier appears in the algorithm field as an AlgorithmIdentifier,
the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
sphincsp-shake-256 or id-sphincsp-sha3-256.
4. IANA Considerations
The OIDs defined in this document are suggested to go under the NIST
arc (sigAlgs) as it appears to be the most natural for them. Since
we expect these algorithms to be a NIST standard. Other arcs may be
considered as well.
5. Security Considerations
As mentioned in Section 1, the object identifiers defined in this
document take into account the underlying hash function adopted in
each post-quantum signature scheme, and does not introduce extra
definitions for the (optional) parameters for each scheme. This is
C. F. Pereira Expires May 23, 2020 [Page 10]
Internet-Draft pereira-pq-signature-oids November 2019
because it is likely that particular parameter sets change in the
next couple years of standardization until 2024. Defining the names
in terms of security categories is deemed to be a suitable approach
as NIST is unlikely to change the categories themselves.
6. Acknowledgement
The author is thankful for the useful discussions and comments by
John Gray and Mike Ounsworth from Entrust Datacard.
7. References
7.1. Normative References
[FIPS202] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", August 2015,
<http://dx.doi.org/10.6028/NIST.FIPS.202>.
[NIST-OIDS]
National Institute of Standards and Technology (NIST),
"Computer Security Objects Register", 2019,
<https://csrc.nist.gov/Projects/Computer-Security-Objects-
Register/Algorithm-Registration>.
[NIST-PQ] National Institute of Standards and Technology (NIST),
"Post-Quantum Cryptography", 2019,
<https://www.nist.gov/pqcrypto>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002,
<https://www.rfc-editor.org/info/rfc3279>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
C. F. Pereira Expires May 23, 2020 [Page 11]
Internet-Draft pereira-pq-signature-oids November 2019
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, January 2010,
<https://www.rfc-editor.org/info/rfc5758>.
7.2. Informative References
[CRYSTALS-Dilithium]
Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky, V.,
Schwabe, P., Seiler, G., and D. Stehle, "Crystals-
dilithium: A lattice-based digital signature scheme", IACR
Cryptology ePrint Archive , 2017,
<https://eprint.iacr.org/2017/633>.
[FALCON-ref]
Fouque, P-A., Hoffstein, J., Kirchner, P., Lyubashevsky,
V., Pornin, T., Prest, T., Ricosset, T., Seiler, G.,
Whyte, W., and Z. Zhang, "Falcon: Fast-Fourier lattice-
based compact signatures over NTRU", IACR Cryptology
ePrint Archive , 2018, <https://falcon-sign.info/>.
[GeMSS-ref]
Casanova, A., Faugere, J-C., Macario-Rat, G., Patarin, J.,
Perret, L., and J. Ryckeghem, "GeMSS: A Great Multivariate
Short Signature", 2017,
<https://www-polsys.lip6.fr/Links/NIST/GeMSS.html>.
[LUOV] Beullens, W. and B. Preneel, "LUOV: Field lifting for
smaller UOV public keys", IACR Cryptology ePrint Archive ,
2017, <https://eprint.iacr.org/2017/776>.
[MQDSS] Hulsing, A., Rijneveld, J., Samardjiska, S., and P.
Schwabe, "From 5-pass MQ-based identification to MQ-based
signatures", IACR Cryptology ePrint Archive , 2016,
<https://eprint.iacr.org/2016/708>.
[PICNIC] Chase, M., Derler, D., Goldfeder, S., Orlandi, C.,
Ramacher, S., Rechberger, C., Slamanig, D., and G.
Zaverucha, "Post-quantum zero-knowledge and signatures
from symmetric-key primitives", ACM SIGSAC Conference on
Computer and Communications Security pp. 1825--1842,
DOI 10.1145/3133956.3133997, 2017.
[qTesla] Alkim, E., L.M. Barreto, P., Bindel, N., Longa, P., and J.
E. Ricardini, "The Lattice-Based Digital Signature Scheme
qTESLA", IACR Cryptology ePrint Archive , 2019,
<https://eprint.iacr.org/2019/085>.
C. F. Pereira Expires May 23, 2020 [Page 12]
Internet-Draft pereira-pq-signature-oids November 2019
[RAINBOW] Ding, J. and D. Schmidt, "Rainbow, a New Multivariable
Polynomial Signature Scheme", 2005,
<https://link.springer.com/chapter/10.1007/11496137_12>.
[SPHINCS-PLUS]
Bernstein, D., Dobraunig, C., Eichlseder, M., Fluhrer, S.,
Gazdag, S-L., Hulsing, A., Kampanakis, P., Kolbl, S.,
Lange, T., Lauridsen, M., Mendel, F., Niederhagen, R.,
Rechberger, C., Rijneveld, J., and P. Schwabe, "SPHINCS+",
2017, <https://sphincs.org/>.
Author's Address
Geovandro C. C. F. Pereira
evolutionQ Inc. / IQC, University of Waterloo
Email: geovandro.pereira@evolutionq.com
C. F. Pereira Expires May 23, 2020 [Page 13]