Diffie-Hellman Proof-of-Possession Algorithms (RFC2875)

Network Working Group H. Prafullchandra Request for Comments: 2875 Critical Path Inc Category: Standards Track J. Schaad July 2000

Diffie-Hellman Proof-of-Possession Algorithms

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing.

1. Introduction

PKCS #10 [RFC2314] defines a syntax for certification requests. It assumes that the public key being requested for certification corresponds to an algorithm that is capable of signing/encrypting. Diffie-Hellman (DH) is a key agreement algorithm and as such cannot be directly used for signing or encryption.

This document describes two new proof-of-possession algorithms using the Diffie-Hellman key agreement process to provide a shared secret as the basis of an integrity check value. In the first algorithm, the value is constructed for a specific recipient/verifier by using a public key of that verifier. In the second algorithm, the value is constructed for arbitrary verifiers.

Prafullchandra & Schaad Standards Track [Page 1]

RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms July 2000

2. Terminology

The following definitions will be used in this document

DH certificate = a certificate whose SubjectPublicKey is a DH public value and is signed with any signature algorithm (e.g. RSA or DSA).

3. Static DH Proof-of-Possession Process

The steps for creating a DH POP are:

1. An entity (E) chooses the group parameters for a DH key agreement.

This is done simply by selecting the group parameters from a certificate for the recipient of the POP process.

A certificate with the correct group parameters has to be available. Let these common DH parameters be g and p; and let this DH key-pair be known as the Recipient key pair (Rpub and Rpriv).

Rpub = g^x mod p (where x=Rpriv, the private DH value and ^ denotes exponentiation)

2. The entity generates a DH public/private key-pair using the parameters from step 1.

For an entity E:

Epriv = DH private value = y Epub = DH public value = g^y mod p

3. The POP computation process will then consist of:

a) The value to be signed is obtained. (For a RFC2314 object, the value is the DER encoded certificationRequestInfo field represented as an octet string.) This will be the ‘text’ referred to in [RFC2104], the data to which HMAC-SHA1 is applied.

b) A shared DH secret is computed, a...