Re: Required Algorithms for Certificates

[Marc Branchaud <marcnarc@xxxxxxxxx>]

Tim Polk wrote:
> 
> 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.

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.
 marcnarc@xcert.com        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+