idnits 2.17.1 draft-schaad-dhsign-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 12: '...hat other groups MAY also distribute w...' RFC 2119 keyword, line 16: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 162: '...l IssuerAndSerialNumber OPTIONAL,...' RFC 2119 keyword, line 210: '... j INTEGER OPTIONAL, -- subgroup...' RFC 2119 keyword, line 211: '...idationParms ValidationParms OPTIONAL...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 1998) is 9297 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' ** Obsolete normative reference: RFC 2314 (Obsoleted by RFC 2986) ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT November 11, 1998 3 Expires in six months 5 Diffie-Hellman Signing Algorithm 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups MAY also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and MAY be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munari.oz.au Pacific Rim), ftp.ietf.org (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document describes a method for producing a signature from a 29 Diffie-Hellman key pair. This behavior is needed for such operations as 30 creating a signature of a PKCS #10 certification request. This document 31 describes two different flavors of the signature algorithm, one using a 32 D-H key from a CA and the other using a temporary key created by the 33 signer. 35 1. Introduction 37 PKCS #10 [RFC2314] defines a syntax for certification requests. It 38 assumes that the public key being requested for certification 39 corresponds to an algorithm that is capable of signing/encrypting. 40 Diffie-Hellman (DH) is a key agreement algorithm and as such cannot be 41 directly used for signing or encryption. 43 This document describes two new signing algorithms using the Diffie- 44 Hellman key agreement process to provide a shared secret as the basis of 45 the signature. In the first signature algorithm, the signature is 46 constructed for a specific recipient/verifier by using a public key of 47 that verifier. In the second signature algorithm, the signature is 48 constructed for arbitrary verifiers. This is done by creating an 49 appropriate D-H key pair and encoding them as part of the signature 50 value. 52 2. Terminology 53 The following definitions will be used in this document 55 DH certificate = a certificate whose SubjectPublicKey is a DH public 56 value and is signed with any signature algorithm (e.g. rsa or dsa). 58 3. DH Signature Process 60 The steps for creating a DH signature are: 62 1. An entity (E) chooses the group parameters for a DH key agreement. In 63 many cases this is done simply by selecting the group parameters from 64 a certificate for the recipient of the signature process (static DH 65 signatures) but they may be computed for other methods (ephemeral DH 66 signatures). 68 In the ephemeral DH signature scheme, a temporary DH key-pair is 69 generated using the group parameters. In the static DH signature 70 scheme, a certificate with the correct group parameters has to be 71 available. Let these common DH parameters be g and p; and let this DH 72 key-pair be known as the CA key pair (CApub and CApriv). 74 CApub = g^x mod p (where x=CApriv, the private DH value) 76 2. The entity generates a DH public/private key-pair using the 77 parameters from step 1. 79 For an entity E: 80 Epriv = DH private value = y 81 Epub = DH public value = g^y mod p 83 3. The signature computation process will then consist of: 85 a) The value to be signed is obtained. (For a RFC2314 object, the 86 value is the DER encoded certificationRequestInfo field represented 87 as an octet string.) This will be the `text' referred to in 88 [RFC2104], the data to which HMAC-SHA1 is applied. 90 b) A shared DH secret is computed, as follows, 91 shared secret = Kec = g^xy mod p 93 [This is done by the entity E as g^(y.CApub) and by the CA as 94 g^(x.Epub), where CApub is retrieved from the CA's DH certificate 95 and Epub is retrieved from the actual certification request. ] 97 c) A temporary key K is derived from the shared secret Kec as follows: 98 K = SHA1(LeadingInfo | Kec | TrailingInfo) 99 where "|" means concatenation. 101 d) Compute HMAC-SHA1 over the data `text' as per [RFC2104] as: 102 SHA1(K XOR opad, SHA1(K XOR ipad, text)) 104 where, 105 opad (outer pad) = the byte 0x36 repeated 64 times 106 and 107 ipad (inner pad) = the byte 0x5C repeated 64 times. 109 Namely, 110 (1) Append zeros to the end of K to create a 64 byte string 111 (e.g., if K is of length 16 bytes it will be appended with 112 48 zero bytes 0x00). 113 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in 114 step (1) with ipad. 115 (3) Append the data stream `text' to the 64 byte string 116 resulting from step (2). 117 (4) Apply SHA1 to the stream generated in step (3). 118 (5) XOR (bitwise exclusive-OR) the 64 byte string computed in 119 step (1) with opad. 120 (6) Append the SHA1 result from step (4) to the 64 byte string 121 resulting from step (5). 122 (7) Apply SHA1 to the stream generated in step (6) and output 123 the result. 125 Sample code is also provided in [RFC2104]. 127 e) The output of (d) is encoded as a BIT STRING (the Signature 128 value). 130 The signature verification process requires the CA to carry out steps 131 (a) through (d) and then simply compare the result of step (d) with what 132 it received as the signature component. If they match then the following 133 can be concluded: 135 1) The Entity possesses the private key corresponding to the public 136 key in the certification request because it needed the private key to 137 calculate the shared secret; and 138 2) For the static signature scheme, that only the CA, the entity 139 sent the request to could actually verify the request because the CA 140 would require its own private key to compute the same shared secret. 141 This protects from rogue CAs. 143 4. Static DH Signature 145 In the static DH Signature scheme, the public key used in the key 146 agreement process of step 2 is obtained from the entity that will be 147 verifying the signature (i.e. the recipient). In the case of a 148 certification request, the public key would normally be extracted from a 149 certificate issued to the CA with the appropriate key parameters. 151 The values used in step 3c for "LeadingInfo" and the "TrailingInfo" are: 153 LeadingInfo ::= Subject Distinguished Name from certificate 154 TrailingInfo ::= Issuer Distinguished Name from certificate 156 The ASN.1 structures associated with the static Diffie-Hellman signature 157 algorithms are: 159 id-dhSig-static-HMAC-SHA1 ::= 161 DhSigStatic ::= SEQUENCE { 162 issuerAndSerial IssuerAndSerialNumber OPTIONAL, 163 hashValue MessageDigest 164 } 166 issuerAndSerial is the issuer name and serial number of the 167 certificate from which the public key was obtained. The 168 issuerAndSerial field is omitted if the public key did not come 169 from a certificate. 171 hashValue contains the result of the SHA-1 HMAC operation in step 172 3d. 174 DhSigStatic is encoded as a BIT STRING and is the signature value (i.e. 175 encodes the above sequence instead of the raw output from 3d). 177 5. Ephemeral DH Signature 179 There are occasions when it is difficult to obtain the CA's certificate, 180 or the group parameters of the CA are inappropriate. In these cases the 181 following variation on what is presented in section 3 can be used. 183 A temporary Diffie-Hellman key pair is generated using the same group 184 parameters as the DH key pair to be used in the signing operation. The 185 private half of the key pair is encoded as part of the signature value 186 and sent in the clear to be used by the signature verifier. The public 187 half of the key pair is not transmitted, as it provides no useful 188 information to the signature verifier. After the signature has been 189 performed the temporary key pair is discarded. 191 The values used in step 3c for "LeadingInfo" and the "TrailingInfo" are: 193 LeadingInfo ::= DER encoded p 194 TrailingInfo ::= DER encoded g 196 The ASN.1 structures used for ephemeral DH signatures are: 198 id-dhSig-ephermal-HMAC-SHA1 ::= 200 DhSigEphemeral ::== SEQUENCE { 201 domainParameters DomainParams, 202 tempPrivateKey DHPrivateKey, 203 hashValue MessageDigest 204 } 206 DomainParameters ::= SEQUENCE { 207 p INTEGER, -- odd prime, p=jq +1 208 g INTEGER, -- generator, g 209 q INTEGER, -- factor of p-1 210 j INTEGER OPTIONAL, -- subgroup factor 211 validationParms ValidationParms OPTIONAL 212 } 214 ValidationParms ::= SEQUENCE { 215 seed BIT STRING, 216 pgenCounter INTEGER 217 } 219 The fields of type DomainParameters have the following meanings: 221 p identifies the prime p defining the Galois field; 223 g specifies the generator of the mutiplicative subgroup of order g; 225 q specifies the prime factor of p-1; 227 j optionally specifies the value that satisfies the equation p=jq+1 228 to support the optional verification of group parameters; 230 seed optionally specifies the bit string parameter used as the seed 231 for the system parameter generation process; and 233 pgenCounter optionally specifies the integer value output as part 234 of the of the system parameter prime generation process. 236 If either of the parameter generation components (pgencounter or 237 seed) is provided, the other must be present as well. The presence 238 of q, j, seed and pgenCounter can be used to do parameter 239 validation. The validation procedures can be found in [FIPS-186] 240 Appendix 2. 242 DHPrivateKey ::= INTEGER 244 DhSigEphermeral is DER encoded as a BIT STRING and is the signature 245 value. 247 5. Security Considerations 249 All the security in this system is provided by the secrecy of the 250 private keying material. If either sender or recipient private keys are 251 disclosed, all messages sent or received using that key are compromised. 252 Similarly, loss of the private key results in an inability to read 253 messages sent using that key. 255 Selection of parameters can be of paramount importance. In the 256 selection of parameters once must take into account the community/group 257 of entities that one wishes to be able to communicate with. In choosing 258 a set of parameters one must also be sure to avoid small groups. [FIPS- 259 186] Appendixes 2 and 3 contain information on the selection of 260 parameters. The paractices outlined in this document will lead to 261 better selection of parameters. 263 6. Open Issues 265 Need to add some text about the validations of parameters that MUST be 266 done as part of the ephemeral signature validation process. (Minimum 267 would be checks on value of 1 < x < q-2) 269 7. References 271 [FIPS-186] Federal Information Processing Standards Publication (FIPS 272 PUB) 186, "Digital Signature Standard", 1994 May 19. 274 [RFC2314] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 275 RFC 2314, October 1997 277 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, 278 "HMAC: Keyed-Hashing for Message Authentication", 279 RFC 2104, February 1997. 281 8. Author's Addresses 283 Hemma Prafullchandra 284 XETI Inc. 285 5150 El Camino Real, #A-32 286 Los Altos, CA 94022 287 (640) 694-6812 288 hemma@xeti.com 290 Jim Schaad 291 Microsoft Corporation 292 One Microsoft Way 293 Redmond, WA 98052-6399 294 (425) 936-3101 295 jimsch@microsoft.com 297 Appendix A. ASN.1 Module 299 DH-Sign DEFINITIONS IMPLICIT TAGS ::= 301 BEGIN 303 --EXPORTS ALL 304 -- The types and values defined in this module are exported for use in 305 -- the other ASN.1 modules. Other applications may use them for their 306 -- own purposes. 308 IMPORTS 309 IssuerAndSerialNumber, MessageDigest 310 FROM CryptographicMessageSyntax { iso(1) member-body(2) 311 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 312 modules(0) cms(1) } 314 id-dhSig-static-HMAC-SHA1 ::= 316 DhSigStatic ::= SEQUENCE { 317 issuerAndSerial IssuerAndSerialNumber OPTIONAL, 318 hashValue MessageDigest 319 } 321 id-dhSig-ephermal-HMAC-SHA1 ::= 323 DhSigEphemeral ::== SEQUENCE { 324 domainParameters DomainParams, 325 tempprivateKey DHPrivateKey, 326 hashValue MessageDigest 327 } 329 DomainParameters ::= SEQUENCE { 330 p INTEGER, -- odd prime, p=jq +1 331 g INTEGER, -- generator, g 332 q INTEGER, -- factor of p-1 333 j INTEGER OPTIONAL, -- subgroup factor 334 validationParms ValidationParms OPTIONAL } 336 ValidationParms ::= SEQUENCE { 337 seed BIT STRING, 338 pgenCounter INTEGER } 340 DHPrivateKey ::= INTEGER 342 END