Subject: RE: Required Algorithms for Certificates

From: Hemma Prafullchandra <[email-masked]>
Date: 21 Dec 2000 12:45:34 -0800

On Thu, 21 December 2000, "Jim Schaad" wrote:
> Ambarish,
> What was said is that both RSA and DSA are the MUST for clients.  I have no
> problems with this myself.
> 
> jim

I agree. For those who are on the leading edge of
implementation and support of IETF standards going
back on "MUSTs" is totally irrelevant in this case.
We already support DSA (as it was a MUST) and RSA
(as the market demanded it) and will continue to
support both.

Hemma

---

From: Tim Polk <[email-masked]>
Date: Thu, 21 Dec 2000 17:04:37 -0500

Folks,

Since different algorithms are a natural fit for different applications, 
the selection of a single MUST algorithm for PKIX seems a bad idea.  That 
is the reason Jeff Schiller let us avoid this issue in the first place.  If 
S/MIME chooses RSA but IPsec chooses DSA and D-H, we would be in conflict 
with at least one of them.  PKIX should not be in the position of dictating 
algorithms to other working groups.  If PKIX decides to specify MUSTs or 
SHOULDs, they should be designed to support broad interoperability.

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.  Yes, it would be nice to move the 
burden to CAs since there will be relatively few CAs.  However, CAs that 
can sign with multiple algorithms doesn't help clients that verify with 
only one unless they issue each certificate multiple times, using each 
supported signing algorithm.  Not a solution, IMHO!

This implies that we need to move the burden to the clients, even though 
that will impact many clients.  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.  The client will never be forced to reject the 
certificate based on the signing algorithm - to me, that's 
interoperability.  (I am assuming, of course, that the client knows how to 
use the end entity's public key.  If the certificate contains a D-H key, 
and the client can't do D-H we still break down.  It wasn't the signature 
algorithm on the certificates that broke it, though...)

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.

Anyway, I personally like Russ's proposal.  I believe it doesn't put too 
great a burden on PKI clients and would foster interoperability.

My $0.02 (which may in fact be overpriced.)

Thanks,

Tim Polk

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 21 Dec 2000 15:53:35 -0800

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

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

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 21 Dec 2000 16:28:15 -0800

Tim Polk wrote:
> algorithms to other working groups.

There's the rub.  PKIX can't choose a (set of) algorithm(s) because PKIX is
so broadly applicable that any choice would shut out a particular community. 
It looks like algorithm choice is really up to the application.

That would be fine, but there seems to be an expectation that there is only
one certificate for a given entity, and that an entity is expected to use its
one certificate for all its applications.

Those two positions are irreconcilable.  Either a user has one cert for
S/MIME, SSL, IPSec, etc. (in which case all those applications will have to
use the same algorithm) or the user has multiple certs.  You can't have it
both ways.

I suggest that the expectation of a single "omnicert" is turning out to be
naive.  Already with existing deployments, users have different certs for
their different applications.  Even users of integrated applications (say, a
browser & S/MIME app) tend to have distinct certs for each protocol.

> If PKIX decides to specify MUSTs or SHOULDs, they should be designed to
> support broad interoperability.

Yes, but what kind of interoperability?  Does an S/MIME cert have to be
interoperable with an SSL cert?  Put another way, will an S/MIME application
ever need to use or process an SSL or IPSec cert?  I say no.  If you accept
that, then interoperability across all protocols becomes meaningless.

So it makes sense for the algorithm decision to be in the hands of the
protocols that adopt PKIX.  In fact, the "users" of PKIX are really other
IETF protocols.  Therefore, I suggest that PKIX have only one MUST with
respect to algorithms:

   Protocols that adopt PKIX SHALL require their applications to implement
   one of the PKIX-compliant algorithms described in [RFCx], [RFCy] and
[RFCz].
   PKIX implementors SHOULD implement the algorithm(s) required by the
   protocol(s) which their PKIX implementation will support.

This is a kind of meta-requirement for using PKIX, and I don't know if IETF
rules allow for that sort of thing.  But I do think it's a reasonable way
forward, because other protocols are then free to make the best choices for
themselves.  S/MIME, for example, could say "implementations SHALL use
[PKIX1] certificates that contain an RSA public key and that are signed using
RSASHA1."  IPSec could make similar requirements for, say, DSA & DH.  As long
as nobody tries to use their S/MIME cert for their VPN, things will work.

One final note: People who want to build generic PKIX toolkits are likely
going to need to implement all the PKIX-compliant algorithms.  This is pretty
much a given anyway (look at the existing toolkits).  What's really at issue
are application developers who aren't using a general PKIX toolkit.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

---

From: Ari Kermaier <[email-masked]>
Date: Fri, 22 Dec 2000 12:54:57 -0500

>It looks like algorithm choice is really up to the application.

I think this is an essential point. I believe that the goal of a 
specification like rfc2459 should be to maximize generality and 
interoperability, *not* to make it as easy as possible for every 
application developer to claim standards compliance in their marketing 
materials. Making RSA signatures MUST for CAs and both RSA and DSA MUST for 
user-agents guarantees both general interoperability and backwards 
compatibility. If a given vendor does not wish to support DSA, then his 
software will probably work in most cases. The decision to risk 
interoperability failure in some circumstances is his choice, and standards 
bodies should not be in the business of making him feel better about that 
choice. The idea of being able to (proudly?) claim standards compliance is 
the implication that this is some guarantee of 
completeness/robustness/ineroperability. If we relax the standards to make 
everything I'm-OK-you're-OK, then standards compliance becomes more a 
marketing tool than a yardstick of good implementations.

>that, then interoperability across all protocols becomes meaningless.

I don't accept that. There does not need to be any essential difference 
between an S/MIME cert and an SSL cert. If we make standards that encode 
the expectation that every application will need to use its own 
certificate, then we encourage unnecessary fragmentation of functionality 
and proliferation of keypairs. If an SSL certificate (what does that mean, 
BTW?) can be used to verify signatures on an S/MIME message, that means 
that an S/MIME application should be able to process it. If we say "well, 
if you wanted to sign S/MIME you should've made sure your integrated 
application had separate keypairs for each function" then we destroy the 
generality of the X.509 certificate design.

>IETF protocols.  Therefore, I suggest that PKIX have only one MUST with

Yes, protocols -- but not individual implementers. For example, the CRFM 
spec (rfc2511) defines the PasswordBasedMac algorithm to be able to use any 
appropriate OWF and MAC algorithms, but mandates the use of SHA-1 and 
HMAC-SHA1 for CMP/CRMF. This means that somebody who would rather use MD5 
in his CMP implementation is free to do so, but is not free to claim 
compliance with rfc2511.

Ari Kermaier
Phaos Technology