David A. Cooper wrote:
Sean,
While a generic statement that implementations must support algorithm
agility is a good one, the RPKI can't transition to a new algorithm
until everyone has implemented support for the specific new algorithm
and experience has shown that getting everyone to implement that support
may take many years. In the Federal PKI, we began to discuss the need
to move from SHA-1 to SHA-256 about seven years ago, yet some agencies
are still saying that they cannot make the transition since they have
applications that don't support SHA-256. So, I think it is reasonable
to begin preparing for a transition at least 5-8 years before the
transition needs to happen.
I 100% feel you pain and I completely agree that we should prepare for
a transition *now* by requiring algorithm agility.
In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 will
be acceptable for so long that by the time there is a need to transition
to something different the consensus will be that the transition should
be to something entirely different (e.g., ECDSA with SHA-3). However,
the current text is intended to suggest that CAs and RPs be prepared to
use stronger cryptography in a way that minimizes the extra effort for
those implementations. It is much easier for an application that can
sign/verify 2048-bit RSA to also support 3072-bit RSA than to also
support ECDSA.
Definitely not arguing that moving to a large key size for RSA is
harder than moving to another signature algorithm.
This draft doesn't presuppose that the RPKI will move to 3072-bit RSA,
it simply helps to ease the transition path to a likely choice for a
transition to stronger cryptography by mainly encouraging CAs and RPs
not to hard code their applications to only support one specific RSA key
length. If in the future the decision is made to transition to
something different (ECDSA, SHA-3, RSASSA-PSS) then this text hasn't
really caused any harm, but it will have to be accepted that such a
transition will require significantly more time that would be required
for a transition to algorithms/key lengths more closely related to those
that are currently required.
I used the word "presuppose" because it's a SHOULD requirement to
support 3072-bit and 4096-bit RSA and SHA-512. That means
implementations need to support these key sizes and algorithms unless
they've got a good reason not too.
I think we have the same goal: require algorithm agility. I think we
can do that with a simple one line sentence in the security
considerations:
Implementations MUST support algorithm agility.
or
Implementations MUST NOT be hard wired to support one hash
algorithm or modulus size.
If we want to say something encouraging about algorithm agility then
maybe something like:
For example, if an implementations supports SHA-512 (code
available in [draft-eastlake-sha2b]), then that implementation
actually supports both SHA-384 and SHA-512 because SHA-384 and
SHA-512 perform identical processing on message blocks and differ
only in how initial hash value is initialized and how they
produce their final output. Likewise, not hard wiring RSA to a
2048-bit key size allows an implementation to support 3072-bit and
4096-bit RSA because the algorithm and key format are identical to
2048-bit RSA modulo the size of the fields.
(or something like that)
spt
Dave
On 10/12/2010 02:06 PM, Sean Turner wrote:
I think this version looks great with one exception. I believe the
last paragraph in Section 5 (repeated below for convenience) should be
deleted:
In anticipation of a potential need to transition to stronger
cryptographic algorithms in the future, CAs and RPs SHOULD be able to
generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512
hash algorithm and RSA key sizes of 3072 and 4096 bits.
I think we should require that implementations support algorithm
agility, but I'd like to not presuppose the algorithms and key sizes
for something that's going to happen 5-8 years down the road. Who
knows maybe SHA3 will be so whiz bang maybe we'll want to move to it.
If we added the following as a security consideration I believe the
intent would be satisfied:
Implementations MUST support algorithm agility.
spt
[email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Secure Inter-Domain Routing Working
Group of the IETF.
Title : A Profile for Algorithms and Key Sizes for use
in the Resource Public Key Infrastructure
Author(s) : G. Huston
Filename : draft-ietf-sidr-rpki-algs-03.txt
Pages : 6
Date : 2010-10-08
This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format for
the Resource Public Key Infrastructure subscribers that generate
digital signatures on certificates, Certificate Revocation Lists, and
signed objects as well as for the Relying Parties (RPs) that verify
these digital signatures.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
