idnits 2.17.1 draft-schaad-pkix-rfc2875-bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 84 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2013) is 4042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1838 -- Looks like a reference, but probably isn't: '3' on line 1383 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 2875 (Obsoleted by RFC 6955) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Obsoletes: 2875 (if approved) H. Prafullchandra 5 Intended status: Standards Track Hy-Trust 6 Expires: September 28, 2013 March 27, 2013 8 Diffie-Hellman Proof-of-Possession Algorithms 9 draft-schaad-pkix-rfc2875-bis-08 11 Abstract 13 This document describes two methods for producing an integrity check 14 value from a Diffie-Hellman key pair and one method for producing an 15 integrity check value from an Elliptic Curve key pair. This behavior 16 is needed for such operations as creating the signature of a PKCS #10 17 certification request. These algorithms are designed to provide a 18 proof-of-possession of the private key and not to be a general 19 purpose signing algorithm. 21 This document obsoletes RFC 2875. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 28, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1. Changes since RFC2875 . . . . . . . . . . . . . . . . . . 4 71 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Static DH Proof-of-Possession Process . . . . . . . . . . . . 5 75 4.1. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . 7 76 5. Discrete Logarithm Signature . . . . . . . . . . . . . . . . 10 77 5.1. Expanding the Digest Value . . . . . . . . . . . . . . . 11 78 5.2. Signature Computation Algorithm . . . . . . . . . . . . . 12 79 5.3. Signature Verification Algorithm . . . . . . . . . . . . 12 80 5.4. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . 13 81 6. Static ECDH Proof-of-Possession Process . . . . . . . . . . . 15 82 6.1. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . 17 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 20 89 A.1. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21 90 A.2. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 91 Appendix B. Example of Static DH Proof-of-Possession . . . . . . 27 92 Appendix C. Example of Discrete Log Signature . . . . . . . . . 35 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 95 1. Introduction 96 Among the responsibilities of a Certificate Authority in issuing 97 certificates is a requirement that it verifies the identity for the 98 entity to which it is issuing a certificate and that it verifies that 99 the private key for the public key to be placed in the certificate is 100 in the possession of that entity. The process of validating that the 101 private key is held by the requester of the certificate is called 102 Proof-of-Possession(POP). Further details on why POP is important 103 can be found in Appendix C of RFC 4211 [CRMF]. 105 This document is designed to deal with the problem of how to support 106 POP for encryption-only keys. PKCS #10 [RFC2986] and the Certificate 107 Request Message Format (CRMF) [CRMF] both define syntaxes for 108 certification requests. However, while CRMF supports an alternative 109 method to support POP for encryption-only keys, PKCS #10 does not. 110 PKCS #10 assumes that the public key being requested for 111 certification corresponds to an algorithm that is capable of 112 producing a POP by a signature operation. Diffie-Hellman (DH) and 113 Elliptic Curve Diffie-Hellman (ECDH) are key agreement algorithms 114 and, as such, cannot be directly used for signing or encryption. 116 This document describes a set of three proof-of-possession 117 algorithms. Two methods use the key agreement process (one for 118 Diffie-Hellman and one for Elliptic-Curve DH) to provide a shared 119 secret as the basis of an integrity check value. For these methods, 120 the value is constructed for a specific recipient/verifier by using a 121 public key of that verifier. The third method uses a modified 122 signature algorithm (for Diffie-Hellman). This method allows for 123 arbitrary verifiers. 125 It should be noted that we did not create an algorithm that parallels 126 ECDSA (Elliptical Curve Digital Signature Algorithm) as was done for 127 DSA (Digital Signature Algorithm). When using ECDH, the common 128 practice is to use one of a set of predefined curves, each of these 129 curves has been designed to be paired with one of the commonly used 130 hash algorithm. This differs in practice from the Diffie-Hellman 131 case where the common practice is to generate a set of group 132 parameters either on a single machine or for a given community and 133 are aligned to encryption algorithms rather than hash algorithms. 134 The implication is that, if a key has the ability to perform the 135 modified DSA algorithm for ECDSA, it should be able to use the 136 correct hash algorithm and perform the regular ECDSA signature 137 algorithm with the correctly sized hash. 139 1.1. Changes since RFC2875 141 The following changes have been made: 143 o The Static DH Proof-of-Possession algorithm has been re-written 144 for parameterization of the hash algorithm and the message 145 authentication code (MAC) algorithm. 147 o New instances of the static DH POP algorithm have been created 148 using HMAC paired with the SHA-224, SHA-256, SHA-384 and SHA-512 149 hash algorithms. However the current SHA-1 algorithm remains 150 identical. 152 o The Discrete Logarithm Signature algorithm has been re-written for 153 parameterization of the hash algorithm. 155 o New instances of the Discrete Logarithm Signature have been 156 created for the SHA-224, SHA-256, SHA-384, and SHA-512 hash 157 functions. However the current SHA-1 algorithm remains identical. 159 o A new Static ECDH Proof-of-Possession algorithm has been added. 161 o New instances of the Static ECDH POP algorithm has been created 162 using HMAC paired with the SHA-224, SHA-256, SHA-384, and SHA-512 163 hash functions. 165 1.2. Requirements Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 When the words are in lower case they have their natural language 172 meaning. 174 2. Terminology 176 The following definitions will be used in this document 178 DH certificate = a certificate whose SubjectPublicKey is a DH public 179 value and is signed with any signature algorithm (e.g., RSA or DSA). 181 ECDH certificate = a certificate whose SubjectPublicKey is an ECDH 182 public value and is signed with any signature algorithm (e.g., RSA or 183 ECDSA). 185 Proof-of-Possession (POP) is a means that provides a method for a 186 second party to perform an algorithm to establish with some degree of 187 assurance that the first party does possess and has the ability to 188 use a private key. The reasoning behind doing POP can be found in 189 Appendix C in [CRMF]. 191 3. Notation 193 This section describes mathematical notations, conventions and 194 symbols used throughout this document. 196 a | b : Concatenation of a and b 197 a ^ b : a raised to the power of b 198 a mod b : a modulo b 199 a / b : a divided by b using integer division 200 a * b : a times b 201 depending on context multiplication may be within 202 an Elliptic Curve or normal multiplication 204 KDF(a) : Key Derivation Function producing a value from a. 205 MAC(a, b) : Message Authentication Code function where 206 a is the key and b is the text 207 LEFTMOST(a, b) : Return the b left most bits of a 208 FLOOR(a) : Return n where n is the largest integer such that 209 n <= a 211 Details on how to implement the HMAC version of a MAC function used 212 in this document can be found in RFC 2104 [RFC2104], RFC 6234 213 [RFC6234] and RFC 4231 [RFC4231]. 215 4. Static DH Proof-of-Possession Process 217 The Static DH POP algorithm is set up to use a key derivation 218 function (KDF) and a message authentication code (MAC). This 219 algorithm requires that a common set of group parameters be used by 220 both the creator and verifier of the POP value. 222 The steps for creating a DH POP are: 224 1. An entity (E) chooses the group parameters for a DH key 225 agreement. 227 This is done simply by selecting the group parameters from a 228 certificate for the recipient of the POP process. A certificate 229 with the correct group parameters has to be available. 231 Let the common DH parameters be g and p; and let the DH key-pair 232 from the certificate be known as the Recipient key pair (Rpub and 233 Rpriv). 235 Rpub = g^x mod p (where x=Rpriv, the private DH value) 237 2. The entity generates a DH public/private key-pair using the group 238 parameters from step 1. 240 For an entity E: 242 Epriv = DH private value = y 243 Epub = DH public value = g^y mod p 245 3. The POP computation process will then consist of: 247 a) The value to be signed (text) is obtained. (For a PKCS #10 248 object, the value is the DER encoded 249 certificationRequestInfo field represented as an octet 250 string.) 252 b) A shared DH secret is computed, as follows, 254 shared secret = ZZ = g^(x*y) mod p 256 [This is done by the entity E as Rpub^y and by the 257 Recipient as Epub^x, where Rpub is retrieved from the 258 Recipient's DH certificate (or is provided in the protocol) 259 and Epub is retrieved from the certification request.] 261 c) A temporary key K is derived from the shared secret ZZ as 262 follows: 264 K = KDF(LeadingInfo | ZZ | TrailingInfo) 266 LeadingInfo ::= Subject Distinguished Name from 267 recipient's certificate 269 TrailingInfo ::= Issuer Distinguished Name from 270 recipient's certificate 272 d) Using the defined MAC function, compute MAC(K, text). 274 The POP verification process requires the Recipient to carry out 275 steps (a) through (d) and then simply compare the result of step (d) 276 with what it received as the signature component. If they match then 277 the following can be concluded: 279 a) The Entity possesses the private key corresponding to the public 280 key in the certification request because it needed the private key 281 to calculate the shared secret; and 283 b) Only the Recipient that the entity sent the request to could 284 actually verify the request because it would require its own 285 private key to compute the same shared secret. In the case where 286 the recipient is a Certification Authority, this protects the 287 Entity from rogue CAs. 289 4.1. ASN.1 Encoding 291 The algorithm outlined above allows for the use of an arbitrary hash 292 function in computing the temporary key and the MAC algorithm. In 293 this specification we define object identifiers for the SHA-1, 294 SHA-256, SHA-384 and SHA-512 hash values and use HMAC for the MAC 295 algorithm. The ASN.1 structures associated with the static Diffie- 296 Hellman POP algorithm are: 298 DhSigStatic ::= SEQUENCE { 299 issuerAndSerial IssuerAndSerialNumber OPTIONAL, 300 hashValue MessageDigest 301 } 303 sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= { 304 IDENTIFIER id-dhPop-static-sha1-hmac-sha1 305 VALUE DhSigStatic 306 PARAMS ARE absent 307 PUBLIC-KEYS { pk-dh } 308 } 310 id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= { 311 id-pkix id-alg(6) 3 312 } 314 id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::= 315 id-dh-sig-hmac-sha1 317 sa-dhPop-static-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= { 318 IDENTIFIER id-alg-dhPop-static-sha224-hmac-sha224 319 VALUE DhSigStatic 320 PARAMS ARE absent 321 PUBLIC-KEYS { pk-dh } 322 } 324 id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 325 id-pkix id-alg(6) 15 326 } 327 sa-dhPop-static-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= { 328 IDENTIFIER id-alg-dhPop-static-sha256-hmac-sha256 329 VALUE DhSigStatic 330 PARAMS ARE absent 331 PUBLIC-KEYS { pk-dh } 332 } 334 id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 335 id-pkix id-alg(6) 16 336 } 338 sa-dhPop-static-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= { 339 IDENTIFIER id-alg-dhPop-static-sha384-hmac-sha384 340 VALUE DhSigStatic 341 PARAMS ARE absent 342 PUBLIC-KEYS { pk-dh } 343 } 345 id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 346 id-pkix id-alg(6) 17 347 } 349 sa-dhPop-static-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= { 350 IDENTIFIER id-alg-dhPop-static-sha512-hmac-sha512 351 VALUE DhSigStatic 352 PARAMS ARE absent 353 PUBLIC-KEYS { pk-dh } 354 } 356 id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 357 id-pkix id-alg(6) 18 358 } 360 In the above ASN.1 the following items are defined: 362 DhSigStatic 363 This ASN.1 type structure holds the information describing the 364 signature. The structure has the following fields: 366 issuerAndSerial 367 This field contains the issuer name and serial number of the 368 certificate from which the public key was obtained. The 369 issuerAndSerial field is omitted if the public key did not 370 come from a certificate. 372 hashValue 373 This field contains the result of the MAC operation in step 374 3d. 376 sa-dhPop-static-sha1-hmac-sha1 377 An ASN.1 SIGNATURE-ALGORITHM object which associates together the 378 information describing a signature algorithm. The structure 379 DhSigStatic represents the signature value and the parameters MUST 380 be absent. 382 id-dhPop-static-sha1-hmac-sha1 383 This OID identifies the Static DH POP algorithm that uses SHA-1 as 384 the KDF and HMAC-SHA1 as the MAC function. The new OID was 385 created for naming consistency with the other OIDs defined here. 386 The value of the OID is the same value as id-dh-sig-hmac-sha1 387 which was defined in the previous version of this document 388 [RFC2875]. 390 sa-dhPop-static-sha224-hmac-sha224 391 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 392 information describing this signature algorithm. The structure 393 DhSigStatic represents the signature value and the parameters MUST 394 be absent. 396 id-dhPop-static-sha224-hmac-sha224 397 This OID identifies the Static DH POP algorithm that uses SHA-224 398 as the KDF and HMAC-SHA224 as the MAC function. 400 sa-dhPop-static-sha256-hmac-sha256 401 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 402 information describing this signature algorithm. The structure 403 DhSigStatic represents the signature value and the parameters MUST 404 be absent. 406 id-dhPop-static-sha256-hmac-sha256 407 This OID identifies the Static DH POP algorithm that uses SHA-256 408 as the KDF and HMAC-SHA256 as the MAC function. 410 sa-dhPop-static-sha384-hmac-sha384 411 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 412 information describing this signature algorithm. The structure 413 DhSigStatic represents the signature value and the parameters MUST 414 be absent. 416 id-dhPop-static-sha384-hmac-sha384 417 This OID identifies the Static DH POP algorithm that uses SHA-384 418 as the KDF and HMAC-SHA384 as the MAC function. 420 sa-dhPop-static-sha512-hmac-sha512 421 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 422 information describing this signature algorithm. The structure 423 DhSigStatic represents the signature value and the parameters MUST 424 be absent. 426 id-dhPop-static-sha512-hmac-sha512 427 This OID identifies the Static DH POP algorithm that uses SHA-512 428 as the KDF and HMAC-SHA512 as the MAC function. 430 5. Discrete Logarithm Signature 432 When a single set of parameters is used for a large group of keys, 433 the chances that a collision will occur in the set of keys either by 434 accident or design increases as the number of keys used increases. A 435 large number of keys from a single parameter set also encourages the 436 use of brute force methods of attack as the entire set of keys in the 437 parameters can be attacked in a single operation rather than having 438 to attack each key parameter set individually. 440 For this reason we need to create a proof-of-possession for Diffie- 441 Hellman keys that does not require the use of a common set of 442 parameters. 444 This POP is based on the Digital Signature Algorithm, but we have 445 removed the restrictions dealing with the hash and key sizes imposed 446 by the [FIPS-186] standard. The use of this method does impose some 447 additional restrictions on the set of keys that may be used, however 448 if the key generation algorithm documented in [RFC2631] is used the 449 required restrictions are met. The additional restrictions are the 450 requirement for the existence of a q parameter. Adding the q 451 parameter is generally accepted as a good practice as it allows for 452 checking of small subgroup attacks. 454 The following definitions are used in the rest of this section: 456 p is a large prime 457 g = h^((p-1)/q) mod p , 458 where h is any integer 1 < h < p-1 such that h^((p-1)/q) mod p > 1 459 (g has order q mod p) 460 q is a large prime 461 j is a large integer such that p = q*j + 1 462 x is a randomly or pseudo-randomly generated integer with 1 < x < q 463 y = g^x mod p 464 HASH is a hash function such that 465 b = the output size of HASH in bits 467 Note: These definitions match the ones in [RFC2631]. 469 5.1. Expanding the Digest Value 471 Besides the addition of a q parameter, [FIPS-186] also imposes size 472 restrictions on the parameters. The length of q must be 160 bits 473 (matching the output length of the SHA-1 digest algorithm) and the 474 length of p must be 1024 bits. The size restriction on p is 475 eliminated in this document, but the size restriction on q is 476 replaced with the requirement that q must be at least b bits in 477 length. (If the hash function is SHA-1, then b=160 bits and the size 478 restriction on b is identical with that in [FIPS-186].) 480 Given that there is not a random length-hashing algorithm, a hash 481 value of the message will need to be derived such that the hash is in 482 the range from 0 to q-1. If the length of q is greater than b then a 483 method must be provided to expand the hash. 485 The method for expanding the digest value used in this section does 486 not add any additional security beyond the b bits provided by the 487 hash algorithm. For this reason the hash algorithm should be the 488 largest size possible to match q. The value being signed is 489 increased mainly to enhance the difficulty of reversing the signature 490 process. 492 This algorithm produces m, the value to be signed. 494 Let L = the size of q (i.e., 2^L <= q < 2^(L+1)). 495 Let M be the original message to be signed. 496 Let b be the length of HASH output 498 1. Compute d = HASH(M), the digest of the original message. 500 2. If L == b then m = d. 502 3. If L > b then follow steps (a) through (d) below. 504 a) Set n = FLOOR(L / b) 506 b) Set m = d, the initial computed digest value. 508 c) For i = 0 to n - 1 509 m = m | HASH(m) 511 d) m = LEFTMOST(m, L-1) 513 Thus the final result of the process meets the criteria that 0 <= m < 514 q. 516 5.2. Signature Computation Algorithm 518 The signature algorithm produces the pair of values (r, s), which is 519 the signature. The signature is computed as follows: 521 Given m, the value to be signed, as well as the parameters defined 522 earlier in section 5. 524 1. Generate a random or pseudorandom integer k, such that 0 < k-1 < 525 q. 527 2. Compute r = (g^k mod p) mod q. 529 3. If r is zero, repeat from step 1. 531 4. Compute s = ((k^-1) * (m + x*r)) mod q. 533 5. If s is zero, repeat from step 1. 535 5.3. Signature Verification Algorithm 537 The signature verification process is far more complicated than is 538 normal for the Digital Signature Algorithm, as some assumptions about 539 the validity of parameters cannot be taken for granted. 541 Given a value m to be validated, the signature value pair (r, s) and 542 the parameters for the key. 544 1. Perform a strong verification that p is a prime number. 546 2. Perform a strong verification that q is a prime number. 548 3. Verify that q is a factor of p-1, if any of the above checks fail 549 then the signature cannot be verified and must be considered a 550 failure. 552 4. Verify that r and s are in the range [1, q-1]. 554 5. Compute w = (s^-1) mod q. 556 6. Compute u1 = m*w mod q. 558 7. Compute u2 = r*w mod q. 560 8. Compute v = ((g^u1 * y^u2) mod p) mod q. 562 9. Compare v and r, if they are the same then the signature verified 563 correctly. 565 5.4. ASN.1 Encoding 567 The signature algorithm is parameterized by the hash algorithm. The 568 ASN.1 structures associated with the Discrete Logarithm Signature 569 algorithm are: 571 sa-dhPop-SHA1 SIGNATURE-ALGORITHM ::= { 572 IDENTIFIER id-alg-dh-pop 573 VALUE DSA-Sig-Value 574 PARAMS TYPE DomainParameters ARE preferredAbsent 575 HASHES { mda-sha1 } 576 PUBLIC-KEYS { pk-dh } 577 } 579 id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop 581 id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 } 583 sa-dhPop-sha224 SIGNATURE-ALGORITHM ::= { 584 IDENTIFIER id-alg-dhPop-sha224 585 VALUE DSA-Sig-Value 586 PARAMS TYPE DomainParameters ARE preferredAbsent 587 HASHES { mda-sha224 } 588 PUBLIC-KEYS { pk-dh } 589 } 591 id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= { 592 id-pkix id-alg(6) 5 593 } 595 sa-dhPop-sha256 SIGNATURE-ALGORITHM ::= { 596 IDENTIFIER id-alg-dhPop-sha256 597 VALUE DSA-Sig-Value 598 PARAMS TYPE DomainParameters ARE preferredAbsent 599 HASHES { mda-sha256 } 600 PUBLIC-KEYS { pk-dh } 601 } 603 id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= { 604 id-pkix id-alg(6) 6 605 } 607 sa-dhPop-sha384 SIGNATURE-ALGORITHM ::= { 608 IDENTIFIER id-alg-dhPop-sha384 609 VALUE DSA-Sig-Value 610 PARAMS TYPE DomainParameters ARE preferredAbsent 611 HASHES { mda-sha384 } 612 PUBLIC-KEYS { pk-dh } 614 } 616 id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= { 617 id-pkix id-alg(6) 7 618 } 620 sa-dhPop-sha512 SIGNATURE-ALGORITHM ::= { 621 IDENTIFIER id-alg-dhPop-sha512 622 VALUE DSA-Sig-Value 623 PARAMS TYPE DomainParameters ARE preferredAbsent 624 HASHES { mda-sha512 } 625 PUBLIC-KEYS { pk-dh } 626 } 628 id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= { 629 id-pkix id-alg(6) 8 630 } 632 In the above ASN.1 the following items are defined: 634 sa-dhPop-sha1 635 A SIGNATURE-ALGORITHM object that associates together the 636 information describing this signature algorithm. The structure 637 DSA-Sig-Value represents the signature value and the parameters 638 DomainParameters SHOULD be omitted in the signature, but MUST be 639 present in the associated key request. 641 id-alg-dhPop-sha1 642 This OID identifies the discrete logarithm signature using SHA-1 643 as the hash algorithm. The new OID was created for naming 644 consistency with the others defined here. The value of the OID is 645 the same as id-alg-dh-pop which was defined in the previous 646 version of this document [RFC2875]. 648 sa-dhPop-sha224 649 A SIGNATURE-ALGORITHM object that associates together the 650 information describing this signature algorithm. The structure 651 DSA-Sig-Value represents the signature value and the parameters 652 DomainParameters SHOULD be omitted in the signature, but MUST be 653 present in the associated key request. 655 id-alg-dhPop-sha224 656 This OID identifies the discrete logarithm signature using SHA-224 657 as the hash algorithm. 659 sa-dhPop-sha256 660 A SIGNATURE-ALGORITHM object that associates together the 661 information describing this signature algorithm. The structure 662 DSA-Sig-Value represents the signature value and the parameters 663 DomainParameters SHOULD be omitted in the signature, but MUST be 664 present in the associated key request. 666 id-alg-dhPop-sha256 667 This OID identifies the discrete logarithm signature using SHA-256 668 as the hash algorithm. 670 sa-dhPop-sha384 671 A SIGNATURE-ALGORITHM object that associates together the 672 information describing this signature algorithm. The structure 673 DSA-Sig-Value represents the signature value and the parameters 674 DomainParameters SHOULD be omitted in the signature, but MUST be 675 present in the associated key request. 677 id-alg-dhPop-sha384 678 This OID identifies the discrete logarithm signature using SHA-384 679 as the hash algorithm. 681 sa-dhPop-sha512 682 A SIGNATURE-ALGORITHM object that associates together the 683 information describing this signature algorithm. The structure 684 DSA-Sig-Value represents the signature value and the parameters 685 DomainParameters SHOULD be omitted in the signature, but MUST be 686 present in the associated key request. 688 id-alg-dhPop-sha512 689 This OID identifies the discrete logarithm signature using SHA-512 690 as the hash algorithm. 692 6. Static ECDH Proof-of-Possession Process 694 The Static ECDH POP algorithm is set up to use a key derivation 695 function (KDF) and a message authentication code (MAC). This 696 algorithm requires that a common set of group parameters be used by 697 both the creator and verifier of the POP value. Full details of how 698 Elliptic Curve Cryptography works can be found in RFC 6090 [RFC6090]. 700 The steps for creating an ECDH POP are: 702 1. An entity (E) chooses the group parameters for an ECDH key 703 agreement. 705 This is done simply by selecting the group parameters from a 706 certificate for the recipient of the POP process. A certificate 707 with the correct group parameters has to be available. 709 The ECDH parameters can be identified either by a named group or 710 by a set of curve parameters. Section 2.3.5 of RFC 3279 711 [RFC3279] documents how the parameters are encoded for PKIX 712 certificates. For PKIX-based applications, the parameters will 713 almost always be defined by a named group. Designate G as the 714 group from the ECDH parameters. Let the ECDH key-pair associated 715 with the certificate be known as the Recipient key pair (Rpub and 716 Rpriv). 718 Rpub = Rpriv * G 720 2. The entity generates an ECDH public/private key-pair using the 721 parameters from step 1. 723 For an entity E: 725 Epriv = Entity private value 726 Epub = ECDH public point = Epriv * G 728 3. The POP computation process will then consist of: 730 a) The value to be signed (text) is obtained. (For a PKCS #10 731 object, the value is the DER encoded 732 certificationRequestInfo field represented as an octet 733 string.) 735 b) A shared ECDH secret is computed, as follows, 737 shared secret point (x, y) = Epriv * Rpub = Rpriv * Epub 739 shared secret value ZZ is the x coordinate of the computed 740 point 742 c) A temporary key K is derived from the shared secret ZZ as 743 follows: 745 K = KDF(LeadingInfo | ZZ | TrailingInfo) 747 LeadingInfo ::= Subject Distinguished Name from certificate 748 TrailingInfo ::= Issuer Distinguished Name from certificate 750 d) Compute MAC(K, text). 752 The POP verification process requires the Recipient to carry out 753 steps (a) through (d) and then simply compare the result of step (d) 754 with what it received as the signature component. If they match then 755 the following can be concluded: 757 a) The Entity possesses the private key corresponding to the public 758 key in the certification request because it needed the private key 759 to calculate the shared secret; and 761 b) Only the Recipient that the entity sent the request to could 762 actually verify the request because it would require its own 763 private key to compute the same shared secret. In the case where 764 the recipient is a Certification Authority, this protects the 765 Entity from rogue CAs. 767 6.1. ASN.1 Encoding 769 The algorithm outlined above allows for the use of an arbitrary hash 770 function in computing the temporary key and the MAC value. In this 771 specification we defined object identifiers for the SHA-1 and SHA-256 772 hash values. The ASN.1 structures associated with the static ECDH 773 POP algorithm are: 775 id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 776 id-pkix id-alg(6) 25 777 } 779 sa-ecdhPop-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= { 780 IDENTIFIER id-alg-ecdhPop-static-sha224-hmac-sha224 781 VALUE DhSigStatic 782 PARAMS ARE absent 783 PUBLIC-KEYS { pk-ec } 784 } 786 id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 787 id-pkix id-alg(6) 26 788 } 790 sa-ecdhPop-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= { 791 IDENTIFIER id-alg-ecdhPop-static-sha256-hmac-sha256 792 VALUE DhSigStatic 793 PARAMS ARE absent 794 PUBLIC-KEYS { pk-ec } 795 } 797 id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 798 id-pkix id-alg(6) 27 799 } 801 sa-ecdhPop-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= { 802 IDENTIFIER id-alg-ecdhPop-static-sha384-hmac-sha384 803 VALUE DhSigStatic 804 PARAMS ARE absent 805 PUBLIC-KEYS { pk-ec } 806 } 808 id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 809 id-pkix id-alg(6) 28 810 } 812 sa-ecdhPop-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= { 813 IDENTIFIER id-alg-ecdhPop-static-sha512-hmac-sha512 814 VALUE DhSigStatic 815 PARAMS ARE absent 816 PUBLIC-KEYS { pk-ec } 817 } 819 In the above ASN.1 the following items are defined: 821 sa-ecdhPop-static-sha224-hmac-sha224 822 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 823 information describing this signature algorithm. The structure 824 DhSigStatic represents the signature value and the parameters MUST 825 be absent. 827 id-ecdhPop-static-sha224-hmac-sha224 828 This OID identifies the Static ECDH POP algorithm that uses 829 SHA-224 as the KDF and HMAC-SHA224 as the MAC function. 831 sa-ecdhPop-static-sha256-hmac-sha256 832 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 833 information describing this signature algorithm. The structure 834 DhSigStatic represents the signature value and the parameters MUST 835 be absent. 837 id-ecdhPop-static-sha256-hmac-sha256 838 This OID identifies the Static ECDH POP algorithm that uses 839 SHA-256 as the KDF and HMAC-SHA256 as the MAC function. 841 sa-ecdhPop-static-sha384-hmac-sha384 842 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 843 information describing this signature algorithm. The structure 844 DhSigStatic represents the signature value and the parameters MUST 845 be absent. 847 id-ecdhPop-static-sha384-hmac-sha384 848 This OID identifies the Static ECDH POP algorithm that uses 849 SHA-384 as the KDF and HMAC-SHA384 as the MAC function. 851 sa-ecdhPop-static-sha512-hmac-sha512 852 An ASN.1 SIGNATURE-ALGORITHM object that associates together the 853 information describing this signature algorithm. The structure 854 DhSigStatic represents the signature value and the parameters MUST 855 be absent. 857 id-ecdhPop-static-sha512-hmac-sha512 858 This OID identifies the Static ECDH POP algorithm that uses 859 SHA-512 as the KDF and HMAC-SHA512 as the MAC function. 861 7. Security Considerations 863 None of the algorithms defined in this document are meant for use in 864 general purpose situations. These algorithms are designed and 865 purposed solely for use in doing Proof-of-Possession with PKCS#10 and 866 CRMF constructs. 868 In the static DH POP and static ECDH POP algorithms, an appropriate 869 value can be produced by either party. Thus these algorithms only 870 provide integrity and not origination service. The Discrete 871 Logarithm algorithm provides both integrity checking and origination 872 checking. 874 All the security in this system is provided by the secrecy of the 875 private keying material. If either sender or recipient private keys 876 are disclosed, all messages sent or received using that key are 877 compromised. Similarly, loss of the private key results in an 878 inability to read messages sent using that key. 880 Selection of parameters can be of paramount importance. In the 881 selection of parameters one must take into account the community/ 882 group of entities that one wishes to be able to communicate with. In 883 choosing a set of parameters one must also be sure to avoid small 884 groups. [FIPS-186] Appendixes 2 and 3 contain information on the 885 selection of parameters for DH. [RFC6090] Section 10 contains 886 information on the selection of parameter for ECC. The practices 887 outlined in these documents will lead to better selection of 888 parameters. 890 8. IANA Considerations 892 This document contains no IANA considerations. 894 9. References 896 9.1. Normative References 898 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 899 Hashing for Message Authentication", RFC 2104, February 900 1997. 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, March 1997. 905 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 906 2631, June 1999. 908 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 909 Request Syntax Specification Version 1.7", RFC 2986, 910 November 2000. 912 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC- 913 SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 914 RFC 4231, December 2005. 916 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 917 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 919 9.2. Informative References 921 [CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure 922 Certificate Request Message Format (CRMF)", RFC 4211, 923 September 2005. 925 [FIPS-186] 926 , "Digital Signature Standard", Federal Information 927 Processing Standards Publication 186, May 1994. 929 [RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- 930 of-Possession Algorithms", RFC 2875, July 2000. 932 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 933 Identifiers for the Internet X.509 Public Key 934 Infrastructure Certificate and Certificate Revocation List 935 (CRL) Profile", RFC 3279, April 2002. 937 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 938 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 939 June 2010. 941 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 942 Curve Cryptography Algorithms", RFC 6090, February 2011. 944 Appendix A. ASN.1 Modules 945 A.1. 2008 ASN.1 Module 947 This appendix contains an ASN.1 module which is conformant with the 948 2008 version of ASN.1. This module references the object classes 949 defined by [RFC5912] to more completely describe all of the 950 associations between the elements defined in this document. Where a 951 difference exists between the module in this section and the 1988 952 module, the 2008 module is the definitive module. 954 DH-Sign 955 { iso(1) identified-organization(3) dod(6) internet(1) 956 security(5) mechanisms(5) pkix(7) id-mod(0) 957 id-mod-dhSign-2012-08(80) } 958 DEFINITIONS IMPLICIT TAGS ::= 960 BEGIN 961 --EXPORTS ALL 962 -- The types and values defined in this module are exported for use 963 -- in the other ASN.1 modules. Other applications may use them 964 -- for their own purposes. 966 IMPORTS 967 SIGNATURE-ALGORITHM 968 FROM AlgorithmInformation-2009 969 { iso(1) identified-organization(3) dod(6) internet(1) 970 security(5) mechanisms(5) pkix(7) id-mod(0) 971 id-mod-algorithmInformation-02(58) } 973 IssuerAndSerialNumber, MessageDigest 974 FROM CryptographicMessageSyntax-2010 975 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 976 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 978 DSA-Sig-Value, DomainParameters, ECDSA-Sig-Value, 979 mda-sha1, mda-sha224, mda-sha256, mda-sha384, mda-sha512, 980 pk-dh, pk-ec 981 FROM PKIXAlgs-2009 982 { iso(1) identified-organization(3) dod(6) internet(1) 983 security(5) mechanisms(5) pkix(7) id-mod(0) 984 id-mod-pkix1-algorithms2008-02(56) } 986 id-pkix 987 FROM PKIX1Explicit-2009 988 { iso(1) identified-organization(3) dod(6) internet(1) 989 security(5) mechanisms(5) pkix(7) id-mod(0) 990 id-mod-pkix1-explicit-02(51) }; 992 DhSigStatic ::= SEQUENCE { 993 issuerAndSerial IssuerAndSerialNumber OPTIONAL, 994 hashValue MessageDigest 995 } 997 sa-dhPop-static-sha1-hmac-sha1 SIGNATURE-ALGORITHM ::= { 998 IDENTIFIER id-dhPop-static-sha1-hmac-sha1 999 VALUE DhSigStatic 1000 PARAMS ARE absent 1001 PUBLIC-KEYS { pk-dh } 1002 } 1004 id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= { 1005 id-pkix id-alg(6) 3 1006 } 1008 id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::= 1009 id-dh-sig-hmac-sha1 1011 sa-dhPop-static-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= { 1012 IDENTIFIER id-alg-dhPop-static-sha224-hmac-sha224 1013 VALUE DhSigStatic 1014 PARAMS ARE absent 1015 PUBLIC-KEYS { pk-dh } 1016 } 1018 id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 1019 id-pkix id-alg(6) 15 1020 } 1022 sa-dhPop-static-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= { 1023 IDENTIFIER id-alg-dhPop-static-sha256-hmac-sha256 1024 VALUE DhSigStatic 1025 PARAMS ARE absent 1026 PUBLIC-KEYS { pk-dh } 1027 } 1029 id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 1030 id-pkix id-alg(6) 16 1031 } 1033 sa-dhPop-static-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= { 1034 IDENTIFIER id-alg-dhPop-static-sha384-hmac-sha384 1035 VALUE DhSigStatic 1036 PARAMS ARE absent 1037 PUBLIC-KEYS { pk-dh } 1038 } 1040 id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 1041 id-pkix id-alg(6) 17 1042 } 1044 sa-dhPop-static-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= { 1045 IDENTIFIER id-alg-dhPop-static-sha512-hmac-sha512 1046 VALUE DhSigStatic 1047 PARAMS ARE absent 1048 PUBLIC-KEYS { pk-dh } 1049 } 1051 id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 1052 id-pkix id-alg(6) 18 1053 } 1055 sa-dhPop-SHA1 SIGNATURE-ALGORITHM ::= { 1056 IDENTIFIER id-alg-dh-pop 1057 VALUE DSA-Sig-Value 1058 PARAMS TYPE DomainParameters ARE preferredAbsent 1059 HASHES { mda-sha1 } 1060 PUBLIC-KEYS { pk-dh } 1061 } 1063 id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop 1065 id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 } 1067 sa-dhPop-sha224 SIGNATURE-ALGORITHM ::= { 1068 IDENTIFIER id-alg-dhPop-sha224 1069 VALUE DSA-Sig-Value 1070 PARAMS TYPE DomainParameters ARE preferredAbsent 1071 HASHES { mda-sha224 } 1072 PUBLIC-KEYS { pk-dh } 1073 } 1075 id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= { 1076 id-pkix id-alg(6) 5 1077 } 1079 sa-dhPop-sha256 SIGNATURE-ALGORITHM ::= { 1080 IDENTIFIER id-alg-dhPop-sha256 1081 VALUE DSA-Sig-Value 1082 PARAMS TYPE DomainParameters ARE preferredAbsent 1083 HASHES { mda-sha256 } 1084 PUBLIC-KEYS { pk-dh } 1085 } 1086 id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= { 1087 id-pkix id-alg(6) 6 1088 } 1090 sa-dhPop-sha384 SIGNATURE-ALGORITHM ::= { 1091 IDENTIFIER id-alg-dhPop-sha384 1092 VALUE DSA-Sig-Value 1093 PARAMS TYPE DomainParameters ARE preferredAbsent 1094 HASHES { mda-sha384 } 1095 PUBLIC-KEYS { pk-dh } 1096 } 1098 id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= { 1099 id-pkix id-alg(6) 7 1100 } 1102 sa-dhPop-sha512 SIGNATURE-ALGORITHM ::= { 1103 IDENTIFIER id-alg-dhPop-sha512 1104 VALUE DSA-Sig-Value 1105 PARAMS TYPE DomainParameters ARE preferredAbsent 1106 HASHES { mda-sha512 } 1107 PUBLIC-KEYS { pk-dh } 1108 } 1110 id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= { 1111 id-pkix id-alg(6) 8 1112 } 1114 id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 1115 id-pkix id-alg(6) 25 1116 } 1118 sa-ecdhPop-sha224-hmac-sha224 SIGNATURE-ALGORITHM ::= { 1119 IDENTIFIER id-alg-ecdhPop-static-sha224-hmac-sha224 1120 VALUE DhSigStatic 1121 PARAMS ARE absent 1122 PUBLIC-KEYS { pk-ec } 1123 } 1125 id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 1126 id-pkix id-alg(6) 26 1127 } 1129 sa-ecdhPop-sha256-hmac-sha256 SIGNATURE-ALGORITHM ::= { 1130 IDENTIFIER id-alg-ecdhPop-static-sha256-hmac-sha256 1131 VALUE DhSigStatic 1132 PARAMS ARE absent 1133 PUBLIC-KEYS { pk-ec } 1135 } 1137 id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 1138 id-pkix id-alg(6) 27 1139 } 1141 sa-ecdhPop-sha384-hmac-sha384 SIGNATURE-ALGORITHM ::= { 1142 IDENTIFIER id-alg-ecdhPop-static-sha384-hmac-sha384 1143 VALUE DhSigStatic 1144 PARAMS ARE absent 1145 PUBLIC-KEYS { pk-ec } 1146 } 1148 id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 1149 id-pkix id-alg(6) 28 1150 } 1152 sa-ecdhPop-sha512-hmac-sha512 SIGNATURE-ALGORITHM ::= { 1153 IDENTIFIER id-alg-ecdhPop-static-sha512-hmac-sha512 1154 VALUE DhSigStatic 1155 PARAMS ARE absent 1156 PUBLIC-KEYS { pk-ec } 1157 } 1159 END 1161 A.2. 1988 ASN.1 Module 1163 This appendix contains an ASN.1 module which is conformant with the 1164 1988 version of ASN.1 represents an informational version of the 1165 ASN.1 module for this document. Where a difference exists between 1166 the module in this section and the 2008 module, the 2008 module is 1167 the definitive module. 1169 DH-Sign 1170 { iso(1) identified-organization(3) dod(6) internet(1) 1171 security(5) mechanisms(5) pkix(7) id-mod(0) 1172 id-mod-dhSign-2012-88(79) } 1173 DEFINITIONS IMPLICIT TAGS ::= 1175 BEGIN 1176 --EXPORTS ALL 1177 -- The types and values defined in this module are exported for use 1178 -- in the other ASN.1 modules. Other applications may use them 1179 -- for their own purposes. 1181 IMPORTS 1182 IssuerAndSerialNumber, MessageDigest 1183 FROM CryptographicMessageSyntax2004 1184 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1185 pkcs-9(9) smime(16) modules(0) cms-2004(24) } 1187 id-pkix 1188 FROM PKIX1Explicit88 1189 { iso(1) identified-organization(3) dod(6) internet(1) 1190 security(5) mechanisms(5) pkix(7) id-mod(0) 1191 id-pkix1-explicit(18) } 1193 Dss-Sig-Value, DomainParameters 1194 FROM PKIX1Algorithms88 1195 { iso(1) identified-organization(3) dod(6) internet(1) 1196 security(5) mechanisms(5) pkix(7) id-mod(0) 1197 id-mod-pkix1-algorithms(17) }; 1199 id-dh-sig-hmac-sha1 OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 3} 1201 DhSigStatic ::= SEQUENCE { 1202 issuerAndSerial IssuerAndSerialNumber OPTIONAL, 1203 hashValue MessageDigest 1204 } 1206 id-alg-dh-pop OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 4 } 1208 id-dhPop-static-sha1-hmac-sha1 OBJECT IDENTIFIER ::= 1209 id-dh-sig-hmac-sha1 1211 id-alg-dhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 1212 id-pkix id-alg(6) 15 } 1214 id-alg-dhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 1215 id-pkix id-alg(6) 16 } 1217 id-alg-dhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 1218 id-pkix id-alg(6) 17 } 1220 id-alg-dhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 1221 id-pkix id-alg(6) 18 } 1223 id-alg-dhPop-sha1 OBJECT IDENTIFIER ::= id-alg-dh-pop 1225 id-alg-dhPop-sha224 OBJECT IDENTIFIER ::= { 1226 id-pkix id-alg(6) 5 } 1228 id-alg-dhPop-sha256 OBJECT IDENTIFIER ::= { 1229 id-pkix id-alg(6) 6 } 1231 id-alg-dhPop-sha384 OBJECT IDENTIFIER ::= { 1232 id-pkix id-alg(6) 7 } 1234 id-alg-dhPop-sha512 OBJECT IDENTIFIER ::= { 1235 id-pkix id-alg(6) 8 } 1237 id-alg-ecdhPop-static-sha224-hmac-sha224 OBJECT IDENTIFIER ::= { 1238 id-pkix id-alg(6) 25 } 1240 id-alg-ecdhPop-static-sha256-hmac-sha256 OBJECT IDENTIFIER ::= { 1241 id-pkix id-alg(6) 26 } 1243 id-alg-ecdhPop-static-sha384-hmac-sha384 OBJECT IDENTIFIER ::= { 1244 id-pkix id-alg(6) 27 } 1246 id-alg-ecdhPop-static-sha512-hmac-sha512 OBJECT IDENTIFIER ::= { 1247 id-pkix id-alg(6) 28 } 1249 END 1251 Appendix B. Example of Static DH Proof-of-Possession 1253 The following example follows the steps described earlier in section 1254 4. 1256 Step 1: Establishing common Diffie-Hellman parameters. Assume the 1257 parameters are as in the DER encoded certificate. The certificate 1258 contains a DH public key signed by a CA with a DSA signing key. 1260 0 30 939: SEQUENCE { 1261 4 30 872: SEQUENCE { 1262 8 A0 3: [0] { 1263 10 02 1: INTEGER 2 1264 : } 1265 13 02 6: INTEGER 1266 : 00 DA 39 B6 E2 CB 1267 21 30 11: SEQUENCE { 1268 23 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 1269 32 05 0: NULL 1270 : } 1271 34 30 72: SEQUENCE { 1272 36 31 11: SET { 1273 38 30 9: SEQUENCE { 1274 40 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1275 45 13 2: PrintableString 'US' 1276 : } 1277 : } 1278 49 31 17: SET { 1279 51 30 15: SEQUENCE { 1280 53 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 1281 58 13 8: PrintableString 'XETI Inc' 1282 : } 1283 : } 1284 68 31 16: SET { 1285 70 30 14: SEQUENCE { 1286 72 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 1287 11) 1288 77 13 7: PrintableString 'Testing' 1289 : } 1290 : } 1291 86 31 20: SET { 1292 88 30 18: SEQUENCE { 1293 90 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1294 95 13 11: PrintableString 'Root DSA CA' 1295 : } 1296 : } 1297 : } 1298 108 30 30: SEQUENCE { 1299 110 17 13: UTCTime '990914010557Z' 1300 125 17 13: UTCTime '991113010557Z' 1301 : } 1302 140 30 70: SEQUENCE { 1303 142 31 11: SET { 1304 144 30 9: SEQUENCE { 1305 146 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1306 151 13 2: PrintableString 'US' 1307 : } 1308 : } 1309 155 31 17: SET { 1310 157 30 15: SEQUENCE { 1311 159 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 1312 164 13 8: PrintableString 'XETI Inc' 1313 : } 1314 : } 1315 174 31 16: SET { 1316 176 30 14: SEQUENCE { 1317 178 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 1318 11) 1319 183 13 7: PrintableString 'Testing' 1320 : } 1321 : } 1322 192 31 18: SET { 1323 194 30 16: SEQUENCE { 1324 196 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1325 201 13 9: PrintableString 'DH TestCA' 1326 : } 1327 : } 1328 : } 1329 212 30 577: SEQUENCE { 1330 216 30 438: SEQUENCE { 1331 220 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1) 1332 229 30 425: SEQUENCE { 1333 233 02 129: INTEGER 1334 : 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 1335 : C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 1336 : F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 1337 : 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 1338 : 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 1339 : 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 1340 : 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 1341 : D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 1342 : 27 1343 365 02 128: INTEGER 1344 : 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90 1345 : 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4 1346 : 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57 1347 : 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6 1348 : 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE 1349 : 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1 1350 : 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48 1351 : 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD 1352 496 02 33: INTEGER 1353 : 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 1354 : B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 1355 : FB 1356 531 02 97: INTEGER 1357 : 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 1358 : B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D 1359 : AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 1360 : 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 1361 : B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 1362 : 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 1363 : 92 1364 630 30 26: SEQUENCE { 1365 632 03 21: BIT STRING 0 unused bits 1366 : 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 1367 : 09 E4 98 34 1368 655 02 1: INTEGER 55 1369 : } 1370 : } 1371 : } 1372 658 03 132: BIT STRING 0 unused bits 1373 : 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1 1374 : E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0 1375 : 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69 1376 : B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22 1377 : 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF 1378 : D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21 1379 : E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31 1380 : 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0 1381 : 8F C5 1A 1382 : } 1383 793 A3 85: [3] { 1384 795 30 83: SEQUENCE { 1385 797 30 29: SEQUENCE { 1386 799 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 1387 804 04 22: OCTET STRING 1388 : 04 14 80 DF 59 88 BF EB 17 E1 AD 5E C6 40 A3 42 1389 : E5 AC D3 B4 88 78 1390 : } 1391 828 30 34: SEQUENCE { 1392 830 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 1393 35) 1394 835 01 1: BOOLEAN TRUE 1395 838 04 24: OCTET STRING 1396 : 30 16 80 14 6A 23 37 55 B9 FD 81 EA E8 4E D3 C9 1397 : B7 09 E5 7B 06 E3 68 AA 1398 : } 1399 864 30 14: SEQUENCE { 1400 866 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 1401 871 01 1: BOOLEAN TRUE 1402 874 04 4: OCTET STRING 1403 : 03 02 03 08 1404 : } 1405 : } 1406 : } 1407 : } 1408 880 30 11: SEQUENCE { 1409 882 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 1410 891 05 0: NULL 1411 : } 1412 893 03 48: BIT STRING 0 unused bits 1413 : 30 2D 02 14 7C 6D D2 CA 1E 32 D1 30 2E 29 66 BC 1414 : 06 8B 60 C7 61 16 3B CA 02 15 00 8A 18 DD C1 83 1415 : 58 29 A2 8A 67 64 03 92 AB 02 CE 00 B5 94 6A 1416 : } 1418 Step 2. End Entity/User generates a Diffie-Hellman key-pair using 1419 the parameters from the CA certificate. 1421 EE DH public key: 1423 Y: 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8 93 74 AE 1424 FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18 FE 94 B8 1425 A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A 1426 0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A BE B2 5C 1427 DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A 1428 93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8 29 98 EC 1429 D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33 1430 62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53 EF B2 E8 1432 EE DH private key: 1434 X: 32 CC BD B4 B7 7C 44 26 BB 3C 83 42 6E 7D 1B 00 1435 86 35 09 71 07 A0 A4 76 B8 DB 5F EC 00 CE 6F C3 1437 Step 3. Compute the shared secret ZZ 1439 56 b6 01 39 42 8e 09 16 30 b0 31 4d 12 90 af 03 1440 c7 92 65 c2 9c ba 88 bb 0a d5 94 02 ed 6f 54 cb 1441 22 e5 94 b4 d6 60 72 bc f6 a5 2b 18 8d df 28 72 1442 ac e0 41 dd 3b 03 2a 12 9e 5d bd 72 a0 1e fb 6b 1443 ee c5 b2 16 59 ee 12 00 3b c8 e0 cb c5 08 8e 2d 1444 40 5f 2d 37 62 8c 4f bb 49 76 69 3c 9e fc 2c f7 1445 f9 50 c1 b9 f7 01 32 4c 96 b9 c3 56 c0 2c 1b 77 1446 3f 2f 36 e8 22 c8 2e 07 76 d0 4f 7f aa d5 c0 59 1448 Step 4. Compute K and the signature. 1450 LeadingInfo: DER encoded Subject/Requestor DN (as in the generated 1451 Certificate Signing Request) 1453 30 46 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 1454 11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49 1455 6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73 1456 74 69 6E 67 31 12 30 10 06 03 55 04 03 13 09 44 1457 48 20 54 65 73 74 43 41 1459 TrailingInfo: DER encoded Issuer/Recipient DN (from the certificate 1460 described in step 1) 1461 30 48 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 1462 11 30 0F 06 03 55 04 0A 13 08 58 45 54 49 20 49 1463 6E 63 31 10 30 0E 06 03 55 04 0B 13 07 54 65 73 1464 74 69 6E 67 31 14 30 12 06 03 55 04 03 13 0B 52 1465 6F 6F 74 20 44 53 41 20 43 41 1467 K: 1468 B1 91 D7 DB 4F C5 EF EF AC 9A C5 44 5A 6D 42 28 1469 DC 70 7B DA 1471 TBS: the "text" for computing the SHA-1 HMAC. 1473 30 82 02 98 02 01 00 30 4E 31 0B 30 09 06 03 55 1474 04 06 13 02 55 53 31 11 30 0F 06 03 55 04 0A 13 1475 08 58 45 54 49 20 49 6E 63 31 10 30 0E 06 03 55 1476 04 0B 13 07 54 65 73 74 69 6E 67 31 1A 30 18 06 1477 03 55 04 03 13 11 50 4B 49 58 20 45 78 61 6D 70 1478 6C 65 20 55 73 65 72 30 82 02 41 30 82 01 B6 06 1479 07 2A 86 48 CE 3E 02 01 30 82 01 A9 02 81 81 00 1480 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5 1481 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5 1482 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51 1483 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B 1484 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A 1485 F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32 1486 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7 1487 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27 1488 02 81 80 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 1489 53 3F 90 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 1490 0C 53 D4 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1491 1B 7F 57 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 1492 7A 48 B6 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 1493 D9 9B DE 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 1494 51 C8 F1 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 1495 15 26 48 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E 1496 DA D1 CD 02 21 00 E8 72 FA 96 F0 11 40 F5 F2 DC 1497 FD 3B 5D 78 94 B1 85 01 E5 69 37 21 F7 25 B9 BA 1498 71 4A FC 60 30 FB 02 61 00 A3 91 01 C0 A8 6E A4 1499 4D A0 56 FC 6C FE 1F A7 B0 CD 0F 94 87 0C 25 BE 1500 97 76 8D EB E5 A4 09 5D AB 83 CD 80 0B 35 67 7F 1501 0C 8E A7 31 98 32 85 39 40 9D 11 98 D8 DE B8 7F 1502 86 9B AF 8D 67 3D B6 76 B4 61 2F 21 E1 4B 0E 68 1503 FF 53 3E 87 DD D8 71 56 68 47 DC F7 20 63 4B 3C 1504 5F 78 71 83 E6 70 9E E2 92 30 1A 03 15 00 1C D5 1505 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 09 E4 1506 98 34 02 01 37 03 81 84 00 02 81 80 13 63 A1 85 1507 04 8C 46 A8 88 EB F4 5E A8 93 74 AE FD AE 9E 96 1508 27 12 65 C4 4C 07 06 3E 18 FE 94 B8 A8 79 48 BD 1509 2E 34 B6 47 CA 04 30 A1 EC 33 FD 1A 0B 2D 9E 50 1510 C9 78 0F AE 6A EC B5 6B 6A BE B2 5C DA B2 9F 78 1511 2C B9 77 E2 79 2B 25 BF 2E 0B 59 4A 93 4B F8 B3 1512 EC 81 34 AE 97 47 52 E0 A8 29 98 EC D1 B0 CA 2B 1513 6F 7A 8B DB 4E 8D A5 15 7E 7E AF 33 62 09 9E 0F 1514 11 44 8C C1 8D A2 11 9E 53 EF B2 E8 1516 Certification Request: 1518 0 30 793: SEQUENCE { 1519 4 30 664: SEQUENCE { 1520 8 02 1: INTEGER 0 1521 11 30 78: SEQUENCE { 1522 13 31 11: SET { 1523 15 30 9: SEQUENCE { 1524 17 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1525 22 13 2: PrintableString 'US' 1526 : } 1527 : } 1528 26 31 17: SET { 1529 28 30 15: SEQUENCE { 1530 30 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 1531 35 13 8: PrintableString 'XETI Inc' 1532 : } 1533 : } 1534 45 31 16: SET { 1535 47 30 14: SEQUENCE { 1536 49 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 1537 11) 1538 54 13 7: PrintableString 'Testing' 1539 : } 1540 : } 1541 63 31 26: SET { 1542 65 30 24: SEQUENCE { 1543 67 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1544 72 13 17: PrintableString 'PKIX Example User' 1545 : } 1546 : } 1547 : } 1548 91 30 577: SEQUENCE { 1549 95 30 438: SEQUENCE { 1550 99 06 7: OBJECT IDENTIFIER dhPublicKey (1 2 840 10046 2 1) 1551 108 30 425: SEQUENCE { 1552 112 02 129: INTEGER 1553 : 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 1554 : C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 1555 : F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 1556 : 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 1557 : 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 1558 : 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 1559 : 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 1560 : D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 1561 : 27 1562 244 02 128: INTEGER 1563 : 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90 1564 : 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4 1565 : 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57 1566 : 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6 1567 : 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE 1568 : 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1 1569 : 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48 1570 : 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD 1571 375 02 33: INTEGER 1572 : 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 1573 : B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 1574 : FB 1575 410 02 97: INTEGER 1576 : 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 1577 : B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D 1578 : AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 1579 : 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 1580 : B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 1581 : 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 1582 : 92 1583 509 30 26: SEQUENCE { 1584 511 03 21: BIT STRING 0 unused bits 1585 : 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E 1586 : DB 09 E4 98 34 1587 534 02 1: INTEGER 55 1588 : } 1589 : } 1590 : } 1591 537 03 132: BIT STRING 0 unused bits 1592 : 02 81 80 13 63 A1 85 04 8C 46 A8 88 EB F4 5E A8 1593 : 93 74 AE FD AE 9E 96 27 12 65 C4 4C 07 06 3E 18 1594 : FE 94 B8 A8 79 48 BD 2E 34 B6 47 CA 04 30 A1 EC 1595 : 33 FD 1A 0B 2D 9E 50 C9 78 0F AE 6A EC B5 6B 6A 1596 : BE B2 5C DA B2 9F 78 2C B9 77 E2 79 2B 25 BF 2E 1597 : 0B 59 4A 93 4B F8 B3 EC 81 34 AE 97 47 52 E0 A8 1598 : 29 98 EC D1 B0 CA 2B 6F 7A 8B DB 4E 8D A5 15 7E 1599 : 7E AF 33 62 09 9E 0F 11 44 8C C1 8D A2 11 9E 53 1600 : EF B2 E8 1601 : } 1602 : } 1603 672 30 12: SEQUENCE { 1604 674 06 8: OBJECT IDENTIFIER dh-sig-hmac-sha1 (1 3 6 1 5 5 7 6 3) 1605 684 05 0: NULL 1606 : } 1607 686 03 109: BIT STRING 0 unused bits 1608 : 30 6A 30 52 30 48 31 0B 30 09 06 03 55 04 06 13 1609 : 02 55 53 31 11 30 0F 06 03 55 04 0A 13 08 58 45 1610 : 54 49 20 49 6E 63 31 10 30 0E 06 03 55 04 0B 13 1611 : 07 54 65 73 74 69 6E 67 31 14 30 12 06 03 55 04 1612 : 03 13 0B 52 6F 6F 74 20 44 53 41 20 43 41 02 06 1613 : 00 DA 39 B6 E2 CB 04 14 2D 05 77 FE 5E 8F 65 F5 1614 : AF AD C9 5C 9B 02 C0 A8 88 29 61 63 1615 : } 1617 Signature verification requires CA's private key, the CA certificate 1618 and the generated Certification Request. 1620 CA DH private key: 1622 x: 3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7 1623 52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D 1625 Appendix C. Example of Discrete Log Signature 1627 Step 1. Generate a Diffie-Hellman Key with length of q being 256 1628 bits. 1630 p: 1631 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 C5 1632 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 F5 1633 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 51 1634 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 5B 1635 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 8A 1636 F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 32 1637 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 D7 1638 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 27 1640 q: 1641 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 B1 1642 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 FB 1644 g: 1645 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90 1646 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4 1647 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57 1648 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6 1649 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE 1650 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1 1651 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48 1652 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD 1654 j: 1655 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 B0 1656 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D AB 1657 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 40 1658 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 B4 1659 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 68 1660 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 92 1662 y: 1663 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1 E6 A7 01 1664 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0 46 79 50 1665 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69 B7 11 A1 1666 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22 4D 0A 11 1667 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF D8 59 92 1668 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21 E1 AF 7A 1669 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31 4D F2 C6 1670 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0 8F C5 1A 1672 seed: 1673 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 1674 09 E4 98 34 1676 C: 1677 00000037 1679 x: 1680 3E 5D AD FD E5 F4 6B 1B 61 5E 18 F9 0B 84 74 a7 1681 52 1E D6 92 BC 34 94 56 F3 0C BE DA 67 7A DD 7D 1683 Step 2. Form the value to be signed and hash with SHA1. The result 1684 of the hash for this example is: 1686 5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6 1687 d4 21 e5 2c 1689 Step 3. The hash value needs to be expanded since |q| = 256. This 1690 is done by hashing the hash with SHA1 and appending it to the 1691 original hash. The value after this step is: 1693 5f a2 69 b6 4b 22 91 22 6f 4c fe 68 ec 2b d1 c6 1694 d4 21 e5 2c 64 92 8b c9 5e 34 59 70 bd 62 40 ad 1695 6f 26 3b f7 1c a3 b2 cb 1697 Next the first 255 bits of this value are taken to be the resulting 1698 "hash" value. Note in this case a shift of one bit right is done 1699 since the result is to be treated as an integer: 1701 2f d1 34 db 25 91 48 91 37 a6 7f 34 76 15 e8 e3 1702 6a 10 f2 96 32 49 45 e4 af 1a 2c b8 5e b1 20 56 1704 Step 4. The signature value is computed. In this case you get the 1705 values 1707 r: 1708 A1 B5 B4 90 01 34 6B A0 31 6A 73 F5 7D F6 5C 14 1709 43 52 D2 10 BF 86 58 87 F7 BC 6E 5A 77 FF C3 4B 1711 s: 1712 59 40 45 BC 6F 0D DC FF 9D 55 40 1E C4 9E 51 3D 1713 66 EF B2 FF 06 40 9A 39 68 75 81 F7 EC 9E BE A1 1715 The encoded signature value is then: 1717 30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73 1718 F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E 1719 5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D 1720 55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68 1721 75 81 F7 EC 9E BE A1 1723 Result: 1724 30 82 02 c2 30 82 02 67 02 01 00 30 1b 31 19 30 1725 17 06 03 55 04 03 13 10 49 45 54 46 20 50 4b 49 1726 58 20 53 41 4d 50 4c 45 30 82 02 41 30 82 01 b6 1727 06 07 2a 86 48 ce 3e 02 01 30 82 01 a9 02 81 81 1728 00 94 84 e0 45 6c 7f 69 51 62 3e 56 80 7c 68 e7 1729 c5 a9 9e 9e 74 74 94 ed 90 8c 1d c4 e1 4a 14 82 1730 f5 d2 94 0c 19 e3 b9 10 bb 11 b9 e5 a5 fb 8e 21 1731 51 63 02 86 aa 06 b8 21 36 b6 7f 36 df d1 d6 68 1732 5b 79 7c 1d 5a 14 75 1f 6a 93 75 93 ce bb 97 72 1733 8a f0 0f 23 9d 47 f6 d4 b3 c7 f0 f4 e6 f6 2b c2 1734 32 e1 89 67 be 7e 06 ae f8 d0 01 6b 8b 2a f5 02 1735 d7 b6 a8 63 94 83 b0 1b 31 7d 52 1a de e5 03 85 1736 27 02 81 80 26 a6 32 2c 5a 2b d4 33 2b 5c dc 06 1737 87 53 3f 90 06 61 50 38 3e d2 b9 7d 81 1c 12 10 1738 c5 0c 53 d4 64 d1 8e 30 07 08 8c dd 3f 0a 2f 2c 1739 d6 1b 7f 57 86 d0 da bb 6e 36 2a 18 e8 d3 bc 70 1740 31 7a 48 b6 4e 18 6e dd 1f 22 06 eb 3f ea d4 41 1741 69 d9 9b de 47 95 7a 72 91 d2 09 7f 49 5c 3b 03 1742 33 51 c8 f1 39 9a ff 04 d5 6e 7e 94 3d 03 b8 f6 1743 31 15 26 48 95 a8 5c de 47 88 b4 69 3a 00 a7 86 1744 9e da d1 cd 02 21 00 e8 72 fa 96 f0 11 40 f5 f2 1745 dc fd 3b 5d 78 94 b1 85 01 e5 69 37 21 f7 25 b9 1746 ba 71 4a fc 60 30 fb 02 61 00 a3 91 01 c0 a8 6e 1747 a4 4d a0 56 fc 6c fe 1f a7 b0 cd 0f 94 87 0c 25 1748 be 97 76 8d eb e5 a4 09 5d ab 83 cd 80 0b 35 67 1749 7f 0c 8e a7 31 98 32 85 39 40 9d 11 98 d8 de b8 1750 7f 86 9b af 8d 67 3d b6 76 b4 61 2f 21 e1 4b 0e 1751 68 ff 53 3e 87 dd d8 71 56 68 47 dc f7 20 63 4b 1752 3c 5f 78 71 83 e6 70 9e e2 92 30 1a 03 15 00 1c 1753 d5 3a 0d 17 82 6d 0a 81 75 81 46 10 8e 3e db 09 1754 e4 98 34 02 01 37 03 81 84 00 02 81 80 5f cf 39 1755 ad 62 cf 49 8e d1 ce 66 e2 b1 e6 a7 01 4d 05 c2 1756 77 c8 92 52 42 a9 05 a4 db e0 46 79 50 a3 fc 99 1757 3d 3d a6 9b a9 ad bc 62 1c 69 b7 11 a1 c0 2a f1 1758 85 28 f7 68 fe d6 8f 31 56 22 4d 0a 11 6e 72 3a 1759 02 af 0e 27 aa f9 ed ce 05 ef d8 59 92 c0 18 d7 1760 69 6e bd 70 b6 21 d1 77 39 21 e1 af 7a 3a cf 20 1761 0a b4 2c 69 5f cf 79 67 20 31 4d f2 c6 ed 23 bf 1762 c4 bb 1e d1 71 40 2c 07 d6 f0 8f c5 1a a0 00 30 1763 0c 06 08 2b 06 01 05 05 07 06 04 05 00 03 47 00 1764 30 44 02 20 54 d9 43 8d 0f 9d 42 03 d6 09 aa a1 1765 9a 3c 17 09 ae bd ee b3 d1 a0 00 db 7d 8c b8 e4 1766 56 e6 57 7b 02 20 44 89 b1 04 f5 40 2b 5f e7 9c 1767 f9 a4 97 50 0d ad c3 7a a4 2b b2 2d 5d 79 fb 38 1768 8a b4 df bb 88 bc 1770 Decoded Version of result: 1772 0 30 707: SEQUENCE { 1773 4 30 615: SEQUENCE { 1774 8 02 1: INTEGER 0 1775 11 30 27: SEQUENCE { 1776 13 31 25: SET { 1777 15 30 23: SEQUENCE { 1778 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1779 22 13 16: PrintableString 'IETF PKIX SAMPLE' 1780 : } 1781 : } 1782 : } 1783 40 30 577: SEQUENCE { 1784 44 30 438: SEQUENCE { 1785 48 06 7: OBJECT IDENTIFIER dhPublicNumber (1 2 840 10046 2 1786 1) 1787 57 30 425: SEQUENCE { 1788 61 02 129: INTEGER 1789 : 00 94 84 E0 45 6C 7F 69 51 62 3E 56 80 7C 68 E7 1790 : C5 A9 9E 9E 74 74 94 ED 90 8C 1D C4 E1 4A 14 82 1791 : F5 D2 94 0C 19 E3 B9 10 BB 11 B9 E5 A5 FB 8E 21 1792 : 51 63 02 86 AA 06 B8 21 36 B6 7F 36 DF D1 D6 68 1793 : 5B 79 7C 1D 5A 14 75 1F 6A 93 75 93 CE BB 97 72 1794 : 8A F0 0F 23 9D 47 F6 D4 B3 C7 F0 F4 E6 F6 2B C2 1795 : 32 E1 89 67 BE 7E 06 AE F8 D0 01 6B 8B 2A F5 02 1796 : D7 B6 A8 63 94 83 B0 1B 31 7D 52 1A DE E5 03 85 1797 : 27 1798 193 02 128: INTEGER 1799 : 26 A6 32 2C 5A 2B D4 33 2B 5C DC 06 87 53 3F 90 1800 : 06 61 50 38 3E D2 B9 7D 81 1C 12 10 C5 0C 53 D4 1801 : 64 D1 8E 30 07 08 8C DD 3F 0A 2F 2C D6 1B 7F 57 1802 : 86 D0 DA BB 6E 36 2A 18 E8 D3 BC 70 31 7A 48 B6 1803 : 4E 18 6E DD 1F 22 06 EB 3F EA D4 41 69 D9 9B DE 1804 : 47 95 7A 72 91 D2 09 7F 49 5C 3B 03 33 51 C8 F1 1805 : 39 9A FF 04 D5 6E 7E 94 3D 03 B8 F6 31 15 26 48 1806 : 95 A8 5C DE 47 88 B4 69 3A 00 A7 86 9E DA D1 CD 1807 324 02 33: INTEGER 1808 : 00 E8 72 FA 96 F0 11 40 F5 F2 DC FD 3B 5D 78 94 1809 : B1 85 01 E5 69 37 21 F7 25 B9 BA 71 4A FC 60 30 1810 : FB 1811 359 02 97: INTEGER 1812 : 00 A3 91 01 C0 A8 6E A4 4D A0 56 FC 6C FE 1F A7 1813 : B0 CD 0F 94 87 0C 25 BE 97 76 8D EB E5 A4 09 5D 1814 : AB 83 CD 80 0B 35 67 7F 0C 8E A7 31 98 32 85 39 1815 : 40 9D 11 98 D8 DE B8 7F 86 9B AF 8D 67 3D B6 76 1816 : B4 61 2F 21 E1 4B 0E 68 FF 53 3E 87 DD D8 71 56 1817 : 68 47 DC F7 20 63 4B 3C 5F 78 71 83 E6 70 9E E2 1818 : 92 1819 458 30 26: SEQUENCE { 1820 460 03 21: BIT STRING 0 unused bits 1821 : 1C D5 3A 0D 17 82 6D 0A 81 75 81 46 10 8E 3E DB 1822 : 09 E4 98 34 1823 483 02 1: INTEGER 55 1824 : } 1825 : } 1826 : } 1827 486 03 132: BIT STRING 0 unused bits 1828 : 02 81 80 5F CF 39 AD 62 CF 49 8E D1 CE 66 E2 B1 1829 : E6 A7 01 4D 05 C2 77 C8 92 52 42 A9 05 A4 DB E0 1830 : 46 79 50 A3 FC 99 3D 3D A6 9B A9 AD BC 62 1C 69 1831 : B7 11 A1 C0 2A F1 85 28 F7 68 FE D6 8F 31 56 22 1832 : 4D 0A 11 6E 72 3A 02 AF 0E 27 AA F9 ED CE 05 EF 1833 : D8 59 92 C0 18 D7 69 6E BD 70 B6 21 D1 77 39 21 1834 : E1 AF 7A 3A CF 20 0A B4 2C 69 5F CF 79 67 20 31 1835 : 4D F2 C6 ED 23 BF C4 BB 1E D1 71 40 2C 07 D6 F0 1836 : 8F C5 1A 1837 : } 1838 621 A0 0: [0] 1839 : } 1840 623 30 12: SEQUENCE { 1841 625 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 6 4' 1842 635 05 0: NULL 1843 : } 1844 637 03 72: BIT STRING 0 unused bits 1845 : 30 45 02 21 00 A1 B5 B4 90 01 34 6B A0 31 6A 73 1846 : F5 7D F6 5C 14 43 52 D2 10 BF 86 58 87 F7 BC 6E 1847 : 5A 77 FF C3 4B 02 20 59 40 45 BC 6F 0D DC FF 9D 1848 : 55 40 1E C4 9E 51 3D 66 EF B2 FF 06 40 9A 39 68 1849 : 75 81 F7 EC 9E BE A1 1850 : } 1852 Authors' Addresses 1854 Jim Schaad 1855 Soaring Hawk Consulting 1857 Email: ietf@augustcellars.com 1859 Hemma Prafullchandra 1860 Hy-Trust