]>
Internet X.509 Public Key Infrastructure: Additional SHAKE Algorithms and Identifiers for RSA and ECDSACisco Systemspkampana@cisco.comNIST100 Bureau Drive, Stop 8930GaithersburgMD20899-8930USAquynh.dang@nist.gov
General
LAMPS WGThis document describes the conventions for using the SHAKE family of
hash functions in the Internet X.509 as one-way hash functions
with the RSA and ECDSA signature algorithms; the
conventions for the associated subject public keys are also
described. Digital signatures are used to sign messages,
certificates and CRLs (Certificate Revocation Lists).[ EDNOTE: Remove this section before publication. ]draft-ietf-lamps-pkix-shake-01:
Changed titles and section names.Removed DSA after WG discussions.Updated shake OID names and parameters, added MGF1 section.Updated RSASSA-PSS section.Added Public key algorithm OIDs.Populated Introduction and IANA sections.draft-ietf-lamps-pkix-shake-00:
Initial versionThis document describes several cryptographic algorithms which may be used
with the Internet X.509 Certificate and CRL profile .
It describes the OIDs for variable length SHAKE algorithms introduced in
and how they can be used in X.509 certificates. [ EDNOTE: Update here. ] This section describes two one-way hash functions and digital signature
algorithms using these functions, which may be used to sign certificates and
CRLs, and identifies OIDs (Object Identifiers) for public keys contained in
certificates.The SHA-3 family of one-way hash functions is specified in .
In the SHA-3 family, two extendable-output functions, called SHAKE128 and SHAKE256 are
defined. Four hash functions, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also
defined but are out of scope for this document. SHAKE is a variable length hash function.
The output lengths, in bits, of the SHAKE hash functions is defined by the parameter d.
The corresponding collision and preimage resistance security levels for SHAKE128 and SHAKE256
are respectively min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256).
The Object Identifiers (OIDs) for these two hash functions are defined in
and are included here for convenience: When using the id-shake128-len algorithm identifier, the parameters
MUST be present, and they MUST employ the ShakeOutputLen
syntax that contains an encoded positive integer value at least 32
in this specification.When using the id-shake256-len algorithm identifier, the parameters
MUST be present, and they MUST employ the ShakeOutputLen
syntax that contains an encoded positive integer value at least 64
in this specification.The RSASSA-PSS signature algorithm uses a mask generation function. A mask generation function
takes an octet string of variable length and a desired output length as input, and outputs an
octet string of the desired length. The mask generation function used in RSASSA-PSS is defined in
, but we include it here as well for convenience:The parameters field associated with id-mgf1 MUST have a hashAlgorithm value that identifies
the hash used with MGF1. To use SHAKE as this hash, this parameter MUST be
id-shake128-len or id-shake256-len as specified in above. The RSASSA-PSS signature algorithm identifier and its parameters are specifed in : This document adds two new hash algorithm choices and two new choices for mask generation functions.
These are the SHAKE128 and SHAKE256 algorithm identifiers specified in .When SHAKE128 or SHAKE256 is used as the hashAlgorithm, it MUST also be used as the maskGenAlgorithm.When used as the hashAlgorithm, the SHAKE128 or SHAKE256 output-length must be either 32
or 64 bytes respectively. In these cases, the parameters MUST be present, and they MUST employ
the ShakeOutputLen syntax that contains
an encoded positive integer value of 32 or 64 for id-shake128-len or id-shake256-len algorithm
identifier respectively.When id-shake128-len or id-shake256-len algorithm identifier is used as the id-mfg1 maskGenAlgorithm
parameter, the ShakeOutputLen parameter must be (n - 264)/8 or (n - 520)/8 respectively for SHAKE128 and SHAKE256,
where n is the RSA modulus in bits. For example, when RSA modulus n is 2048, ShakeOutputLen must be 223 or 191
when id-shake128-len or id-shake256-len is are used respectively.The parameter saltLength MUST be 32 or 64 bytes respectively for the SHAKE128 and SHA256 OIDs.The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
"Public Key Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Standard (ECDSA)" .
The ASN.1 OIDs of ECDSA signature algorithms using SHAKE128 and SHAKE256,
are below: [ EDNOTE: "x" and "y" will be specified by NIST later. ]When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-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 ecdsa-with-SHAKE128 or ecdsa-with-SHAKE256.Conforming CA implementations MUST specify the hash algorithm
explicitly using the OIDs specified in Section 3.2 above when encoding ECDSA/SHAKE
signatures in certificates and CRLs.Conforming client implementations that process ECDSA signatures with
any of the SHAKE hash algorithms when processing certificates and CRLs
MUST recognize the corresponding OIDs specified in Sections 3.1 and 3.2 above.Encoding rules for ECDSA signature values are specified in
, Section 2.2.3, and .Conforming CA implementations that generate ECDSA signatures in
certificates or CRLs MUST generate such ECDSA signatures in
accordance with all the requirements specified in Sections 7.2 and
7.3 of or with all the requirements specified in Section
4.1.3 of . They MAY also generate such ECDSA
signatures in accordance with all the recommendations in or
if they have a stated policy that requires
conformance to these standards. These standards above may have not specified
SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and
SHAKE256 with output length being 32 and 64 octets respectively are
subtitutions for 256 and 512-bit output hash algorithms such as SHA256
and SHA512 used in the standards.The conventions for RSA and ECDSA public keys are as specified in
, and .
We include them here for convenience. defines the following OID for RSA with NULL parameters.Additionally, adds the corresponding RSASSA-PSS OID public key
identifier and parameters (also shown in of this document).
The parameters may be either absent or present when RSASSA-PSS OID is used as subject
public key information.If id-RSASSA-PSS is used in the public key identifier with parameters, Section 3.3 of
describes that the signature algorithm parameters MUST match the
parameters in the key structure algorithm identifier except the saltLength field. The
saltLength field in the signature parameters MUST be greater or equal to that in the key
parameters field. If the id-RSASSA-PSS parameters are NULL no further parameter validation
is necessary.For ECDSA, defines the EC public key identifier and its parameters as The ECParameters associated with the ECDSA public key in the signer's
certificate SHALL apply to the verification of the signature.We would like to thank Sean Turner for his valuable contributions to this document.This document uses several registries that were originally created in .
No further registries are required. [ EDNOTE: Update here. ] SHAKE128 and SHAKE256 are one-way extensible-output functions. Their output length depends on
a required length of the consumming application. The SHAKEs are deterministic functions. Like any other deterministic functions, executing each
function with the same input multiple times will produce the same output.
Therefore, users should not expect unrelated outputs (with the same or different output lengths)
from excuting a SHAKE function with the same input multiple times. Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade.When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the
content could originate from any one of the parties.Implementations must randomly generate message-authentication keys
and one-time values, such as the k value when generating a ECDSA
signature. In addition, the generation of public/private key pairs
relies on random numbers. The use of inadequate pseudo-random
number generators (PRNGs) to generate such cryptographic values can
result in little or no security. The generation of quality random
numbers is difficult. offers important guidance
in this area, and series provide acceptable
PRNGs.Implementers should be aware that cryptographic algorithms may become
weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared to
regularly update the set of algorithms in their implementations.
&RFC3279;
&RFC4055;
&RFC5280;
&RFC5480;
&RFC8017;
SHA-3 Standard - Permutation-Based Hash and Extendable-Output Functions FIPS PUB 202National Institute of Standards and Technology
&RFC4086;
Computer Security Objects RegisterNational Institute of Standards and TechnologySEC 1: Elliptic Curve CryptographyStandards for Efficient Cryptography GroupX9.62-2005 Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)American National Standard for Financial Services (ANSI)Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90ANational Institute of Standards and Technology[ EDNOTE: More here. ]