One document matched: draft-schaad-pkix-rfc2875-bis-02.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:rfc2875-bis.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2012-08-01T20:52:19Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- xml2rfc-processed-entity RFC2119 -->
<!-- xml2rfc-processed-entity RFC2314 -->
<!-- xml2rfc-processed-entity RFC2104 -->
<!-- xml2rfc-processed-entity RFC2875 -->
<!-- xml2rfc-processed-entity RFC5280 -->
<!-- xml2rfc-processed-entity RFC2631 -->
<!-- xml2rfc-processed-entity RFC4211 -->
<!-- xml2rfc-processed-entity RFC5912 -->
<!-- xml2rfc-processed-entity RFC6090 -->
<!-- xml2rfc-processed-entity RFC287588 -->
<!-- xml2rfc-processed-entity RFC287508 -->
<!-- xml2rfc-processed-entity RFC2875_STATIC -->
<!-- xml2rfc-processed-entity RFC2875_SIG -->
<!-- xml2rfc-processed-entity RFC2875_ECDH -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-schaad-pkix-rfc2875-bis-02" ipr="pre5378Trust200902" obsoletes="2875">
<front>
<title abbrev="DH POP Algorithms">Diffie-Hellman Proof-of-Possession Algorithms</title>
<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<author fullname="Hemma Prafullchandra" initials="H." surname="Prafullchandra">
</author>
<date year="2012"/>
<area>Security</area>
<workgroup>PKIX</workgroup>
<abstract>
<t>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 PKCS #10 certification
request. These algorithms are designed to provide a proof-of-possession rather than general purpose signing.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
PKCS #10 <xref target="RFC2314"/> and the Certificate Request Message Format (CRMF) <xref target="CRMF"/> define syntaxes for certification requests.
While CRMF supports an alternative method to support Proof-of-Possession (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 signing/encrypting operation.
Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) are a key agreement algorithms and as such cannot be directly used for signing or encryption.</t>
<t>
This document describes new proof-of-possession algorithms.
Two methods use the Diffie-Hellman key agreement process to provide a shared secret as the basis of an integrity check value and one method uses the Elliptic-Curve key agreement process.
In the first and third 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.</t>
<t>
It should be noted that we did not create an algorithm that parallels ECDSA (Elliptical Curve Digital Signature Algorithm) like was done for DSA (Digital Signature Algorithm).
Given the current PKIX definitions for the public key parameters of elliptic curve, the number of groups is both limited and predefined.
This means that the probability that the same set of parameters are going to be used by the key requester and the key validator would be high.
Also since the group verification has been done centrally and with lots of validation, the odds that a cryptographically weak group is used are much reduced.
Additionally, any system which could compute such a parallel algorithm would just be able to use the ECDSA algorithm in any event.</t>
<section title="Changes since RFC2875">
<t>The following changes have been made:
<list style="symbols">
<t>The Static DH Proof-of-Possession algorithm has been re-written for parameterization of the hash algorithm and the message authentication code (MAC) algorithm.</t>
<t>New instances of the static DH POP algorithm have been created using HMAC paired with the SHA-224, SHA-256, SHA-384 and SHA_512 hash algorithms.</t>
<t>The Discrete Logarithm Signature algorithm has been re-written for parameterization of the hash algorithm.</t>
<t>New instances of the Discrete Logarithm Signature have been created for the SHA-224, SHA-256, SHA-384, and SHA-512 hash functions.</t>
<t>A new Static ECDH Proof-of-Possession algorithm has been added.</t>
<t>New instances of the Static ECDH POP algorithm has been created using HMAC paired with the SHA-224, SHA-256, SHA-384, and SHA-512 hash functions.</t>
</list>
</t>
</section>
<section title="Requirements Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>When the words are in lower case they have their natural language meaning.</t>
</section>
</section>
<section title="Terminology">
<t>The following definitions will be used in this document</t>
<t>DH certificate = a certificate whose SubjectPublicKey is a DH public value and is signed with any signature algorithm (e.g., RSA or DSA).</t>
<t>ECDH certificate = a certificate whose SubjectPublicKey is an ECDH public value and is signed with any signature algorithm (e.g., RSA or ECDSA).</t>
<t>Proof-of-Possession (POP) is 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 Appendix C in <xref target="CRMF"/>.</t>
</section>
<section title="Notation">
<t>This section describes mathematical notations, conventions and symbols used throughout this document.</t>
<figure>
<artwork>
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
KDF(a) : Key Derivation Function producing a value from a.
MAC(a, b) : Message Authentication Code function where
a is the text and b is the key
LEFTMOST(a,b) : Return the b left most bits of a
</artwork>
</figure>
</section>
<section title="Static DH Proof-of-Possession Process" anchor="dh-static">
<t>The Static DH POP algorithm is setup to use a key derivation function (KDF) and a message authentication code (MAC). This algorithm requires that a common set of group parameters be used by both the creator and verifier of the POP value. </t>
<t> The steps for creating a DH POP are:
<list style="numbers">
<t>An entity (E) chooses the group parameters for a DH key agreement.
<vspace blankLines='1'/>
This is done simply by selecting the group parameters from a certificate for the recipient of the POP process.
<vspace blankLines='1'/>
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).
<vspace blankLines='1'/>
Rpub = g^x mod p (where x=Rpriv, the private DH value)
</t>
<t> The entity generates a DH public/private key-pair using the parameters from step 1.
<vspace blankLines='1'/>
For an entity E:
<vspace blankLines='1'/>
Epriv = DH private value = y
<vspace blankLines='0'/>
Epub = DH public value = g^y mod p
</t>
<t> The POP computation process will then consist of:
<list style="format %c)">
<t> 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.)</t>
<t> A shared DH secret is computed, as follows,
<vspace blankLines='1'/>
shared secret = ZZ = g^xy mod p
<vspace blankLines='1'/>
[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.]</t>
<t>A temporary key K is derived from the shared secret ZZ as follows:
<list style="empty">
<t>K = KDF(LeadingInfo | ZZ | TrailingInfo)</t>
<t>LeadingInfo ::= Subject Distinguished Name from certificate</t>
<t>TrailingInfo ::= Issuer Distinguished Name from certificate</t>
</list>
</t>
<t> Using the defined MAC function, compute MAC(K, text).</t>
</list>
</t>
</list>
</t>
<t>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:
<list style="format %c)">
<t> 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</t>
<t> Only the Recipient that the entity sent the request to could
actually verify the request because they would require their
own private key to compute the same shared secret. In the case
where the recipient is a Certification Authority, this
protects the Entity from rogue CAs.</t>
</list>
</t>
<section title="ASN Encoding">
<t>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-256, SHA-384 and SHA-512 hash values. The ASN.1 structures associated with the static Diffie-Hellman POP algorithm are:</t>
<?rfc linefile="1:ForDraft/rfc2875-static.incl"?><figure><artwork>
DhSigStatic ::= SEQUENCE {
issuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-dhPop-static-HMAC-SHA1
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-dhPop-static-HMAC-SHA1 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 3
}
id-dhPop-static-SHA1-HMAC-SHA1 OBJECT IDENTIFIER ::=
id-dhPop-static-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) TBD1
}
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) TBD2
}
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) TBD3
}
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) TBD4
}
</artwork></figure>
<?rfc linefile="208:rfc2875-bis.xml"?>
<t>In the above ASN.1 the following items are defined:
<list style="hanging">
<t hangText="DhSigStatic"><vspace/>This structure ASN.1 type structure holds the information describing the signature. The structure has the following fields:
<list style="hanging">
<t hangText="issuerAndSerial"><vspace/>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.</t>
<t hangText="hashValue"><vspace/>This field contains the result of the MAC operation in step 3d.</t>
</list>
</t>
<t hangText="sa-dh-static-SHA1-HMAC-SHA1"><vspace/>An ASN.1 SIGNATURE-ALGORITHM object which associates together the information describing a signature algorithm. The structure DhSigStatic represents the signature value and the parameters MUST be absent.</t>
<t hangText="id-dhPop-static-SHA1-HMAC-SHA1"><vspace/>This OID identifies the Static DH POP algorithm that uses SHA1 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-dhPop-static-HMAC-SHA1 which was defined in the previous version of this document <xref target="RFC2875"/>.</t>
<t hangText="sa-dh-static-SHA224-HMAC-SHA224"><vspace/>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.</t>
<t hangText="id-dhPop-static-SHA224-HMAC-SHA224"><vspace/>This OID identifies the Static DH POP algorithm that uses SHA224 as the KDF and HMAC-SHA224 as the MAC function.</t>
<t hangText="sa-dh-static-SHA256-HMAC-SHA256"><vspace/>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.</t>
<t hangText="id-dhPop-static-SHA1-HMAC-SHA256"><vspace/>This OID identifies the Static DH POP algorithm that uses SHA256 as the KDF and HMAC-SHA256 as the MAC function.</t>
<t hangText="sa-dh-static-SHA384-HMAC-SHA384"><vspace/>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.</t>
<t hangText="id-dhPop-static-SHA1-HMAC-SHA384"><vspace/>This OID identifies the Static DH POP algorithm that uses SHA384 as the KDF and HMAC-SHA384 as the MAC function.</t>
<t hangText="sa-dh-static-SHA512-HMAC-SHA512"><vspace/>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.</t>
<t hangText="id-dhPop-static-SHA1-HMAC-SHA512"><vspace/>This OID identifies the Static DH POP algorithm that uses SHA512 as the KDF and HMAC-SHA512 as the MAC function.</t>
</list>
</t>
</section>
</section>
<section title="Discrete Logarithm Signature" anchor="dh-sig">
<t>The use of a single set of parameters for an entire public key
infrastructure allows all keys in the group to be attacked together.</t>
<t>For this reason we need to create a proof of possession for Diffie-
Hellman keys that does not require the use of a common set of
parameters.</t>
<t> This POP is based on the Digital Signature Algorithm, but we have
removed the restrictions imposed by the [FIPS-186] 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 <xref target="RFC2631"/> 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 group attacks.</t>
<t>The following definitions are used in the rest of this section:</t>
<t>
p is a large prime
<vspace blankLines='0'/>
g = h(p-1)/q mod p ,
<vspace blankLines='0'/>
where h is any integer 1 < h < p-1 such that h(p-1) mod q > 1
<vspace blankLines='0'/>
(g has order q mod p)
<vspace blankLines='0'/>
q is a large prime
<vspace blankLines='0'/>
j is a large integer such that p = qj + 1
<vspace blankLines='0'/>
x is a randomly or pseudo-randomly generated integer with 1 < x < q
<vspace blankLines='0'/>
y = g^x mod p
<vspace blankLines='0'/>
HASH is a hash function such that
<vspace blankLines='0'/>
h = the output size of HASH in bits
</t>
<t>Note: These definitions match the ones in <xref target="RFC2631"/>.</t>
<section title="Expanding the Digest Value">
<t>Besides the addition of a q parameter, [FIPS-186] also imposes size
restrictions on the parameters. The length of q must be 160-bits
(matching output of the SHA-1 digest algorithm) and 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 h bits in length. (If the hash function is SHA-1, then h=160 bits and the size restriction
on q is identical with that in <xref target="RFC2631"/>.)</t>
<t> Given that 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 h
then a method must be provided to expand the hash length.</t>
<t> The method for expanding the digest value used in this section does
not add any additional security beyond the h bits provided by the hash algorithm. The value being signed is increased mainly to enhance the
difficulty of reversing the signature process.</t>
<t> This algorithm produces m, the value to be signed.</t>
<t> Let L = the size of q (i.e., 2^L <= q < 2^(L+1)).
<vspace blankLines='0'/>Let M be the original message to be signed.
<vspace blankLines='0'/>Let h be the length of HASH output
</t>
<t>
<list style="numbers">
<t> Compute d = HASH(M), the digest of the original message.</t>
<t>If L == h then m = d.</t>
<t>If L > h then follow steps (a) through (d) below.
<list style="format %c)">
<t>Set n = L / h, (if L = 200, h = 160 then n = 1)<cref source="PEY">Defined a floor operator?</cref></t>
<t>Set m = d, the initial computed digest value.</t>
<t> For i = 0 to n - 1
<vspace blankLines='0'/>
m = m | HASH(m)</t>
<t> m = LEFTMOST(m, L-1)</t>
</list></t>
</list>
</t>
<t>Thus the final result of the process meets the criteria that 0 <= m <
q.</t>
</section>
<section title="Signature Computation Algorithm">
<t>The signature algorithm produces the pair of values (r, s), which is
the signature. The signature is computed as follows:</t>
<t> Given m, the value to be signed, as well as the parameters defined
earlier in section 5.</t>
<t>
<list style="numbers">
<t> Generate a random or pseudorandom integer k, such that 0 < k^-1 <
q.</t>
<t>Compute r = (g^k mod p) mod q.</t>
<t> If r is zero, repeat from step 1.</t>
<t> Compute s = (k^-1 (m + xr)) mod q.</t>
<t> If s is zero, repeat from step 1.</t>
</list>
</t>
</section>
<section title="Signature Verification Algorithm">
<t> The signature verification process is far more complicated than is
normal for the Digital Signature Algorithm, as some assumptions about
the validity of parameters cannot be taken for granted.</t>
<t> Given a message m to be validated, the signature value pair (r, s)
and the parameters for the key.</t>
<t>
<list style="numbers">
<t>Perform a strong verification that p is a prime number.</t>
<t>Perform a strong verification that q is a prime number.</t>
<t> 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.</t>
<t>Verify that r and s are in the range [1, q-1].</t>
<t>Compute w = (s^-1) mod q.</t>
<t>Compute u1 = m*w mod q.</t>
<t>Compute u2 = r*w mod q.</t>
<t>Compute v = ((g^u1 * y^u2) mod p) mod q.</t>
<t>Compare v and r, if they are the same then the signature verified
correctly.</t>
</list>
</t>
</section>
<section title="ASN.1 Encoding">
<t>The signature algorithm is parameterized by the hash algorithm.
The ASN.1 structures associated with the Discrete Logarithm Signature algorithm are:</t>
<?rfc linefile="1:ForDraft/rfc2875-sig.incl"?><figure><artwork>
sa-dh-pop-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-dh-pop-SHA1 OBJECT IDENTIFIER ::= id-alg-dh-pop
id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 }
sa-dh-pop-SHA224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA224
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha224 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD5
}
sa-dh-pop-SHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA256
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha256 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD6
}
sa-dh-pop-SHA384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA384
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha384 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD7
}
sa-dh-pop-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA512
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha512 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD8
}
</artwork></figure>
<?rfc linefile="406:rfc2875-bis.xml"?>
<t>In the above ASN.1 the following items are defined:
<list style="hanging">
<t hangText="sa-dh-pop-SHA1"><vspace/>A SIGNATURE-ALGORITHM object that associates together the information describing this signature algorithm. The structure DSA-Sig-Value represents the signature value and the parameters DomainParameters SHOULD be omitted in the signature, but MUST be present in the associated key request.</t>
<t hangText="id-alg-dh-pop-SHA1"><vspace/>This OID that identifies the discrete logarithm signature using SHA1 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 <xref target="RFC2875"/>.</t>
<t hangText="sa-dh-pop-SHA224"><vspace/>A SIGNATURE-ALGORITHM object that associates together the information describing this signature algorithm. The structure DSA-Sig-Value represents the signature value and the parameters DomainParameters SHOULD be omitted in the signature, but MUST be present in the associated key request.</t>
<t hangText="id-alg-dh-pop-SHA224"><vspace/>This OID that identifies the discrete logarithm signature using SHA224 as the hash algorithm.</t>
<t hangText="sa-dh-pop-SHA256"><vspace/>A SIGNATURE-ALGORITHM object that associates together the information describing this signature algorithm. The structure DSA-Sig-Value represents the signature value and the parameters DomainParameters SHOULD be omitted in the signature, but MUST be present in the associated key request.</t>
<t hangText="id-alg-dh-pop-SHA256"><vspace/>This OID that identifies the discrete logarithm signature using SHA256 as the hash algorithm.</t>
<t hangText="sa-dh-pop-SHA384"><vspace/>A SIGNATURE-ALGORITHM object that associates together the information describing this signature algorithm. The structure DSA-Sig-Value represents the signature value and the parameters DomainParameters SHOULD be omitted in the signature, but MUST be present in the associated key request.</t>
<t hangText="id-alg-dh-pop-SHA384"><vspace/>This OID that identifies the discrete logarithm signature using SHA384 as the hash algorithm.</t>
<t hangText="sa-dh-pop-SHA512"><vspace/>A SIGNATURE-ALGORITHM object that associates together the information describing this signature algorithm. The structure DSA-Sig-Value represents the signature value and the parameters DomainParameters SHOULD be omitted in the signature, but MUST be present in the associated key request.</t>
<t hangText="id-alg-dh-pop-SHA512"><vspace/>This OID that identifies the discrete logarithm signature using SHA512 as the hash algorithm.</t>
</list>
</t>
</section>
</section>
<section title="Static ECDH Proof-of-Possession Process" anchor="ecdh-static">
<t>The Static ECDH POP algorithm is setup to use a key derivation function (KDF) and a message authentication code (MAC). This algorithm requires that a common set of group parameters be used by both the creator and verifier of the POP value. Full details of how Elliptic Curve Cryptography works can be found in RFC 6090 <xref target="RFC6090"/>.</t>
<t> The steps for creating an ECDH POP are:
<list style="numbers">
<t>An entity (E) chooses the group parameters for an ECDH key agreement.
<vspace blankLines='1'/>
This is done simply by selecting the group parameters from a certificate for the recipient of the POP process.
<vspace blankLines='1'/>
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).
<vspace blankLines='1'/>
Rpub = g^x mod p (where x=Rpriv, the private DH value)<cref source="PEY">Are these steps correct for elliptic curve cryptography? This look more like finite field cryptography, as though you had cut and pasted the text but not updated it.</cref>
</t>
<t> The entity generates a DH public/private key-pair using the parameters from step 1.
<vspace blankLines='1'/>
For an entity E:
<vspace blankLines='1'/>
Epriv = DH private value = y
<vspace blankLines='0'/>
Epub = DH public value = g^y mod p
</t>
<t> The POP computation process will then consist of:
<list style="format %c)">
<t> 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.)</t>
<t> A shared ECDH secret is computed, as follows,
<vspace blankLines='1'/>
shared secret = ZZ = g^xy mod p
<vspace blankLines='1'/>
[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.]</t>
<t>A temporary key K is derived from the shared secret ZZ as follows:
<vspace blankLines='1'/>
K = KDF(LeadingInfo | ZZ | TrailingInfo)
<vspace blankLines='1'/>
LeadingInfo ::= Subject Distinguished Name from certificate
<vspace blankLines='0'/>
TrailingInfo ::= Issuer Distinguished Name from certificate</t>
<t> Compute MAC(K, text).</t>
</list>
</t>
</list>
</t>
<t>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:
<list style="format %c)">
<t> 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</t>
<t> Only the Recipient that the entity sent the request to could
actually verify the request because they would require their
own private key to compute the same shared secret. In the case
where the recipient is a Certification Authority, this
protects the Entity from rogue CAs.</t>
</list>
</t>
<section title="ASN.1 Encoding">
<t>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 defined object identifiers for the SHA-1 and SHA-256 hash values. The ASN.1 structures associated with the static EC-DH POP algorithm are:</t>
<?rfc linefile="1:ForDraft/rfc2875-ecdh.incl"?><figure><artwork>
id-alg-ecdhPop-static-SHA224-HMAC-SHA224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD11
}
sa-ecdh-pop-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) TBD912
}
sa-ecdh-pop-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) TBD13
}
sa-ecdh-pop-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) TBD14
}
sa-ecdh-pop-SHA512-HMAC-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-SHA512-HMAC-SHA512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
</artwork></figure>
<?rfc linefile="523:rfc2875-bis.xml"?>
<t>
In the above ASN.1 the following items are defined:
<list style="hanging">
<t hangText="sa-ecdh-static-SHA224-HMAC-SHA224"><vspace/>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.</t>
<t hangText="id-ecdhPop-static-SHA224-HMAC-SHA224"><vspace/>This OID identifies the Static ECDH POP algorithm that uses SHA224 as the KDF and HMAC-SHA224 as the MAC function.</t>
<t hangText="sa-ecdh-static-SHA256-HMAC-SHA256"><vspace/>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.</t>
<t hangText="id-ecdhPop-static-SHA256-HMAC-SHA256"><vspace/>This OID identifies the Static ECDH POP algorithm that uses SHA256 as the KDF and HMAC-SHA256 as the MAC function.</t>
<t hangText="sa-ecdh-static-SHA384-HMAC-SHA384"><vspace/>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.</t>
<t hangText="id-ecdhPop-static-SHA384-HMAC-SHA384"><vspace/>This OID identifies the Static ECDH POP algorithm that uses SHA384 as the KDF and HMAC-SHA384 as the MAC function.</t>
<t hangText="sa-ecdh-static-SHA512-HMAC-SHA512"><vspace/>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.</t>
<t hangText="id-ecdhPop-static-SHA512-HMAC-SHA512"><vspace/>This OID identifies the Static ECDH POP algorithm that uses SHA512 as the KDF and HMAC-SHA512 as the MAC function.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>In the static DH POP and static ECDH POP algorithms, an appropriate value can be produced
by either party. Thus these algorithms only provides integrity and not
origination service. The Discrete Logarithm algorithm provides both
integrity checking and origination checking.</t>
<t>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 that key are
compromised. Similarly, loss of the private key results in an
inability to read messages sent using that key.</t>
<t>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. [FIPS-186] Appendixes 2 and 3 contain information on
the selection of parameters for DH. <xref target="RFC6090"/> Section 10 contains information on the selection of parameter for ECC. The practices outlined in these document
will lead to better selection of parameters.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:bibxml/reference.RFC.2119.xml"?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="575:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2314.xml"?>
<reference anchor='RFC2314'>
<front>
<title abbrev='PKCS #10: Certification Request Syntax'>PKCS #10: Certification Request Syntax Version 1.5</title>
<author initials='B.' surname='Kaliski' fullname='Burt Kaliski'>
<organization>RSA Laboratories East</organization>
<address>
<postal>
<street>20 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code></postal>
<phone>(617) 687-7000</phone>
<email>burt@rsa.com</email></address></author>
<date year='1998' month='March' />
<area>Security</area>
<keyword>public key cryptography standards</keyword></front>
<seriesInfo name='RFC' value='2314' />
<format type='TXT' octets='15814' target='ftp://ftp.isi.edu/in-notes/rfc2314.txt' />
<format type='HTML' octets='9111' target='http://xml.resource.org/public/rfc/html/rfc2314.html' />
<format type='XML' octets='2254' target='http://xml.resource.org/public/rfc/xml/rfc2314.xml' />
</reference>
<?rfc linefile="576:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2104.xml"?>
<reference anchor='RFC2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'>
<organization /></author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'>
<organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'>
<organization /></author>
<date year='1997' month='February' /></front>
<seriesInfo name='RFC' value='2104' />
<format type='TXT' octets='22297' target='ftp://ftp.isi.edu/in-notes/rfc2104.txt' />
</reference>
<?rfc linefile="577:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2631.xml"?>
<reference anchor='RFC2631'>
<front>
<title>Diffie-Hellman Key Agreement Method</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='1999' month='June' /></front>
<seriesInfo name='RFC' value='2631' />
<format type='TXT' octets='25932' target='ftp://ftp.isi.edu/in-notes/rfc2631.txt' />
</reference>
<?rfc linefile="578:rfc2875-bis.xml"?>
</references>
<references title="Informative References">
<?rfc linefile="1:bibxml/reference.RFC.4211.xml"?>
<reference anchor='CRMF'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2005' month='September' /></front>
<seriesInfo name='RFC' value='4211' />
<format type='TXT' octets='86136' target='ftp://ftp.isi.edu/in-notes/rfc4211.txt' />
</reference>
<?rfc linefile="581:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5280.xml"?>
<reference anchor='RFC5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' /></front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='ftp://ftp.isi.edu/in-notes/rfc5280.txt' />
</reference>
<?rfc linefile="582:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.5912.xml"?>
<reference anchor='RFC5912'>
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2010' month='June' /></front>
<seriesInfo name='RFC' value='5912' />
<format type='TXT' octets='216154' target='ftp://ftp.isi.edu/in-notes/rfc5912.txt' />
</reference>
<?rfc linefile="583:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.2875.xml"?>
<reference anchor='RFC2875'>
<front>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title>
<author initials='H.' surname='Prafullchandra' fullname='H. Prafullchandra'>
<organization /></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2000' month='July' /></front>
<seriesInfo name='RFC' value='2875' />
<format type='TXT' octets='45231' target='ftp://ftp.isi.edu/in-notes/rfc2875.txt' />
</reference>
<?rfc linefile="584:rfc2875-bis.xml"?>
<?rfc linefile="1:bibxml/reference.RFC.6090.xml"?>
<reference anchor='RFC6090'>
<front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'>
<organization /></author>
<author initials='K.' surname='Igoe' fullname='K. Igoe'>
<organization /></author>
<author initials='M.' surname='Salter' fullname='M. Salter'>
<organization /></author>
<date year='2011' month='February' /></front>
<seriesInfo name='RFC' value='6090' />
<format type='TXT' octets='75993' target='ftp://ftp.isi.edu/in-notes/rfc6090.txt' />
</reference>
<?rfc linefile="585:rfc2875-bis.xml"?>
</references>
<section title="Open Issues">
<t>The following is a partial list of issues to be addressed:
<list>
<t>What examples should be added?</t>
</list>
</t>
</section>
<section title="ASN.1 Modules">
<section title="1988 ASN.1 Module">
<t>This appendix represents the normative version of the ASN.1 module for this document. In the event of a discrepancy between this module and the 2008 version of the module, this module wins.</t>
<?rfc linefile="1:ForDraft/rfc2875-88.incl"?><figure><artwork>
DH-Sign DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--EXPORTS ALL
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them
-- for their own purposes.
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 }
id-alg-dh-pop-sha256-hmac-sha256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD1
}
END
</artwork></figure>
<?rfc linefile="599:rfc2875-bis.xml"?>
</section>
<section title="2008 ASN.1 Module">
<t>This appendix represents an informative version of the ASN.1 module for this document. This module references the object classes defined by <xref target="RFC5912"/> to more completely describe all of the associations between the elements defined in this document. It also represents a module that will compile using the most current definition of ASN.1</t>
<?rfc linefile="1:ForDraft/rfc2875-08.incl"?><figure><artwork>
DH-Sign
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
TBD9 }
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) };
DhSigStatic ::= SEQUENCE {
issuerAndSerial IssuerAndSerialNumber OPTIONAL,
hashValue MessageDigest
}
sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-dhPop-static-HMAC-SHA1
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-dh }
}
id-dhPop-static-HMAC-SHA1 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) 3
}
id-dhPop-static-SHA1-HMAC-SHA1 OBJECT IDENTIFIER ::=
id-dhPop-static-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) TBD1
}
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) TBD2
}
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) TBD3
}
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) TBD4
}
sa-dh-pop-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-dh-pop-SHA1 OBJECT IDENTIFIER ::= id-alg-dh-pop
id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 }
sa-dh-pop-SHA224 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA224
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha224 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD5
}
sa-dh-pop-SHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA256
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha256 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA256 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD6
}
sa-dh-pop-SHA384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA384
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha384 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA384 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD7
}
sa-dh-pop-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-dh-pop-SHA512
VALUE DSA-Sig-Value
PARAMS TYPE DomainParameters ARE preferredAbsent
HASHES { mda-sha512 }
PUBLIC-KEYS { pk-dh }
}
id-alg-dh-pop-SHA512 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD8
}
id-alg-ecdhPop-static-SHA224-HMAC-SHA224 OBJECT IDENTIFIER ::= {
id-pkix id-alg(6) TBD11
}
sa-ecdh-pop-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) TBD912
}
sa-ecdh-pop-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) TBD13
}
sa-ecdh-pop-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) TBD14
}
sa-ecdh-pop-SHA512-HMAC-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-ecdhPop-static-SHA512-HMAC-SHA512
VALUE DhSigStatic
PARAMS ARE absent
PUBLIC-KEYS { pk-ec }
}
END
</artwork></figure>
<?rfc linefile="603:rfc2875-bis.xml"?>
</section>
</section>
<section title="Example of Static DH Proof-of-Possession">
<t> The following example follows the steps described earlier in section 3.</t>
<t> Step 1: Establishing common Diffie-Hellman 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.</t>
<figure><artwork>
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'
: }
: }
: }
108 30 30: SEQUENCE {
110 17 13: UTCTime '990914010557Z'
125 17 13: UTCTime '991113010557Z'
: }
140 30 70: SEQUENCE {
142 31 11: SET {
144 30 9: SEQUENCE {
146 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
151 13 2: PrintableString 'US'
: }
: }
155 31 17: SET {
157 30 15: SEQUENCE {
159 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
164 13 8: PrintableString 'XETI Inc'
: }
: }
174 31 16: SET {
176 30 14: SEQUENCE {
178 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4
11)
183 13 7: PrintableString 'Testing'
: }
: }
192 31 18: SET {
194 30 16: SEQUENCE {
196 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
201 13 9: PrintableString 'DH TestCA'
: }
: }
: }
212 30 577: SEQUENCE {
216 30 438: SEQUENCE {
220 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1)
229 30 425: SEQUENCE {
233 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
365 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
496 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
531 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
630 30 26: SEQUENCE {
632 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
655 02 1: INTEGER 55
: }
: }
: }
658 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
: }
793 A3 85: [3] {
795 30 83: SEQUENCE {
797 30 29: SEQUENCE {
799 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
804 04 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
: }
828 30 34: SEQUENCE {
830 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29
35)
835 01 1: BOOLEAN TRUE
838 04 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
: }
864 30 14: SEQUENCE {
866 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
871 01 1: BOOLEAN TRUE
874 04 4: OCTET STRING
: 03 02 03 08
: }
: }
: }
: }
880 30 11: SEQUENCE {
882 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
891 05 0: NULL
: }
893 03 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
: }
</artwork></figure>
<t> Step 2. End Entity/User generates a Diffie-Hellman key-pair using the
parameters from the CA certificate.</t>
<t> EE DH public key: SunJCE Diffie-Hellman Public Key:</t>
<figure><artwork>
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
</artwork></figure>
<t> EE DH private key:</t>
<figure><artwork>
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
</artwork></figure>
<t> Step 3. Compute K and the signature.</t>
<t> LeadingInfo: DER encoded Subject/Requestor DN (as in the generated
Certificate Signing Request)</t>
<figure><artwork>
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
</artwork></figure>
<t> TrailingInfo: DER encoded Issuer/Recipient DN (from the certificate
described in step 1)</t>
<figure><artwork>
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
</artwork></figure>
<figure><artwork>
K:
F4 D7 BB 6C C7 2D 21 7F 1C 38 F7 DA 74 2D 51 AD
14 40 66 75
</artwork></figure>
<t> TBS: the "text" for computing the SHA-1 HMAC.</t>
<figure><artwork>
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
</artwork></figure>
<t> Certification Request:</t>
<figure><artwork>
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
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
: }
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 1B 17 AD 4E 65 86 1A 6C
: 7C 85 FA F7 95 DE 48 93 C5 9D C5 24
: }
</artwork></figure>
<t> Signature verification requires CAÆs private key, the CA certificate
and the generated Certification Request.</t>
<t> CA DH private key:</t>
<figure><artwork>
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
</artwork></figure>
</section>
<section title="Example of Discrete Log Signature">
<t> Step 1. Generate a Diffie-Hellman Key with length of q being 256-
bits.</t>
<figure><artwork>
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
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
</artwork></figure>
<t> Step 2. Form the value to be signed and hash with SHA1. The result
of the hash for this example is:</t>
<figure><artwork>
5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6
d4 21 e5 2c
</artwork></figure>
<t> 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:</t>
<figure><artwork>
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
</artwork></figure>
<t> Next the first 255 bits of this value are taken to be the resulting
"hash" value. Note in this case a shift of one bit right is done
since the result is to be treated as an integer:</t>
<figure><artwork>
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
</artwork></figure>
<t> Step 4. The signature value is computed. In this case you get the
values</t>
<figure><artwork>
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
</artwork></figure>
<t> The encoded signature values is then:</t>
<figure><artwork>
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
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
</artwork></figure>
<t> Decoded Version of result:</t>
<figure><artwork>
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)
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
: }
: }
: }
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
: }
</artwork></figure>
</section>
</back>
</rfc>
<!-- LocalWords: PKIX HMAC SHA SubjectPublicKey RSA KDF Rpub Rpriv Epriv Epub
-->
<!-- LocalWords: certificationRequestInfo ZZ xy LeadingInfo TrailingInfo CAs
-->
<!-- LocalWords: ASN issuerAndSerial DhSigStatic OID OIDs dhPop FIPS qj xr alg
-->
<!-- LocalWords: pseudorandom DomainParameters dh
-->
| PAFTECH AB 2003-2026 | 2026-04-23 09:37:06 |