idnits 2.17.1 draft-ietf-pkix-cmc-archive-01.txt: -(425): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(426): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(676): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(678): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(786): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1078. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 17 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 558 has weird spacing: '...s being reque...' == Line 913 has weird spacing: '... -- key is en...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2005) is 7003 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: 'CMC-BASE' is mentioned on line 876, but not defined == Missing Reference: 'PROFILE' is mentioned on line 892, but not defined -- Looks like a reference, but probably isn't: '1' on line 1040 == Unused Reference: 'HMAC' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'PKCS8' is defined on line 849, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'AES-WRAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC' ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRMF' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 3851 (ref. 'MSG31') (Obsoleted by RFC 5751) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIXCERT' Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Expires: August 5, 2005 February 2005 6 CMC Extensions: Server Side Key Generation and Key Escrow 7 draft-ietf-pkix-cmc-archive-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 5, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines a set of extensions to the CMC (Certificate 43 Management over CMS) protocol that address the desire for having two 44 additional services: 1) Server side generation of keys, 2) 45 server-side escrow and subsequent recovery of key material. These 46 services are provided by the definition of additional control 47 statements within the CMC architecture. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 3 53 1.2 Defintions . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Shroud With a Public Key . . . . . . . . . . . . . . . . . 5 56 2.2 Shroud With a Shared-Secret Key . . . . . . . . . . . . . 5 57 3. Enveloping a Private Key . . . . . . . . . . . . . . . . . . . 6 58 3.1 Encrypted Private Key with Identifier . . . . . . . . . . 6 59 3.2 Multiple Encrypted Private Keys . . . . . . . . . . . . . 7 60 4. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 7 61 4.1 Server-Side Key Generation Request Attribute . . . . . . . 7 62 4.2 Server-side Key Generation Response . . . . . . . . . . . 9 63 4.3 Control Flow . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.4 Recovery of pre-generated keys . . . . . . . . . . . . . . 10 65 4.5 RA/LRA behavior modifications . . . . . . . . . . . . . . 10 66 5. Key Archival and Recovery . . . . . . . . . . . . . . . . . . 11 67 5.1 Key Archival Control Attribute . . . . . . . . . . . . . . 11 68 5.1.1 Using the Unsigned Attribute . . . . . . . . . . . . . 13 69 5.1.2 Use the CMS Sequence . . . . . . . . . . . . . . . . . 13 70 5.2 Key Recovery Request Control Attribute . . . . . . . . . . 13 71 5.2.1 Key Recovery Response Control Attribute . . . . . . . 14 72 5.3 Control Flow . . . . . . . . . . . . . . . . . . . . . . . 15 73 6. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 17 74 7. Interactions between Server side Key Gen and Archive 75 Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 10.1 Normative References . . . . . . . . . . . . . . . . . . . 18 80 10.2 Informational References . . . . . . . . . . . . . . . . . 18 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 82 A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 B. Sample Message Layouts . . . . . . . . . . . . . . . . . . . . 21 84 B.1 Server Key Generation . . . . . . . . . . . . . . . . . . 21 85 Intellectual Property and Copyright Statements . . . . . . . . 24 87 1. Overview 89 This document defines a set of extensions to [CMC] (Certificate 90 Management over CMS) that allow for 1) server side generation of key 91 material, and 2) server side key archival and subsequent retrieval of 92 the archived key material. There are some strong reasons for 93 providing each of these services. 94 o Clients can have poor key generation, and having multiple clients 95 means that this must be checked for all clients. 96 o Hardware tokens may not have key generation capabilities. 97 o End users routinely lose keys from either user error or software 98 errors. 100 The creation of private keys relies on the use of good key generation 101 algorithms. In most cases this depends on the use of a superior 102 random number generator and strong testing for such things a prime 103 numbers. The client side generation of this material can often times 104 be suspect for either for reasons of poor coding in the multiple 105 client applications, poor input (seeding material) from users and the 106 requirements that user's not spend time waiting for things to occur. 107 Moving the task of key generation to a server process allows for 108 superior key generation as hardware can be installed in servers for 109 the purpose of key generation. There is a trade off for generation 110 of signature keys on server systems. It can provide for better key 111 generation, but the ability for a server to know the signing key is 112 an issue. (Note: In the case of DSS the parameter generation could 113 be done on a server, while the private key is still generated on the 114 client's system. This allows for good parameter generation without 115 sharing the private key with the server.) 117 These extensions to the CMC protocol are designed to provide the 118 services without adding any additional round trips to the enrollment 119 process. Server-side key generation is designed so that a 120 client-side generated signature key and server-side generated 121 key-management key can be processed in a single CMC interaction. 123 Sections Section 2 and 3 describe the concepts and structures used in 124 transporting private keys between the server and client applications. 125 Section 4 describes the structure and processes for server-side key 126 generation. Section 5 describes the structure and process for doing 127 key archival and retrieval. 129 1.1 Requirements Terminology 131 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 132 in this document are to be interpreted as described in [RFC2119]. 134 1.2 Defintions 136 This section defines some of the terms that we use in this document: 137 Identification is used as a generic term for a name, generally 138 assigned by a server, used to match a request against a known 139 individual. Identification can be either authenticated (a subject 140 name in a certificate) or unauthenticated (a text string). 141 Pass Phrase is a shared secret string between two or more entities 142 that allows for a MAC to be computed. This allows for a high 143 degree of assurance that the data covered by the MAC actually came 144 from one of the entities that knows the secret. Pass phrases must 145 be treated as confidential by the holders of the secret. 146 Shrouding is used as a generic term to cover methods of masking the 147 content of an object from unauthorized viewers. The most common 148 method of shrouding used is encryption of the data. 150 2. Shrouding Algorithms 152 Both the server-side key generation and the key recovery control 153 attributes described in this document require that the client be able 154 to tell the server in advance what encryption algorithm and what key 155 value is to be used in shrouding the private keys being returned. In 156 both of these cases the encrypted data returned is returned as an 157 EnvelopedData object as defined by [CMS] and placed in the 158 cmsSequence field of a ResponseBody. 160 Each request control for which the response includes encrypted data 161 contains two fields to define type of encryption used. 163 The encCapabilities field contains the advertised capabilities of the 164 client-side entity. This field use the S/MIME Capabilities type 165 defined in section 2.5.2 of [MSG31]. The capabilities to be listed 166 are content encryption algorithms, key-wrap algorithms and key 167 derivation algorithms. 169 The shroudMethod field defines the method by which the server will do 170 the key management of the CEK value in an EnvelopedData. The 171 shroudMethod field uses the type ShroudMethod. This type is defined 172 as: 174 ShroudMethod ::= AlgorithmIdentifier 176 When a new shroud method is defined it must include (a) the source of 177 the key material, (b) the public or salting information, and (c) the 178 method of deriving a key management key using the requested data, 179 source key material and salt. This document defines two shroud 180 methods; clients and servers MUST support id-cmc-shroudWithPublicKey. 181 Clients and servers SHOULD support id-cmc-shroudWithSharedSecret. 183 2.1 Shroud With a Public Key 185 Clients can provide a public key to the server either as a bare key 186 or wrapped in a certificate. 188 id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= {id-cmc XX } 190 ShroudWithPublicKey ::= CHOICE { 191 certificate Certificate, 192 publicKey SubjectPublicKey 193 } 195 certificate provides a public key certificate containing the key to 196 be used. Servers SHOULD check that the subject and subject 197 alternative names match in some way with the entity that the 198 private key is destined for. 199 publicKey provides a bare public key that is to be used for 200 encrypting the content encryption key. When a bare public key is 201 encountered serves need to perform some type of authentication 202 before returning an encrypted private key. 204 Servers and clients MUST support use of RSA keys for key management. 205 Servers and clients MAY support use of DH keys for key management. 207 2.2 Shroud With a Shared-Secret Key 209 A shared secret value is identified to the server by the client. The 210 derived key is then used as a key encryption key in the EnvelopedData 211 recipient info structure. This shrouding method is identified by 212 id-cmc-shroudWithSharedSecret. The parameter type associated with 213 this shrouding method is ShroudWithSharedSecret. The ASN.1 for these 214 items follows: 216 id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX} 218 ShroudWithSharedSecret ::= UTF8String 220 The common identification string for the client and the server is 221 placed in the UTF8String field. In addition the client needs to 222 place both a key derivation function and a key wrap function in the 223 set of capabilities advertised by the client in the encCapabilities 224 field. The identification string is used to identify the pass phrase 225 or shared key 227 Clients and servers MUST support the PBKDF2 key derivation algorithm 228 defined in [CMS-ALGS]. 230 If shared-secret shrouding is supported, clients and servers MUST 231 support the AES key wrap algorithm as defined by [AES-WRAP]. Clients 232 and servers SHOULD support 3DES key wrap. Clients and servers MAY 233 support RC2 key-wrap. The latter two algorithms are defined in 234 [CMS-ALGS]. 236 3. Enveloping a Private Key 238 Two different methods of enveloping a private key are supported. 239 Both are defined by different content types for the EnvelopedData 240 type from [CMS]. The first is used both for sending private keys 241 from a client to a server and returning it from a server to a client. 242 The second is used for returning multiple keys from a server to a 243 client. The assumption is made that a client rarely sends multiple 244 keys to a server for escrow at the same time and thus can deal with 245 the additional overhead from having multiple EnvelopedData objects in 246 the request message. 248 The definition of how to place private keys into the PrivateKeyInfo 249 structure can be found in section X of [CRMF]. 251 [[[[QUESTION: There are three different ways of attacking this 252 problem. The group needs to discuss and agree on a common method. 253 These methods are: 254 1. Use the Multiple Encrypted Private keys defined in this document. 255 2. State that if you are returning multiple keys, then you just have 256 to deal with multiple returned EnvelopedData items. Only real 257 issue is size and this case needs to be dealt with in any event. 258 In some cases the escrow agent is merely a storage agent and 259 keeps the encrypted blob rather than decrypting and storing the 260 private key along with identification. 261 3. Extend the CRMF type to allow for multiple keys. This would 262 allow for sending multiple keys to the server in a simpler 263 manner, but still requires that option 2 of multiple items be 264 allowed. Currently no backwards compatibility issues until this 265 update of CRMF passes last call. 267 ]]]] 269 3.1 Encrypted Private Key with Identifier 271 The encrypted private key with identifier content type is defined in 272 [CRMF]. When using this type, the identifier MUST be present when 273 sending private keys from the client to the server. This allows for 274 an additional check by the server that the private keys are being 275 escrowed by the owner of the keys. If one can create this message 276 with a correct identifier in it, then one has possession of the 277 private key blob. 279 3.2 Multiple Encrypted Private Keys 281 The multiple encrypted private keys is used when multiple private 282 keys are to be from a single escrow agent for a single client. The 283 OID defined for this content type and the body are as follows: 285 id-ct-multiplePrivateKey OBJECT IDENTIFIER ::= {id-ct XX} 287 MultiplePrivateKey ::= SEQUENCE OF ExtendedPrivateKey 289 ExtendedPrivateKey ::= SEQUENCE { 290 privateKey PrivateKeyInfo, 291 certificateId RecipientIdentifier 292 } 294 4. Server-Side Key Generation 296 This section provides the control attributes necessary for doing 297 server-side generation of keys for clients. The client places the 298 request for the key generation in a request message and sends it to 299 the server. The server will generate the key pair, create a 300 certificate for the public key and return the data in a response 301 message, or the server will return a failure. 303 Clients SHOULD NOT request server-side generation of signing-only key 304 pairs. Servers SHOULD NOT grant requests for generation of key-pairs 305 and creating a signing only certificate. This is designed to reduce 306 responsibility on the server's part for possible use of the signing 307 keys. 309 4.1 Server-Side Key Generation Request Attribute 311 The client initiates a request for server-side key generation by 312 including the Server-Side Key Generation Request Attribute in the 313 control attributes section of a PKIData object. The request 314 attribute includes information about how to return the generated key 315 as well as any client suggested items for the certificate. The 316 control attribute for doing Server-side key generation has the 317 following OID and structure: 319 id-cmc-ServerKeyGenRequest OBJECT IDENTIFIER ::= {id-cmc XX} 321 ServerKeyGenRequest ::= SEQUENCE { 322 certificateRequest CertTemplate, 323 shroudMethod ShroudMethod, 324 encCapabilities SMimeCapabilties, 325 fArchiveKey BOOLEAN DEFAULT FALSE, 326 selectionCriteria OCTET STRING OPTIONAL 327 } 329 certificateRequest contains the data fields that the client suggests 330 for the certificate being requested for the server generated key 331 pair. 332 shroudMethod contains the identifier of the algorithm to be used in 333 deriving the key used to encrypt the private key. 334 encCapabilities contains the set of algorithm capabilities being 335 advertised by the client. The server uses algorithms from this 336 set in the ServerKeyGenResponse object to encrypt the private key 337 of the server generated key pair. 338 fArchiveKey is set to TRUE if the client wishes the key to be 339 archived as well as generated on the server. Servers MAY archive 340 the server-generated key even if fArchiveKey is set to FALSE. 341 Servers SHOULD NOT generate the key pair when archival is 342 requested but the server would not archive the key material. 343 selectionCriteria contains a string allowing for the selective 344 retrieval of archived keys from the server. The selectionCriteria 345 field should appear only if fArchiveKey is set to TRUE. 347 The client can request that the generated key be a specific algorithm 348 by placing data in the publicKey field of the certificateRequest 349 field. When the publicKey field is populated, the subjectPublicKey 350 MUST be a zero length bit string and the algorithmIdentifier SHOULD 351 omit the parameters field. If the client requests a specific 352 algorithm, the server MUST generate a key of that algorithm (with the 353 parameters if defined) or it MUST fail the request. Servers MUST 354 support key generation for RSA. Servers MAY support key generation 355 for Diffie-Hellman. Servers MAY support key generation for other 356 algorithms. 358 If the request contains no requested algorithm, servers SHOULD 359 generate an RSA key exchange key pair. 361 A server is not required to use all of the values suggested by the 362 client in the certificate template. Servers MUST be able to process 363 all extensions defined in [PKIXCERT]. Servers are not required to be 364 able to process other V3 X.509 extension transmitted using this 365 protocol, nor are they required to be able to process other, private 366 extensions. Servers are permitted to modify client-requested 367 extensions. Servers MUST NOT alter an extension so as to invalidate 368 the original intent of a client-requested extension. (For example 369 change key usage from key exchange to signing.) If a certificate 370 request is denied due to the inability to handle a requested 371 extension, the server MUST respond with a failInfo attribute of 372 unsupportedExt. 374 The identity proof algorithm presented in section 5.2 in [CMC] does 375 not work if there are no certificate requests present. If the 376 request contains no certificate request objects and the request is 377 not being signed by a pre-existing signing certificate, the algorithm 378 in section 5.2 should be modified to use the set of server key 379 generation requests encoded in a sequence as the data hashed. 381 4.2 Server-side Key Generation Response 383 The server creates a server-side key generation response attribute 384 for every key generation request made and successfully completed. 385 The response message has a pointer to both the originating request 386 attribute and to the body part in the current message that holds the 387 encrypted private keys. The response message also can contain a 388 pointer to the certificate issued. The key recovery response control 389 attribute has the following OID and syntax: 391 id-cmc-ServerKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX} 393 ServerKeyGenResponse ::= SEQUENCE { 394 cmsBodyPartId BodyPartID, 395 requestBodyPartId BodyPartID, 396 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 397 } 399 cmsBodyPartId identifies a TaggedContentInfo contained within the 400 enclosing PKIData. The ContentInfo object is of type 401 EnvelopedData and has a body of id-ct-encKeyWithID. The body MUST 402 contain the private key and MAY contain an identifier. 403 requestBodyPartId contains the body part identifier for the 404 server-side key generation request control attribute. This allows 405 for clients to associate the resulting key and certificate with 406 the original request. 407 issuerAndSerialNumber if present contains the identity of the 408 certificate issued to satisfy the request. The certificate is 409 placed in the certificate bag of the immediately encapsulating 410 signedData object. 412 Clients MUST NOT assume the certificates are in any order. Servers 413 SHOULD include all intermediate certificates needed to form complete 414 chains to one or more self-signed certificates, not just the newly 415 issued certificate(s). The server MAY additionally return CRLs in 416 the CRL bag. Servers MAY include the self-signed certificates. 417 Clients MUST NOT implicitly trust included self-signed certificate(s) 418 merely due to its presence in the certificate bag. In the event 419 clients receive a new self-signed certificate from the server, 420 clients SHOULD provide a mechanism to enable the user to explicitly 421 trust the certificate. 423 4.3 Control Flow 425 In the following control flow examples, �����client���å refers to the 426 entity requesting generation of a private key, and �����server���å 427 refers to the key generation facility. 428 1. The client creates a CMC message containing a server-side key 429 generation request. The required information is filled in on the 430 request. 431 2. Optionally, any client-side key generation is done (for signing 432 keys) and the certificate requests are constructed and placed in 433 the PKIData request message. 434 3. If the client possesses a signing key, or one was created in step 435 2, it is used to sign the CMC message. If no signing key exists, 436 the PKIData request body is placed in an AuthenticatedData 437 structure and a shared secret is used to authenticate the 438 message. 439 4. The request is sent to the server. 440 5. The server does the key generation for the request. 441 6. The server issues all required certificates. 442 7. The server creates a CMC response message with the following 443 attributes: 444 A. All certificates requested are placed in the certificateList 445 in the CMS SignedData object 446 B. The private key generated is encoded as a id-ct-encKeyWithID 447 ContentInfo object. 448 C. The ContentInfo object is wrapped in a CMS EnvelopedData 449 object using the shrouding information from the request. 450 D. The EnvelopedData object is placed in the cmcSequence of a 451 PKI-Responses Body. 452 E. An id-cmc-serverKeyGetnResponse control is placed in the CMS 453 SignedData object pointing to the EnvelopedData object. 454 8. The CMC response message sent to client. 456 4.4 Recovery of pre-generated keys 458 Some server-side key generation servers will need to limit the number 459 of current certified key-pairs for clients. Under these 460 circumstances a server MAY return an already existing certified 461 key-pair if the keys and certificate satisfy the server-side key 462 generation request. 464 4.5 RA/LRA behavior modifications 466 In many cases the actual processing of key archival and key 467 generation controls is done not at the Certification Authority, but 468 at a Registration agent. This section discusses the differences in 469 the protocol based on an RA doing the key generation. 471 An LRA that does the key generation operation would behave as follows 472 1. The key generation would be done in response to the request as 473 above. 474 2. A certificate request body is placed in a new CMC message along 475 with the clients CMC message. (Optionally a new CMC message 476 containing all requests plus all relevant controls could be 477 constructed.) 478 3. The new CMC message is then sent to the Certification Authority. 479 4. When the response is returned, the LRA builds a new CMC response 480 message containing the encrypted private key info and all 481 relevant certificates. 483 If the AuthenticatedData object is used to provide for protection of 484 the data between the client and the RA, two different shared secrets 485 may be needed to provide the originators identity (one for the RA and 486 one for the CA). However, one would generally work on the assumption 487 in this case that the RA/LRA would be allowed to assert that both POP 488 and identity have been proved. 490 5. Key Archival and Recovery 492 Servers MAY require key archival of encryption keys as a condition of 493 issuing a certificate for that encryption key pair. Servers MAY 494 reject all requests contained within a PKIData if any required key 495 archival message is missing for any element within the PKIData. 497 There are four objects involved in key archival and recovery 498 scenarios: 499 1. The Key Archival control attribute, 500 2. The Key Recovery Request control attribute, 501 3. The Key Recovery Response control attribute, 502 4. A ContentInfo containing private key material. 504 It is assumed that a key recovery operation will only return 505 previously archived material. (That is, if an archival operation and 506 a recovery operation happen simultaneously, the newly archived key 507 material is not returned as part of the recovery response.) 509 5.1 Key Archival Control Attribute 511 This control is used to indication that key archival is to take 512 place. The actual data to be archived an live in one of two 513 different locations. The first is in an EnvelopedData object in the 514 cmsSequence of the request message. The second is as part of the 515 id-aa-cmc-unsignedData attribute in the SignedData section of the 516 request message. The two different methods of sending the data allow 517 for different constraints to be dealt with. 519 The data is placed in the body in those cases where one is either 520 dealing only with an archive agent, or where it is of extreme 521 importance to make sure that the EnvelopedData body has not been 522 tampered with in any way. 524 The data is placed in the unsigned attribute in those cases where it 525 needs to be removed in the middle of processing by the escrow agent. 526 A common case where this occurs is when the escrow agent is inside of 527 a company (or division in the company) and the actual certificate 528 authority is outside of the company (or division). By removing the 529 data from the enrollment message, the outside authority has no chance 530 to attempt and decrypt it. 532 All systems MUST support placing the EnvelopedData object in the 533 unsigned attribute. All escrow agents SHOULD support having the 534 EnvelopedData object inside of the body. All keys are returned 535 inside of a body in either event. 537 The key archival control attribute has the following ASN.1 syntax: 539 id-cmc-keyArchival OBJECT IDENTIIFER ::= { id-cmc XX} 541 KeyArchival ::= SEQUENCE { 542 keyIdentification CHOICE { 543 reqBodyPartID BodyPartID, 544 certificateID RecipientIdentifier 545 } 546 cmsBodyPartID BodyPartID, 547 selectionCriteria OCTET STRING OPTIONAL 548 } 550 reqBodyPartID is a reference to the payload within the enclosing 551 PKIData that contains the certification request for the public key 552 component of the encryption key pair. If multiple certification 553 requests for the same public key are included in the PKIData, 554 reqBodyPartID may point to any one of them. 555 certificateID is a reference to a certificate that contains the 556 public key for the private key being escrowed. This element is 557 used if the key is being archived at a different point in time 558 than a certificate is being requested for the key. 559 cmsBodyPartID notifies the escrow agent where the EnvelopedData 560 object containing the private key is to be found. If the value is 561 non-zero is a reference to an EnvelopedData object in the 562 cmsSequence section of the same body. If the value is zero, then 563 the EnvelopedData is found in the unsignedAttributes of a 564 SignedData object. Only one id-cmc-keyArchive control can exist 565 in a body where the value is zero. (I.e. only one key can be 566 archived using this method.) 568 selectionCriteria is optional information to be associated with the 569 archived key material to facilitate key recovery of subsections of 570 the archive database. 572 The EnvelopedData object referred to MUST have an encapsulated 573 content type of id-ct-encKeyWithID. The identifier field MUST be 574 populated if the EnvelopedData object has been encrypted for any 575 entity other than the originator to decrypt. 577 Some escrow agents will archive the entire EnvelopedData without 578 examining it for correctness. In these cases the private key will be 579 shrouded to a private secret of the client only. 581 Escrowing a key with an escrow agent is one way that is permitted for 582 POP verification to be done. In this case the escrow agent would add 583 a wrapping layer with the id-cmc-lraPOPWitness control pointing to 584 the certificate request matching the archived private key. 586 5.1.1 Using the Unsigned Attribute 588 When the EnvelopedData object is placed in the unsigned attribute 589 section of a SignedData object, it is done as follows: 590 1. The EnvelopedData object is constructed. 591 2. A unsigned attribute id-aa-cmc-unsignedData is created where: 592 A. the field bodyPartPath consists of the body part id for the 593 id-cmc-archiveRequest control, 594 B. the field identifier is set to id-cmc-archive-enveloped-data, 595 C. the content is set to the EnvelopedData object. 596 3. The unsigned attribute is placed in the outermost SignedData 597 object created. If there is more than one SignerInfo block 598 (extremely unusual), then it must be the same in all SignerInfo 599 blocks. 601 Note that when the processing is done by the escrow agent, the 602 unsigned attribute will have migrated outwards gaining fields in the 603 bodyPartPath as the layers of wrapping are added. This allows for 604 the attribute to be matched to the correct request body. 606 5.1.2 Use the CMS Sequence 608 If the EnvelopedData field is to be embedded in the message, then a 609 tag is created and it is placed in the cmsSequence section of the 610 request body. 612 5.2 Key Recovery Request Control Attribute 614 The key recovery request control attribute has the following ASN.1 615 syntax: 617 id-cmc-keyRecoveryReq OBJECT IDENTIFER ::= {id-cmc XX} 619 KeyRecoveryReq ::= SEQUENCE { 620 shroudMethod ShroudMethod, 621 encCapabilities SMimeCapabilities, 622 selectionCriteria OCTET STRING OPTIONAL 623 } 625 shroudMethod structure defines the encryption method and key material 626 that MUST be used in the key recovery response to encrypt the 627 recovered private key material. 628 encCapabilities provides a set of algorithm identifiers that 629 identifies the capabilities of the client. The server MUST use 630 algorithms that are identified by this list. 631 selectionCriteria is optional information to be associated with the 632 archived key material to facilitate key recovery of subsections of 633 the archive database. If selectionCriteria is absent, all 634 archived keys associated with the enrolling identity MUST be 635 returned. [the selectionCriteria sounds rather detailed given the 636 abstract quality of the rest of this discussion. Why not just 637 present the public key(s) in question?] 639 Notice that the recovery request does not include any end-entity 640 identification. Determination of the identity comes from other 641 locations: The name in a certificate request, the name in an identity 642 proof, the name in the shrouding certificate or the name in the 643 signing certificate on the containing SignedInfo structure. Servers 644 need to establish a policy to be used by that server for identifying 645 the entity doing the request operation. 647 5.2.1 Key Recovery Response Control Attribute 649 The key recovery response control attribute has the following ASN.1 650 syntax: 652 id-cmc-keyRecoveryRsp OBJECT IDENTIFER ::= {id-cmc XX} 654 KeyRecoveryRsp ::= SEQUENCE { 655 cmsBodyPartID BodyPartID, 656 certificateID RecipientIdentifier OPTIONAL, 657 selectionCriteria OCTET STRING OPTIONAL 658 } 659 cmsBodyPartID identifies a TaggedContentInfo contained within the 660 enclosing PKIData. The object referenced is to be an 661 EnvelopedData object with an embedded content type of either 662 id-encKeyWithID or id-multipleKey. The shouding in the associated 663 recovery request is used in constructing the EnvelopedData object. 664 certificateID provides an association with the certificate and the 665 recovered key. This field is used only if a the 666 id-ct-encKeyWithID content info type is used in the associated 667 EnvelopedData object. If the id-ct-multipleKeys content info type 668 is used, then the associations are placed in that object rather 669 than here. 670 selectionCriteria is the optional information that was used to 671 retrieve a subset of the keys archived in the archive database. 672 [see corresponding comment above] 674 5.3 Control Flow 676 In the following control flow examples, �����client���å refers to the 677 entity archiving a private key or requesting recovery of a private 678 key, and �����server���å refers to the key archive facility. 680 Control flow for Key Archival is assumed to proceed as follows: 681 1. Client retrieves an encryption certificate for the archiving 682 server, so that key material to be archived may be encrypted to 683 it. 684 2. Client generates an encryption key pair. 685 3. Client submits an enrollment request for the key pair. As part 686 of the PKIData, the client includes: 687 A. A certificate request (PKCS10 or CRMF) for the key pair, 688 which includes the public key component and a message 689 identifier (either bodyPartID or certReqId), 690 B. A Key Archival control attribute, which includes two message 691 identifier references: 692 1. The identifier of the certification request in (3a), and 693 2. The identifier of the ContentInfo in (3c). 694 C. A ContentInfo containing inside it the private key material 695 corresponding to the public key contained in the request in 696 (3a) and encrypted using the public key from the certificate 697 obtained in (1). 698 4. Server receives the request, archives the key material, and 699 issues certificates as appropriate. Server responds with an 700 enrollment response containing the issued certificates. 701 5. It is assumed that whatever mechanisms are used to identify the 702 entity requesting certification also serve to identify the 703 archiving party. 705 Control flow for Key Recovery is assumed to proceed as follows: 707 1. Client sends a Full PKI Request message containing the Key 708 Recovery Request control attribute to the server. (The PKIData 709 need contain only the Key Recovery Request attribute.) 710 2. Server performs policy-based operations to determine whether the 711 recovery request is valid. 712 3. Assuming the request is indeed valid, the server sends back to 713 the client a Full PKI Response containing: 714 A. One or more Key Recovery Response control attributes. 715 B. One or more Private Key attributes containing encrypted 716 private key material as defined in section 0 above. 717 4. Client processes the response and extracts private key material 718 from the ContentInfo(s). 720 The above control flow for key recovery assumes that the client 721 possesses at least a previously-certified signature key, which is 722 used to sign the Full PKI Request message. In the event of a 723 catastrophic failure on the client resulting in loss of all client 724 keys, generation and certification of a new signature key may occur 725 simultaneously to a request for recovery of private encryption keys. 726 Control flow for recovering from catastrophic failure may proceed as 727 follows: 728 1. Client generates a new signature key pair and creates a 729 certification request for the public component of the new 730 signature key. 731 2. Client creates a Full PKI Request message containing: 732 A. The certificate request from Step 1, 733 B. A Key Recovery Request control attribute. 734 3. The Full PKI Request message is signed using the private 735 signature key generated as part of Step 1. Following Section 736 4.2, the signerInfo field of the signed message will contain a 737 NULL issuer name and a serial number corresponding to the 738 bodyPartID of the certificate request within the PKIData. Notice 739 that as it is not possible for the client to prove identity 740 within the PKI (because all certified key pairs have been lost), 741 another form of proof-of-identity is required (such as use of the 742 identification and identityProof control attributes). 743 4. Client sends the Full PKI Request to the server. 744 5. Server performs policy-based operations on the request message to 745 determine: 746 1. Whether the certification request on the new signature key 747 should be granted, and 748 2. Whether the recovery request is valid. 749 6. Assuming that both requests are valid, the server sends back to 750 the client a Full PKI Response containing: 751 1. A certificate for the signature key, corresponding to the 752 certification request generated by the client. 753 2. One or more Key Recovery Response control attributes. 755 3. One or more Private Key attributes containing private key 756 material as defined in section 3.4.8.4. 757 7. Client processes the response and extracts private key material 758 and certificates. 760 6. Additional Error Codes 762 CMC Archival servers MUST use the id-cmc-statusInfoExt for all 763 failures specific to this document. The ExtendedFailInfo section of 764 OtherInfo is used to convey the more detailed information used here. 765 For generic failures, such as bad signatures on the SignedData 766 object, the failure codes from [CMC] are used. 768 The error codes defined in this document are identified by the object 769 identifier id-cmc-errs-archive. 771 The following error codes are defined by this document: 772 the specified shroud method in the request is either unknown to or 773 unsupported by the server. 775 7. Interactions between Server side Key Gen and Archive Retrieval 777 There are no interactions between the two. If a key gen uses an 778 existing key to satisfy the key gen request, that key MUST be omitted 779 from a key recovery request in the same CMC message. It MUST be 780 included if the recovery request comes in a separate message. 782 8. Open Issues 783 What if there were no keys to be recovered in response to a 784 recovery response? 785 How about a first request of a key with no existing info. Can't 786 sign the wrapper. ��鼂ǣ Use AuthenticatedData object from CMS? 787 Open question dealing with returning multiple keys in section ?.? 789 9. Security Considerations 791 - Servers should never generate signing key material. 793 - POP and identity proofs are important. 795 - Protection of key material on user's machine, in transit and on 796 server's machine. 798 - Issues with using MACs for identification 800 - Good random number generation 802 - Returning data to the wrong people 804 10. References 806 10.1 Normative References 808 [AES-WRAP] 809 Schaad, J. and R. Housley, "Advanced Encryption Standard 810 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 812 [CMC] Schaad, J., "Certificate Management over CMS", Work In 813 Progress , February 2005. 815 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 816 RFC 3852, July 2004. 818 [CMS-ALGS] 819 Housley, R., "Cryptographic Message Syntax (CMS) 820 Algorithms", RFC 3370, August 2002. 822 [CRMF] Schaad, J., "Internet X.509 Certificate Request Message 823 Format", Work In Progress , February 2005. 825 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 826 Keyed-Hashing for Message Authentication", RFC 2104, 827 February 1997. 829 [MSG31] Ramsdell, B., "Secure/Multipurpose Internet Mail 830 Extensions(S/MIME) Version 3.1 Message Specification", 831 RFC 3851, July 2004. 833 [PKIXCERT] 834 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 835 X.509 Public Key Infrastructure Certificate and 836 Certificate Revocation List (CRL) Profile", April 2002. 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", RFC 2119, BCP 14, March 1997. 841 10.2 Informational References 843 [DH] Kaliski, B., "PKCS 3: Diffie-Hellman Key Agreement v1.4", 844 Lost 1900. 846 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", 847 PKCS #1, March 1998. 849 [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Informaiton Syntax", 850 PKCS #8, November 1993. 852 Author's Address 854 Jim Schaad 855 Soaring Hawk Consulting 856 PO Box 675 857 Gold Bar, WA 97132 858 US 860 Phone: 425-785-1031 861 Email: jimsch@exmsft.com 863 Appendix A. ASN.1 Module 865 CMC-ARCHIVE 867 DEFINITIONS IMPLICIT TAGS ::= 868 BEGIN 870 IMPORTS 871 -- PXIX CRMF FROM [CRMF] 872 CertTemplate 873 FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) 874 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)} 876 -- PKIX CMC FROM [CMC-BASE] 877 BodyPartID, id-cmc 878 FROM EnrollmentMessageSyntax { iso(1) identified-organization(3) 879 dod(4) internet(1) security(5) mechansims(5) pkix(7) 880 id-mod(0) id-mod-cmc(6)} 882 -- S/MIME CMS FROM [CMS] 883 IssuerAndSerialNumber 884 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 885 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 886 -- S/MIME Message FROM [MSG31] 887 SMimeCapabilities 888 FROM SecureMimeMessageV3dot1 {iso(1) member-body(2) us(840) 889 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 890 msg-v3dot1(21) } 892 -- PKIX Part 1 ��鼂ǣ Implicit FROM [PROFILE] 893 AlgorithmIdentifier, Attribute, Certificate, SubjectPublicKeyInfo 894 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 895 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 896 id-pkix1-implicit(18)}; 898 -- Shroud Methods are used to identify the algorithm and 899 -- structures used in shrouding data returned. 901 ShroudMethod ::= AlgorithmIdentifier 903 -- Data to be returned is encrypted and the content encryption 904 -- key is encrypted by this public key. 906 id-cmc-shroudWithPublicKey OBJECT IDENTIFIER ::= {id-cmc XX0} 907 ShroudWithPublicKey ::= CHOICE { 908 certificate Certificate, 909 publicKey SubjectPublicKeyInfo 910 } 912 -- Data to be returned is encrypted and the content encryption 913 -- key is encrypted by a key derived from the associated pass phrase 915 id-cmc-shroudWithSharedSecret OBJECT IDENTIFIER ::= {id-cmc XX1} 916 ShroudWithSharedSecret ::= UTF8String 918 -- CMS ContentInfo type for holding multiple keys 919 -- 920 -- This type allows for return of multiple private keys along 921 -- with and identifier to associate each private key with a 922 -- certificate. 924 id-ct-multiplePrivateKeys OBJECT IDENTIFIER ::= {id-ct XX} 925 MultiplePrivateKeys ::= SEQUENCE OF SinglePrivateKey 927 SinglePrivateKey ::= SEQUENCE { 928 privateKey PrivateKeyInfo, 929 certificateId RecipientIdentifier 930 } 932 -- This CMC control is used to request server side key generation 933 -- to occur. 935 id-cmc-ServerKeyGenRequest OBJECT IDENTIFIER ::= {id-cmc XX4} 936 ServerKeyGenRequest ::= SEQUENCE { 937 certificateRequest CertTemplate, 938 shroudMethod ShroudMethod, 939 encCapabilities SMimeCapabilities, 940 fArchiveKey BOOLEAN DEFAULT FALSE, 941 selectionCriteria OCTET STRING OPTIONAL 942 } 944 -- This CMC control is used to return the results of a server side 945 -- key generation operation. The actual key is placed in the 946 -- an EnvelopedData object in the cmsSequence portion of the response 948 id-cmc-ServerKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX5} 949 ServerKeyGenResponse ::= SEQUENCE { 950 cmsBodyPartId BodyPartID, 951 requestBodyPartId BodyPartID, 952 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 953 } 955 -- This CMC control is used to archive a private key with 956 -- an escrow server. 958 id-cmc-KeyArchival OBJECT IDENTIFIER ::= {id-cmc XX6} 959 KeyArchival ::= SEQUENCE { 960 keyIdentification CHOICE { 961 reqBodyPartID BodyPartID, 962 certificateID RecipientIdentifier 963 } 964 cmsBodyPartID BodyPartID, 965 selectionCriteria OCTET STRING OPTIONAL 966 } 968 id-cmc-keyRecoveryReq OBJECT IDENTIFIER ::= {id-cmc XX7} 969 KeyRecoverReq ::= SEQUENCE { 970 shroudMethod ShroudMethod, 971 encCapabilities SMimeCapabilities, 972 selectionCriteria OCTET STRING OPTIONAL 973 } 975 id-cmc-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-cmc XX8} 976 KeyRecoveryRsp ::= SEQUENCE { 977 cmsBodyPartID BodyPartID, 978 certificateId RecipientIdentifier, 979 selectionCriteria OCTET STRING OPTIONAL 980 } 982 END 984 Appendix B. Sample Message Layouts 986 This appendix contains several sample message sequences. Note that 987 these are not complete messages but trimmed down messages giving only 988 the content where needed. 990 Appendix B.1 Server Key Generation 992 In this example, both a signing-only certificate and an 993 encryption-only certificate are being requested. The client supplies 994 the key for the signing-only certificate and the server supplies the 995 key for the encryption-only certificate. 997 Message from client to server: 999 ContentInfo.contentType = id-SignedData 1000 ContentInfo.content 1001 SignedData.encapContentInfo 1002 eContentType = id-ct-PKIData 1003 eContent 1004 controlSequence 1005 {102, id-cmc-identityProof, computed value}, 1006 {103, id-cmc-senderNonce, 10001} 1007 {104, id-cmc-serverkeyGenRequest, { 1008 {subject = cn="my identity string"}, 1009 {id-cmc-shroudWithSharedSecret, identity string}, 1010 {{id-PBKDF2}, {id-aes128-wrap}, {id-aes128-CBC}}} 1011 reqSequence 1012 certRequest 1013 certReqID=201 1014 certTemplate 1015 subject = "cn=my identity string" 1016 publicKey = My Public Signing key 1017 extentions 1018 {id-ce-subjectPublicKeyIdentifer, 100001} 1019 {id-ce-keyUsage, digitalSignature} 1020 SignedData.SignerInfos 1021 SignerInfo 1022 sid.subjectKeyIdentifier = 100001 1024 Response from server to client: 1026 ContentInfo.contentType = id-SignedData 1027 ContentInfo.content 1028 SignedData.encapContentInfo 1029 eContentType = id-ct-PKIResponse 1030 eContent 1031 controlSequence 1032 {102, id-cmc-cMCStatusInfoEx, {success, {201, 104}}} 1033 {103, id-cmc-senderNonce, 10005} 1034 {104, id-cmc-recipientNonce, 10001} 1035 {105, id-cmc-serverKeyGenResponse, 201, 104, 1036 {CA issuer name, enc cert serial number}} 1037 cmsSequence 1038 {201, 1039 {id-EnvelopedData, 1040 recipientInfo[1].pwri 1041 version = 1 1042 keyDerivationAlgorithm = id-PBKDF2 1043 keyEncryptionAlgortihm = id-aes-128wrap 1044 EncryptedContentInfo 1045 contentType = id-ct-encKeyWithID 1046 contentEncryptionAlgorithm = id-aes128-cbc 1047 encryptedContent 1048 privateKey = private key structure}} 1049 certificates 1050 Newly issued signing certificate 1051 Newly issued encryption certificate 1052 Other certificates 1053 SignedData.SignerInfos 1054 Signed by CA 1056 Intellectual Property Statement 1058 The IETF takes no position regarding the validity or scope of any 1059 Intellectual Property Rights or other rights that might be claimed to 1060 pertain to the implementation or use of the technology described in 1061 this document or the extent to which any license under such rights 1062 might or might not be available; nor does it represent that it has 1063 made any independent effort to identify any such rights. Information 1064 on the procedures with respect to rights in RFC documents can be 1065 found in BCP 78 and BCP 79. 1067 Copies of IPR disclosures made to the IETF Secretariat and any 1068 assurances of licenses to be made available, or the result of an 1069 attempt made to obtain a general license or permission for the use of 1070 such proprietary rights by implementers or users of this 1071 specification can be obtained from the IETF on-line IPR repository at 1072 http://www.ietf.org/ipr. 1074 The IETF invites any interested party to bring to its attention any 1075 copyrights, patents or patent applications, or other proprietary 1076 rights that may cover technology that may be required to implement 1077 this standard. Please address the information to the IETF at 1078 ietf-ipr@ietf.org. 1080 Disclaimer of Validity 1082 This document and the information contained herein are provided on an 1083 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1084 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1085 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1086 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1087 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1088 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1090 Copyright Statement 1092 Copyright (C) The Internet Society (2005). This document is subject 1093 to the rights, licenses and restrictions contained in BCP 78, and 1094 except as set forth therein, the authors retain all their rights. 1096 Acknowledgment 1098 Funding for the RFC Editor function is currently provided by the 1099 Internet Society.