Diffie-Hellman Proof-of-Possession Algorithms
obsoletes
- rfc-2875 — Diffie-Hellman Proof-of-Possession Algorithms
Extracted elements (24)
No EC analog of the Discrete Logarithm Signature (ECDSA-like DH POP) was defined because ECDH keys use predefined named curves paired with specific hash algorithms; if a key can perform ECDSA it should use the correctly sized hash directly, making a modified variant unnecessary unlike the DH case where group parameters are typically aligned to encryption rather than hash sizes.
The digest expansion algorithm in Section 5.1 does not add security beyond the b-bit hash output; its sole purpose is to produce a value of sufficient length to cover the range [0, q-1] when q is larger than b bits, making signature reversal harder without increasing the true entropy.
The Discrete Logarithm Signature was introduced to provide POP for DH keys that do not share a common parameter set. When multiple keys share the same DH parameters, the probability of collisions increases and brute-force attacks can target the entire parameter set at once; a signature-based approach with a q parameter eliminates this dependency.
The Static DH POP binds the POP value to a specific recipient by incorporating the recipient's Subject DN as LeadingInfo and Issuer DN as TrailingInfo in the KDF input. This means only the intended CA can verify the request, protecting the entity from rogue CAs that might intercept the certification request.
The OID id-dhPop-static-sha1-hmac-sha1 has the same value as id-dh-sig-hmac-sha1 (id-pkix id-alg 6.3) defined in the predecessor RFC 2875; similarly id-alg-dhPop-sha1 equals id-alg-dh-pop (6.4). New names were assigned for consistency while preserving backward compatibility.
Discrete Log Signature verification MUST perform strong primality verification of both p and q, verify that q is a factor of p-1, and verify r and s are in range [1, q-1] before proceeding; any failure MUST cause the signature to be considered invalid.
For Static ECDH POP, both creator and verifier MUST use a common set of elliptic curve group parameters; for PKIX-based applications these are almost always identified by a named curve per RFC 3279 Section 2.3.5.
For the Discrete Logarithm Signature, DomainParameters SHOULD be omitted in the signature value but MUST be present in the associated key request (PKCS #10 or CRMF).
For the Static DH POP algorithm, the entity MUST use a recipient certificate's DH group parameters (g and p); a certificate with the correct group parameters must be available to allow computation of the shared secret.
In all Static DH POP and Static ECDH POP SIGNATURE-ALGORITHM objects, the algorithm parameters MUST be absent.
The Discrete Logarithm Signature requires the existence of a q parameter in the DH group. If the key-generation algorithm from RFC 2631 is used, the required restrictions are met. The length of q MUST be at least b bits where b is the output size of the hash function.
Discrete Log Signature computation: generate random k (0 < k-1 < q), compute r = (g^k mod p) mod q, compute s = ((k^-1) * (m + x*r)) mod q; repeat if r or s is zero. Returns (r, s) as DSA-Sig-Value.
The digest expansion algorithm for Discrete Log Signature iteratively appends HASH(m) to m for n = FLOOR(L/b) iterations (where L is the bit length of q and b is hash output bits), then takes the LEFTMOST(m, L-1) bits, ensuring 0 <= m < q without adding security beyond the underlying hash.
The Discrete Logarithm Signature algorithm is based on DSA but removes FIPS-186-3 size restrictions on p and q, replacing them with the requirement that q must be at least b bits (where b is the hash output size). It requires a q parameter in the DH group parameters and produces a DSA-Sig-Value (r, s) pair.
The Static DH POP algorithm establishes proof-of-possession by computing a shared DH secret ZZ = g^(x*y) mod p, deriving a temporary key K = KDF(LeadingInfo | ZZ | TrailingInfo), and producing MAC(K, text) where LeadingInfo is the Subject DN and TrailingInfo is the Issuer DN from the recipient's certificate.
The Static ECDH POP algorithm mirrors the Static DH POP process but uses elliptic curve operations: shared secret ZZ is the x-coordinate of the point Epriv * Rpub, key K is derived as KDF(LeadingInfo | ZZ | TrailingInfo), and the POP value is MAC(K, text) encoded in DhSigStatic.
This document registers Discrete Logarithm Signature OIDs under id-pkix id-alg: id-alg-dh-pop / id-alg-dhPop-sha1 (arc 6.4), id-alg-dhPop-sha224 (6.5), id-alg-dhPop-sha256 (6.6), id-alg-dhPop-sha384 (6.7), id-alg-dhPop-sha512 (6.8).
This document registers Static DH POP OIDs under id-pkix id-alg: id-dh-sig-hmac-sha1 (arc 6.3), id-alg-dhPop-static-sha224-hmac-sha224 (6.15), id-alg-dhPop-static-sha256-hmac-sha256 (6.16), id-alg-dhPop-static-sha384-hmac-sha384 (6.17), id-alg-dhPop-static-sha512-hmac-sha512 (6.18).
This document registers Static ECDH POP OIDs under id-pkix id-alg: id-alg-ecdhPop-static-sha224-hmac-sha224 (arc 6.25), id-alg-ecdhPop-static-sha256-hmac-sha256 (6.26), id-alg-ecdhPop-static-sha384-hmac-sha384 (6.27), id-alg-ecdhPop-static-sha512-hmac-sha512 (6.28).
All security depends on the secrecy of private keying material. Disclosure of either sender or recipient private keys compromises all messages sent or received using those keys; loss of a private key results in inability to verify the POP.
Implementers MUST avoid small DH or EC groups when selecting parameters; FIPS-186-3 Appendixes A and B.2 and RFC 6090 Section 10 provide guidance on parameter selection to resist small subgroup attacks.
None of the algorithms defined in this document are meant for general-purpose signing; they are designed solely for Proof-of-Possession in PKCS #10 and CRMF constructs and MUST NOT be used as general-purpose signature algorithms.
The Static DH POP and Static ECDH POP algorithms provide only integrity checking, not origination service, because an appropriate MAC value can be produced by either party to the key agreement. Only the Discrete Logarithm Signature provides both integrity and origination assurance.
DhSigStatic is a SEQUENCE with an OPTIONAL IssuerAndSerialNumber field (identifying the certificate from which the verifier's public key was obtained) and a required MessageDigest field (hashValue) containing the MAC output. The issuerAndSerial field is omitted if the public key did not come from a certificate.