idnits 2.17.1 draft-ietf-pkix-ipki-kea-02.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. Found some kind of copyright notice around line 31 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-23) 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 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 5, 1998) is 9393 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) -- Missing reference section? 'KEA' on line 281 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Polk (NIST) 4 expires in six months August 5, 1998 6 Internet X.509 Public Key Infrastructure 8 Representation of Key Exchange Algorithm (KEA) Keys in 9 Internet X.509 Public Key Infrastructure Certificates 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Representation of Key Exchange Algorithm (KEA) Keys in 34 Internet X.509 Public Key Infrastructure Certificates 36 Table of Contents 38 Abstract .......................................................... 3 39 1. Executive Summary ............................................. 3 40 2. Requirements and Assumptions .................................. 3 41 2.1. Communication and Topology .................................. 3 42 2.2. Acceptability Criteria ...................................... 4 43 2.3. User Expectations ........................................... 4 44 2.4. Administrator Expectations .................................. 4 45 3. KEA Algorithm Support ......................................... 5 46 3.1. Subject Public Key Info ..................................... 5 47 3.1.1. Algorithm Identifier and Parameters ....................... 5 48 3.1.2. Encoding of KEA Public Keys ............................... 6 49 3.2. Key Usage Extension in KEA certificates ..................... 6 50 4. ASN.1 Modules .................................................. 7 51 4.1 1988 Syntax ................................................... 7 52 4.2 1993 Syntax ................................................... 7 53 5. References ..................................................... 8 54 6. Patent Statements .............................................. 8 55 7. Security Considerations ........................................ 8 56 8. Author Addresses ............................................... 9 57 Abstract 59 This is the third draft of a profile for specification of Key 60 Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure 61 X.509 certificates. There are only minor changes in content from the 62 second draft. Several modifications are required now that KEA has 63 been declassified. A patent statement is required, and a published 64 reference for the KEA algorithm is required. After these modifica- 65 tions, the document will be complete. Please send comments on this 66 document to the ietf-pkix@imc.org mail list. 68 1. Executive Summary 70 This specification contains guidance on the use of the Internet Pub- 71 lic Key Infrastructure certificates to convey Key Exchange Algorithm 72 (KEA) keys. This specification is an addendum to RFC xxxx, "Internet 73 X.509 Public Key Infrastructure: Certificate and CRL Profile". 74 Implementations of this specification must also conform to RFC xxxx. 75 Implementations of this specification are not required to conform to 76 other parts from that series. 78 The Key Exchange Algorithm (KEA) is a classified algorithm for 79 exchanging keys. This specification profiles the format and seman- 80 tics of fields in X.509 V3 certificates containing KEA keys. The 81 specification addresses the subjectPublicKeyInfo field and the 82 keyUsage extension. 84 2. Requirements and Assumptions 86 The goal is to augment the X.509 certificate profile presented in 87 Part 1 to facilitate the management of KEA keys for those communities 88 which use this algorithm. 90 2.1. Communication and Topology 92 This profile, as presented in Part 1 and augmented by this specifica- 93 tion, supports users without high bandwidth, real-time IP connec- 94 tivity, or high connection availablity. In addition, the profile 95 allows for the presence of firewall or other filtered communication. 97 This profile does not assume the deployment of an X.500 Directory 98 system. The profile does not prohibit the use of an X.500 Directory, 99 but other means of distributing certificates and certificate revoca- 100 tion lists (CRLs) are supported. 102 2.2. Acceptability Criteria 104 The goal of the Internet Public Key Infrastructure (PKI) is to meet 105 the needs of deterministic, automated identification, authentication, 106 access control, and authorization functions. Support for these ser- 107 vices determines the attributes contained in the certificate as well 108 as the ancillary control information in the certificate such as pol- 109 icy data and certification path constraints. 111 The goal of this document is to profile KEA certificates, specifying 112 the contants and semantics of attributes which were not fully speci- 113 fied by Part 1. If not specifically addressed by this document, the 114 contents and semantics of the fields and extensions must be as 115 described in Part 1. 117 2.3. User Expectations 119 Users of the Internet PKI are people and processes who use client 120 software and are the subjects named in certificates. These uses 121 include readers and writers of electronic mail, the clients for WWW 122 browsers, WWW servers, and the key manager for IPSEC within a router. 123 This profile recognizes the limitations of the platforms these users 124 employ and the sophistication/attentiveness of the users themselves. 125 This manifests itself in minimal user configuration responsibility 126 (e.g., root keys, rules), explicit platform usage constraints within 127 the certificate, certification path constraints which shield the user 128 from many malicious actions, and applications which sensibly automate 129 validation functions. 131 2.4. Administrator Expectations 133 As with users, the Internet PKI profile is structured to support the 134 individuals who generally operate Certification Authorities (CAs). 135 Providing administrators with unbounded choices increases the chances 136 that a subtle CA administrator mistake will result in broad comprom- 137 ise or unnecessarily limit interoperability. This profile defines 138 the object identifiers and data formats that must be supported to 139 intepret KEA public keys. 141 3. KEA Algorithm Support 143 This section describes object identifiers and data formats which may 144 be used with PKIX certicate profile to describe X.509 certificates 145 containing a KEA public key. Conforming CAs are required to use the 146 object identifiers and data formats when issuing KEA certificates. 147 Conforming applications shall recognize the object identifiers and 148 process the data formats when processing such certificates. 150 3.1. Subject Public Key Info 152 The certificate identifies the KEA algorithm, conveys optional param- 153 eters, and specifies the KEA public key in the subjectPublicKeyInfo 154 field. The subjectPublicKeyInfo field is a SEQUENCE of an algorithm 155 identifier and the subjectPublicKey field. 157 The certificate indicates the algorithm through an algorithm identif- 158 ier. This algorithm identifier consists of an object identifier 159 (OID) and optional associated parameters. Section 3.1.1 identifies 160 the preferred OID and parameters for the KEA algorithm. Conforming 161 CAs shall use the identified OID when issuing certificates containing 162 public keys for the KEA algorithm. Conforming applications supporting 163 the KEA algorithm shall, at a minimum, recognize the OID identified 164 in section 3.1.1. 166 The certificate conveys the KEA public key through the subjectPub- 167 licKey field. This subjectPublicKey field is a BIT STRING. Section 168 3.1.2 specifies the method for encoding a KEA public key as a BIT 169 STRING. Conforming CAs shall encode the KEA public key as described 170 in Section 3.1.2 when issuing certificates containing public keys for 171 the KEA algorithm. Conforming applications supporting the KEA algo- 172 rithm shall decode the subjectPublicKey as described in section 3.1.2 173 when the algorithm identifier is the one presented in 3.1.1. 175 3.1.1. Algorithm Identifier and Parameters 177 The Key Exchange Algorithm (KEA) is a classified algorithm for 178 exchanging keys. A KEA "pairwise key" may be generated between two 179 users if their KEA public keys were generated with the same KEA 180 parameters. The KEA parameters are not included in a certificate; 181 instead a "domain identifier" is supplied in the parameters field. 183 When the subjectPublicKeyInfo field contains a KEA key, the algorithm 184 identifier and parameters shall be as defined in [sdn.701r]: 186 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= 187 { 2 16 840 1 101 2 1 1 22 } 189 KEA-Parms-Id ::= OCTET STRING 191 CAs shall populate the parameters field of the AlgorithmIdentifier 192 within the subjectPublicKeyInfo field of each certificate containing 193 a KEA public key with an 80-bit parameter identifier (OCTET STRING), 194 also known as the domain identifier. The domain identifier will be 195 computed in three steps: (1) the KEA parameters are DER encoded using 196 the Dss-Parms structure; (2) a 160-bit SHA-1 hash is generated from 197 the parameters; and (3) the 160-bit hash is reduced to 80-bits by 198 performing an "exclusive or" of the 80 high order bits with the 80 199 low order bits. The resulting value is encoded such that the most 200 significant byte of the 80-bit value is the first octet in the octet 201 string. 203 The Dss-Parms is provided in [RFC xxx] and reproduced below for com- 204 pleteness. 206 Dss-Parms ::= SEQUENCE { 207 p INTEGER, 208 q INTEGER, 209 g INTEGER } 211 3.1.2. Encoding of KEA Public Keys 213 A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING 214 such that the most significant bit (MSB) of y becomes the MSB of the 215 BIT STRING value field and the least significant bit (LSB) of y 216 becomes the LSB of the BIT STRING value field. This results in the 217 following encoding: BIT STRING tag, BIT STRING length, 0 (indicating 218 that there are zero unused bits in the final octet of y), BIT STRING 219 value field including y. 221 3.2. Key Usage Extension in KEA certificates 223 The key usage extension may optionally appear in a KEA certificate. If 224 a KEA certificate includes the keyUsage extension, only the following 225 values may be asserted: 227 keyAgreement; 228 encipherOnly; and 229 decipherOnly. 231 The encipherOnly and decipherOnly values may only be asserted if the 232 keyAgreement value is also asserted. At most one of encipherOnly and 233 decipherOnly shall be asserted in keyUsage extension. 235 4. ASN.1 Modules 237 4.1 1988 Syntax 239 PKIXkea88 {iso(1) identified-organization(3) dod(6) inter- 240 net(1) security(5) mechanisms(5) pkix(7) id-mod(0) to be 241 assigned(?) } BEGIN ::= 243 -- EXPORTS ALL -- 245 -- IMPORTS NONE -- 247 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= 248 { 2 16 840 1 101 2 1 1 22 } 250 KEA-Parms-Id ::= OCTET STRING 252 END 254 4.2 1993 Syntax 256 PKIXkea93 {iso(1) identified-organization(3) dod(6) inter- 257 net(1) security(5) mechanisms(5) pkix(7) id-mod(0) to be 258 assigned(?) } 260 BEGIN ::= 262 -- EXPORTS ALL -- 264 IMPORTS ALGORITHM-ID 265 FROM PKIX1Explicit93 {iso(1) identified-organization(3) 266 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 267 id-mod(0) id-pkix1-explicit-93(3) } 269 KeaPublicKey ALGORTHM-ID ::= { OID id-keyExchangeAlgorithm 270 PARMS KEA-Parms-Id } 272 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= 273 { 2 16 840 1 101 2 1 1 22 } 275 KEA-Parms-Id ::= OCTET STRING 277 END 279 5. References 281 [KEA] "Skipjack and KEA Algorithm Specification", Version 2.0, 282 29 May 1998. available from 283 http://csrc.nist.gov/encryption/skipjack-kea.htm 285 [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0 286 1996-06-07 with "Corrections to Message Security Protocol, 287 SDN.701, Rev 4.0, 96-06-07." August 30, 1996. 289 [RFC xxxx] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 290 Public Key Infrastructure: X.509 Certificate and CRL 291 Profile", July 28, 1998. 293 6. Patent Statements 295 To be added. 297 7. Security Considerations 299 This specification is devoted to the format and encoding of KEA keys 300 in X.509 certificates. Since certificates are digitally signed, no 301 additional integrity service is necessary. Certificates need not be 302 kept secret, and unrestricted and anonymous access to certificates 303 and CRLs has no security implications. 305 However, security factors outside the scope of this specification 306 will affect the assurance provided to certificate users. This sec- 307 tion highlights critical issues that should be considered by imple- 308 mentors, administrators, and users. 310 The procedures performed by CAs and RAs to validate the binding of 311 the subject's identity of their public key greatly affect the 312 assurance that should be placed in the certificate. Relying parties 313 may wish to review the CA's certificate practice statement. 315 The protection afforded private keys is a critical factor in main- 316 taining security. Failure of users to protect their KEA private keys 317 will permit an attacker to masquerade as them, or decrypt their per- 318 sonal information. 320 The availability and freshness of revocation information will affect 321 the degree of assurance that should be placed in a certificate. 323 While certificates expire naturally, events may occur during its 324 natural lifetime which negate the binding between the subject and 325 public key. If revocation information is untimely or unavailable, 326 the assurance associated with the binding is clearly reduced. Simi- 327 larly, implementations of the Path Validation mechanism described in 328 section 6 that omit revocation checking provide less assurance than 329 those that support it. 331 The path validation algorithm specified in [RFC xxxx] depends on the 332 certain knowledge of the public keys (and other information) about 333 one or more trusted CAs. The decision to trust a CA is an important 334 decision as it ultimately determines the trust afforded a certifi- 335 cate. The authenticated distribution of trusted CA public keys (usu- 336 ally in the form of a "self-signed" certificate) is a security criti- 337 cal out of band process that is beyond the scope of this specifica- 338 tion. 340 In addition, where a key compromise or CA failure occurs for a 341 trusted CA, the user will need to modify the information provided to 342 the path validation routine. Selection of too many trusted CAs will 343 make the trusted CA information difficult to maintain. On the other 344 hand, selection of only one trusted CA may limit users to a closed 345 community of users until a global PKI emerges. 347 The quality of implementations that process certificates may also 348 affect the degree of assurance provided. The path validation algo- 349 rithm described in section 6 relies upon the integrity of the trusted 350 CA information, and especially the integrity of the public keys asso- 351 ciated with the trusted CAs. By substituting public keys for which 352 an attacker has the private key, an attacker could trick the user 353 into accepting false certificates. 355 The binding between a key and certificate subject cannot be stronger 356 than the cryptographic module implementation and algorithms used to 357 generate the signature. 359 8. Author Addresses: 361 Russell Housley 362 SPYRUS 363 PO Box 1198 364 Herndon, VA 20172 365 USA 366 housley@spyrus.com 368 Tim Polk 369 NIST 370 Building 820, Room 426 371 Gaithersburg, MD 20899 372 USA 373 wpolk@nist.gov