doc: Add RFC documents

1 files changed, 662 insertions, 0 deletions

diff --git a/doc/rfc/rfc8692.txt b/doc/rfc/rfc8692.txt
new file mode 100644
index 0000000..a8da835
--- /dev/null
+++ b/doc/rfc/rfc8692.txt
@@ -0,0 +1,662 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                     P. Kampanakis
+Request for Comments: 8692                                 Cisco Systems
+Updates: 3279                                                    Q. Dang
+Category: Standards Track                                           NIST
+ISSN: 2070-1721                                            December 2019
+
+
+     Internet X.509 Public Key Infrastructure: Additional Algorithm
+           Identifiers for RSASSA-PSS and ECDSA Using SHAKEs
+
+Abstract
+
+   Digital signatures are used to sign messages, X.509 certificates, and
+   Certificate Revocation Lists (CRLs).  This document updates the
+   "Algorithms and Identifiers for the Internet X.509 Public Key
+   Infrastructure Certificate and Certificate Revocation List (CRL)
+   Profile" (RFC 3279) and describes the conventions for using the SHAKE
+   function family in Internet X.509 certificates and revocation lists
+   as one-way hash functions with the RSA Probabilistic signature and
+   Elliptic Curve Digital Signature Algorithm (ECDSA) signature
+   algorithms.  The conventions for the associated subject public keys
+   are also described.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8692.
+
+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
+   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.  Terminology
+   3.  Identifiers
+   4.  Use in PKIX
+     4.1.  Signatures
+       4.1.1.  RSASSA-PSS Signatures
+       4.1.2.  ECDSA Signatures
+     4.2.  Public Keys
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  ASN.1 Module
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC3279] defines cryptographic algorithm identifiers for the
+   "Internet X.509 Public Key Infrastructure Certificate and Certificate
+   Revocation List (CRL) Profile" [RFC5280].  This document updates RFC
+   3279 and defines identifiers for several cryptographic algorithms
+   that use variable-length output SHAKE functions introduced in [SHA3]
+   which can be used with RFC 5280.
+
+   In the SHA-3 family, two extendable-output functions (SHAKEs) are
+   defined: SHAKE128 and SHAKE256.  Four other hash function instances,
+   SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also defined but are
+   out of scope for this document.  A SHAKE is a variable-length hash
+   function defined as SHAKE(M, d) where the output is a d-bits-long
+   digest of message M.  The corresponding collision and second-
+   preimage-resistance strengths for SHAKE128 are min(d/2, 128) and
+   min(d, 128) bits, respectively (see Appendix A.1 of [SHA3]).  And the
+   corresponding collision and second-preimage-resistance strengths for
+   SHAKE256 are min(d/2, 256) and min(d, 256) bits, respectively.
+
+   A SHAKE can be used as the message digest function (to hash the
+   message to be signed) in RSA Probabilistic Signature Scheme (RSASSA-
+   PSS) [RFC8017] and ECDSA [X9.62] and as the hash in the mask
+   generation function (MGF) in RSASSA-PSS.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Identifiers
+
+   This section defines four new object identifiers (OIDs), for RSASSA-
+   PSS and ECDSA with each of SHAKE128 and SHAKE256.  The same algorithm
+   identifiers can be used for identifying a public key in RSASSA-PSS.
+
+   The new identifiers for RSASSA-PSS signatures using SHAKEs are below.
+
+     id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1)
+               identified-organization(3) dod(6) internet(1)
+               security(5) mechanisms(5) pkix(7) algorithms(6)
+               30 }
+
+     id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1)
+               identified-organization(3) dod(6) internet(1)
+               security(5) mechanisms(5) pkix(7) algorithms(6)
+               31 }
+
+   The new algorithm identifiers of ECDSA signatures using SHAKEs are
+   below.
+
+     id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1)
+               identified-organization(3) dod(6) internet(1)
+               security(5) mechanisms(5) pkix(7) algorithms(6)
+               32 }
+
+     id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1)
+               identified-organization(3) dod(6) internet(1)
+               security(5) mechanisms(5) pkix(7) algorithms(6)
+               33 }
+
+   The parameters for the four identifiers above MUST be absent.  That
+   is, the identifier SHALL be a SEQUENCE of one component: the OID.
+
+   Sections 4.1.1 and 4.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 MGFs in RSASSA-PSS, their output length is (8*ceil((n-1)/8) -
+   264) or (8*ceil((n-1)/8) - 520) bits, respectively, where n is the
+   RSA modulus size in bits.
+
+4.  Use in PKIX
+
+4.1.  Signatures
+
+   Signatures are used in a number of different ASN.1 structures.  As
+   shown in the ASN.1 representation from [RFC5280] below, in an X.509
+   certificate, a signature is encoded with an algorithm identifier in
+   the signatureAlgorithm attribute and a signatureValue attribute that
+   contains the actual signature.
+
+      Certificate  ::=  SEQUENCE  {
+         tbsCertificate       TBSCertificate,
+         signatureAlgorithm   AlgorithmIdentifier,
+         signatureValue       BIT STRING  }
+
+   The identifiers defined in Section 3 can be used as the
+   AlgorithmIdentifier in the signatureAlgorithm field in the sequence
+   Certificate and the signature field in the sequence TBSCertificate in
+   X.509 [RFC5280].  The parameters of these signature algorithms are
+   absent, as explained in Section 3.
+
+   Conforming Certification Authority (CA) implementations MUST specify
+   the algorithms explicitly by using the OIDs specified in Section 3
+   when encoding RSASSA-PSS or ECDSA with SHAKE signatures in
+   certificates and CRLs.  Conforming client implementations that
+   process certificates and CRLs using RSASSA-PSS or ECDSA with SHAKE
+   MUST recognize the corresponding OIDs.  Encoding rules for RSASSA-PSS
+   and ECDSA signature values are specified in [RFC4055] and [RFC5480],
+   respectively.
+
+   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.
+   Refer to Section 6 for more details.
+
+4.1.1.  RSASSA-PSS Signatures
+
+   The RSASSA-PSS algorithm is defined in [RFC8017].  When id-RSASSA-
+   PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 (specified in Section 3) is
+   used, the encoding MUST omit the parameters field.  That is, the
+   AlgorithmIdentifier SHALL be a SEQUENCE of one component: id-RSASSA-
+   PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256.  [RFC4055] defines RSASSA-
+   PSS-params that is used to define the algorithms and inputs to the
+   algorithm.  This specification does not use parameters because the
+   hash, mask generation algorithm, trailer, and salt are embedded in
+   the OID definition.
+
+   The hash algorithm to hash a message being signed and the hash
+   algorithm used as the MGF in RSASSA-PSS MUST be the same: both
+   SHAKE128 or both SHAKE256.  The output length of the hash algorithm
+   that hashes the message SHALL be 32 bytes (for SHAKE128) or 64 bytes
+   (for SHAKE256).
+
+   The MGF takes an octet string of variable length 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 used natively as the
+   MGF, instead of the MGF1 algorithm that uses the hash function in
+   multiple iterations, as specified in Appendix 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-SHAKE128 and id-RSASSA-PSS-SHAKE256,
+   respectively.  The mgfSeed is the seed from which the mask is
+   generated, an octet string [RFC8017].  As 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 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, respectively.  Thus,
+   when SHAKE is used as the MGF, the SHAKE output length maskLen is
+   (8*emLen - 264) or (8*emLen - 520) bits, respectively.  For example,
+   when RSA modulus n is 2048 bits, the output length of SHAKE128 or
+   SHAKE256 as the MGF will be 1784 or 1528 bits when id-RSASSA-PSS-
+   SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively.
+
+   The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128
+   or 64 bytes for id-RSASSA-PSS-SHAKE256.  Finally, the trailerField
+   MUST be 1, which represents the trailer field with hexadecimal value
+   0xBC [RFC8017].
+
+4.1.2.  ECDSA Signatures
+
+   The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
+   [X9.62].  When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
+   (specified in Section 3) algorithm identifier appears, the respective
+   SHAKE function (SHAKE128 or SHAKE256) is used as the hash.  The
+   encoding MUST omit the parameters field.  That is, the
+   AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID id-
+   ecdsa-with-shake128 or id-ecdsa-with-shake256.
+
+   For simplicity and compliance with the ECDSA standard specification
+   [X9.62], the output length of the hash function must be explicitly
+   determined.  The output length, d, for SHAKE128 or SHAKE256 used in
+   ECDSA MUST be 256 or 512 bits, respectively.
+
+   Conforming CA implementations that generate ECDSA with SHAKE
+   signatures in certificates or CRLs SHOULD generate such signatures
+   with a deterministically generated, nonrandom k in accordance with
+   all the requirements specified in [RFC6979].  They MAY also generate
+   such signatures in accordance with all other recommendations in
+   [X9.62] or [SEC1] if they have a stated policy that requires
+   conformance to those standards.  Those standards have not specified
+   SHAKE128 and SHAKE256 as hash algorithm options.  However, SHAKE128
+   and SHAKE256 with output length being 32 and 64 octets, respectively,
+   can be used instead of 256- and 512-bit output hash algorithms such
+   as SHA256 and SHA512.
+
+4.2.  Public Keys
+
+   Certificates conforming to [RFC5280] can convey a public key for any
+   public key algorithm.  The certificate indicates the public key
+   algorithm through an algorithm identifier.  This algorithm identifier
+   is an OID with optionally associated parameters.  The conventions and
+   encoding for RSASSA-PSS and ECDSA public key algorithm identifiers
+   are as specified in Sections 2.3.1 and 2.3.5 of [RFC3279],
+   Section 3.1 of [RFC4055] and Section 2.1 of [RFC5480].
+
+   Traditionally, the rsaEncryption object identifier is used to
+   identify RSA public keys.  The rsaEncryption object identifier
+   continues to identify the subject public key when the RSA private key
+   owner does not wish to limit the use of the public key exclusively to
+   RSASSA-PSS with SHAKEs.  When the RSA private key owner wishes to
+   limit the use of the public key exclusively to RSASSA-PSS with
+   SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 3
+   SHOULD be used as the algorithm field in the SubjectPublicKeyInfo
+   sequence [RFC5280].  Conforming client implementations that process
+   RSASSA-PSS with SHAKE public keys when processing certificates and
+   CRLs MUST recognize the corresponding OIDs.
+
+   Conforming CA implementations MUST specify the X.509 public key
+   algorithm explicitly by using the OIDs specified in Section 3 when
+   encoding ECDSA with SHAKE public keys in certificates and CRLs.
+   Conforming client implementations that process ECDSA with SHAKE
+   public keys when processing certificates and CRLs MUST recognize the
+   corresponding OIDs.
+
+   The identifier parameters, as explained in Section 3, MUST be absent.
+
+5.  IANA Considerations
+
+   One object identifier for the ASN.1 module in Appendix A has been
+   assigned in the "SMI Security for PKIX Module Identifier"
+   (1.3.6.1.5.5.7.0) registry:
+
+            +---------+--------------------------+------------+
+            | Decimal |       Description        | References |
+            +=========+==========================+============+
+            |    94   | id-mod-pkix1-shakes-2019 |  RFC 8692  |
+            +---------+--------------------------+------------+
+
+                                  Table 1
+
+   IANA has updated the "SMI Security for PKIX Algorithms"
+   (1.3.6.1.5.5.7.6) registry [SMI-PKIX] with four additional entries:
+
+             +---------+------------------------+------------+
+             | Decimal |      Description       | References |
+             +=========+========================+============+
+             |    30   | id-RSASSA-PSS-SHAKE128 |  RFC 8692  |
+             +---------+------------------------+------------+
+             |    31   | id-RSASSA-PSS-SHAKE256 |  RFC 8692  |
+             +---------+------------------------+------------+
+             |    32   | id-ecdsa-with-shake128 |  RFC 8692  |
+             +---------+------------------------+------------+
+             |    33   | id-ecdsa-with-shake256 |  RFC 8692  |
+             +---------+------------------------+------------+
+
+                                  Table 2
+
+   IANA has updated the "Hash Function Textual Names" registry
+   [Hash-Texts] with two additional entries for SHAKE128 and SHAKE256:
+
+       +--------------------+-------------------------+-----------+
+       | Hash Function Name |           OID           | Reference |
+       +====================+=========================+===========+
+       |      shake128      | 2.16.840.1.101.3.4.2.11 |  RFC 8692 |
+       +--------------------+-------------------------+-----------+
+       |      shake256      | 2.16.840.1.101.3.4.2.12 |  RFC 8692 |
+       +--------------------+-------------------------+-----------+
+
+                                 Table 3
+
+6.  Security Considerations
+
+   This document updates [RFC3279].  The Security Considerations section
+   of that document applies to this specification as well.
+
+   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.
+
+   SHAKE128 with output length of 256 bits offers 128 bits of collision
+   and preimage resistance.  Thus, SHAKE128 OIDs in this specification
+   are RECOMMENDED with 2048- (112-bit security) or 3072-bit (128-bit
+   security) RSA modulus or curves with group order of 256 bits (128-bit
+   security).  SHAKE256 with a 512-bit output length offers 256 bits of
+   collision and preimage resistance.  Thus, the SHAKE256 OIDs in this
+   specification are RECOMMENDED with 4096-bit RSA modulus or higher or
+   curves with a group order of at least 512 bits, such as the NIST
+   Curve P-521 (256-bit security).  Note that we recommended a 4096-bit
+   RSA because we would need a 15360-bit modulus for 256 bits of
+   security, which is impractical for today's technology.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, 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, DOI 10.17487/RFC3279, April
+              2002, <https://www.rfc-editor.org/info/rfc3279>.
+
+   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
+              Algorithms and Identifiers for RSA Cryptography for use in
+              the Internet X.509 Public Key Infrastructure Certificate
+              and Certificate Revocation List (CRL) Profile", RFC 4055,
+              DOI 10.17487/RFC4055, June 2005,
+              <https://www.rfc-editor.org/info/rfc4055>.
+
+   [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>.
+
+   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+              "Elliptic Curve Cryptography Subject Public Key
+              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
+              <https://www.rfc-editor.org/info/rfc5480>.
+
+   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+              "PKCS #1: RSA Cryptography Specifications Version 2.2",
+              RFC 8017, DOI 10.17487/RFC8017, November 2016,
+              <https://www.rfc-editor.org/info/rfc8017>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [SHA3]     National Institute of Standards and Technology, "SHA-3
+              Standard: Permutation-Based Hash and Extendable-Output
+              Functions", DOI 10.6028/NIST.FIPS.202, FIPS PUB 202,
+              August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
+
+7.2.  Informative References
+
+   [Hash-Texts]
+              IANA, "Hash Function Textual Names",
+              <https://www.iana.org/assignments/hash-function-text-
+              names/>.
+
+   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
+              DOI 10.17487/RFC5912, June 2010,
+              <https://www.rfc-editor.org/info/rfc5912>.
+
+   [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:
+              Elliptic Curve Cryptography", May 2009,
+              <http://www.secg.org/sec1-v2.pdf>.
+
+   [SMI-PKIX] IANA, "SMI Security for PKIX Algorithms",
+              <https://www.iana.org/assignments/smi-numbers>.
+
+   [SP800-107]
+              National Institute of Standards and Technology (NIST),
+              "Recommendation for Applications Using Approved Hash
+              Algorithms", DOI 10.6028/NIST.SP.800-107r1, Revision 1,
+              NIST Special Publication (SP) 800-107, August 2012,
+              <http://dx.doi.org/10.6028/NIST.SP.800-107r1>.
+
+   [SP800-78-4]
+              National Institute of Standards and Technology (NIST),
+              "Cryptographic Algorithms and Key Sizes for Personal
+              Identity Verification", DOI 10.6028/NIST.SP.800-78-4, NIST
+              Special Publication (SP) 800-78-4, May 2015,
+              <http://dx.doi.org/10.6028/NIST.SP.800-78-4>.
+
+   [X9.62]    ANSI, "Public Key Cryptography for the Financial Services
+              Industry: the Elliptic Curve Digital Signature Algorithm
+              (ECDSA)", ANSI X9.62, 2005.
+
+Appendix A.  ASN.1 Module
+
+   This appendix includes the ASN.1 module for SHAKEs in X.509.  This
+   module does not come from any previously existing RFC.  This module
+   references [RFC5912].
+
+   PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6)
+     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+     id-mod-pkix1-shakes-2019(94) }
+
+   DEFINITIONS EXPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL;
+
+   IMPORTS
+
+   -- FROM RFC 5912
+
+   PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-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 RFC 5912
+
+   RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,
+   CURVE, id-ecPublicKey, ECPoint, ECParameters, 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) }
+   ;
+
+   --
+   -- Message Digest Algorithms (mda-)
+   --
+   DigestAlgorithms DIGEST-ALGORITHM ::= {
+     -- This expands DigestAlgorithms from RFC 5912
+     mda-shake128   |
+     mda-shake256,
+     ...
+   }
+
+   --
+   -- 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 }
+
+   -- SHAKE256
+   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 ::= {
+     -- This expands PublicKeys from RFC 5912
+     pk-rsaSSA-PSS-SHAKE128 |
+     pk-rsaSSA-PSS-SHAKE256,
+     ...
+   }
+
+   -- The hashAlgorithm is mda-shake128
+   -- The maskGenAlgorithm is id-shake128
+   -- Mask Gen Algorithm is SHAKE128 with output length
+   -- (8*ceil((n-1)/8) - 264) bits, 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 ARE absent
+     -- Private key format not in this module --
+     CERT-KEY-USAGE { nonRepudiation, digitalSignature,
+                      keyCertSign, cRLSign }
+   }
+
+   -- The hashAlgorithm is mda-shake256
+   -- The maskGenAlgorithm is id-shake256
+   -- Mask Gen Algorithm is SHAKE256 with output length
+   -- (8*ceil((n-1)/8) - 520)-bits, 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 ARE absent
+     -- Private key format not in this module --
+     CERT-KEY-USAGE { nonRepudiation, digitalSignature,
+                      keyCertSign, cRLSign }
+   }
+
+   --
+   -- Signature Algorithms (sa-)
+   --
+   SignatureAlgs SIGNATURE-ALGORITHM ::= {
+     -- This expands SignatureAlgorithms from RFC 5912
+     sa-rsassapssWithSHAKE128 |
+     sa-rsassapssWithSHAKE256 |
+     sa-ecdsaWithSHAKE128 |
+     sa-ecdsaWithSHAKE256,
+     ...
+   }
+
+   --
+   -- SMIME Capabilities (sa-)
+   --
+   SMimeCaps SMIME-CAPS ::= {
+     -- The expands SMimeCaps from RFC 5912
+     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 ARE absent
+         -- The hashAlgorithm is mda-shake128
+         -- The maskGenAlgorithm is id-shake128
+         -- Mask Gen Algorithm is SHAKE128 with output length
+         -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
+         -- modulus in bits.
+         -- The saltLength is 32. The trailerField is 1
+     HASHES { mda-shake128 }
+     PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 }
+     SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
+   }
+   id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1)
+           identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) algorithms(6)
+           30 }
+
+   -- RSASSA-PSS with SHAKE256
+   sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
+     IDENTIFIER id-RSASSA-PSS-SHAKE256
+     PARAMS ARE absent
+         -- The hashAlgorithm is mda-shake256
+         -- The maskGenAlgorithm is id-shake256
+         -- Mask Gen Algorithm is SHAKE256 with output length
+         -- (8*ceil((n-1)/8) - 520)-bits, where n is the
+         -- RSA modulus in bits.
+         -- The saltLength is 64. The trailerField is 1.
+    HASHES { mda-shake256 }
+    PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 }
+    SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
+   }
+   id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1)
+           identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) algorithms(6)
+           31 }
+
+   -- ECDSA with SHAKE128
+   sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
+     IDENTIFIER id-ecdsa-with-shake128
+     VALUE ECDSA-Sig-Value
+     PARAMS ARE absent
+     HASHES { mda-shake128 }
+     PUBLIC-KEYS { pk-ec }
+     SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
+   }
+   id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1)
+           identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) algorithms(6)
+           32 }
+
+   -- ECDSA with SHAKE256
+   sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
+     IDENTIFIER id-ecdsa-with-shake256
+     VALUE ECDSA-Sig-Value
+     PARAMS ARE absent
+     HASHES { mda-shake256 }
+     PUBLIC-KEYS { pk-ec }
+     SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
+   }
+   id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1)
+           identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) algorithms(6)
+           33 }
+
+   END
+
+Acknowledgements
+
+   We would like to thank Sean Turner, Jim Schaad, and Eric Rescorla for
+   their valuable contributions to this document.
+
+   The authors would like to thank Russ Housley for his guidance and
+   very valuable contributions with the ASN.1 module.
+
+Authors' Addresses
+
+   Panos Kampanakis
+   Cisco Systems
+
+   Email: pkampana@cisco.com
+
+
+   Quynh Dang
+   NIST
+   100 Bureau Drive, Stop 8930
+   Gaithersburg, MD 20899-8930
+   United States of America
+
+   Email: quynh.dang@nist.gov