RE: Required Algorithms for Certificates

["Yuriy Dzambasow" <yuriy@xxxxxxxxxxxxxxx>]

The reality is, in my opinion, that there will be PKIs (BIG I's) and PKis
(Little i's), both of which wanting to claim PKIX compliance.  To achieve
that, I think there are two options, both of which I can support:

1) Mandate a single algorithm on clients and CAs (RSA with SHA-1), and state
the others are MAY implements
2) Do not specify anything in son-of-2459 with respect to required
algorithms, but rather provide text that encourages CAs to implement support
for algorithms based on applications that the CA needs to support, and
further, have groups like S/MIME, TLS, and IPSEC define the required
algorithms.

Yuriy

-----Original Message-----
From: Frank Balluffi [mailto:frankb@valicert.com]
Sent: Friday, December 22, 2000 10:22 AM
To: 'Marc Branchaud'; ietf-pkix@imc.org
Subject: RE: Required Algorithms for Certificates

Marc Branchaud said:

> I suggest that the expectation of a single "omnicert" is
> turning out to be
> naive.

It seems to me that the REAL issue is whether we want a PKI which anyone can
dynamically plug into or a PKi (note the small i) which only pre-arranged
groups can plug into. I would prefer the former. My sense is that MUST RSA
has a better chance of satisfying the former for the following reasons:

1. one algorithm minimizes the number of algorithm combinations
2. RSA can be used for both signing and encryption
3. RSA already has more critical mass than DSA
4. one algorithm minimizes the system resource usage on small footprint
devices
5. RSA is in the public domain

Also, I do not see a problem with changing MUST DSA to {SHALL | MAY} DSA as
long as a it is scheduled with reasonable warning. There was a good reason
for mandating DSA and that reason has changed.

To reiterate, the question remains, "What the heck are we trying to
accomplish here?"

Frank

> -----Original Message-----
> From: Marc Branchaud [mailto:marcnarc@xcert.com]
> Sent: Thursday, December 21, 2000 7:28 PM
> To: ietf-pkix@imc.org
> Subject: Re: Required Algorithms for Certificates
>
>
>
> 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/
+------------------------------------------------------------------------+