I agree with Russ in part, but would propose a different solution.
Barring any as yet undiscovered cryptanalytic attacks, SHA-256 is
already stronger than 2048-bit RSA. According to Table 3 of NIST SP
800-57 part 1
(http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf),
a hash function when used for digital signatures has a cryptographic
strength (i.e., number of bits of security) equal to half the length of
its output. That is 128, 192, and 256 bits for SHA-256, SHA-384, and
SHA-512, respectively. Meanwhile, Table 2 of SP 800-57 part 1 indicates
the RSA key length needed to obtain various bits of security:
bits of security RSA modulus length
-------------- ---------------------
80 1024
112 2048
128 3072
192 7680
256 15360
So, I don't see any reason to allow the use of hash algorithms stronger
than SHA-256 while simultaneously stating that the RSA public key must
be exactly 2048 bits. As an alternative, I would suggest mandating the
use of SHA-256 with a 2048 bit RSA key, while encouraging
implementations to be able to handle both longer RSA key sizes and
stronger hash algorithms in order to facilitate a transition to stronger
cryptography at some point in the future.
In addition, I see no reason to recommend support for SHA-384. As
stated in Section 6 of FIPS 180-3:
the specification for SHA-224 is identical to SHA-256,
except that different initial hash values are used, and the
final hash value is truncated to 224 bits for SHA-224.
The same is true for SHA-512 and SHA-384, except that
the final hash value is truncated to 384 bits for SHA-384.
So, if you use SHA-384 you are essentially just computing SHA-512 and
then truncating the output. This truncation is useful in some cases
(e.g., ECDSA), but there's no reason to do it for an RSA signature.
Granted, SHA-384 is already overkill, but if you're going to go through
the work of computing a SHA-512 hash, you might as well just go ahead
and use the resulting output rather than truncating it unnecessarily.
So, here would be my recommendation for Section 2:
This profile specifies the use of RSASSA-PKCS1-v1_5 [RFC3447]
with the SHA-256 hash algorithm to compute the signature of
certificates, CRLs, and signed objects in the context of the RPKI.
Accordingly, the OID value in the RPKI for such signatures MUST
be 1.2.840.113549.1.1.11 (sha256WithRSAEncryption). The RSA
key pairs used to compute the signatures MUST have a 2048-bit
modulus and a public exponent (e) of 65,537.
In order to facilitate a potential need to transition to stronger
cryptographic
algorithms in the future, Certification Authorities (CAs) and Relying
Parties
(RPs) SHOULD be able to generate and verify RSASSA-PKCS1-v1_5
signatures using the SHA-512 hash algorithm and RSA key sizes longer
than 2048 bits.
[NOTE: There are certainly other algorithms that one might encourage
CAs and RPs to be able to support as candidates for use in the future,
such as RSASSA-PSS or ECDSA, but the text that I proposed seems to align
most closely with the current text.]
Dave
Russ Housley wrote:
>> Why allow all three hash functions. Since you are specifying a
particular key size, it seems better to select the hash function that
matches that key size.
>> I can see an argument for MUST SHA-256 and SHOULD SHA-384 as an
indicator that the longer has will be needed in the future.
Russ
2. Algorithm and Key Size
This profile specifies the use of the RSA algorithm [RFC3447] to
compute the signature of certificates, CRLs and signed objects in the
context of the RPKI. This profile specifies a default of SHA-256
with RSA (sha256WithRSAEncryption), and allows for the use of SHA-384
(sha384WithRSAEncryption) or SHA-512 (sha384WithRSAEncryption).
Accordingly, The OID values used in the RPKI for such signatures MUST
be one of { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } [RFC4055].
The required RSA key size MUST be 2048 bits.
The public exponent (e) of the RSA algorithm is F4 (65,537).
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
