Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
updated by
- rfc-5756 — Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters
updates
- rfc-3279 — Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (24)
PKCS #1 Version 1.5 signatures are included for compatibility with existing applications. Although no attacks are known against PKCS #1 v1.5, RSASSA-PSS is preferred for new applications because it has provable security properties, and a gradual migration is encouraged.
The ambiguity allowing both NULL and absent hash algorithm parameters arose because the OPTIONAL keyword was inadvertently dropped when the 1988 AlgorithmIdentifier syntax was translated to 1997 syntax; it was later restored via a defect report, but by then many implementations had already mandated NULL. RSASSA-PSS and RSAES-OAEP were defined using NULL parameters, compounding the ambiguity.
The id-RSASSA-PSS and id-RSAES-OAEP OIDs were introduced alongside rsaEncryption so that a certificate owner can restrict a key to a specific algorithm. Without this restriction, the relying party cannot determine the intended use from the certificate, making it harder to enforce single-purpose key use as recommended in Security Considerations.
For the SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 AlgorithmIdentifiers, implementations MUST accept both a NULL parameters field and an absent parameters field as legal and equivalent encodings. This dual-acceptance is required because the OPTIONAL nature of the parameters was lost and then recovered in the ASN.1 syntax history, causing divergent implementations.
Conforming CAs and applications MUST support the RSAES-OAEP key transport algorithm using SHA-1; other hash functions MAY be supported. Compliant implementations MUST NOT use any value other than id-pSpecified for the pSourceFunc field.
Entities that validate RSASSA-PSS signatures MUST support SHA-1; support for SHA-224, SHA-256, SHA-384, and SHA-512 is optional. CAs that use RSASSA-PSS for signing certificates or CRLs MUST include RSASSA-PSS-params in the signatureAlgorithm parameters in TBSCertificate or TBSCertList.
For the PKCS #1 Version 1.5 signature algorithm OIDs sha224WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption, and sha512WithRSAEncryption, when any of these appears in an AlgorithmIdentifier the parameters MUST be NULL; implementations MUST also accept absent parameters.
If the keyUsage extension is present in a certificate conveying an RSA public key with id-RSAES-OAEP, the extension MUST contain only keyEncipherment and/or dataEncipherment; however, both keyEncipherment and dataEncipherment SHOULD NOT be present simultaneously.
If the keyUsage extension is present in an end-entity certificate conveying an RSA public key with id-RSASSA-PSS, the extension MUST contain nonRepudiation and/or digitalSignature. For a CA certificate with id-RSASSA-PSS, it MUST contain one or more of nonRepudiation, digitalSignature, keyCertSign, or cRLSign.
The RSASSA-PSS trailerField MUST be 1 (hex 0xBC). Signature generation implementations MUST omit the trailerField when the default is used; signature validation implementations MUST recognize both an explicitly present trailerField of 1 and an absent trailerField as equivalent.
When rsaEncryption is used in the SubjectPublicKeyInfo algorithm field (indicating no exclusive algorithm restriction), the parameters field MUST contain NULL.
When the public key is identified by id-RSASSA-PSS and parameters are present, all RSASSA-PSS-params fields in the signature algorithm identifier MUST match those in the key algorithm identifier, except saltLength; the saltLength in the signature parameters MUST be greater than or equal to that in the key parameters.
When the RSA private key owner restricts use exclusively to RSAES-OAEP, id-RSAES-OAEP MUST be used in the SubjectPublicKeyInfo algorithm field; if parameters are present, they MUST contain RSAES-OAEP-params. The certificate user MUST then use the key only for RSAES-OAEP operations.
MGF1 is the sole supported mask generation function, identified by id-mgf1 (pkcs-1 8). Its AlgorithmIdentifier parameters field MUST contain a HashAlgorithm identifying the hash function used with MGF1; implementations MUST support sha1Identifier as the default and MAY support sha224, sha256, sha384, or sha512.
RSA public keys are encoded as RSAPublicKey ::= SEQUENCE { modulus INTEGER, publicExponent INTEGER }, carried as a DER-encoded value in the subjectPublicKey BIT STRING within SubjectPublicKeyInfo. This encoding is used regardless of which algorithm OID (rsaEncryption, id-RSASSA-PSS, or id-RSAES-OAEP) appears in the algorithm field.
RSAES-OAEP-params is encoded as SEQUENCE { hashFunc [0] DEFAULT sha1Identifier, maskGenFunc [1] DEFAULT mgf1SHA1Identifier, pSourceFunc [2] DEFAULT pSpecifiedEmptyIdentifier } with explicit tags. The pSourceFunc identifies the encoding parameters P; implementations MUST represent P using id-pSpecified with an OCTET STRING value.
RSASSA-PSS-params is encoded as SEQUENCE { hashAlgorithm [0] DEFAULT sha1Identifier, maskGenAlgorithm [1] DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } with explicit tags. The trailerField MUST be 1 (representing hex 0xBC).
No new IANA registry is created by this document. All object identifiers used were assigned in PKCS documents or by NIST; no further IANA action is required.
Current implementations MUST support 1024-bit RSA public keys (approximately 80-bit security). Before the end of 2007, implementations SHOULD support at least 2048-bit RSA keys and SHOULD support SHA-256, to provide adequate protection through 2010.
For RSAES-OAEP, collision attacks on the hash function do not directly translate to key transport attacks unless the encoding parameter P varies across different messages. For consistency and to cover the non-empty P case, the hash function's bit length should be at least twice the desired security level in bits.
Good cryptographic practice uses a given RSA key pair in only one scheme. An RSA key pair used for RSASSA-PSS SHOULD NOT be used for other purposes; one key pair SHOULD always be used with the same RSASSA-PSS parameters (except possibly saltLength). Likewise, an RSAES-OAEP key pair should not be used for other purposes.
RSA private keys must be protected; compromise of the private key may result in disclosure of all messages protected with that key. Key generation relies on quality random numbers, and inadequate PRNGs can reduce security to the point where an attacker can reproduce the PRNG state and search the small key space.
Wang et al. demonstrated a collision attack against SHA-1 with complexity 2^69, below the generic bound of 2^80. When SHA-1 is used in a digital signature scheme, this translates to a forgery attack if the attacker can induce the signer to sign a colliding message, reducing security to 69 bits; SHA-256, SHA-384, or SHA-512 should be used when a higher security level is needed.
The RSASSA-PSS signature value is an octet string of the same length as the RSA modulus n. To encode as a BIT STRING in an X.509 certificate or CRL, the most significant bit of the first octet becomes the first bit of the bit string, proceeding through to the least significant bit of the last octet.