Re: RSA vs. DSA MUST

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

Chicken and egg is exactly the situation we find ourselves in.  Implementors certainly want to support their customers, but don't want to be "required" by standards to implement algorithms that no one uses or are willing to pay for.

Ozan Gonenc also makes a good point in suggesting that perhaps the MUST algorithms be limited to FIPS approved algorithms.  I'm a slightly concerned that this may be too US-centric a view, but on the other hand I haven't heard of any other governments or customers requiring or promoting any other algorithms, except for unpublished/proprietary/classified algorithms used in certain restricted sectors.  (An exception might be GOST, but so far we can't even get the Russians to agree to pay anything for the capability., much less anyone else) So maybe limiting the MUST algorithms to a subset of the FIPS-approved list is acceptable.  At least the FIPS listing implies a rather serious degree of vetting as to the security of the algorithms, which is something I don't think the IETF is institutionally capable of, not withstanding the cryptographic expertise of some of the members.

The point about having at least one algorithm in the suite that could be used if RSA were suddenly shown to be seriously flawed is also valid, so long as we don't get carried away with the list!

FIPS 186-2 includes DSA, ANSI X9.31 RSA, and X9.31 Elliptic Curve DSA; but not PKCS-1 RSA, the one interoperable algorithm that everyone is using presently!

Hmm.

I'm not necessarily advocating this position -- I might like to think about it some more myself -- but just for the sake of argument and to take the pulse, what would people think of making ANSI X9.31 RSA a MUST,  X9.31 EC-DSA a SHOULD, and DSA and PKCS-1 RSA a MAY?

It is my understanding that X9.31 RSA is considered to be superior to PKCS-1 RSA in terms of resistance to certain forms of attack, and should not be that great a stretch for existing RSA implementations, and hence the MUST. We wouldn't deprecate PKCS-1 RSA (at least not yet), since it must continue to be supported for backwards compatibility.

This wouldn't deprecate DSA either, but it wouldn't be required  for people outside of the (quite limited) community of interest presently using it. 

EC-DSA certainly beats regular DSA in terms of speed and size and deserves to be included in its own right, but I'm not entirely clear as to the patent situation, hence the SHOULD and not a MUST.

In the area of symmetric algorithms, as soon as Rijndael is officially certified as the AES algorithm I believe we should promote AES to MUST, along with triple-DES and single DES for backwards compatibility.  ( haven't heard of anyone clamoring for SKIPJACK, so I think it can safely be ignored in favor of triple-DES and/or AES.)

Likewise, I think we will have to add SHA-386 and SHA-512 as MUST algorithms, along with SHA-1, and probably deprecate MD2 and MD5.

What think ye?

Bob


>Enzo has captured the chicken-and-egg essence of my concern.  The U.S.
>Government has a requirement to purchase products which support FIPS
>186-2 algorithms (this includes DSA and ANSI X9.31 RSA, but not PKCS-1
>RSA).  And, at least in the DoD, we have requirements coming from our
>customers to be algorithm independent:
>
>  "PKI must support a variety of public key cryptographic algorithms
>   both in the public/private key pairs created and certified by PKI,
>   and in the algorithms used to apply digital signatures to certificates
>   and other PKI products.  PKI must support the concurrent use of several
>   digital signature algorithms for issuing certificates and must be able
>   to migrate over time to using new signature algorithms."
>
>           -- DoD PKI Operational Requirements Document, 22 October 2000
>
>
>There is also the fact that DSA signatures are significantly smaller
>than RSA signatures, especially as we move to public keys above 1024 bits
>and the signature could be bigger than the entire to-be-signed certificate.
>This doesn't matter in many environments, but it does in some.
>
>If vendors look at what certificates have already been issued to decide
>what certificates to support in products under development, we will never
>evolve.  I favor keeping DSA (in addition to RSA) as a MUST for S/MIME
>clients because algorithm independence is valuable in and of itself.
>
>Dave
>
>
>
>> From: "Enzo Michelangeli" <em@xxxxxxx> 
>> 
>> Well, there is one problem, and it's due to the store-and-forwad nature of
>> e-mail which prevents negotiation, making it impossible to know whether a
>> given algorithm is supported by a new recipient (think, e.g., of signed
>> messages sent to mailing list). The result is that everybody ends up using
>> ONLY the common denominator, i.e. the "MUST" algorithms. Incidentally, this
>> was precisely the root of the trouble with 40-bit security in the bad old
>> days: a sort of Grisham's Law for algorithms...
>> In my opinion, "MAY" algorithms are pretty useless in non-interactive
>> contexts, and if DSA is not kept as a "MUST" (my preferred choice), it might
>> as well be dropped altogether.
>> 
>> Enzo
>