RE: Combo DSS/ElGamal keys
dpkemp@missi.ncsc.mil (David P. Kemp) Fri, 01 August 1997 15:33 UTC
Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA28742; Fri, 1 Aug 1997 08:33:12 -0700
Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id IAA28736; Fri, 1 Aug 1997 08:33:11 -0700
Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA04273 for <ietf-pkix@tandem.com>; Fri, 1 Aug 1997 11:32:48 -0400
Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma004271; Fri Aug 1 11:32:30 1997
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA05136 for <ietf-pkix@tandem.com>; Fri, 1 Aug 1997 11:29:37 -0400
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA10438; Fri, 1 Aug 1997 11:31:42 -0400
Date: Fri, 01 Aug 1997 11:31:42 -0400
From: dpkemp@missi.ncsc.mil
Message-Id: <199708011531.LAA10438@argon.ncsc.mil>
To: ietf-pkix@tandem.com
Subject: RE: Combo DSS/ElGamal keys
X-Sun-Charset: US-ASCII
> From: Carlisle Adams <Cadams@entrust.com> > > Maybe I haven't seen the full details of this proposal, but what you've > written here doesn't make sense to me. If the DH public value is in a > *certificate*, why would another public value (in this case a DSS value) > _in_the_same_certificate_ be useful for authenticating the DH exchange? > > In other words, if you trust the certificate to tie the DSS public value > to an entity, why can you not trust the certificate to tie the DH public > value to an entity? What further authentication assurance does the DSS > key (in the same certificate as the DH value) have? One situation where this is needed is in email, where you have only one message to establish the key, not a two or three message interactive handshake. "Paul's book :-)" (the Handbook of Applied Cryptograpy) describes El Gamal key agreement in section 12.6 and calls it "half-certified Diffie-Hellman". In it, the recipient is authenticated to the originator by the D-H certificate, but if the recipient wants to authenticate the originator, some other mechanism (such as a signature certificate) is needed. So 1-message protocols which use CAs to certify key establishment keys might find a DH-with-DSS certificate (to be used only for an atomic key establishment algorithm) to be appropriate. But specifically for PGP, if an issuer certifies the user's DSS key and the user signs his own DH public key, then the issue of multiple-key certificates does not even come up - the DH and DSS keys are signed by different entities, even if they do happen to be aggregated together in some larger certificate-containing structure.
- Re: Combo DSS/ElGamal keys Denis Pinkas
- RE: Combo DSS/ElGamal keys Charles Moore
- Re: Combo DSS/ElGamal keys John Lowry
- Re: Combo DSS/ElGamal keys Peter Williams
- Re: Combo DSS/ElGamal keys Fillingham, David W.
- RE: Combo DSS/ElGamal keys
- RE: Combo DSS/ElGamal keys Charles Breed
- Re: Combo DSS/ElGamal keys Stephen Kent
- RE: Combo DSS/ElGamal keys Carlisle Adams
- Re: Combo DSS/ElGamal keys Peter Williams
- Re: Combo DSS/ElGamal keys Peter Williams
- Re: Combo DSS/ElGamal keys
- Re: Combo DSS/ElGamal keys Peter Williams
- RE: Combo DSS/ElGamal keys Carlisle Adams
- Re: Combo DSS/ElGamal keys David P. Kemp
- Re: Combo DSS/ElGamal keys Mark Shuttleworth
- Re: Combo DSS/ElGamal keys Dan Laska
- Re: Combo DSS/ElGamal keys Charles Breed
- Re: Combo DSS/ElGamal keys David P. Kemp
- Combo DSS/ElGamal keys Mark Shuttleworth
- RE: Combo DSS/ElGamal keys David P. Kemp