idnits 2.17.00 (12 Aug 2021) /tmp/idnits32021/draft-turner-sodp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4092 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) == Unused Reference: 'XMLNS' is defined on line 1920, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Downref: Normative reference to an Informational RFC: RFC 5911 ** Downref: Normative reference to an Informational RFC: RFC 5912 == Outdated reference: draft-ietf-tls-ssl2-must-not has been published as RFC 6176 == Outdated reference: draft-turner-cms-symmetrickeypackage-algs has been published as RFC 6160 -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSCHEMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'TO DO' -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Turner 3 Internet-Draft IECA 4 Intended status: Standards Track March 7, 2011 5 Expires: September 6, 2011 7 Secure Object Delivery Protocol (SODP) 8 draft-turner-sodp-00.txt 10 Abstract 12 This document describes the Secure Object Delivery Protocol (SODP). 13 SODP enables clients to access secure packages produced by a Key 14 Management Systems (KMS). Client access is ideally direct and web- 15 based, but access via agents acting on behalf of clients is 16 supported. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 48 Internet-Draft SODP 2011-03-07 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. SODP Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Key Management System . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. KMS Services . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.2. Distribution Service . . . . . . . . . . . . . . . 10 62 3.1.3. Publication Service . . . . . . . . . . . . . . . . 11 63 3.1.4. Certificate Management Service . . . . . . . . . . 12 64 3.2. KMS Packages . . . . . . . . . . . . . . . . . . . . . . 13 65 4. Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.1. Registration . . . . . . . . . . . . . . . . . . . . . . 14 67 4.2. Activation and Operation . . . . . . . . . . . . . . . . 16 68 4.3. Packages . . . . . . . . . . . . . . . . . . . . . . . . 17 69 5. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 6. Electronic Serial Number . . . . . . . . . . . . . . . . . . 18 71 7. Product Availability List . . . . . . . . . . . . . . . . . . 18 72 7.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . 21 73 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 7.2.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . 23 75 7.2.2. URI Authority . . . . . . . . . . . . . . . . . . . 24 76 7.2.3. URI Path . . . . . . . . . . . . . . . . . . . . . . 24 77 7.2.4. URI Query and Fragments . . . . . . . . . . . . . . 25 78 8. SODP Transport Requirements . . . . . . . . . . . . . . . . . 26 79 8.1. KMS Requirements . . . . . . . . . . . . . . . . . . . . 26 80 8.2. Client Requirements . . . . . . . . . . . . . . . . . . . 27 81 8.3. Agent Requirements . . . . . . . . . . . . . . . . . . . 27 82 9. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 28 83 9.1. Distribution . . . . . . . . . . . . . . . . . . . . . . 28 84 9.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 29 85 9.3. Certificate Management . . . . . . . . . . . . . . . . . 30 86 10. Cryptographic Algorithm Requirements . . . . . . . . . . . . 32 87 10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32 88 10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . 33 89 10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 92 12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . 34 93 12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . 35 94 12.3. SODP Message Types . . . . . . . . . . . . . . . . . . . 36 95 12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . 38 96 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 98 Internet-Draft SODP 2011-03-07 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 102 14.2. Informative References . . . . . . . . . . . . . . . . . 40 103 Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 42 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 106 1. Introduction 108 The Secure Object Delivery Protocol (SODP) enables clients to obtain 109 secured packages from a supporting Key Management System (KMS). 110 Client access is via the HyperText Transfer Protocol (HTTP) over 111 Transport Security Layer (TLS). Clients can directly access the KMS 112 or an agent can act on the client's behalf. Clients access the KMS 113 to retrieve a Product Availability List (PAL), which provides the 114 location of their packages with a User Resource Identifier (URI), or 115 can directly retrieve the package if the client obtains the URI via 116 another method. Packages are secured using the Cryptographic Message 117 Syntax (CMS). 119 The remainder of this document will explain the SODP model, provide 120 requirements for the KMS, client, and agent, as well specify the PAL 121 format. 123 1.1 Definitions 125 Agent: An entity that performs functions on behalf of a client. 126 Asymmetric Key Package: A package that includes an asymmetric key 127 content type [RFC5959]. 129 Certificate Management Packages: A package that contains a PKI Data 130 or PKI Response content types [RFC5272][RFC5912]. 132 Clients: An entity that contains one or more End Cryptographic Unit 133 (ECU). Clients consume products generated by the Key Management 134 System (KMS). 136 Encrypted Key Package: A package that includes an encrypted key 137 content type [RFC6032]. 139 Firmware Package: A package that contains a firmware content type 140 [RFC4108][RFC5911]. 142 NOTE: [RFC4108] defines the semantics for the firmware content 143 type's fields. [RFC5911] provides the 2002 ASN.1 definitions. 145 Identity and Authentication (IA) Key/Certificate: Key/Certificate 147 Internet-Draft SODP 2011-03-07 149 used to support IA of the client, when the client communicates with 150 the KMS as well as with other end-entities. It provides the KMS or 151 other end-entities with an appropriate degree of confidence in the 152 client's identity before delivering products, services or sensitive 153 information to the client. 155 Key Exchange (KE) Key/Certificate: Key/Certificate used when the 156 client and the KMS or other end-entity must cooperatively create a 157 wrapping key to protect the delivery of products or sensitive 158 information for use by the client. It is also used to establish 159 secure sessions (e.g., TLS) from a client to the KMS. Other examples 160 include traffic encryption keys and transmission security keys. 162 Key Management System (KMS): A set of one or more components that is 163 designed to protect, manage, and distribute cryptographic products. 164 In this document, cryptographic products are referred to as packages. 166 Operator: A person who "runs" the device (e.g., network 167 administrator). 169 Package: An object that contains one or more CMS content types. At a 170 minimum, all packages are protected using the CMS [RFC5652] 171 SignedData structure. There are numerous types of packages: 172 Asymmetric, Certificate Management, Encrypted Key, Firmware, 173 Publication, and Symmetric Packages. 175 NOTE: This document does not define any packages they are all 176 defined elsewhere. Product Availability List (PAL): A PAL is an 177 XML file that furnishes information for KMS service messages that 178 are currently available and authorized for retrieval by a client 179 or agent. 181 Publication Package: A package that contains certificates and 182 Certificate Revocation Lists (CRLs). These are typically additional 183 CA certificates or CRLs not provided as part of other packages. The 184 package is a degenerate CMS SignedData, which is sometimes referred 185 to as a "certs-only" message. 187 Service Messages: KMS-produced packages are the instantiation of the 188 KMS services. This document defines three services that manifest in 189 three types of service messages: publication, distribution, and 190 certificate management. One, registration, does not manifest itself 191 in a service message. 193 Source Authority: A source authority is trusted by clients to 194 generate particular package types. Clients determine this by 195 validating the digital signature on the package back to a Trust 196 Anchor (TA). 198 Internet-Draft SODP 2011-03-07 200 Sponsor: A person that is accountable for use of the client's 201 identity. This may or may not be the entity that operates the client 202 (i.e., the operator). 204 Symmetric Key Package: A package that contains a symmetric key 205 content type [RFC6031]. 207 Trust Anchor (TA): From [RFC5934], a TA contains a public key that is 208 used to validate digital signatures. In this document, a TA 209 represents an authoritative entity via a public key and associated 210 data. The public key is used to verify digital signatures and the 211 associated data is used to constrain the types of information for 212 which the TA is authoritative. A relying party uses TAs to determine 213 if a digitally signed object is valid by verifying a digital 214 signature using the TA's public key, and by enforcing the constraints 215 expressed in the associated data for the TA. 217 1.2 Key Words 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 221 "OPTIONAL" in this document are to be interpreted as described in 222 [RFC2119]. 224 2. SODP Model 226 Figure 1 depicts the SODP model. It is comprised of three entities: 227 the key management system, one or more clients, and agents acting on 228 behalf of clients. KMS-to-client and KMS-to-agent protocol 229 interactions are in-scope; agent-to-client protocol interactions are 230 out-of-scope. KMS-to-client and KMS-to-agent interactions support 231 mutual authentication, provide integrity, and optionally provide 232 confidentiality through the use of HTTPS. Confidentiality for KMS- 233 to-client and KMS-to-agent interactions is OPTIONAL because when 234 confidentiality is needed the packages are encrypted for the client. 235 See Section 10 for requirements on cryptographic suites. 237 Internet-Draft SODP 2011-03-07 239 <===> IP-Based Protocol Profile (in scope) 240 <- -> ECU-Specified Access Protocol (out of scope) 241 ///// CMS-Protected Packages (in scope; full support) 242 \\\\\ CMS-Protected Packages (in scope; partial support; 243 requires validation of outer signature only) 244 +----------------+ 245 | | +------------+ 246 | Key | | Client A | 247 | Management | | +---+ | 248 | System |<=====>| /// |ECU| | 249 | | | /A/ | | | 250 | +-------+ /// | | /// | A | | 251 | |A's PAL| /A/ | | +---+ | 252 | +-------+ /// | +------------+ 253 | | 254 | +-------+ /// | +-------+ +------------+ 255 | |B's PAL| /B/ | | | | Client B | 256 | +-------+ /// | | | | +---+ | 257 | | | Agent |<- - ->| /// |ECU| | 258 | +-------+ /// | | | | /B/ | | | 259 | |C's PAL| /C/ | | | | /// | B | | 260 | +-------+ /// | | \\\ | | +---+ | 261 | |<=====>| \B\ | +------------+ 262 | . . | | \\\ | 263 | . . | | | +------------+ 264 | . . | | | | Client C | 265 | | | \\\ | | +---+ | 266 | +-------+ /// | | \C\ |<- - ->| /// |ECU| | 267 | |Z's PAL| /Z/ | | \\\ | | /C/ | | | 268 | +-------+ /// | | | | /// | C | | 269 | | | | | +---+ | 270 +----------------+ +-------+ +------------+ 272 Figure 1 - SODP Model 274 Clients or agents access the KMS via HTTPS to retrieve and inspect 275 their PAL. The PAL is an XML file that contains Uniform Resource 276 Identifiers (URIs) for client packages. Retrieval of packages 277 referenced in the PAL delivers KMS services to the client. 278 Alternatively, clients can retrieve packages directly from the KMS if 279 they obtain URIs from another source. KMS services are discussed in 280 Section 2.1; the PAL and URI format are discussed in Section 5. 282 While the KMS is viewed as being a single entity, operationally the 283 issuance of different packages can be assigned to different 284 authorities within the KMS. These authorities are referred to as 285 source authorities. A source authority is trusted by clients to 287 Internet-Draft SODP 2011-03-07 289 generate particular package types. Entities validate their source 290 authorities when validating the digital signature(s) in/on packages. 291 That is, when a client retrieves a package referred to in their PAL 292 the client ensures that the signatures in/on the package validate to 293 an installed trust anchor (TA). See Section 4.1 for more information 294 on clients' TAs. 296 Packages may be encrypted for the client. Packages that contain 297 cleartext (i.e., unencrypted) symmetric keys or asymmetric private 298 keys MUST be encrypted for the client to ensure that the keys are not 299 disclosed to another party. Relying on encrypted packages instead of 300 relying on HTTPS-encrypted links allows agents to further distribute 301 the packages to clients without disclosing the cleartext to the 302 agent. Encrypted packages also enable alternate distribution paths 303 such as store-and-forward, which is beyond the scope of this 304 document. Package requirements are discussed in Section 4. 306 Prior to clients accessing the KMS, clients need be registered with 307 the KMS. The process for this will vary. One possible process 308 involves sponsorship by an individual. This individual collects 309 information about the client and enters the information into the 310 KMS's database. Also during this time, the client is assigned an 311 initial identity. Once registered, the client is issued a 312 certificate, which is later used to access the KMS. Clients and 313 agents use what is referred to as IA certificates when communicating 314 with the KMS. An IA certificate provides the client's/agent's 315 identity and allows the KMS to authenticate that the entity accessing 316 the KMS is in fact the client/agent. The registration and client IA 317 certificate issuance process is described in more detail in Section 318 3.1. The format and protocol for communicating the registration data 319 and sending the initial IA certificate directly to client is out-of- 320 scope. The client authenticates itself to the KMS with this 321 certificate using HTTPS. After the IA certificate is installed, the 322 client requests a KE certificate. KE certificates allow clients to 323 perform key establishment with the KMS to decrypt/encrypt packages. 325 Some implementations may require further separation for some clients 326 who are issued another set of certificates that support client-to- 327 client interactions, which is the client's joie de vivre or the 328 client's mission. The initial certificate set is only used to 329 communicate with the KMS and the second set is only ever used to 330 communicate with other clients. In this case the first set is 331 referred to as IA(I)/KE(I) certificates for (I)nfrastructure 332 certificates and the second set is referred to as IA(M)/KE(M) 333 certificates for (M)ission certificates. Not all clients need the 334 second set of certificate, if clients only need symmetric key, then 335 only one set of certificates is issued. *(I) certificates are issued 336 to it and instead of IA(M)/KE(M) certificates issued later only 338 Internet-Draft SODP 2011-03-07 340 symmetric key packages are provided. 342 3. Key Management System 344 The SODP is the interface to the KMS that clients use to access KMS- 345 services and associated KMS-generated packages. The internal 346 components of the KMS and their interactions are out-of-scope. 347 However, if a KMS provides all of the KMS packages (see Section 3.2), 348 it will need the capability to package trust anchors (TAs), generate 349 and package symmetric keys, package firmware, generate and package 350 asymmetric keys, issue and package public key certificates, and issue 351 and package Certificate Revocation Lists (CRLs). It will also need 352 to generate and receive packages, which includes generating and 353 verifying digital signatures on packages as well as encrypting and 354 decrypting of packages. Additionally, it will need a repository to 355 store information about clients and their packages. 357 The remainder of this section is split in to two parts. The first 358 part, Section 3.1, describes the KMS services and the second part, 359 Section 3.2, describes the KMS package requirements. 361 3.1. KMS Services 363 This section addresses the four services provided by the KMS: 364 Registration, Distribution, Publication, and Certificate Management. 365 The latter three services are instantiated in packages. 367 3.1.1. Registration Service 369 The KMS only provides services to clients that are KMS-registered. 370 Registration information collected is KMS-specific. However, the 371 information collected MUST include a permanent identifier that is 372 used to identify the client throughout its lifecycle. This permanent 373 identifier is referred to as an Electronic Serial Number (ESN). See 374 Section 6 for more information on ESNs. 376 Other OPTIONAL information to collect includes: 378 o Client Manufacturer 379 o Client Name 380 o Client Type 382 The KMS could also assign a KMS user number for an internal index, 383 label, or abbreviated name for associating data elements pertaining 384 to that user. This number is not sent to the client and is only used 385 by the KMS. 387 During this step the client is also assigned an identity, which the 389 Internet-Draft SODP 2011-03-07 391 KMS stores in its database. At a minimum the identity is an 392 identifier but it can also include additional information such as a 393 client's sponsor (e.g., Alexa Morris), the client's operator (e.g., 394 Alexa Morris), and the sponsor's organizational affiliation (e.g., 395 AMS). That is, the KMS MUST assign and record an identifier to the 396 client, but recording other client-related identity data is OPTIONAL. 397 Additionally: 399 o For cases where the sponsor isn't the entity that operates the 400 client, the identity can also include an indication of the entity 401 operating the client. This allows the network group to sponsor 402 the client, but the security group to operate the client (i.e., 403 network groups say it's okay to add client to the network but 404 doesn't want to manage the clients keys). 406 o For cases where the client can be transferred from one operator 407 to another, the identity MUST include identity of the previous 408 operator. This provides a "chain-of-control" over the device for 409 its lifetime. A KMS can support a wide variety of environments: 411 o For a KMS that support non-X.509 certificate and non-X.509 CRL 412 types, the identity SHOULD include an indication of certificate 413 type. 415 NOTE: This supports cases where the client uses alternate 416 certificate formats such as Pretty Good Privacy (PGP) [RFC4880]. 417 Alternative certificate formats are supported by many security 418 protocols including Internet Key Exchange v2 (IKEv2) [RFC5996], 419 TLS [RFC5246], and CMS [RFC5652]. 421 o For a KMS that supports humans as well as clients, the identity 422 SHOULD include an indication of the type of user (e.g., 423 client/device, human, administrator). 425 The KMS MUST ensure that the client identity is KMS-unique. That is, 426 the collection of data that comprises the client identity MUST NOT 427 match another client served by the KMS. After this check passes, the 428 final step in the registration process occurs: client IA certificate 429 issuance. The KMS MUST issue a certificate [RFC5280] to the client 430 that contains the client's permanent identifier (see Section 6). 431 NOTE: 1) The process for delivering the IA certificate directly to 432 the client is out-of-scope; 2) the format and protocol for 433 communicating the registration data is out-of-scope; and 3) the 434 client need not contribute to or respond to the supplied identity 435 information. 437 Internet-Draft SODP 2011-03-07 439 3.1.2. Distribution Service 441 The KMS employs the distribution service to provide clients' access 442 to their packages. The KMS provides access to packages through the 443 use of URIs, which uniquely refers to specifically CMS-wrapped 444 packages for delivery to the target client. The KMS generates a PAL 445 that clients can use to retrieve packages. Alternatively, the client 446 can directly access the package, but this assumes the client obtained 447 the URI(s) via another mechanism, which is out-of-scope. Packages 448 include symmetric key packages as well as centrally-generated 449 asymmetric key packages. 451 NOTE: Certificates associated with client generated asymmetric 452 keys (i.e., locally-generated public-private keys) are delivered 453 via the Certificate Management Service (See Section 3.1.3). 455 Figure 2 depicts an example ladder diagram for a protocol flow. The 456 first step is to establish a mutually authenticated HTTPS connection 457 between the client/agent and KMS. The client then requests their PAL 458 from the KMS (via HTTP GET). The KMS replies with the client's PAL 459 (via HTTP GET Response). Once a client has successfully downloaded 460 their PAL, it will process it to obtain the included packages(s). 461 The processing provided will depend on the PAL entry. Section 3.2 462 details the KMS-package requirements, Section 4 details clients- 463 package requirements, and Section 5 details agent-package 464 requirements. 466 Internet-Draft SODP 2011-03-07 468 | | 469 KMS | Establish HTTPS | Client or Agent 470 | Connection | 471 |<-------------------->| 472 | | 473 | Request PAL | 474 | (HTTP GET) | 475 |<---------------------| 476 |--------------------->| 477 | Deliver PAL with URI | 478 | (HTTP GET Response) | 479 | | 480 | Request packages by | 481 | specified URI | 482 | (HTTP GET) | 483 |<---------------------| 484 |--------------------->| 485 | Deliver requested | 486 | CMS package product | 487 | (HTTP GET Response) | 488 | | 490 Figure 2 - SODP Distribution Service Message Sequence 492 A device can request (via HTTP GET) and download (via HTTP GET 493 Response) any, or all, packages and new PALs by repeating the 494 necessary sequence of steps. When the client is finished, it SHOULD 495 terminate the connection. See Section 8 for more information on 496 SODP's HTTP requirements. 498 The KMS MUST support generation of a PAL. The KMS MUST support 499 access to client packages directly and through a PAL. 501 3.1.3. Publication Service 503 The KMS Publication Service provides clients that are PKI subscribers 504 and relying parties with a means to obtain publicly-available, 505 ancillary services related to PKIs namely: Certificates, CRLs, 506 Certificate Policies (CPs), and Certificate Practice Statements 507 (CPSs) packages. The KMS MUST support distribution of CRLs but MAY 508 support distribution of CPs and CPSs. 510 NOTE: CPs and CPSs are the one exception to the Package 511 definition found in section 1.1. CPs and CPSs are not 512 encapsulated in CMS, they are URIs to the location on the KMS for 513 the CP and CPS. 515 Certificates delivered can include additional CA certificates or peer 517 Internet-Draft SODP 2011-03-07 519 client certificate(s). 521 Clients may elect to obtain the CRLs that they rely on from sources 522 other than the (e.g., a local directory). 524 CRLs are offered in the form, or forms, produced by the responsible 525 Certification Authority (CA). The form of the CRL is transparent to 526 the KMS Publication Service. CAs may choose to publish compact 527 versions of CRLs (e.g., partitioned CRLs) that are compatible with a 528 disadvantaged client within the overall subscriber population. The 529 PAL provided to a client will always contain a URI for the most 530 current version of each CRL needed to verify the packages in the form 531 used by the particular client. The KMS Publication Service will not 532 list CRLs that a client does not need or cannot use. Based on its 533 capabilities, the freshness of currently held CRLs, and the 534 circumstances, the client will determine whether it needs to download 535 each offered CRL. KMS Publication Services packages will be signed, 536 but need not be encrypted. The information in the package is already 537 signed; CAs sign the certificates and CRLs so there is no need to 538 sign a package containing them. 540 NOTE: The KMS Publication Service is not meant to be a general 541 repository for all relying parties. Access is only provided to 542 registered clients. 544 3.1.4. Certificate Management Service 546 The KMS Certificate Management Service allows a client to develop an 547 asymmetric key pair and obtain the public key certificate associated 548 with the key pair. It additionally provides certificates and CRLs 549 necessary to validate the asymmetric key pair to an installed TA. 551 The KMS Certificate Management Service supports two kinds of 552 certificate management processes: 554 o Issuance: Where a new public/private key pair is established for 555 a KE certificate. 557 o Rekey: Where an existing IA certificate is provided with new 558 keying material. 560 CA MUST generate public key certificates in accordance with 561 [RFC5280]. A Registration Authority (RA) may be used to register 562 subscribers as well as assist the CA when issuing and rekeying 563 certificates for clients. 565 Internet-Draft SODP 2011-03-07 567 3.2. KMS Packages 569 The KMS Distribution, Publication, and Certificate Management 570 services translate into KMS packages. The primary packages are key 571 packages, but they also include firmware packages necessary to use 572 the key packages, TAMP packages to validate the package's source of 573 authority, publication packages that contain additional certificates 574 and CRLs, and collections of key packages. This section lists the 575 package requirements for the KMS. 577 There are many different key packages, but at their core there are 578 three types: 580 o Symmetric key packages are defined in [RFC6031]. A symmetric key 581 package can contain one or more symmetric keys. It also can 582 contain attributes that apply to one or more keys. The KMS MUST 583 support the ct-symmetric-key-package content type encapsulated in 584 a ct-signed-data content type [RFC5652][RFC5911]. 586 o Asymmetric key packages are defined in [RFC5958]. An asymmetric 587 key package can contains one or more private asymmetric keys and 588 associated algorithm parameters. It can also contain the public 589 key and other attributes. This key package is used in 590 conjunction with the certificate management packages when the KMS 591 generates the client's key pair. The KMS MUST support the ct- 592 asymmetric-key-package content type encapsulated in a ct-signed- 593 data content type. 595 o Certificate management packages are defined in 596 [RFC5272][RFC5912]. PKI Data and PKI Response content types are 597 used to manage public key certificates [RFC5280]. The KMS MUST 598 support the ct-PKIData and ct-PKIResponse content types. The KMS 599 MUST also support encapsulating ct-PKIData in the ct-signed-data 600 content type. 602 Distribution of the symmetric and asymmetric key packages require 603 that these keys be disclosed only to the client and to not to anyone 604 else. The key packages needs to be enveloped. The encrypted key 605 package [RFC6032] supports encrypting key packages in one of three 606 ways: with key exchange algorithms (i.e., using EnvelopedData), with 607 previously distributed symmetric algorithms (i.e., using 608 EncryptedData), and with authenticated-encryption algorithms (i.e., 609 using AuthEnvelopedData). The KMS MUST support the ct-encrypted-key- 610 package content type and the EnvelopedData choice (i.e., support ct- 611 enveloped-data). The KMS MUST support encapsulating ct-encrypted- 612 key-package in a ct-signed-data content type. 614 The KMS distributes object code for implementing one or more 616 Internet-Draft SODP 2011-03-07 618 cryptographic algorithms in a cryptographic module and software to 619 implement a communications protocol with the Firmware package 620 [RFC4108][RFC5911]. The KMS MUST support the ct-firmwarePacakge 621 content type. It MUST support receipt of the ct-firmwareLoadReceipt 622 and ct-firmwareLoadError content types. The KMS MUST support 623 encapsulating the ct-firmwarePackage content type in a ct-signed-data 624 content type. 626 To support sending multiple package types to a client, the KMS can 627 use the Content Collection [RFC4073] CMS content type. To allow the 628 KMS to apply additional attributes to the package the can use the 629 Content With Attributes [RFC4073] CMS content type. The KMS SHOULD 630 support the ct-contentCollection any MAY support the ct- 631 contentWithAttributes content type. The KMS MUST support 632 encapsulating these in a ct-signed-data content type. 634 The publication package is supported by the KMS with the "certs-only" 635 package [RFC5751], which is a CMS SignedData with no content just 636 CRLs and certificates. The KMS MUST support the "certs-only" package 637 with ct-data content type with no eContent. The KMS manages TAs to 638 support validating packages with the Trust Anchor Management Protocol 639 (TAMP) [RFC5934]. TAMP supports multiple formats for the TA. The 640 KMS MUST support the Certificate choice. The KMS MUST support the 641 tamp-update content type [RFC5934]. As specified in [RFC5934], tamp- 642 update MUST be encapsulated in a ct-signed-data content type. 644 TO DO: Add TAMP to Service Identifiers. 646 The KMS MUST support validating package signatures back to a TA 647 [RFC5652][RFC5280]. 649 4. Client 651 Clients use SODP to access the KMS-services and associated KMS- 652 generated packages. This section addresses client registration, use, 653 and package requirements. 655 4.1. Registration 657 Section 3.1.1 addresses client registration. As noted there, the 658 client need not contribute to or respond to the supplied identity 659 information. After registration is completed, the client is supplied 660 with an IA certificate. Prior to using this certificate, the client 661 MUST verify that the certificate back to an installed trust anchor. 662 The number of TAs is implementation KMS-specific, but in general: 664 o If the client supports locally-generated asymmetric keys, then it 665 MUST support at least one TA. 667 Internet-Draft SODP 2011-03-07 669 o If the client support centrally-generated asymmetric keys, then 670 it MUST also support at least one TA. 672 o If the client supports symmetric keys, then it MUST support two 673 TAs: one for symmetric keys and one for the asymmetric keys 674 (i.e., the PKI Root). 676 o If the client support firmware, the it MUST support two TAs: one 677 for the firmware and one for the asymmetric keys (i.e., the PKI 678 Root). 680 More complicated scenarios are possible. For example in Figure 3, a 681 KMS and client support centrally-generated asymmetric keys. The KMS 682 supports two TAs: one for the certificate and one for the asymmetric 683 keys (a Key TA (KTA)). The KTA delegates source authority to a Key 684 Source Authority (KSA) and distribution authority to a Key 685 Distribution Authority (KDA). The KSA creates the asymmetric key 686 places it in the symmetric key content type, signs it (signed data 687 content type), includes the corresponding certificate, and encrypts 688 it (encrypted key content type). The KDA applies an additional 689 signature layer around the encrypted data. Upon receipt the client 690 validates KDA's certificate and signature to the KTA, decrypt the 691 message, the KSA's signature and certificates to the KTA, the client 692 validates their certificate to the PKI TA, and the client checks that 693 the private key corresponds to the public key. 695 Internet-Draft SODP 2011-03-07 697 +-----+ +--------+ 698 | KTA | | PKI TA | 699 +-----+ +--------+ 700 | | 701 | Signs | Signs 702 | | 703 +-------------+ V 704 | | +----+ 705 V V | CA | 706 +-----+ +-----+ +----+ 707 | KSA | | KDA | | 708 +-----+ +-----+ | Signs 709 | | | 710 | Signs & | Optionally V 711 | Encrypts | Signs +-----+ 712 | | | PKC | 713 | | +-----+ 714 | V | 715 +---|-------------+ Included In | 716 | V SignedData | Key Package | 717 | +-------------+ | | 718 | | Key Package |<--------------------+ 719 | +-------------+ | 720 +-----------------+ 721 Figure 3 - Example Authority Architecture 723 4.2. Activation and Operation 725 The activation/operation phase of the client lifecycle is where the 726 client performs its prime mission (e.g., secure Voice Over IP (VoIP), 727 cable box). 729 Activation can occur immediately following registration, when the 730 client receives an IA certificate. Activation can also occur when 731 the client resides at and is associated with its intended operator 732 (i.e., the client is registered and sponsored in the Canada but not 733 activated by the operator until it arrives where they are located in 734 Greenland). In other words, the client can be immediately actived or 735 it can occur at a later time. 737 NOTE: A client only needs to be loaded with an IA key to perform 738 KMS Services. 740 If the client needs additional certificates (e.g., for 741 confidentiality or separate mission certificates), the client or 742 agent can retrieve them via the PAL. Client retrieval of packages 743 via the PAL is OPTIONAL. Clients may elect to obtain product package 744 URI information using a different mechanism (e.g., inputs from a 746 Internet-Draft SODP 2011-03-07 748 human or agent). 750 4.3. Packages 752 Client support for packages varies depending on the type of service 753 they desire. All clients MUST support the ct-signed-data content 754 type to ensure the packages source of authority can be determined. 755 They MUST also support validating package signatures back to a TA 756 [RFC5652][RFC5280]. 758 For clients that support symmetric key packages [RFC6031], they MUST 759 support the ct-symmetric-key-package content type. Additionally, 760 clients MUST support the ct-encrypted-key-package content type and 761 the EnvelopedData choice (i.e., support ct-enveloped-data) to support 762 encrypting the cleartext symmetric key. 764 For clients that support certificate management packages with 765 locally-generated keys, they MUST support certs-only 766 [RFC5751][RFC5911], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse 767 [RFC5272][RFC5912]. 769 Retrieval of CRLs and additional certificates via the certs-only 770 package, is OPTIONAL. Clients can retrieve CRLs and additional 771 certificate via other mechanisms. Client support for the ct- 772 contentCollection and the ct-contentWithAttributes content types is 773 OPTIONAL. 775 For clients that support firmware packages [RFC4108][RFC5911], they 776 MUST support the ct-firmwarePacakge content type. Client support for 777 the ct-firmwareLoadReceipt and ct-firmwareLoadError content types is 778 OPTIONAL, as per [RFC4108]. 780 For clients that support the Trust Anchor Management Protocol (TAMP) 781 [RFC5934], they MUST support the Certificate choice of the TA format 782 and MUST support the tamp-update content type [RFC5934]. 784 TO DO: Complete the following: 786 For clients that support certificate management packages with 787 centrally-generated keys, they MUST support ct-asymmetric-key-package 788 [RFC5958], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse 789 [RFC5272][RFC5912]. 791 5. Agents 793 Agents act on behalf of the client. Agents MUST support PAL 794 processing. 796 Internet-Draft SODP 2011-03-07 798 TO DO: Fill this out. 800 6. Electronic Serial Number 802 The Electronic Serial Number (ESN) is a permanent identifier that is 803 used to identify the client throughout its lifecycle. Certificates 804 include the ESN with the Hardware Module Name from [RFC4108] in the 805 Subject Alternative Name extension [RFC5280]. The hardware module 806 name form is an hwType (an object identifier) and hwSerialNumber 807 (octet string). The combination of the object identifier and octet 808 string guarantees global uniqueness. For example, a company uses 809 their private enterprise number they received from IANA and includes 810 their serial number the octet string. The KMS, clients, and agents 811 SHOULD support ESNs at least 8 octets in length. 813 7. Product Availability List 815 The PAL provides clients with: 817 o Advertisements for available packages and transactions that can 818 be retrieved from the KMS; 820 o Advertisement for another PAL. 822 TO DO: Add definition of Notification in Section 1.1. Need to 823 explain it's an exception the PAL including packages. 825 An example PAL is provided in Figure 4. The explanation of the 826 fields is explained in the subsequent text and sections. 828 829 830 831 TBD 832 00000000000000 833 1996 834 https://www.example.com/pki/12 835 836 837 100 838 00000000000000 839 0 840 DN of subject 841 842 843 TBD 844 00000000000000 845 2390 847 Internet-Draft SODP 2011-03-07 849 https://www.example.com/distribution/100 850 851 852 1 853 00000000000000 854 0 855 https://www.example.com/distribution/12345 856 857 859 Figure 4 - Example PAL 861 TO DO: Include legal encoding for DN in Figure 4. 863 PAL processing by clients is OPTIONAL, yet RECOMMENDED. PAL 864 retrieval can be performed by a client or by an agent that is 865 assisting the device. Agents that service clients which do not 866 process PALs, MUST process the PAL on behalf of the client. The 867 agent MUST retrieve and process the PAL from the KMS as well as the 868 packages advertised within the PAL. Once delivered to the agent, the 869 agent MUST provide the package to the target client in an 870 implementation specific manner. The method of delivery of the 871 package to the target client may or may not implement a PAL type 872 distribution mechanism. 874 When a client or agent requests a PAL, the KMS dynamically assembles 875 a PAL based on the current information and packages it has for the 876 requesting client or agent. The KMS servicing the request relies on 877 the knowledge of the requesting client's ESN, in order to amass the 878 proper list of items. 880 The following identifies the items for each KMS service the KMS could 881 include in a PAL for an identified Device: 883 o Publication: Anywhere from zero (0) to a maximum of i CA 884 certificates, client certificate, and CRLs or other issuers 885 offering public publications. 887 o Certificate: Anywhere from 0 to a maximum of j candidate entries 888 (i.e., pending certificate management transactions or certificate 889 notifications) where j <= the maximum number of certificates the 890 device can have. 892 o Distribution: Anywhere from zero (0) to a maximum of q packages 893 where q is less than or equal to the total number of 894 independently-deliverable keys, and bundled packages the client 895 is designed to accept. 897 Internet-Draft SODP 2011-03-07 899 An order of precedence for PAL offerings is based on the following 900 rationale: 902 o Publication packages are the most important because they support 903 validation decisions on certificates used to sign and encrypt 904 other listed PAL items. 906 o Certificate Management packages items are next in importance, 907 since they can impact an IA certificate used by the device to 908 sign CMS content or a KE certificate to establish keys for 909 encrypting content exchanged with the client. 911 * A client engaged in a certificate management should accept and 912 process CA-provided transactions as soon as possible to avoid 913 undue delays that might lead to protocol failure. 915 o Distribution packages containing keys and other types of products 916 are last. Precedence SHOULD be given to KMS packages that the 917 client has not previously downloaded. The items listed in a PAL 918 may not identify all of the packages available for a device. 919 This can be for any of the following reasons: 921 o The KMS may temporarily withhold some outstanding PAL items to 922 simplify client processing. 924 * Certificate Management PAL entries linked to a near-real-time 925 CA device protocol (i.e., not staged through intermediary media 926 devices or store and forward communication systems that may 927 significantly delay interactions) will be limited to one-at-a- 928 time. 930 * If a CA has more than one certificate ready to begin a 931 certificate management protocol with a client, the KMS will 932 provide a notice for one at a time. Pending notices will be 933 serviced in order of the earliest date when the certificate 934 will be used. 936 * The KMS will complete a certificate management activity for one 937 certificate, before beginning the process for another. At most 938 one pending certificate management transaction will be 939 advertised in the PAL at a time. 941 o A PAL is limited to a maximum of thirty-two entries. If more 942 than thirty-two entries are available for the client, additional 943 PALs will be identified in the last entry of the PAL. The first 944 PAL in the chain is identified as the Initial PAL. 946 o Packages will be removed when their contents are superseded or at 948 Internet-Draft SODP 2011-03-07 950 the direction of a KMS Manager. 952 The remainder of this section describes the PAL format and its use of 953 URIs. 955 7.1. PAL Format 957 The PAL furnishes information for KMS messages that are currently 958 available and authorized for retrieval by a client or an agent. The 959 PAL is used to identify the following information: 961 o The KMS Package type and unique package identifier of each 962 package available. 964 o The size of each package. 966 o The last time and date the device downloaded the data, if any. 968 o The presence of KMS notifications and the ancillary data the 969 client may need to respond to that notification. 971 o The availability of another PAL listing packages that were not 972 included on the current PAL. 974 o For those package delivered out of the KMS Distribution and KMS 975 Certificate Management Services, the KMS Service message type. 977 The initially offered PAL, will contain anywhere from zero to thirty- 978 two XML-encoded PAL entries following the XML Header. The PAL's XML 979 schema can be found in Section 12. Each PAL entry is composed of the 980 following four REQUIRED subcomponents: 982 o The Type subcomponent is provided for each PAL entry. The Type 983 uniquely identifies each KMS package defined within this 984 specification that a client may retrieve from KMS with a 4-digit 985 field. The Types are defined in Section 9 and registered in 986 Section 11. 988 o The Last Download Date subcomponent is provided for each PAL 989 entry. It is a 14-character field that contains either: 991 o The date and time (expressed as Generalized Time) that the client 992 last successfully downloaded the identified package from the KMS, 993 or 995 o All zeroes characters, if: 997 * There is no indication the device has successfully loaded the 999 Internet-Draft SODP 2011-03-07 1001 identified KMS package, 1003 o The PAL entry is a notification, or 1005 o The PAL entry corresponds to a notification or pointer to a 1006 next PAL. 1008 o The Package Size subcomponent is provided for each PAL entry. If 1009 the PAL entry is for a notification, this subcomponent will be 1010 populated with a zero character. Otherwise, it indicates the 1011 size of the identified package in bytes. The maximum size of 1012 packages is 2.1 Gbytes. 1014 o The Additional Information subcomponent will be provided for each 1015 PAL entry and will either provide a Distinguished Name (DN) or a 1016 URI of where the identified KMS package can be retrieved. When 1017 the entry is a notification, the subcomponent is a DN that 1018 identifies a certificate that is the subject of the 1019 notification. 1021 When more than thirty-two PAL entries are available, an additional 1022 PAL is advertised in the thirty second PAL entry. The additional PAL 1023 will have between one and thirty-two PAL entries. 1025 The Last Download Date MUST be represented in a form that matches the 1026 dateTime production in "canonical representation" [XMLSCHEMA]. 1027 Implementations SHOULD NOT rely on time resolution finer than 1028 milliseconds and MUST NOT generate time instants that specify leap 1029 seconds. 1031 7.2. URIs 1033 A client that supports the PAL will use URIs to obtain both the KMS 1034 packages they need from the KMS, and to post device information KMS 1035 requires. Clients that support PALs and agents MUST be capable of 1036 using URIs [RFC3986]. 1038 In order to GET or POST, the client or agent needs to have a 1039 currently valid URI associated with that information. The URI can 1040 correspond to: 1042 o A PAL that provides a unique URI for each KMS package that the 1043 KMS holds for the client and URIs identifying client actions that 1044 need to be taken, or 1046 o A KMS package that the client believes is being held by the KMS. 1047 The data may contain product, a protocol-related transaction, or 1048 a collection of packages with various contents. 1050 Internet-Draft SODP 2011-03-07 1052 When a client performs an HTTP POST operation, the URI indicates the 1053 specific KMS Service that is targeted to process the information. A 1054 client SHALL be capable of requesting information by providing a URI 1055 in an HTTP GET request to a connected KMS. 1057 A client may know, or believe they know, a specific KMS package URI, 1058 because: 1060 o They discovered the URI on a PAL, 1062 o They are anticipating the next step in a protocol initiated by a 1063 prior URI submission, or 1065 o They were provided with the URI out-of-band by a human or an 1066 agent. Clients and agents MUST be capable of accepting a URI that 1067 uniquely identifies the location of a KMS Service package that is 1068 available for delivery. 1070 Clients and agents MUST be capable of accepting a URI that identifies 1071 an action that is to be taken by the client. 1073 In order to POST information, the client or agent supplies a URI that 1074 identifies associated information to the KMS. For example, the URI 1075 could correspond to a request to initiate, furnish intermediate 1076 results for, or conclude a certificate management protocol. 1078 Regardless of whether an HTTP GET or HTTP POST request is being made, 1079 URI components have consistent definitions and usage requirements. 1080 These are specified in the following subsections. Figure 5 provides 1081 a view of the URI components: 1083 scheme://Authority/Path/query|fragment 1084 | Host:Port | 1085 | | +---------+---------------+ 1086 | | | Path 1 | Path 2 (optional) 1087 | +- www.example.com | | 1088 +- https +- distribution +- unique package 1089 +- publication identifier 1090 +- certificate 1091 Figure 5 - PAL URI Components 1093 7.2.1. URI Scheme 1095 All HTTP GET and POST requests and responses MUST use "https" as the 1096 scheme [RFC2818]. All processing of scheme data will be case- 1097 insensitive as required in [RFC3986]. 1099 PALs that do not specify "https" as the URI scheme for every PAL 1101 Internet-Draft SODP 2011-03-07 1103 entry MUST be rejected. 1105 7.2.2. URI Authority 1107 The authority component of a URI identifies the KMS that the client 1108 is requesting the specific KMS Service from. The authority component 1109 is in the form of a host name and an optional "https" port number. 1110 The host name identifies the HTTP server by name, and the port number 1111 identifies the HTTP server port that will service the request. 1112 Inclusion of the port number is OPTIONAL, as port 443 MUST be used. 1114 Clients and agents that access KMS Services are configured with the 1115 applicable registered name(s) or corresponding IP address(es) of the 1116 KMS with which they may establish a connection to. 1118 When generating a URI, the KMS SHALL populate the Authority Component 1119 of the URI with the registered name of the target KMS. 1121 When generating a URI, clients and agents SHALL populate the 1122 Authority Component of the URI with the registered name of the target 1123 KMS. 1125 Clients and agents SHALL reject the delivery of a received PAL, if 1126 any URI Authority Component contains a registered name that does not 1127 correspond to the connected KMS. 1129 7.2.3. URI Path 1131 The Path component of a URI identifies a resource that can be 1132 retrieved from, or a location that information can be posted to, at 1133 the KMS. Path components are presented in the hierarchical form of 1134 KMS Service Identifier followed by a Product Identifier. They adhere 1135 to the rules for path-absolute parsing as defined in [RFC3986]. 1137 Service Identifiers that constitute the first path (aka Path 1) 1138 segment in a URI received or generated by a device are listed below 1139 together will a brief description of their purpose: 1141 o distribution - This identifier is used for PALs, product 1142 packages, and bundled packages with one or more collections of 1143 content types as offered by the KMS Distribution Service. 1145 o publication - This identifier is used to obtain publicly- 1146 available CA, CRLs, and CPs as offered by the KMS Publication 1147 Service. 1149 o certificate - This identifier is used in PKI issuance and rekey 1150 protocols as offered by the KMS Certificate Management. 1152 Internet-Draft SODP 2011-03-07 1154 The Product Identifier (aka Path 2), when present, is always the 1155 second path segment. It is formatted as an integer and represents 1156 the unique identifier the KMS has associated with the package to be 1157 retrieved. Message types are included in the Message Type registry 1158 found in Section 11. The Product Identifier is only present in the 1159 URIs that will be included in HTTP GET requests to obtain a package. 1160 The Product Identifier is not included in: 1162 o The URI a client uses to obtain the initial PAL, 1164 o The URI portion of a KMS Distribution Service PAL entry a KMS 1165 uses to point to other PALs beyond the initial PAL, 1167 o The KMS Certificate Service URIs that a KMS uses to provide 1168 the device notification for a suggested action, and 1170 o URIs that a device provides as a part of an HTTP POST request. 1172 A client SHALL reject the delivery of any PAL received that contains 1173 a URI with the first path component not equal to one of the following 1174 service names: 1176 o distribution, 1177 o pki, and 1178 o certificate. 1180 When generating a URI for the inclusion in a POST operation, a client 1181 SHALL only populate the first Path component of the URI. When 1182 generating a URI for the inclusion in a GET operation for the initial 1183 PAL, a client SHALL only populate the first Path component of the 1184 URI. When generating a URI, clients SHALL populate the first Path 1185 component of the URI with one of the service names defined by this 1186 specification. A client SHALL reject the delivery of any PAL received 1187 that contains a URI with the second path component not equal to an 1188 integer. 1190 7.2.4. URI Query and Fragments 1192 The KMS does not use Query and Fragment elements in support of KMS 1193 Services. They are not supported by clients in the processing of 1194 received URIs, or in the generation of URIs. 1196 The KMS MUST omit query and fragment components from PALs. 1198 The KMS SHOULD reject the delivery of any PAL that contains a URI 1199 with a query or fragment components. 1201 Clients and agents SHOULD reject the delivery of any PAL that 1203 Internet-Draft SODP 2011-03-07 1205 contains a URI with a query or fragment component. 1207 When generating a URI, clients and agents MUST NOT populate the URI 1208 with any query or fragment components. 1210 8. SODP Transport Requirements 1212 This section provides the requirements for SODP interactions. 1214 8.1. KMS Requirements 1216 The KMS MUST support HTTP 1.1 [RFC2616]; the KMS MUST support 1217 generating HTTP GET and POST responses and receiving HTTP GET and 1218 POST requests; the KMS MUST support HTTPS [RFC2818] over TCP [RFC793] 1219 on port 443, and; the KMS MUST support both IPv4 [RFC791] and IPv6 1220 [RFC2460]. TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST be 1221 implemented in conjunction with HTTPS. To ensure only authorized 1222 clients and agents access the KMS, the KMS MUST support 1223 authentication with both client-side certificates and 1224 username/password. See Section 10 for cipher suite requirements. 1226 When the KMS receives and processes an HTTP request from a client, it 1227 will provide a response. HTTP responses include status information 1228 and may include a message body, when a request is successfully 1229 processed. The status information provided in responses to client 1230 requests will be restricted to the three-digit HTTP status code. 1232 HTTP response status codes fall into five general classes (where the 1233 class is indicated by the first digit of the code). 1235 o Informational - The KMS will not make use of the Informational 1236 class of status codes. Protocol switches and continued client 1237 processing are not expected. 1239 o Success - The KMS will return this class when the GET results in 1240 the requested information being returned or the POST action is 1241 successfully completed. 1243 o Redirection - The KMS will not make use of the Redirection class 1244 of status codes. The KMS will not ask a client to take further 1245 action to fulfill a request. 1247 o Client Error - The KMS will return this class when they cannot 1248 fulfill the requested GET or POST because of a client error. 1250 o Server Error - The KMS may return this class, when a valid POST 1251 or GET request was received, but the KMS cannot fulfill the 1252 request for other reasons. 1254 Internet-Draft SODP 2011-03-07 1256 8.2. Client Requirements 1258 Clients MUST support HTTP 1.1 [RFC2616]; clients MUST support HTTP 1259 generating GET and POST requests and HTTP GET and POST responses; 1260 clients MUST support HTTPS [RFC2818] over TCP [RFC793] on port 443, 1261 and; clients MUST support either IPv4 [RFC791] or IPv6 [RFC2460] 1262 (IPv6 is preferred). TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST 1263 be implemented in conjunction with HTTPS. Clients MUST support 1264 client-side certificate authentication when connecting to the KMS. 1265 See Section 10 for cipher suite requirements. 1267 If a client receives an HTTP response with an Informational or 1268 Redirection class status code, it SHALL interpret the response as a 1269 request failure and terminate its session with the KMS. 1271 When an Informational or Redirection class status code is received, a 1272 client MAY, if configured for an alternate KMS, terminate the current 1273 session and attempt to connect with an alternate KMS to obtain the 1274 originally requested KMS Service. 1276 If a client receives an HTTP response with a Success class status 1277 code, it SHALL continue to process the response to determine the 1278 outcome of an HTTP POST request or to use the information contained 1279 in the included package. 1281 If a client receives an HTTP response with a Client Error class 1282 status code, it SHALL abandon the desired action and not repeat the 1283 same request to the same KMS during the connection session. 1285 The client can provide additional processing of Client Error class 1286 status codes for a given request; however, this is out-of-scope of 1287 this document. 1289 A client can attempt other (different) HTTP requests after a request 1290 that failed with a Client Error class status code. However, the 1291 client incorporate a means to limit the number of consecutive 1292 requests that fail for any reason in a given connection session with 1293 the KMS. 1295 If a client receives an HTTP response with a Server Error class 1296 status code, it SHOULD either: 1298 o Reattempt the request after a non-deterministic delay, or 1300 o Attempt the request with a different KMS. 1302 8.3. Agent Requirements 1303 Internet-Draft SODP 2011-03-07 1305 Agent requirements are identical to those for clients with one 1306 exception and that is that agents MUST support either agent-side 1307 certificate authentication when connecting to the KMS or 1308 username/password. 1310 9. Message Sequences 1312 This section depicts message sequences when using a PAL. 1314 9.1. Distribution 1316 The KMS Distribution service instantiates itself with the 1317 distribution of symmetric key packages and firmware packages. The 1318 message types are defined as follows: 1320 Message Package 1321 Type 1322 -------- ------------- 1323 TBD Symmetric Key Package 1324 TBD Firmware Package 1326 An example PAL entry for a distribution package is as follows: 1328 1329 TBD 1330 00000000000000 1331 1996 1332 https://www.example.com/distribution/symmtrickey1 1333 1335 The message type TBD indicates the message is a symmetric key. The 1336 date and time indicates that the package has not been downloaded. 1337 The message size indicates the size of the package and the additional 1338 info element provides a link to the symmetric key. 1340 The sequence for both symmetric key and firmware packages is 1341 identical, as shown in Figure 6. The client or agent connects to the 1342 KMS, retrieves their PAL, and the requests the package from the URI 1343 provided in the additional info component. 1345 Internet-Draft SODP 2011-03-07 1347 | | 1348 KMS | Establish HTTPS | Client or Agent 1349 | Connection | 1350 |<-------------------->| 1351 | | 1352 | Request PAL | 1353 | (HTTP GET) | 1354 |<---------------------| 1355 |--------------------->| 1356 | Deliver PAL with URI | 1357 | (HTTP GET Response) | 1358 | | 1359 | Request package by | 1360 | specified URI | 1361 | (HTTP GET) | 1362 |<---------------------| 1363 |--------------------->| 1364 | Deliver requested | 1365 | CMS package product | 1366 | (HTTP GET Response) | 1367 | | 1369 Figure 6 - SODP Distribution Service Message Sequence 1371 9.2. Publication 1373 The KMS Publication service instantiates itself with the distribution 1374 of additional certificates, CRLs, CPs, and CPSs. The message types 1375 are defined as follows: 1377 Message Package 1378 Type 1379 -------- ------------- 1380 TBD Root CRL 1381 TBD non-Root CRL 1383 TO DO: Add additional certificates, CPs, and CPSs. 1385 An example PAL entry for a publication package is as follows: 1387 1388 TBD 1389 00000000000000 1390 1996 1391 https://www.example.com/publication/Root.crl 1392 1394 The message type TBD indicates the message is a Root CRL. The date 1396 Internet-Draft SODP 2011-03-07 1398 and time indicates that the package has not been downloaded. The 1399 message size indicates the size of the package and the additional 1400 info element provides a link to the Root CRL. The message sequence is 1401 identical to Figure 6. 1403 9.3. Certificate Management 1405 The KMS Certificate Management service instantiates itself with the 1406 distribution of notifications (i.e., start rekey), and CMC 1407 transactions. The message types are defined as follows: 1409 Message Package 1410 Type 1411 -------- ------------- 1412 100 IA Certificate Rekey Notification 1413 N/A IA Certificate Rekey Transaction One 1414 TBD IA Certificate Rekey Transaction Two (Success) 1415 TBD IA Certificate Rekey Transaction Two (Failure) 1416 TBD KE Certificate Issuance Notification 1417 N/A KE Certificate Issuance Transaction One 1418 TBD KE Certificate Issuance Transaction Two (Success) 1419 TBD KE Certificate Issuance Transaction Two (Failure) 1421 An example PAL entry for a publication package notification is as 1422 follows: 1424 1425 100 1426 00000000000000 1427 1996 1428 DN of IA certificate 1429 1431 TO DO: Get legal encoding of DN for IA certificate. 1433 The message type TBD indicates the message is a IA Certificate Rekey 1434 Notification. The date and time indicates that the package has not 1435 been downloaded. The message size indicates the size of the package 1436 and the additional info element provides a link to the rekey 1437 notification. 1439 The message sequence for certificate rekey and issuance is a three- 1440 step process. The initial step is client/agent retrieval of the PAL 1441 and then retrieval of a notification for either IA rekey or KE 1442 issuance. Step two is the client/agent posting of the CMC package. 1443 Step three is certificate request response (success or failure) from 1444 the KMS. Prior to each interaction with the KMS, the client/agent 1445 authenticates itself with the KMS. The three steps are depicted in 1447 Internet-Draft SODP 2011-03-07 1449 Figures 7-9. 1451 Step 1 1453 KMS | Establish HTTPS | Client or Agent 1454 | Connection | 1455 |<-------------------->| 1456 | | 1457 | Request PAL | 1458 | (HTTP GET) | 1459 |<---------------------| 1460 |--------------------->| 1461 | Deliver PAL with URI | 1462 | (HTTP GET Response) | 1463 | | 1464 | Request IA | 1465 | Certificate Rekey | 1466 | Transaction One | 1467 | (HTTP GET) | 1468 |<---------------------| 1469 |--------------------->| 1470 | Deliver Transaction | 1471 | One | 1472 | (HTTP GET Response) | 1474 Figure 7 - SODP Certificate Management Service 1475 Message Sequence - Step 1 1477 Step 2 1479 KMS | Establish HTTPS | Client or Agent 1480 | Connection | 1481 |<-------------------->| 1482 | | 1483 | Deliver Transaction | 1484 | Two | 1485 | (HTTP POST) | 1486 |<---------------------| 1487 |--------------------->| 1488 | (HTTP Post Response) | 1490 Figure 8 - SODP Certificate Management Service 1491 Message Sequence Step 2 1493 Internet-Draft SODP 2011-03-07 1495 Step 3 1497 KMS | Establish HTTPS | Client or Agent 1498 | Connection | 1499 |<-------------------->| 1500 | | 1501 | Request PAL | 1502 | (HTTP GET) | 1503 |<---------------------| 1504 |--------------------->| 1505 | Deliver PAL with URI | 1506 | (HTTP GET Response) | 1507 | | 1508 | Request IA | 1509 | Certificate Rekey | 1510 | Transaction Three | 1511 | (HTTP GET) | 1512 |<---------------------| 1513 |--------------------->| 1514 | Deliver Transaction | 1515 | Three | 1516 | (HTTP GET Response) | 1518 Figure 9 - SODP Certificate Management Service 1519 Message Sequence Step 3 1521 10. Cryptographic Algorithm Requirements 1523 This section defines the cryptographic algorithm requirements for 1524 SODP. There are three types: package protection requirements, TLS 1525 cipher suites, and certificate requirements. 1527 10.1. Package Protection 1529 For [RFC5958] algorithm requirements see [RFC5959]. 1531 For [RFC6031] algorithm requirements see [I-D.turner-cms- 1532 symmetrickeypackage-algs]. 1534 For [RFC6032] algorithm requirements see [RFC6033]. 1536 NOTE: The "cert-only" package does not have algorithm requirements 1537 because no cryptographic operations are performed while generating 1538 this package. 1540 TO DO: Include text or reference(s) for the following: 1542 Internet-Draft SODP 2011-03-07 1544 For [RFC4108][RFC5911] algorithm requirements see [TO DO]. 1546 For [RFC5934] algorithm requirements see [TO DO]. 1548 For [RFC5280] algorithm requirements see [TO DO]. 1550 10.2. TLS Cipher Suites 1552 The following requirements apply to the KMS, client, and agent: 1554 o Cipher suites supported MUST include: "TLS_RSA_WITH_", "TLS_DH_", 1555 "TLS_DHE_", and "TLS_ECDH_". 1557 o Cipher suites that include "anon" MUST NOT be used. These suites 1558 do not support mutual authentication. 1560 o Cipher suite that include "EXPORT" and "DES" MUST NOT be used. 1561 These ciphers do not offer a sufficient level of protection; 40- 1562 bit crypto in '11 doesn't cut the mustard and the use of DES is 1563 deprecated. 1565 o When confidentially is supported (recall that is optional), the 1566 "AES_128" ciphers MUST be supported and "AES_256" cipher SHOULD 1567 be supported. 1569 o Cipher suites that include "SHA256" MUST be supported and 1570 "SHA384" SHOULD be supported. 1572 10.3. Certificates 1574 Client, agents, and the KMS MUST support certificate path validation 1575 on key packages and TLS connections [RFC5280]. 1577 TO DO: Need to add text that lines up algorithm requirements for 1578 packages with certificates. Also add CCC [RFC6010] as an OPTIONAL 1579 extension for source authorities. 1581 11. Security Considerations 1583 TO DO: Expand this section! 1585 This document relies on many other specifications. For IP and TCP 1586 security considerations see [RFC791], [RFC793], and [RFC2460]; for 1587 HTTP, HTTPS, and TLS security considerations see [RFC2616], 1588 [RFC2818], and [RFC5246]; for URI security considerations see 1589 [RFC3986]; for content type security considerations see [RFC4073], 1590 [RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5958], [RFC5934], 1591 [RFC6031], and [RFC6032]; for certificate security considerations see 1593 Internet-Draft SODP 2011-03-07 1595 [RFC5280], [RFC5480], and [RFC6010], and; for algorithm security 1596 considerations see [RFC5959], [RFC6033], 1597 [I-D.turner-cms-symmetrickeypackage-algs]. 1599 TO DO: Probably more references are needed above for algorithms based 1600 on what gets added in Section 9.1. 1602 It is critical that the KMS encrypt symmetric keys and centrally- 1603 generated asymmetric private keys for the end client. Failure 1604 encrypt these keys will allow any intermediaries to intercept the key 1605 and eavesdrop and/or impersonate the client. 1607 When packages are encrypted, the source of the package must randomly 1608 generate package-encryption keys. Also, the generation of 1609 public/private signature key pairs relies on a random numbers. The 1610 use of inadequate pseudo-random number generators (PRNGs) to generate 1611 cryptographic keys can result in little or no security. An attacker 1612 may find it much easier to reproduce the PRNG environment that 1613 produced the keys, searching the resulting small set of 1614 possibilities, rather than brute-force searching the whole key space. 1615 The generation of quality random numbers is difficult. [RFC4086] 1616 offers important guidance in this area. 1618 12. IANA Considerations 1620 IANA is requested to perform four registrations: SODP Name Space, 1621 SODP XML Schema, SODP Message Types, and SODP URI String Types. 1623 12.1. SODP Name Space 1625 This section registers a new XML namespace, 1626 "urn:ietf:params:xml:ns:TBD" per the guidelines in [RFC3688]: 1628 TO DO: Fill in TBDs. 1630 URI: urn:ietf:params:xml:ns:TBD 1631 Registrant Contact: Sean Turner (turners@ieca.com) 1632 XML: 1633 BEGIN 1634 1635 1637 1638 1639 SODP Messages 1640 1641 1642

Namespace for SODP Messages

1644 Internet-Draft SODP 2011-03-07 1646

urn:ietf:params:xml:ns:TBD

1647

See TBD

1648 1649 1650 END 1652 12.2. SODP Schema 1654 This section registers an XML schema as per the guidelines in 1655 [RFC3688]. 1657 TO DO: Fill in TBDs. 1659 URI: urn:ietf:params:xml:ns:TBD 1660 Registrant Contact: Sean Turner turners@ieca.com 1661 XML: 1662 1663 1669 1671 1673 1675 1676 1677 1679 1680 1681 1683 1684 1685 1686 1687 1688 1689 1690 1692 1694 Internet-Draft SODP 2011-03-07 1696 1697 1698 1699 1700 1701 1703 1704 1705 1706 1707 1709 1710 1711 1712 1713 1714 1716 1717 1718 1720 1722 12.3. SODP Message Types 1724 This section registers the SODP Message Types. SODP Message Types 1725 registrations are to be subject to Specification Required, as per RFC 1726 5226 [RFC5226]. The registry has the following values: 1728 Internet-Draft SODP 2011-03-07 1730 +-------+--------------------------------+---------------+ 1731 | Value | Message Type | Specification | 1732 +-------+--------------------------------+---------------+ 1733 | 0 | Reserved | This document | 1734 +-------+--------------------------------+---------------+ 1735 | 1 | Additional PAL value present | This document | 1736 +-------+--------------------------------+---------------+ 1737 | 100 | IA Rekey Notification | This document | 1738 +-------+--------------------------------+---------------+ 1739 | TBD | Symmetric Key Package | This document | 1740 +-------+--------------------------------+---------------+ 1741 | TBD | Firmware Package | This document | 1742 +-------+--------------------------------+---------------+ 1743 | TBD | Root CRL | This document | 1744 +-------+--------------------------------+---------------+ 1745 | TBD | non-Root CRL | This document | 1746 +-------+--------------------------------+---------------+ 1747 | TBD | IA Certificate Rekey | This document | 1748 | | Transaction Two - Success | | 1749 +-------+--------------------------------+---------------+ 1750 | TBD | IA Certificate Rekey | This document | 1751 | | Transaction Two - Fail | | 1752 +-------+--------------------------------+---------------+ 1753 | TBD | KE Certificate Issuance | This document | 1754 | | Transaction One | | 1755 +-------+--------------------------------+---------------+ 1756 | TBD | KE Certificate Issuance | This document | 1757 | | Transaction Three - Success | | 1758 +-------+--------------------------------+---------------+ 1759 | TBD | KE Certificate Issuance | This document | 1760 | | Transaction Three - Fail | | 1761 +-------+--------------------------------+---------------+ 1763 TO DO: Add values from Section 9 to the above table. 1765 Internet-Draft SODP 2011-03-07 1767 12.4. SODP Path 1 String Values 1769 This section registers SODP Path String Types as per [RFC3688]. SODP 1770 Path 1 String Value registrations are to be subject to Specification 1771 Required, as per RFC 5226 [RFC5226]. The registry has the following 1772 structure: 1774 +----------------------------------------+ 1775 | SODP Message Types | Specification | 1776 +----------------------------------------+ 1777 | distribution | This document | 1778 +----------------------------------------+ 1779 | publication | This document | 1780 +----------------------------------------+ 1781 | certificate | This document | 1782 +----------------------------------------+ 1784 TO DO: Verify that specification required is appropriate. 1786 13. IANA Considerations 1788 None. Please remove this section prior to publication as an RFC. 1790 14. References 1792 14.1. Normative References 1794 [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet 1795 Program Protocol Specification", RFC 791, September 1981. 1797 [RFC793] Postel, J. (ed.), "Transmission Control Protocol," RFC 793, 1798 September 1981. 1800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1801 Requirement Levels", BCP 14, RFC 2119, March 1997. 1803 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 1804 (IPv6) Specification," RFC 2460, December 1998. 1806 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1807 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer 1808 Protocol -- HTTP/1.1", RFC 2616, June 1999 1810 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1812 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1813 January 2004. 1815 Internet-Draft SODP 2011-03-07 1817 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1818 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1819 3986, January 2005. 1821 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1822 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1824 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1825 Protect Firmware Packages", RFC 4108, August 2005. 1827 [RFC5226] Naten, T., and H. Alvestrand, "Guidelines for Writing an 1828 IANA Considerations Section in RFCs", RFC 5226, May 2008. 1830 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1831 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1833 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1834 Housley, R., and W. Polk, "Internet X.509 Public Key 1835 Infrastructure Certificate and Certificate Revocation List 1836 (CRL) Profile", RFC 5280, May 2008. 1838 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R. and T. Polk, 1839 "Elliptic Curve Cryptography Subject Public Key 1840 Information", RFC 5480, March 2009. 1842 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1843 RFC 5652, September 2009. 1845 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1846 (CMC)", RFC 5272, June 2008. 1848 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1849 Mail Extensions(S/MIME) Version 3.2 Message Specification", 1850 RFC 5751, January 2010. 1852 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 1853 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 1854 June 2010. 1856 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1857 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1858 June 2010. 1860 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1861 Management Protocol (TAMP)", RFC 5934, August 2010. 1863 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1864 2010. 1866 Internet-Draft SODP 2011-03-07 1868 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Packages", RFC 1869 5959, August 2010. 1871 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 1872 Message Syntax (CMS) Content Constraints Extension", RFC 1873 6010, September 2010. 1875 [RFC6031] Turner, S., and R. Housley, "Symmetric Key Package Content 1876 Type", RFC 6031, December 2010. 1878 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 1879 (CMS) Encrypted Key Package Content Type", RFC 6032, 1880 December 2010. 1882 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 1883 (CMS) Encrypted Key Package Content Type", RFC 6033, 1884 December 2010. 1886 [I-D.tls-ssl2-must-not] 1887 Turner, S., and T. Polk, "Prohibiting SSL Version 2.0", 1888 draft-ietf-tls-ssl2-must-not, work-in-progress. 1890 [I-D.turner-cms-symmetrickeypackage-algs] 1891 Turner, S., "Algorithms for Cryptographic Message Syntax 1892 (CMS) Protection of Symmetric Key Package Content Types", 1893 draft-turner-cms-symmetrickeypackage-algs, work-in- 1894 progress. 1896 [XMLSCHEMA] 1897 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1898 Second Edition", World Wide Web Consortium Recommendation 1899 REC-xmlschema-2-20041082, October 2004, 1900 . 1902 [TO DO] Insert references for Section 9.1. 1904 14.2. Informative References 1906 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 1907 "Randomness Requirements for Security", BCP 106, RFC 4086, 1908 June 2005. 1910 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1911 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1913 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 1914 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1915 September 2010. 1917 Internet-Draft SODP 2011-03-07 1918 Internet-Draft SODP 2011-03-07 1920 [XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in 1921 XML", World Wide Web Consortium FirstEdition REC-xml-names- 1922 19990114, January 1999, . 1925 Appendix A. Example Encodings 1927 TO DO: Include BASE64 encodings of ASN.1 encodings of selected 1928 packages. They're a lot smaller than the ASN.1 pretty prints and 1929 there are tons of available to tools to convert. 1931 Authors' Addresses 1933 Sean Turner 1934 IECA, Inc. 1935 3057 Nutley Street, Suite 106 1936 Fairfax, VA 22031 1937 USA 1939 EMail: turners@ieca.com