RE: Required Algorithms for Certificates

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Many PKis (little i) does not necessarily equal a PKI (big I). A PKI (big I)
does, however, enable PKis (little i). So I am still not convinced that our
current path will result in a PKI (big I). Please excuse the wordiness.

Frank

> -----Original Message-----
> From: Yuriy Dzambasow [mailto:yuriy@digsigtrust.com]
> Sent: Friday, December 22, 2000 11:03 AM
> To: Frank Balluffi; 'Marc Branchaud'; ietf-pkix@imc.org
> Subject: RE: Required Algorithms for Certificates
> 
> 
> 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/
> +-------------------------------------------------------------
> -----------+
>