Diffie-Hellman Proof-of-Possession Algorithms
RFC 2875

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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, as follows,

                shared secret = ZZ = g^xy mod p

Prafullchandra & Schaad     Standards Track                     [Page 2]
RFC 2875     Diffie-Hellman Proof-of-Possession Algorithms     July 2000

         [This is done by the entity E as Rpub^y and by the Recipient
         as Epub^x, where Rpub is retrieved from the Recipient's DH
         certificate (or is the one that was locally generated by the
         Entity) and Epub is retrieved from the actual certification
         request.]

      c) A temporary key K is derived from the shared secret ZZ as
         follows:

            K = SHA1(LeadingInfo | ZZ | TrailingInfo),
               where "|" means concatenation.

            LeadingInfo ::= Subject Distinguished Name from certificate
            TrailingInfo ::= Issuer Distinguished Name from certificate

      d) Compute HMAC-SHA1 over the data `text' as per [RFC2104] as:

            SHA1(K XOR opad, SHA1(K XOR ipad, text))

         where,
            opad (outer pad) = the byte 0x36 repeated 64 times and
            ipad (inner pad) = the byte 0x5C repeated 64 times.

         Namely,

          (1)  Append zeros to the end of K to create a 64 byte string
               (e.g., if K is of length 16 bytes it will be appended
               with 48 zero bytes 0x00).
          (2)  XOR (bitwise exclusive-OR) the 64 byte string computed
               in step (1) with ipad.
          (3)  Append the data stream `text' to the 64 byte string