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.
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.
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.
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
