Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard

From: "Alan Shepherd" <[email-masked]>
Date: Mon, 5 Jun 2000 16:58:41 +0100

Please forgive me if this is a terribly naive question, but I would like to
know what problems arise if a public key is certified erroneously.  I can
not see what security problems arise through this and would very much
appreciate someone wiser explaining it!

Thanks for you help.

Alan

> -----Original Message-----
> From: The IESG [mailto:[email-masked]]
> Sent: 31 May 2000 14:03
> Cc: RFC Editor; RFC Editor; RFC Editor
> Subject: Protocol Action: Diffie-Hellman Proof-of-Possession 
> Algorithms
> to Proposed Standard
> 
> 
> 
> 
> The IESG has approved the Internet-Draft 'Diffie-Hellman
> Proof-of-Possession Algorithms' <draft-ietf-pkix-dhpop-02.txt> as a
> Proposed Standard.  This document is the product of the Public-Key
> Infrastructure (X.509) Working Group.  The IESG contact persons are
> Jeffrey Schiller and Marcus Leech.
> 
> 
>  
> Technical Summary
>  
>   One of the important requirements in cryptographic protocols is the
>   ability for an entity to prove they have possession of a particular
>   key. In particular, Certifying Authorities prior to the 
> issuance of a
>   certificate, need to prove that the entity for which the certificate
>   will be issued in fact does have the private key that corresponds to
>   the public key which is included in the certificate.
> 
>   The traditional approach used with public key encryption 
> systems such
>   as the RSA system is to have the challenger require the entity
>   holding a given private key to sign a challenge string.
> 
>   However the Diffie-Hellman (DH) algorithm does not directly lend
>   itself to providing such signatures, as it is at heart a key
>   agreement algorithm.  This document describes two methods for
>   producing a signature from a Diffie-Hellman key pair.
> 
> Working Group Summary
> 
>   Consensus was reached on the approach used in this document.
> 
> Protocol Quality
> 
>   Jeffrey I. Schiller reviewed this document for the IESG. Furthermore
>   the PKIX Working Group contains members with significant
>   cryptographic experience who also have reviewed this document.
> 
> Note to RFC Editor:
> 
> There were some word-wrapping problems introduced in Appendix A of 
> the document that need to be corrected:
> 
> Appendix A:
> 
> OLD:
>    DH-Sign DEFINITIONS IMPLICIT TAGS ::=
> 
>    BEGIN
>    --EXPORTS ALL
>    -- The types and values defined in this module are exported for use
>    in
>    -- the other ASN.1 modules. Other applications may use them for
>    their
>    -- own purposes.
> 
> NEW/FIXED:
>    DH-Sign DEFINITIONS IMPLICIT TAGS ::=
> 
>    BEGIN
>    --EXPORTS ALL
>    -- The types and values defined in this module are exported for use
>    -- in the other ASN.1 modules. Other applications may use them
>    -- for their own purposes.
> 

------------------------------------------------------------------------------------------
This message is for the named person’s use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.

---

From: Carlisle Adams <[email-masked]>
Date: Tue, 6 Jun 2000 10:14:11 -0400

Hi Alan,

I make no claim to be "someone wiser", but I will point out that
proof-of-possession threads have been both long and numerous on this list in
the past.

The basic principle is that POP is not primarily done to avoid security
problems.  A basic underlying assumption in any certificate-using
environment is that the entity bound to the certificate actually holds the
corresponding private key.  POP ensures that this assumption is valid (at
least at the time of certificate creation).  If I can't assume that you hold
the private key, why in the world would I use your certificate?  If I have
no fundamental reason to use your certificate, why does the certificate
(and, through generalization, the PKI) exist?

POP is done by a CA (or occasionally as part of an operational protocol
between parties) to try and ensure that certificates have some meaning and
value and are not just worthless strings of bits.  If a particular security
problem can be avoided in some cases by doing POP, that's just a useful side
benefit.

Carlisle.

> ----------
> From: 	Alan Shepherd[SMTP:[email-masked]]
> Sent: 	Monday, June 05, 2000 11:58 AM
> To: 	[email-masked]'
> Subject: 	RE: Protocol Action: Diffie-Hellman Proof-of-Possession
> Algorithm s to Proposed Standard
> 
> This message is for the named person's use only.  It may contain
> confidential, proprietary or legally privileged information.  No
> confidentiality or privilege is waived or lost by any mistransmission.  If
> you receive this message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and notify
> the sender.  You must not, directly or indirectly, use, disclose,
> distribute, print, or copy any part of this message if you are not the
> intended recipient. PROTEK Network Management Group and each of its
> subsidiaries reserve the right to monitor all e-mail communications
> through its networks.  Any views expressed in this message are those of
> the individual sender, except where the message states otherwise and the
> sender is authorised to state them to be the views of any such entity.
> 
> 
> 
>