6955
PROPOSED STANDARD
Diffie-Hellman Proof-of-Possession Algorithms
Authors: J. Schaad, H. Prafullchandra
Date: May 2013
Working Group: NON WORKING GROUP
Stream: IETF
Obsoletes:
RFC 2875
Abstract
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
This document obsoletes RFC 2875.
RFC 6955
PROPOSED STANDARD
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 6955 Soaring Hawk Consulting
Obsoletes: <a href="./rfc2875">2875</a> H. Prafullchandra
Category: Standards Track HyTrust, Inc.
ISSN: 2070-1721 May 2013
<span class="h1">Diffie-Hellman Proof-of-Possession Algorithms</span>
Abstract
This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair and one method for producing an
integrity check value from an Elliptic Curve key pair. This behavior
is needed for such operations as creating the signature of a Public-
Key Cryptography Standards (PKCS) #10 Certification Request. These
algorithms are designed to provide a Proof-of-Possession of the
private key and not to be a general purpose signing algorithm.
This document obsoletes <a href="./rfc2875">RFC 2875</a>.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6955">http://www.rfc-editor.org/info/rfc6955</a>.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Changes since <a href="./rfc2875">RFC 2875</a> .....................................<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Requirements Terminology ...................................<a href="#page-5">5</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Notation ........................................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Static DH Proof-of-Possession Process ...........................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. ASN.1 Encoding .............................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Discrete Logarithm Signature ...................................<a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. Expanding the Digest Value ................................<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. Signature Computation Algorithm ...........................<a href="#page-12">12</a>
<a href="#section-5.3">5.3</a>. Signature Verification Algorithm ..........................<a href="#page-13">13</a>
<a href="#section-5.4">5.4</a>. ASN.1 Encoding ............................................<a href="#page-14">14</a>
<a href="#section-6">6</a>. Static ECDH Proof-of-Possession Process ........................<a href="#page-16">16</a>
<a href="#section-6.1">6.1</a>. ASN.1 Encoding ............................................<a href="#page-18">18</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-21">21</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-21">21</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-21">21</a>
<a href="#appendix-A">Appendix A</a>. ASN.1 Modules .........................................<a href="#page-23">23</a>
<a href="#appendix-A.1">A.1</a>. 2008 ASN.1 Module ..........................................<a href="#page-23">23</a>
<a href="#appendix-A.2">A.2</a>. 1988 ASN.1 Module ..........................................<a href="#page-28">28</a>
<a href="#appendix-B">Appendix B</a>. Example of Static DH Proof-of-Possession ..............<a href="#page-30">30</a>
<a href="#appendix-C">Appendix C</a>. Example of Discrete Log Signature .....................<a href="#page-38">38</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Among the responsibilities of a Certification Authority (CA) in
issuing certificates is a requirement that it verifies the identity
for the entity to which it is issuing a certificate and that the
private key for the public key to be placed in the certificate is in
the possession of that entity. The process of validating that the
private key is held by the requester of the certificate is called
Proof-of-Possession (POP). Further details on why POP is important
can be found in <a href="./rfc4211#appendix-C">Appendix C of RFC 4211</a> [<a href="#ref-CRMF" title=""Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)"">CRMF</a>].
This document is designed to deal with the problem of how to support
POP for encryption-only keys. PKCS #10 [<a href="./rfc2986" title=""PKCS #10: Certification Request Syntax Specification Version 1.7"">RFC2986</a>] and the Certificate
Request Message Format (CRMF) [<a href="#ref-CRMF" title=""Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)"">CRMF</a>] both define syntaxes for
Certification Requests. However, while CRMF supports an alternative
method to support POP for encryption-only keys, PKCS #10 does not.
PKCS #10 assumes that the public key being requested for
certification corresponds to an algorithm that is capable of
producing a POP by a signature operation. Diffie-Hellman (DH) and
Elliptic Curve Diffie-Hellman (ECDH) are key agreement algorithms
and, as such, cannot be directly used for signing or encryption.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
This document describes a set of three POP algorithms. Two methods
use the key agreement process (one for DH and one for ECDH) to
provide a shared secret as the basis of an integrity check value.
For these methods, the value is constructed for a specific recipient/
verifier by using a public key of that verifier. The third method
uses a modified signature algorithm (for DH). This method allows for
arbitrary verifiers.
It should be noted that we did not create an algorithm that parallels
the Elliptical Curve Digital Signature Algorithm (ECDSA) as was done
for the Digital Signature Algorithm (DSA). When using ECDH, the
common practice is to use one of a set of predefined curves; each of
these curves has been designed to be paired with one of the commonly
used hash algorithms. This differs in practice from the DH case
where the common practice is to generate a set of group parameters,
either on a single machine or for a given community, that are aligned
to encryption algorithms rather than hash algorithms. The
implication is that, if a key has the ability to perform the modified
DSA algorithm for ECDSA, it should be able to use the correct hash
algorithm and perform the regular ECDSA signature algorithm with the
correctly sized hash.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Changes since <a href="./rfc2875">RFC 2875</a></span>
The following changes have been made:
o The Static DH POP algorithm has been rewritten for
parameterization of the hash algorithm and the Message
Authentication Code (MAC) algorithm.
o New instances of the Static DH POP algorithm have been created
using the Hashed Message Authentication Code (HMAC) paired with
the SHA-224, SHA-256, SHA-384, and SHA-512 hash algorithms.
However, the current SHA-1 algorithm remains identical.
o The Discrete Logarithm Signature algorithm has been rewritten for
parameterization of the hash algorithm.
o New instances of the Discrete Logarithm Signature have been
created for the SHA-224, SHA-256, SHA-384, and SHA-512 hash
functions. However, the current SHA-1 algorithm remains
identical.
o A new Static ECDH POP algorithm has been added.
o New instances of the Static ECDH POP algorithm have been created
using HMAC paired with the SHA-224, SHA-256, SHA-384, and SHA-512
hash functions.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Requirements Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
When the words are in lower case they have their natural language
meaning.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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).
ECDH certificate = a certificate whose SubjectPublicKey is an ECDH
public value and is signed with any signature algorithm (e.g., RSA
or ECDSA).
Proof-of-Possession (POP) = a means that provides a method for a
second party to perform an algorithm to establish with some degree of
assurance that the first party does possess and has the ability to
use a private key. The reasoning behind doing POP can be found in
<a href="#appendix-C">Appendix C</a> in [<a href="#ref-CRMF" title=""Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)"">CRMF</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Notation</span>
This section describes mathematical notations, conventions, and
symbols used throughout this document.
a | b : Concatenation of a and b
a ^ b : a raised to the power of b
a mod b : a modulo b
a / b : a divided by b using integer division
a * b : a times b
Depending on context, multiplication may be within
an EC or normal multiplication
KDF(a) : Key Derivation Function producing a value from a
MAC(a, b) : Message Authentication Code function where
a is the key and b is the text
LEFTMOST(a, b) : Return the b left most bits of a
FLOOR(a) : Return n where n is the largest integer such that
n <= a
<span class="grey">Schaad & Prafullchandra Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Details on how to implement the HMAC version of a MAC function used
in this document can be found in <a href="./rfc2104">RFC 2104</a> [<a href="./rfc2104" title=""HMAC: Keyed-Hashing for Message Authentication"">RFC2104</a>], <a href="./rfc6234">RFC 6234</a>
[<a href="./rfc6234" title=""US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"">RFC6234</a>], and <a href="./rfc4231">RFC 4231</a> [<a href="./rfc4231" title=""Identifiers and Test Vectors for HMAC- SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512"">RFC4231</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Static DH Proof-of-Possession Process</span>
The Static DH POP algorithm is set up to use a Key Derivation
Function (KDF) and a MAC. This algorithm requires that a common set
of group parameters be used by both the creator and verifier of the
POP value.
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 the common DH parameters be g and p; and let the DH key pair
from the certificate be known as the recipient (R) key pair (Rpub
and Rpriv).
Rpub = g^x mod p (where x=Rpriv, the private DH value)
2. The entity generates a DH public/private key pair using the group
parameters from step 1.
For an entity (E):
Epriv = DH private value = y
Epub = DH public value = g^y mod p
<span class="grey">Schaad & Prafullchandra Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
3. The POP computation process will then consist of the following
steps:
(a) The value to be signed (text) is obtained. (For a PKCS #10
object, the value is the DER-encoded
certificationRequestInfo field represented as an octet
string.)
(b) A shared DH secret is computed as follows:
shared secret = ZZ = g^(x*y) mod p
[This is done by E as Rpub^y and by the recipient as Epub^x,
where Rpub is retrieved from the recipient's DH certificate
(or is provided in the protocol) and Epub is retrieved from
the Certification Request.]
(c) A temporary key K is derived from the shared secret ZZ as
follows:
K = KDF(LeadingInfo | ZZ | TrailingInfo)
LeadingInfo ::= Subject Distinguished Name from
recipient's certificate
TrailingInfo ::= Issuer Distinguished Name from
recipient's certificate
(d) Using the defined MAC function, compute MAC(K, text).
The POP verification process requires the recipient to carry out
steps (a) through (d) and then simply compare the result of step (d)
with what it received as the signature component. If they match,
then the following can be concluded:
(a) The entity possesses the private key corresponding to the public
key in the Certification Request because it needs the private
key to calculate the shared secret; and
(b) Only the recipient that the entity sent the request to could
actually verify the request because it would require its own
private key to compute the same shared secret. In the case
where the recipient is a CA, this protects the entity from
rogue CAs.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ASN.1 Encoding</span>
The algorithm outlined above allows for the use of an arbitrary hash
function in computing the temporary key and the MAC algorithm. In
this specification, we define object identifiers for the SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512 hash values and use HMAC for
the MAC algorithm. The ASN.1 structures associated with the Static
DH POP algorithm are:
DhSigStatic ::= SEQUENCE {
issuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-dhPop-static-sha1-hmac-sha1
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 3
}
id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::=
id-dh-sig-hmac-sha1
sa-dhPop-static-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha224-hmac-sha224
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 15
}
sa-dhPop-static-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha256-hmac-sha256
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 16
}
sa-dhPop-static-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha384-hmac-sha384
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 17
}
sa-dhPop-static-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha512-hmac-sha512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 18
}
In the above ASN.1, the following items are defined:
DhSigStatic
This ASN.1 type structure holds the information describing the
signature. The structure has the following fields:
issuerAndSerial
This field contains the issuer name and serial number of the
certificate from which the public key was obtained. The
issuerAndSerial field is omitted if the public key did not come
from a certificate.
hashValue
This field contains the result of the MAC operation in
step 3(d) (<a href="#section-4">Section 4</a>).
sa-dhPop-static-sha1-hmac-sha1
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing a signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-dhPop-static-sha1-hmac-sha1
This OID identifies the Static DH POP algorithm that uses SHA-1 as
the KDF and HMAC-SHA1 as the MAC function. The new OID was
created for naming consistency with the other OIDs defined here.
The value of the OID is the same value as id-dh-sig-hmac-sha1,
which was defined in the previous version of this document
[<a href="./rfc2875" title=""Diffie-Hellman Proof-of-Possession Algorithms"">RFC2875</a>].
sa-dhPop-static-sha224-hmac-sha224
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-dhPop-static-sha224-hmac-sha224
This OID identifies the Static DH POP algorithm that uses SHA-224
as the KDF and HMAC-SHA224 as the MAC function.
sa-dhPop-static-sha256-hmac-sha256
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-dhPop-static-sha256-hmac-sha256
This OID identifies the Static DH POP algorithm that uses SHA-256
as the KDF and HMAC-SHA256 as the MAC function.
sa-dhPop-static-sha384-hmac-sha384
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-dhPop-static-sha384-hmac-sha384
This OID identifies the Static DH POP algorithm that uses SHA-384
as the KDF and HMAC-SHA384 as the MAC function.
sa-dhPop-static-sha512-hmac-sha512
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-dhPop-static-sha512-hmac-sha512
This OID identifies the Static DH POP algorithm that uses SHA-512
as the KDF and HMAC-SHA512 as the MAC function.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Discrete Logarithm Signature</span>
When a single set of parameters is used for a large group of keys,
the chance that a collision will occur in the set of keys, either by
accident or design, increases as the number of keys used increases.
A large number of keys from a single parameter set also encourages
the use of brute force methods of attack, as the entire set of keys
in the parameters can be attacked in a single operation rather than
having to attack each key parameter set individually.
For this reason, we need to create a POP for DH keys that does not
require the use of a common set of parameters.
This POP algorithm is based on DSA, but we have removed the
restrictions dealing with the hash and key sizes imposed by the
[<a href="#ref-FIPS-186-3" title=""Digital Signature Standard (DSS)"">FIPS-186-3</a>] standard. The use of this method does impose some
additional restrictions on the set of keys that may be used; however,
if the key-generation algorithm documented in [<a href="./rfc2631" title=""Diffie-Hellman Key Agreement Method"">RFC2631</a>] is used, the
required restrictions are met. The additional restrictions are the
requirement for the existence of a q parameter. Adding the q
parameter is generally accepted as a good practice, as it allows for
checking of small subgroup attacks.
The following definitions are used in the rest of this section:
p is a large prime
g = h^((p-1)/q) mod p,
where h is any integer 1 < h < p-1 such that h^((p-1)/q) mod p > 1
(g has order q mod p)
q is a large prime
j is a large integer such that p = q*j + 1
x is a randomly or pseudo-randomly generated integer with 1 < x < q
y = g^x mod p
HASH is a hash function such that
b = the output size of HASH in bits
Note: These definitions match the ones in [<a href="./rfc2631" title=""Diffie-Hellman Key Agreement Method"">RFC2631</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Expanding the Digest Value</span>
Besides the addition of a q parameter, [<a href="#ref-FIPS-186-3" title=""Digital Signature Standard (DSS)"">FIPS-186-3</a>] also imposes size
restrictions on the parameters. The length of q must be 160 bits
(matching the output length of the SHA-1 digest algorithm), and the
length of p must be 1024 bits. The size restriction on p is
eliminated in this document, but the size restriction on q is
replaced with the requirement that q must be at least b bits in
length. (If the hash function is SHA-1, then b=160 bits and the size
restriction on b is identical with that in [<a href="#ref-FIPS-186-3" title=""Digital Signature Standard (DSS)"">FIPS-186-3</a>].) Given that
<span class="grey">Schaad & Prafullchandra Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
there is not a random length-hashing algorithm, a hash value of the
message will need to be derived such that the hash is in the range
from 0 to q-1. If the length of q is greater than b, then a method
must be provided to expand the hash.
The method for expanding the digest value used in this section does
not provide any additional security beyond the b bits provided by the
hash algorithm. For this reason, the hash algorithm should be the
largest size possible to match q. The value being signed is
increased mainly to enhance the difficulty of reversing the signature
process.
This algorithm produces m, the value to be signed.
Let L = the size of q (i.e., 2^L <= q < 2^(L+1)).
Let M be the original message to be signed.
Let b be the length of HASH output.
1. Compute d = HASH(M), the digest of the original message.
2. If L == b, then m = d.
3. If L > b, then follow steps (a) through (d) below.
(a) Set n = FLOOR(L / b)
(b) Set m = d, the initial computed digest value
(c) For i = 0 to n - 1
m = m | HASH(m)
(d) m = LEFTMOST(m, L-1)
Thus, the final result of the process meets the criteria that
0 <= m < q.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Signature Computation Algorithm</span>
The signature algorithm produces the pair of values (r, s), which is
the signature. The signature is computed as follows:
Given m, the value to be signed, as well as the parameters defined
earlier in <a href="#section-5">Section 5</a>:
1. Generate a random or pseudo-random integer k, such that
0 < k-1 < q.
2. Compute r = (g^k mod p) mod q.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
3. If r is zero, repeat from step 1.
4. Compute s = ((k^-1) * (m + x*r)) mod q.
5. If s is zero, repeat from step 1.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Signature Verification Algorithm</span>
The signature verification process is far more complicated than is
normal for DSA, as some assumptions about the validity of parameters
cannot be taken for granted.
Given a value m to be validated, the signature value pair (r, s) and
the parameters for the key:
1. Perform a strong verification that p is a prime number.
2. Perform a strong verification that q is a prime number.
3. Verify that q is a factor of p-1; if any of the above checks
fail, then the signature cannot be verified and must be
considered a failure.
4. Verify that r and s are in the range [1, q-1].
5. Compute w = (s^-1) mod q.
6. Compute u1 = m*w mod q.
7. Compute u2 = r*w mod q.
8. Compute v = ((g^u1 * y^u2) mod p) mod q.
9. Compare v and r; if they are the same, then the signature
verified correctly.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. ASN.1 Encoding</span>
The signature algorithm is parameterized by the hash algorithm. The
ASN.1 structures associated with the Discrete Logarithm Signature
algorithm are:
sa-dhPop-SHA1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha1 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop
id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 }
sa-dhPop-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha224
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha224 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 5
}
sa-dhPop-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha256
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha256 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 6
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
sa-dhPop-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha384
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha384 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 7
}
sa-dhPop-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha512
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha512 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 8
}
In the above ASN.1, the following items are defined:
sa-dhPop-sha1
A SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DSA-Sig-Value represents the signature value, and the structure
DomainParameters SHOULD be omitted in the signature but MUST be
present in the associated key request.
id-alg-dhPop-sha1
This OID identifies the Discrete Logarithm Signature using SHA-1
as the hash algorithm. The new OID was created for naming
consistency with the others defined here. The value of the OID is
the same as id-alg-dh-pop, which was defined in the previous
version of this document [<a href="./rfc2875" title=""Diffie-Hellman Proof-of-Possession Algorithms"">RFC2875</a>].
sa-dhPop-sha224
A SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DSA-Sig-Value represents the signature value, and the structure
DomainParameters SHOULD be omitted in the signature but MUST be
present in the associated key request.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-alg-dhPop-sha224
This OID identifies the Discrete Logarithm Signature using SHA-224
as the hash algorithm.
sa-dhPop-sha256
A SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DSA-Sig-Value represents the signature value, and the structure
DomainParameters SHOULD be omitted in the signature but MUST be
present in the associated key request.
id-alg-dhPop-sha256
This OID identifies the Discrete Logarithm Signature using SHA-256
as the hash algorithm.
sa-dhPop-sha384
A SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DSA-Sig-Value represents the signature value, and the structure
DomainParameters SHOULD be omitted in the signature but MUST be
present in the associated key request.
id-alg-dhPop-sha384
This OID identifies the Discrete Logarithm Signature using SHA-384
as the hash algorithm.
sa-dhPop-sha512
A SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DSA-Sig-Value represents the signature value, and the structure
DomainParameters SHOULD be omitted in the signature but MUST be
present in the associated key request.
id-alg-dhPop-sha512
This OID identifies the Discrete Logarithm Signature using SHA-512
as the hash algorithm.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Static ECDH Proof-of-Possession Process</span>
The Static ECDH POP algorithm is set up to use a KDF and a MAC. This
algorithm requires that a common set of group parameters be used by
both the creator and the verifier of the POP value. Full details of
how Elliptic Curve Cryptography (ECC) works can be found in <a href="./rfc6090">RFC 6090</a>
[<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>].
<span class="grey">Schaad & Prafullchandra Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
The steps for creating an ECDH POP are:
1. An entity (E) chooses the group parameters for an ECDH 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.
The ECDH parameters can be identified either by a named group or
by a set of curve parameters. <a href="./rfc3279#section-2.3.5">Section 2.3.5 of RFC 3279</a>
[<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>] documents how the parameters are encoded for PKIX
certificates. For PKIX-based applications, the parameters will
almost always be defined by a named group. Designate G as the
group from the ECDH parameters. Let the ECDH key pair associated
with the certificate be known as the recipient key pair (Rpub
and Rpriv).
Rpub = Rpriv * G
2. The entity generates an ECDH public/private key pair using the
parameters from step 1.
For an entity (E):
Epriv = entity private value
Epub = ECDH public point = Epriv * G
3. The POP computation process will then consist of the following
steps:
(a) The value to be signed (text) is obtained. (For a PKCS #10
object, the value is the DER-encoded
certificationRequestInfo field represented as an octet
string.)
(b) A shared ECDH secret is computed as follows:
shared secret point (x, y) = Epriv * Rpub = Rpriv * Epub
shared secret value ZZ is the x coordinate of the computed
point
<span class="grey">Schaad & Prafullchandra Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
(c) A temporary key K is derived from the shared secret ZZ as
follows:
K = KDF(LeadingInfo | ZZ | TrailingInfo)
LeadingInfo ::= Subject Distinguished Name from certificate
TrailingInfo ::= Issuer Distinguished Name from certificate
(d) Compute MAC(K, text).
The POP verification process requires the recipient to carry out
steps (a) through (d) and then simply compare the result of step (d)
with what it received as the signature component. If they match,
then the following can be concluded:
(a) The entity possesses the private key corresponding to the public
key in the Certification Request because it needed the private
key to calculate the shared secret; and
(b) Only the recipient that the entity sent the request to could
actually verify the request because it would require its own
private key to compute the same shared secret. In the case
where the recipient is a CA, this protects the entity from
rogue CAs.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. ASN.1 Encoding</span>
The algorithm outlined above allows for the use of an arbitrary hash
function in computing the temporary key and the MAC value. In this
specification, we define object identifiers for the SHA-1, SHA-224,
SHA-256, SHA-384, and SHA-512 hash values. The ASN.1 structures
associated with the Static ECDH POP algorithm are:
id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 25
}
sa-ecdhPop-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha224-hmac-sha224
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 26
}
sa-ecdhPop-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha256-hmac-sha256
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 27
}
sa-ecdhPop-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha384-hmac-sha384
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 28
}
sa-ecdhPop-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha512-hmac-sha512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
These items reuse the DhSigStatic structure defined in <a href="#section-4">Section 4</a>.
When used with these algorithms, the value to be placed in the field
hashValue is that computed in step 3(d) (<a href="#section-6">Section 6</a>). In the above
ASN.1, the following items are defined:
sa-ecdhPop-static-sha224-hmac-sha224
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-ecdhPop-static-sha224-hmac-sha224
This OID identifies the Static ECDH POP algorithm that uses
SHA-224 as the KDF and HMAC-SHA224 as the MAC function.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
sa-ecdhPop-static-sha256-hmac-sha256
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-ecdhPop-static-sha256-hmac-sha256
This OID identifies the Static ECDH POP algorithm that uses
SHA-256 as the KDF and HMAC-SHA256 as the MAC function.
sa-ecdhPop-static-sha384-hmac-sha384
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-ecdhPop-static-sha384-hmac-sha384
This OID identifies the Static ECDH POP algorithm that uses
SHA-384 as the KDF and HMAC-SHA384 as the MAC function.
sa-ecdhPop-static-sha512-hmac-sha512
An ASN.1 SIGNATURE-ALGORITHM object that associates together the
information describing this signature algorithm. The structure
DhSigStatic represents the signature value, and the parameters
MUST be absent.
id-ecdhPop-static-sha512-hmac-sha512
This OID identifies the Static ECDH POP algorithm that uses
SHA-512 as the KDF and HMAC-SHA512 as the MAC function.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
None of the algorithms defined in this document are meant for use in
general purpose situations. These algorithms are designed and
purposed solely for use in doing POP with PKCS #10 and CRMF
constructs.
In the Static DH POP and Static ECDH POP algorithms, an appropriate
value can be produced by either party. Thus, these algorithms only
provide integrity and not origination service. The Discrete
Logarithm Signature algorithm provides both integrity checking and
origination checking.
All the security in this system is provided by the secrecy of the
private keying material. If either sender or recipient private keys
are disclosed, all messages sent or received using those keys are
compromised. Similarly, the loss of a private key results in an
inability to read messages sent using that key.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Selection of parameters can be of paramount importance. In the
selection of parameters, one must take into account the community/
group of entities that one wishes to be able to communicate with. In
choosing a set of parameters, one must also be sure to avoid small
groups. [<a href="#ref-FIPS-186-3" title=""Digital Signature Standard (DSS)"">FIPS-186-3</a>] Appendixes A and B.2 contain information on the
selection of parameters for DH. <a href="./rfc6090#section-10">Section 10 of [RFC6090]</a> contains
information on the selection of parameters for ECC. The practices
outlined in these documents will lead to better selection of
parameters.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2104">RFC2104</a>] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", <a href="./rfc2104">RFC 2104</a>,
February 1997.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2631">RFC2631</a>] Rescorla, E., "Diffie-Hellman Key Agreement Method",
<a href="./rfc2631">RFC 2631</a>, June 1999.
[<a id="ref-RFC2986">RFC2986</a>] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", <a href="./rfc2986">RFC 2986</a>,
November 2000.
[<a id="ref-RFC4231">RFC4231</a>] Nystrom, M., "Identifiers and Test Vectors for HMAC-
SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
<a href="./rfc4231">RFC 4231</a>, December 2005.
[<a id="ref-RFC6234">RFC6234</a>] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", <a href="./rfc6234">RFC 6234</a>, May 2011.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-CRMF">CRMF</a>] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", <a href="./rfc4211">RFC 4211</a>,
September 2005.
[<a id="ref-FIPS-186-3">FIPS-186-3</a>] National Institute of Standards and Technology,
"Digital Signature Standard (DSS)", Federal Information
Processing Standards Publication 186-3, June 2009,
<<a href="http://www.nist.gov/">http://www.nist.gov/</a>>.
[<a id="ref-RFC2875">RFC2875</a>] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", <a href="./rfc2875">RFC 2875</a>, July 2000.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
[<a id="ref-RFC3279">RFC3279</a>] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", <a href="./rfc3279">RFC 3279</a>, April 2002.
[<a id="ref-RFC5912">RFC5912</a>] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)",
<a href="./rfc5912">RFC 5912</a>, June 2010.
[<a id="ref-RFC6090">RFC6090</a>] McGrew, D., Igoe, K., and M. Salter, "Fundamental
Elliptic Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>,
February 2011.
<span class="grey">Schaad & Prafullchandra Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. ASN.1 Modules</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. 2008 ASN.1 Module</span>
This appendix contains an ASN.1 module that is conformant with the
2008 version of ASN.1. This module references the object classes
defined by [<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>] to more completely describe all of the
associations between the elements defined in this document. Where a
difference exists between the module in this section and the 1988
module, the 2008 module is the definitive module.
DH-Sign
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dhSign-2012-08(80) }
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.
IMPORTS
SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
IssuerAndSerialNumber, MessageDigest
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
DSA-Sig-Value, DomainParameters, ECDSA-Sig-Value,
mda-sha1, mda-sha224, mda-sha256, mda-sha384, mda-sha512,
pk-dh, pk-ec
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
id-pkix
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) };
<span class="grey">Schaad & Prafullchandra Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
DhSigStatic ::= SEQUENCE {
issuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-dhPop-static-sha1-hmac-sha1
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 3
}
id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::=
id-dh-sig-hmac-sha1
sa-dhPop-static-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha224-hmac-sha224
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 15
}
sa-dhPop-static-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha256-hmac-sha256
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 16
}
sa-dhPop-static-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha384-hmac-sha384
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 17
}
sa-dhPop-static-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-static-sha512-hmac-sha512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 18
}
sa-dhPop-SHA1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha1 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop
id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 }
sa-dhPop-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha224
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha224 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 5
}
sa-dhPop-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha256
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha256 }
PUBLIC-KEYS { pk-dh }
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 6
}
sa-dhPop-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha384
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha384 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 7
}
sa-dhPop-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dhPop-sha512
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha512 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 8
}
id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 25
}
sa-ecdhPop-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha224-hmac-sha224
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 26
}
<span class="grey">Schaad & Prafullchandra Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
sa-ecdhPop-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha256-hmac-sha256
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 27
}
sa-ecdhPop-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha384-hmac-sha384
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 28
}
sa-ecdhPop-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-sha512-hmac-sha512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
END
<span class="grey">Schaad & Prafullchandra Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. 1988 ASN.1 Module</span>
This appendix contains an ASN.1 module that is conformant with the
1988 version of ASN.1, which represents an informational version of
the ASN.1 module for this document. Where a difference exists
between the module in this section and the 2008 module, the 2008
module is the definitive module.
DH-Sign
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dhSign-2012-88(79) }
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.
IMPORTS
IssuerAndSerialNumber, MessageDigest
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-2004(24) }
id-pkix
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
Dss-Sig-Value, DomainParameters
FROM PKIX1Algorithms88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms(17) };
id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 3}
DhSigStatic ::= SEQUENCE {
issuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 }
<span class="grey">Schaad & Prafullchandra Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::=
id-dh-sig-hmac-sha1
id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 15 }
id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 16 }
id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 17 }
id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 18 }
id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop
id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 5 }
id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 6 }
id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 7 }
id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 8 }
id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 25 }
id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 26 }
id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 27 }
id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 28 }
END
<span class="grey">Schaad & Prafullchandra Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Example of Static DH Proof-of-Possession</span>
The following example follows the steps described earlier in
<a href="#section-4">Section 4</a>.
Step 1. Establishing common DH parameters: Assume the parameters are
as in the DER-encoded certificate. The certificate contains a DH
public key signed by a CA with a DSA signing key.
0 30 939: SEQUENCE {
4 30 872: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 6: INTEGER
: 00 DA 39 B6 E2 CB
21 30 11: SEQUENCE {
23 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
32 05 0: NULL
: }
34 30 72: SEQUENCE {
36 31 11: SET {
38 30 9: SEQUENCE {
40 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
45 13 2: PrintableString 'US'
: }
: }
49 31 17: SET {
51 30 15: SEQUENCE {
53 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
58 13 8: PrintableString 'XETI Inc'
: }
: }
68 31 16: SET {
70 30 14: SEQUENCE {
72 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
77 13 7: PrintableString 'Testing'
: }
: }
86 31 20: SET {
88 30 18: SEQUENCE {
90 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
95 13 11: PrintableString 'Root DSA CA'
: }
: }
: }
<span class="grey">Schaad & Prafullchandra Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="section-108" href="#section-108">108</a> 30 </span>30: SEQUENCE {
<span class="h2"><a class="selflink" id="section-110" href="#section-110">110</a> 17 </span>13: UTCTime '990914010557Z'
<span class="h2"><a class="selflink" id="section-125" href="#section-125">125</a> 17 </span>13: UTCTime '991113010557Z'
: }
<span class="h2"><a class="selflink" id="section-140" href="#section-140">140</a> 30 </span>70: SEQUENCE {
<span class="h2"><a class="selflink" id="section-142" href="#section-142">142</a> 31 </span>11: SET {
<span class="h2"><a class="selflink" id="section-144" href="#section-144">144</a> 30 </span> 9: SEQUENCE {
<span class="h2"><a class="selflink" id="section-146" href="#section-146">146</a> 06 </span> 3: OBJECT IDENTIFIER countryName (2 5 4 6)
<span class="h2"><a class="selflink" id="section-151" href="#section-151">151</a> 13 </span> 2: PrintableString 'US'
: }
: }
<span class="h2"><a class="selflink" id="section-155" href="#section-155">155</a> 31 </span>17: SET {
<span class="h2"><a class="selflink" id="section-157" href="#section-157">157</a> 30 </span>15: SEQUENCE {
<span class="h2"><a class="selflink" id="section-159" href="#section-159">159</a> 06 </span> 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
<span class="h2"><a class="selflink" id="section-164" href="#section-164">164</a> 13 </span> 8: PrintableString 'XETI Inc'
: }
: }
<span class="h2"><a class="selflink" id="section-174" href="#section-174">174</a> 31 </span>16: SET {
<span class="h2"><a class="selflink" id="section-176" href="#section-176">176</a> 30 </span>14: SEQUENCE {
<span class="h2"><a class="selflink" id="section-178" href="#section-178">178</a> 06 </span> 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
<span class="h2"><a class="selflink" id="section-183" href="#section-183">183</a> 13 </span> 7: PrintableString 'Testing'
: }
: }
<span class="h2"><a class="selflink" id="section-192" href="#section-192">192</a> 31 </span>18: SET {
<span class="h2"><a class="selflink" id="section-194" href="#section-194">194</a> 30 </span>16: SEQUENCE {
<span class="h2"><a class="selflink" id="section-196" href="#section-196">196</a> 06 </span> 3: OBJECT IDENTIFIER commonName (2 5 4 3)
<span class="h2"><a class="selflink" id="section-201" href="#section-201">201</a> 13 </span> 9: PrintableString 'DH TestCA'
: }
: }
: }
<span class="h2"><a class="selflink" id="section-212" href="#section-212">212</a> 30 577: </span> SEQUENCE {
<span class="h2"><a class="selflink" id="section-216" href="#section-216">216</a> 30 438: </span> SEQUENCE {
<span class="h2"><a class="selflink" id="section-220" href="#section-220">220</a> 06 </span> 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1)
<span class="h2"><a class="selflink" id="section-229" href="#section-229">229</a> 30 425: </span> SEQUENCE {
<span class="h2"><a class="selflink" id="section-233" href="#section-233">233</a> 02 129: </span> INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
<span class="grey">Schaad & Prafullchandra Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="section-365" href="#section-365">365</a> 02 128: </span> INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
<span class="h2"><a class="selflink" id="section-496" href="#section-496">496</a> 02 </span>33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
<span class="h2"><a class="selflink" id="section-531" href="#section-531">531</a> 02 </span>97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
: 92
<span class="h2"><a class="selflink" id="section-630" href="#section-630">630</a> 30 </span>26: SEQUENCE {
<span class="h2"><a class="selflink" id="section-632" href="#section-632">632</a> 03 </span>21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
: 09 E4 98 34
<span class="h2"><a class="selflink" id="section-655" href="#section-655">655</a> 02 </span> 1: INTEGER 55
: }
: }
: }
<span class="h2"><a class="selflink" id="section-658" href="#section-658">658</a> 03 132: </span> BIT STRING 0 unused bits
: 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1
: E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0
: 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69
: B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22
: 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF
: D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21
: E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31
: 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0
: 8F C5 1A
: }
<span class="h2"><a class="selflink" id="section-793" href="#section-793">793</a> A3 </span>85: [3] {
<span class="h2"><a class="selflink" id="section-795" href="#section-795">795</a> 30 </span>83: SEQUENCE {
<span class="h2"><a class="selflink" id="section-797" href="#section-797">797</a> 30 </span>29: SEQUENCE {
<span class="h2"><a class="selflink" id="section-799" href="#section-799">799</a> 06 </span> 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
<span class="h2"><a class="selflink" id="section-804" href="#section-804">804</a> 04 </span>22: OCTET STRING
: 04 14 80 DF 59 88 BF EB 17 E1 AD 5E C6 40 A3 42
: E5 AC D3 B4 88 78
: }
<span class="grey">Schaad & Prafullchandra Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
<span class="h2"><a class="selflink" id="section-828" href="#section-828">828</a> 30 </span>34: SEQUENCE {
<span class="h2"><a class="selflink" id="section-830" href="#section-830">830</a> 06 </span> 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29
35)
<span class="h2"><a class="selflink" id="section-835" href="#section-835">835</a> 01 </span> 1: BOOLEAN TRUE
<span class="h2"><a class="selflink" id="section-838" href="#section-838">838</a> 04 </span>24: OCTET STRING
: 30 16 80 14 6A 23 37 55 B9 FD 81 EA E8 4E D3 C9
: B7 09 E5 7B 06 E3 68 AA
: }
<span class="h2"><a class="selflink" id="section-864" href="#section-864">864</a> 30 </span>14: SEQUENCE {
<span class="h2"><a class="selflink" id="section-866" href="#section-866">866</a> 06 </span> 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
<span class="h2"><a class="selflink" id="section-871" href="#section-871">871</a> 01 </span> 1: BOOLEAN TRUE
<span class="h2"><a class="selflink" id="section-874" href="#section-874">874</a> 04 </span> 4: OCTET STRING
: 03 02 03 08
: }
: }
: }
: }
<span class="h2"><a class="selflink" id="section-880" href="#section-880">880</a> 30 </span>11: SEQUENCE {
<span class="h2"><a class="selflink" id="section-882" href="#section-882">882</a> 06 </span> 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
<span class="h2"><a class="selflink" id="section-891" href="#section-891">891</a> 05 </span> 0: NULL
: }
<span class="h2"><a class="selflink" id="section-893" href="#section-893">893</a> 03 </span>48: BIT STRING 0 unused bits
: 30 2D 02 14 7C 6D D2 CA 1E 32 D1 30 2E 29 66 BC
: 06 8B 60 C7 61 16 3B CA 02 15 00 8A 18 DD C1 83
: 58 29 A2 8A 67 64 03 92 AB 02 CE 00 B5 94 6A
: }
Step 2. End entity/user generates a DH key pair using the parameters
from the CA certificate.
End entity DH public key:
Y: 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8 93 74 AE
FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18 FE 94 B8
A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A
0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A BE B2 5C
DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A
93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8 29 98 EC
D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33
62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53 EF B2 E8
End entity DH private key:
X: 32 CC BD B4 B7 7C 44 26 BB 3C 83 42 6E 7D 1B 00
86 35 09 71 07 A0 A4 76 B8 DB 5F EC 00 CE 6F C3
<span class="grey">Schaad & Prafullchandra Standards Track [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Step 3. Compute the shared secret ZZ.
56 b6 01 39 42 8e 09 16 30 b0 31 4d 12 90 af 03
c7 92 65 c2 9c ba 88 bb 0a d5 94 02 ed 6f 54 cb
22 e5 94 b4 d6 60 72 bc f6 a5 2b 18 8d df 28 72
ac e0 41 dd 3b 03 2a 12 9e 5d bd 72 a0 1e fb 6b
ee c5 b2 16 59 ee 12 00 3b c8 e0 cb c5 08 8e 2d
40 5f 2d 37 62 8c 4f bb 49 76 69 3c 9e fc 2c f7
f9 50 c1 b9 f7 01 32 4c 96 b9 c3 56 c0 2c 1b 77
3f 2f 36 e8 22 c8 2e 07 76 d0 4f 7f aa d5 c0 59
Step 4. Compute K and the signature.
LeadingInfo: DER-encoded Subject/Requester Distinguished Name (DN),
as in the generated Certificate Signing Request
30 46 31 0B 30 09 06 03 55 04 06 13 02 55 53 31
11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49
6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73
74 69 6E 67 31 12 30 10 06 03 55 04 03 13 09 44
48 20 54 65 73 74 43 41
TrailingInfo: DER-encoded Issuer/recipient DN (from the certificate
described in step 1)
30 48 31 0B 30 09 06 03 55 04 06 13 02 55 53 31
11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49
6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73
74 69 6E 67 31 14 30 12 06 03 55 04 03 13 0B 52
6F 6F 74 20 44 53 41 20 43 41
K:
B1 91 D7 DB 4F C5 EF EF AC 9A C5 44 5A 6D 42 28
DC 70 7B DA
<span class="grey">Schaad & Prafullchandra Standards Track [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
TBS: the "text" for computing the SHA-1 HMAC.
30 82 02 98 02 01 00 30 4E 31 0B 30 09 06 03 55
04 06 13 02 55 53 31 11 30 0F 06 03 55 04 0A 13
08 58 45 54 49 20 49 6E 63 31 10 30 0E 06 03 55
04 0B 13 07 54 65 73 74 69 6E 67 31 1A 30 18 06
03 55 04 03 13 11 50 4B 49 58 20 45 78 61 6D 70
6C 65 20 55 73 65 72 30 82 02 41 30 82 01 B6 06
07 2A 86 48 CE 3E 02 01 30 82 01 A9 02 81 81 00
94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5
A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5
D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51
63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B
79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A
F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32
E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7
B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27
02 81 80 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87
53 3F 90 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5
0C 53 D4 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6
1B 7F 57 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31
7A 48 B6 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69
D9 9B DE 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33
51 C8 F1 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31
15 26 48 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E
DA D1 CD 02 21 00 E8 72 FA 96 F0 11 40 F5 F2 DC
FD 3B 5D 78 94 B1 85 01 E5 69 37 21 F7 25 B9 BA
71 4A FC 60 30 FB 02 61 00 A3 91 01 C0 A8 6E A4
4D A0 56 FC 6C FE 1F A7 B0 CD 0F 94 87 0C 25 BE
97 76 8D EB E5 A4 09 5D AB 83 CD 80 0B 35 67 7F
0C 8E A7 31 98 32 85 39 40 9D 11 98 D8 DE B8 7F
86 9B AF 8D 67 3D B6 76 B4 61 2F 21 E1 4B 0E 68
FF 53 3E 87 DD D8 71 56 68 47 DC F7 20 63 4B 3C
5F 78 71 83 E6 70 9E E2 92 30 1A 03 15 00 1C D5
3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 09 E4
98 34 02 01 37 03 81 84 00 02 81 80 13 63 A1 85
04 8C 46 A8 88 EB F4 5E A8 93 74 AE FD AE 9E 96
27 12 65 C4 4C 07 06 3E 18 FE 94 B8 A8 79 48 BD
2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A 0B 2D 9E 50
C9 78 0F AE 6A EC B5 6B 6A BE B2 5C DA B2 9F 78
2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A 93 4B F8 B3
EC 81 34 AE 97 47 52 E0 A8 29 98 EC D1 B0 CA 2B
6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33 62 09 9E 0F
11 44 8C C1 8D A2 11 9E 53 EF B2 E8
<span class="grey">Schaad & Prafullchandra Standards Track [Page 35]</span><span id="page-36" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Certification Request:
0 30 793: SEQUENCE {
4 30 664: SEQUENCE {
8 02 1: INTEGER 0
11 30 78: SEQUENCE {
13 31 11: SET {
15 30 9: SEQUENCE {
17 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
22 13 2: PrintableString 'US'
: }
: }
26 31 17: SET {
28 30 15: SEQUENCE {
30 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
35 13 8: PrintableString 'XETI Inc'
: }
: }
45 31 16: SET {
47 30 14: SEQUENCE {
49 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
54 13 7: PrintableString 'Testing'
: }
: }
63 31 26: SET {
65 30 24: SEQUENCE {
67 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
72 13 17: PrintableString 'PKIX Example User'
: }
: }
: }
91 30 577: SEQUENCE {
95 30 438: SEQUENCE {
99 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1)
108 30 425: SEQUENCE {
112 02 129: INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
<span class="grey">Schaad & Prafullchandra Standards Track [Page 36]</span><span id="page-37" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
244 02 128: INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
375 02 33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
410 02 97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
: 92
509 30 26: SEQUENCE {
511 03 21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E
: DB 09 E4 98 34
534 02 1: INTEGER 55
: }
: }
: }
537 03 132: BIT STRING 0 unused bits
: 02 81 80 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8
: 93 74 AE FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18
: FE 94 B8 A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC
: 33 FD 1A 0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A
: BE B2 5C DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E
: 0B 59 4A 93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8
: 29 98 EC D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E
: 7E AF 33 62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53
: EF B2 E8
: }
: }
672 30 12: SEQUENCE {
674 06 8: OBJECT IDENTIFIER dh-sig-hmac-sha1 (1 3 6 1 5 5 7 6 3)
684 05 0: NULL
: }
<span class="grey">Schaad & Prafullchandra Standards Track [Page 37]</span><span id="page-38" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
686 03 109: BIT STRING 0 unused bits
: 30 6A 30 52 30 48 31 0B 30 09 06 03 55 04 06 13
: 02 55 53 31 11 30 0F 06 03 55 04 0A 13 08 58 45
: 54 49 20 49 6E 63 31 10 30 0E 06 03 55 04 0B 13
: 07 54 65 73 74 69 6E 67 31 14 30 12 06 03 55 04
: 03 13 0B 52 6F 6F 74 20 44 53 41 20 43 41 02 06
: 00 DA 39 B6 E2 CB 04 14 2D 05 77 FE 5E 8F 65 F5
: AF AD C9 5C 9B 02 C0 A8 88 29 61 63
: }
Signature verification requires CA's private key, the CA certificate,
and the generated Certification Request.
CA DH private key:
x: 3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7
52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>. Example of Discrete Log Signature</span>
Step 1. Generate a DH key with length of q being 256 bits.
p:
94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5
A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5
D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51
63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B
79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A
F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32
E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7
B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27
q:
E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 B1
85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 FB
g:
26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
<span class="grey">Schaad & Prafullchandra Standards Track [Page 38]</span><span id="page-39" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
j:
A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 B0
CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D AB
83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 40
9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 B4
61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 68
47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 92
y:
5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1 E6 A7 01
4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0 46 79 50
A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69 B7 11 A1
C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22 4D 0A 11
6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF D8 59 92
C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21 E1 AF 7A
3A CF 20 0A B4 2C 69 5F CF 79 67 20 31 4D F2 C6
ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0 8F C5 1A
seed:
1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
09 E4 98 34
C:
00000037
x:
3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7
52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D
Step 2. Form the value to be signed and hash with SHA1. The result
of the hash for this example is:
5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6
d4 21 e5 2c
Step 3. The hash value needs to be expanded, since |q| = 256. This
is done by hashing the hash with SHA1 and appending it to the
original hash. The value after this step is:
5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6
d4 21 e5 2c 64 92 8b c9 5e 34 59 70 bd 62 40 ad
6f 26 3b f7 1c a3 b2 cb
<span class="grey">Schaad & Prafullchandra Standards Track [Page 39]</span><span id="page-40" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
Next, the first 255 bits of this value are taken to be the resulting
"hash" value. Note that in this case a shift of one bit right is
done, since the result is to be treated as an integer:
2f d1 34 db 25 91 48 91 37 a6 7f 34 76 15 e8 e3
6a 10 f2 96 32 49 45 e4 af 1a 2c b8 5e b1 20 56
Step 4. The signature value is computed. In this case, you get the
values:
r:
A1 B5 B4 90 01 34 6B A0 31 6A 73 F5 7D F6 5C 14
43 52 D2 10 BF 86 58 87 F7 BC 6E 5A 77 FF C3 4B
s:
59 40 45 BC 6F 0D DC FF 9D 55 40 1E C4 9E 51 3D
66 EF B2 FF 06 40 9A 39 68 75 81 F7 EC 9E BE A1
The encoded signature value is then:
30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73
F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E
5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D
55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68
75 81 F7 EC 9E BE A1
Result:
30 82 02 c2 30 82 02 67 02 01 00 30 1b 31 19 30
17 06 03 55 04 03 13 10 49 45 54 46 20 50 4b 49
58 20 53 41 4d 50 4c 45 30 82 02 41 30 82 01 b6
06 07 2a 86 48 ce 3e 02 01 30 82 01 a9 02 81 81
00 94 84 e0 45 6c 7f 69 51 62 3e 56 80 7c 68 e7
c5 a9 9e 9e 74 74 94 ed 90 8c 1d c4 e1 4a 14 82
f5 d2 94 0c 19 e3 b9 10 bb 11 b9 e5 a5 fb 8e 21
51 63 02 86 aa 06 b8 21 36 b6 7f 36 df d1 d6 68
5b 79 7c 1d 5a 14 75 1f 6a 93 75 93 ce bb 97 72
8a f0 0f 23 9d 47 f6 d4 b3 c7 f0 f4 e6 f6 2b c2
32 e1 89 67 be 7e 06 ae f8 d0 01 6b 8b 2a f5 02
d7 b6 a8 63 94 83 b0 1b 31 7d 52 1a de e5 03 85
27 02 81 80 26 a6 32 2c 5a 2b d4 33 2b 5c dc 06
87 53 3f 90 06 61 50 38 3e d2 b9 7d 81 1c 12 10
c5 0c 53 d4 64 d1 8e 30 07 08 8c dd 3f 0a 2f 2c
d6 1b 7f 57 86 d0 da bb 6e 36 2a 18 e8 d3 bc 70
31 7a 48 b6 4e 18 6e dd 1f 22 06 eb 3f ea d4 41
69 d9 9b de 47 95 7a 72 91 d2 09 7f 49 5c 3b 03
33 51 c8 f1 39 9a ff 04 d5 6e 7e 94 3d 03 b8 f6
31 15 26 48 95 a8 5c de 47 88 b4 69 3a 00 a7 86
9e da d1 cd 02 21 00 e8 72 fa 96 f0 11 40 f5 f2
<span class="grey">Schaad & Prafullchandra Standards Track [Page 40]</span><span id="page-41" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
dc fd 3b 5d 78 94 b1 85 01 e5 69 37 21 f7 25 b9
ba 71 4a fc 60 30 fb 02 61 00 a3 91 01 c0 a8 6e
a4 4d a0 56 fc 6c fe 1f a7 b0 cd 0f 94 87 0c 25
be 97 76 8d eb e5 a4 09 5d ab 83 cd 80 0b 35 67
7f 0c 8e a7 31 98 32 85 39 40 9d 11 98 d8 de b8
7f 86 9b af 8d 67 3d b6 76 b4 61 2f 21 e1 4b 0e
68 ff 53 3e 87 dd d8 71 56 68 47 dc f7 20 63 4b
3c 5f 78 71 83 e6 70 9e e2 92 30 1a 03 15 00 1c
d5 3a 0d 17 82 6d 0a 81 75 81 46 10 8e 3e db 09
e4 98 34 02 01 37 03 81 84 00 02 81 80 5f cf 39
ad 62 cf 49 8e d1 ce 66 e2 b1 e6 a7 01 4d 05 c2
77 c8 92 52 42 a9 05 a4 db e0 46 79 50 a3 fc 99
3d 3d a6 9b a9 ad bc 62 1c 69 b7 11 a1 c0 2a f1
85 28 f7 68 fe d6 8f 31 56 22 4d 0a 11 6e 72 3a
02 af 0e 27 aa f9 ed ce 05 ef d8 59 92 c0 18 d7
69 6e bd 70 b6 21 d1 77 39 21 e1 af 7a 3a cf 20
0a b4 2c 69 5f cf 79 67 20 31 4d f2 c6 ed 23 bf
c4 bb 1e d1 71 40 2c 07 d6 f0 8f c5 1a a0 00 30
0c 06 08 2b 06 01 05 05 07 06 04 05 00 03 47 00
30 44 02 20 54 d9 43 8d 0f 9d 42 03 d6 09 aa a1
9a 3c 17 09 ae bd ee b3 d1 a0 00 db 7d 8c b8 e4
56 e6 57 7b 02 20 44 89 b1 04 f5 40 2b 5f e7 9c
f9 a4 97 50 0d ad c3 7a a4 2b b2 2d 5d 79 fb 38
8a b4 df bb 88 bc
Decoded version of result:
0 30 707: SEQUENCE {
4 30 615: SEQUENCE {
8 02 1: INTEGER 0
11 30 27: SEQUENCE {
13 31 25: SET {
15 30 23: SEQUENCE {
17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
22 13 16: PrintableString 'IETF PKIX SAMPLE'
: }
: }
: }
40 30 577: SEQUENCE {
44 30 438: SEQUENCE {
48 06 7: OBJECT IDENTIFIER dhPublicNumber (1 2 840 10046 2
1)
<span class="grey">Schaad & Prafullchandra Standards Track [Page 41]</span><span id="page-42" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
57 30 425: SEQUENCE {
61 02 129: INTEGER
: 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7
: C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82
: F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21
: 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68
: 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72
: 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2
: 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02
: D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85
: 27
193 02 128: INTEGER
: 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90
: 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4
: 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57
: 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6
: 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE
: 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1
: 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48
: 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD
324 02 33: INTEGER
: 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94
: B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30
: FB
359 02 97: INTEGER
: 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7
: B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D
: AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39
: 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76
: B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56
: 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2
: 92
458 30 26: SEQUENCE {
460 03 21: BIT STRING 0 unused bits
: 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB
: 09 E4 98 34
483 02 1: INTEGER 55
: }
: }
: }
<span class="grey">Schaad & Prafullchandra Standards Track [Page 42]</span><span id="page-43" ></span>
<span class="grey"><a href="./rfc6955">RFC 6955</a> DH POP Algorithms May 2013</span>
486 03 132: BIT STRING 0 unused bits
: 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1
: E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0
: 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69
: B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22
: 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF
: D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21
: E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31
: 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0
: 8F C5 1A
: }
621 A0 0: [0]
: }
623 30 12: SEQUENCE {
625 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 6 4'
635 05 0: NULL
: }
637 03 72: BIT STRING 0 unused bits
: 30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73
: F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E
: 5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D
: 55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68
: 75 81 F7 EC 9E BE A1
: }
Authors' Addresses
Jim Schaad
Soaring Hawk Consulting
EMail: [email protected]
Hemma Prafullchandra
HyTrust, Inc.
1975 W. El Camino Real, Suite 203
Mountain View, CA 94040
USA
Phone: (650) 681-8100
EMail: [email protected]
Schaad & Prafullchandra Standards Track [Page 43]
Annotations
Select text to annotate