RE: Required Algorithms for Certificates

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

I agree with Paul. I see absolutely no move to support DSA/DH in S/MIME, 
SSL/TLS, or IPSEC, regardless of what the IETF standards state.

We implemented DSA within NICI primarily because it was available in BSAFE, 
relatively easy to do, and was required for any meaningful compliance with 
FIPS 140-1 at the time, NOT because we expected anyone to ever use it.

Within a more or less general-purpose crypto library, the overhead isn't all that
great, and clearly there isn't any issue of interoperability at the API level to 
worry about, so in that environment I more or less don't care.  However, if
I were trying to develop some crypto applications on a tiny-weenie processor
like a credit card, that would be a much different story. Then I would simply
be non-compliant, rather than include something that provided me no benefit.

Other than avoiding the intellectual property issues (which are now moot), I see 
no reason to make DSA even a SHOULD, much less a MUST.  I wouldn't argue
with a MAY, if that helps people (both of them? :-) who have already implemented 
DSA because they actually believed the standards, or because they thought that 
if the Government required it as part of their procurement specs, they would actually 
buy (only) those products that complied. But I don't think there is any issue that DSA 
is a dead horse.

The real issue, I believe, is going to be between RSA and ECDSA.  RSA obviously 
has a lot going for it as the de facto standard.  And ECDSA also has a lot going for it,
in terms of compactness and minimum power requirements.

I don't have a good crystal ball that would tell me whether WAP and some of the 
other wireless applications are going to succeed or fail. Personally, I have a 
mini-browser built into my cellular phone (a Samsung), and I have yet to find ANY
application for it that is worth the hassle, much less the airtime.  Maybe if I were 
a day trader I would view things differently.

But although I'm still looking for that killer application, I would not be inclined
to bet against the possibility.  Somebody, somewhere, will probably come up with
something useful.

And in that case, I think that ECDSA will become a requirement.

Because of all of the existing CAs and certificates, those applications are going 
to have to continue to support RSA-signed certificates for the indefinite future.
Fortunately, validating an RSA signature is a lot easier than generating one.

But because digitally signing something is a lot easier (in terms of power and 
size) with ECDSA, end-user certs for such applications are going to have to 
contain ECDSA signing keys, even if the certificates themselves are signed 
with RSA for the time being.  And there will be pressure to have the certs 
themselves signed with ECDSA, in order to reduce the overall size.

So maybe the requirement hasn't quite materialized, but I would support making
RSA a MUST, deprecating DSA to a MAY, and making ECDSA a SHOULD, 
with the option of transitioning ECDSA to a MUST if and when a critical mass 
of implementations and users can be demonstrated.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software




>>> Paul Hoffman / VPNC <paul.hoffman@vpnc.org> 12/21/00 04:53PM >>>
At 5:04 PM -0500 12/21/00, Tim Polk wrote:
>If PKIX decides to specify MUSTs or SHOULDs, they should be designed 
>to support broad interoperability.

Exactly. It is easier to get interoperability with one algorithm than 
with two, particularly when one of those algorithms hasn't been 
widely implemented and tested in products.

>Interoperability is a prime concern here at NIST.  In terms of 
>algorithm independence, we have come to the conclusion that 
>interoperability *requires* multi-algorithm clients.

Could you explain the logic there a bit more? If only one algorithm 
is mandated, how does that leasd to less interoperability?

>This implies that we need to move the burden to the clients, even 
>though that will impact many clients.

Here we disagree. Do you *really* think that all the IPsec 
implementations and all the S/MIME implementations are going to add 
DSA support? That is certainly not what I hear from the members of my 
organizations; even the ones who do DSA support are not sure that it 
works that well because it is rarely tested.

>   If a PKIX client can validate both DSA and RSA signatures, it can 
>handle certificates from any CA when signed with a PKIX-specified 
>algorithm.

If we only mandate RSA, well, you can fill in the rest...

>The question is whether multiple algorithm support is a practical 
>requirement for clients.  I just took a few minutes to scan the FIPS 
>140-1 validated crypto module list.  This list currently has 130 
>modules - some hardware, some software.  (For those interested, see 
>http://csrc.nist.gov/cryptval/140-1/1401val.htm)  Many of those 
>cryptographic modules already support multiple signature algorithms. 
>I didn't count, but it appears that most of the recent products 
>(both hardware and software) support both DSA and RSA for signatures.
>
>To me, this implies that multiple algorithm support is reasonable 
>unless the device footprint must be very small.  This may be a 
>biased data set, though.  Validated products are required to support 
>at least one FIPS-approved algorithm, and RSA has only recently 
>become a FIPS-approved algorithm.

Bingo: that obviously skewed the requirements. In the IPsec and 
S/MIME space, there was no such requirement (that is, S/MIME vendors 
simply ignore the v3 specs), and there are almost no commercial or 
even freeware implementations using DSA.

--Paul Hoffman, Director
--VPN Consortium