Hi Stephen,
Thanks for the clues.
On 9-Oct-2006, at 09:29, Stephen Kent wrote:
As Robert noted, in the long run we can transition to EC DSA when
we feel to need for bigger (equivalent) key sizes. That's what
folks are doing in general, as an alternative to very big RSA keys.
Re-reading the document, I think I might have mis-read the text in
the first place. Section 3.8 says:
This field specifies the subject's public key and the algorithm with
which the key is used. The public key algorithm MUST be RSA, and,
accordingly, the OID for the algorithm is 1.2.840.113549.1.1.1. A
minimum key size of 1024 bits is mandated in this profile. In the
context of certifying resources it is recommended that certificates
that are intended to be used as root certificates, and their
immediate subordinates SHOULD use a key size of 2048 bits.
Subordinates of these subordinate certificates, in the context of
continued level of high trust, SHOULD use a key size of 2048 bits.
In the application of this profile to certification of public number
resources, it would be consistent with this recommendation that the
Regional Internet Registries used a key size of 2048 bits, and that
their immediate subordinate certificate authorities also use a key
size of 2048 bits. All other subordinate certificates MAY use a key
size of 1024 bits.
So, in fact, for general use it is a minimum that is recommended
(1024 bits), not an absolute, and where an absolute number is quoted
it's for RIRs and LIRs, and even then a SHOULD rather than a MUST.
Your comments above though (and Rob's comments earlier) make me
wonder about the hard requirement that the algorithm MUST be RSA,
though. Seems to me that a future transition to a different algorithm
would require a new document to be issued which updates this one.
Perhaps that's a feature.
Joe
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
