idnits 2.17.00 (12 Aug 2021) /tmp/idnits33016/draft-turner-sodp-01.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 (September 1, 2011) is 3914 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 1819, 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 September 1, 2011 5 Expires: March 4, 2012 7 Secure Object Delivery Protocol (SODP) 8 draft-turner-sodp-01.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 March 4, 2012. 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 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. SODP Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Key Management System . . . . . . . . . . . . . . . . . . . . . 8 57 3.1. KMS Services . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1.2. Distribution Service . . . . . . . . . . . . . . . 10 59 3.1.3. Publication Service . . . . . . . . . . . . . . . . 11 60 3.1.4. Certificate Management Service . . . . . . . . . . 12 61 3.2. KMS Packages . . . . . . . . . . . . . . . . . . . . . . 13 62 4. Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 4.1. Registration . . . . . . . . . . . . . . . . . . . . . . 14 64 4.2. Activation and Operation . . . . . . . . . . . . . . . . 16 65 4.3. Packages . . . . . . . . . . . . . . . . . . . . . . . . 17 66 5. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 6. Electronic Serial Number . . . . . . . . . . . . . . . . . . 18 68 7. Product Availability List . . . . . . . . . . . . . . . . . . 18 69 7.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . 21 70 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 7.2.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . 23 72 7.2.2. URI Authority . . . . . . . . . . . . . . . . . . . 24 73 7.2.3. URI Path . . . . . . . . . . . . . . . . . . . . . . 24 74 7.2.4. URI Query and Fragments . . . . . . . . . . . . . . 25 75 8. SODP Transport Requirements . . . . . . . . . . . . . . . . . 26 76 8.1. KMS Requirements . . . . . . . . . . . . . . . . . . . . 26 77 8.2. Client Requirements . . . . . . . . . . . . . . . . . . . 27 78 8.3. Agent Requirements . . . . . . . . . . . . . . . . . . . 27 79 9. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 28 80 9.1. Distribution . . . . . . . . . . . . . . . . . . . . . . 28 81 9.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 29 82 9.3. Certificate Management . . . . . . . . . . . . . . . . . 30 83 10. Cryptographic Algorithm Requirements . . . . . . . . . . . . 32 84 10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32 85 10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . 33 86 10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 89 12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . 34 90 12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . 35 91 12.3. SODP Message Types . . . . . . . . . . . . . . . . . . . 36 92 12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . 38 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 96 14.2. Informative References . . . . . . . . . . . . . . . . . 40 97 Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 42 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 100 1. Introduction 102 The Secure Object Delivery Protocol (SODP) enables clients to obtain 103 secured packages from a supporting Key Management System (KMS). 104 Client access is via the HyperText Transfer Protocol (HTTP) over 105 Transport Security Layer (TLS). Clients can directly access the KMS 106 or an agent can act on the client's behalf. Clients access the KMS 107 to retrieve a Product Availability List (PAL), which provides the 108 location of their packages with a User Resource Identifier (URI), or 109 can directly retrieve the package if the client obtains the URI via 110 another method. Packages are secured using the Cryptographic Message 111 Syntax (CMS). 113 The remainder of this document will explain the SODP model, provide 114 requirements for the KMS, client, and agent, as well specify the PAL 115 format. 117 1.1 Definitions 119 Agent: An entity that performs functions on behalf of a client. 120 Asymmetric Key Package: A package that includes an asymmetric key 121 content type [RFC5959]. 123 Certificate Management Packages: A package that contains a PKI Data 124 or PKI Response content types [RFC5272][RFC5912]. 126 Clients: An entity that contains one or more End Cryptographic Unit 127 (ECU). Clients consume products generated by the Key Management 128 System (KMS). 130 Encrypted Key Package: A package that includes an encrypted key 131 content type [RFC6032]. 133 Firmware Package: A package that contains a firmware content type 134 [RFC4108][RFC5911]. 136 NOTE: [RFC4108] defines the semantics for the firmware content 137 type's fields. [RFC5911] provides the 2002 ASN.1 definitions. 139 Identity and Authentication (IA) Key/Certificate: Key/Certificate 140 used to support IA of the client, when the client communicates with 141 the KMS as well as with other end-entities. It provides the KMS or 142 other end-entities with an appropriate degree of confidence in the 143 client's identity before delivering products, services or sensitive 144 information to the client. 146 Key Exchange (KE) Key/Certificate: Key/Certificate used when the 147 client and the KMS or other end-entity must cooperatively create a 148 wrapping key to protect the delivery of products or sensitive 149 information for use by the client. It is also used to establish 150 secure sessions (e.g., TLS) from a client to the KMS. Other examples 151 include traffic encryption keys and transmission security keys. 153 Key Management System (KMS): A set of one or more components that is 154 designed to protect, manage, and distribute cryptographic products. 155 In this document, cryptographic products are referred to as packages. 157 Operator: A person who "runs" the device (e.g., network 158 administrator). 160 Package: An object that contains one or more CMS content types. At a 161 minimum, all packages are protected using the CMS [RFC5652] 162 SignedData structure. There are numerous types of packages: 163 Asymmetric, Certificate Management, Encrypted Key, Firmware, 164 Publication, and Symmetric Packages. 166 NOTE: This document does not define any packages they are all 167 defined elsewhere. Product Availability List (PAL): A PAL is an 168 XML file that furnishes information for KMS service messages that 169 are currently available and authorized for retrieval by a client 170 or agent. 172 Publication Package: A package that contains certificates and 173 Certificate Revocation Lists (CRLs). These are typically additional 174 CA certificates or CRLs not provided as part of other packages. The 175 package is a degenerate CMS SignedData, which is sometimes referred 176 to as a "certs-only" message. 178 Service Messages: KMS-produced packages are the instantiation of the 179 KMS services. This document defines three services that manifest in 180 three types of service messages: publication, distribution, and 181 certificate management. One, registration, does not manifest itself 182 in a service message. 184 Source Authority: A source authority is trusted by clients to 185 generate particular package types. Clients determine this by 186 validating the digital signature on the package back to a Trust 187 Anchor (TA). 189 Sponsor: A person that is accountable for use of the client's 190 identity. This may or may not be the entity that operates the client 191 (i.e., the operator). 193 Symmetric Key Package: A package that contains a symmetric key 194 content type [RFC6031]. 196 Trust Anchor (TA): From [RFC5934], a TA contains a public key that is 197 used to validate digital signatures. In this document, a TA 198 represents an authoritative entity via a public key and associated 199 data. The public key is used to verify digital signatures and the 200 associated data is used to constrain the types of information for 201 which the TA is authoritative. A relying party uses TAs to determine 202 if a digitally signed object is valid by verifying a digital 203 signature using the TA's public key, and by enforcing the constraints 204 expressed in the associated data for the TA. 206 1.2 Key Words 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in 211 [RFC2119]. 213 2. SODP Model 215 Figure 1 depicts the SODP model. It is comprised of three entities: 216 the key management system, one or more clients, and agents acting on 217 behalf of clients. KMS-to-client and KMS-to-agent protocol 218 interactions are in-scope; agent-to-client protocol interactions are 219 out-of-scope. KMS-to-client and KMS-to-agent interactions support 220 mutual authentication, provide integrity, and optionally provide 221 confidentiality through the use of HTTPS. Confidentiality for KMS- 222 to-client and KMS-to-agent interactions is OPTIONAL because when 223 confidentiality is needed the packages are encrypted for the client. 224 See Section 10 for requirements on cryptographic suites. 226 <===> IP-Based Protocol Profile (in scope) 227 <- -> ECU-Specified Access Protocol (out of scope) 228 ///// CMS-Protected Packages (in scope; full support) 229 \\\\\ CMS-Protected Packages (in scope; partial support; 230 requires validation of outer signature only) 231 +----------------+ 232 | | +------------+ 233 | Key | | Client A | 234 | Management | | +---+ | 235 | System |<=====>| /// |ECU| | 236 | | | /A/ | | | 237 | +-------+ /// | | /// | A | | 238 | |A's PAL| /A/ | | +---+ | 239 | +-------+ /// | +------------+ 240 | | 241 | +-------+ /// | +-------+ +------------+ 242 | |B's PAL| /B/ | | | | Client B | 243 | +-------+ /// | | | | +---+ | 244 | | | Agent |<- - ->| /// |ECU| | 245 | +-------+ /// | | | | /B/ | | | 246 | |C's PAL| /C/ | | | | /// | B | | 247 | +-------+ /// | | \\\ | | +---+ | 248 | |<=====>| \B\ | +------------+ 249 | . . | | \\\ | 250 | . . | | | +------------+ 251 | . . | | | | Client C | 252 | | | \\\ | | +---+ | 253 | +-------+ /// | | \C\ |<- - ->| /// |ECU| | 254 | |Z's PAL| /Z/ | | \\\ | | /C/ | | | 255 | +-------+ /// | | | | /// | C | | 256 | | | | | +---+ | 257 +----------------+ +-------+ +------------+ 259 Figure 1 - SODP Model 261 Clients or agents access the KMS via HTTPS to retrieve and inspect 262 their PAL. The PAL is an XML file that contains Uniform Resource 263 Identifiers (URIs) for client packages. Retrieval of packages 264 referenced in the PAL delivers KMS services to the client. 265 Alternatively, clients can retrieve packages directly from the KMS if 266 they obtain URIs from another source. KMS services are discussed in 267 Section 2.1; the PAL and URI format are discussed in Section 5. 269 While the KMS is viewed as being a single entity, operationally the 270 issuance of different packages can be assigned to different 271 authorities within the KMS. These authorities are referred to as 272 source authorities. A source authority is trusted by clients to 273 generate particular package types. Entities validate their source 274 authorities when validating the digital signature(s) in/on packages. 275 That is, when a client retrieves a package referred to in their PAL 276 the client ensures that the signatures in/on the package validate to 277 an installed trust anchor (TA). See Section 4.1 for more information 278 on clients' TAs. 280 Packages may be encrypted for the client. Packages that contain 281 cleartext (i.e., unencrypted) symmetric keys or asymmetric private 282 keys MUST be encrypted for the client to ensure that the keys are not 283 disclosed to another party. Relying on encrypted packages instead of 284 relying on HTTPS-encrypted links allows agents to further distribute 285 the packages to clients without disclosing the cleartext to the 286 agent. Encrypted packages also enable alternate distribution paths 287 such as store-and-forward, which is beyond the scope of this 288 document. Package requirements are discussed in Section 4. 290 Prior to clients accessing the KMS, clients need be registered with 291 the KMS. The process for this will vary. One possible process 292 involves sponsorship by an individual. This individual collects 293 information about the client and enters the information into the 294 KMS's database. Also during this time, the client is assigned an 295 initial identity. Once registered, the client is issued a 296 certificate, which is later used to access the KMS. Clients and 297 agents use what is referred to as IA certificates when communicating 298 with the KMS. An IA certificate provides the client's/agent's 299 identity and allows the KMS to authenticate that the entity accessing 300 the KMS is in fact the client/agent. The registration and client IA 301 certificate issuance process is described in more detail in Section 302 3.1. The format and protocol for communicating the registration data 303 and sending the initial IA certificate directly to client is out-of- 304 scope. The client authenticates itself to the KMS with this 305 certificate using HTTPS. After the IA certificate is installed, the 306 client requests a KE certificate. KE certificates allow clients to 307 perform key establishment with the KMS to decrypt/encrypt packages. 309 Some implementations may require further separation for some clients 310 who are issued another set of certificates that support client-to- 311 client interactions, which is the client's joie de vivre or the 312 client's mission. The initial certificate set is only used to 313 communicate with the KMS and the second set is only ever used to 314 communicate with other clients. In this case the first set is 315 referred to as IA(I)/KE(I) certificates for (I)nfrastructure 316 certificates and the second set is referred to as IA(M)/KE(M) 317 certificates for (M)ission certificates. Not all clients need the 318 second set of certificate, if clients only need symmetric key, then 319 only one set of certificates is issued. *(I) certificates are issued 320 to it and instead of IA(M)/KE(M) certificates issued later only 321 symmetric key packages are provided. 323 3. Key Management System 325 The SODP is the interface to the KMS that clients use to access KMS- 326 services and associated KMS-generated packages. The internal 327 components of the KMS and their interactions are out-of-scope. 328 However, if a KMS provides all of the KMS packages (see Section 3.2), 329 it will need the capability to package trust anchors (TAs), generate 330 and package symmetric keys, package firmware, generate and package 331 asymmetric keys, issue and package public key certificates, and issue 332 and package Certificate Revocation Lists (CRLs). It will also need 333 to generate and receive packages, which includes generating and 334 verifying digital signatures on packages as well as encrypting and 335 decrypting of packages. Additionally, it will need a repository to 336 store information about clients and their packages. 338 The remainder of this section is split in to two parts. The first 339 part, Section 3.1, describes the KMS services and the second part, 340 Section 3.2, describes the KMS package requirements. 342 3.1. KMS Services 344 This section addresses the four services provided by the KMS: 345 Registration, Distribution, Publication, and Certificate Management. 346 The latter three services are instantiated in packages. 348 3.1.1. Registration Service 350 The KMS only provides services to clients that are KMS-registered. 351 Registration information collected is KMS-specific. However, the 352 information collected MUST include a permanent identifier that is 353 used to identify the client throughout its lifecycle. This permanent 354 identifier is referred to as an Electronic Serial Number (ESN). See 355 Section 6 for more information on ESNs. 357 Other OPTIONAL information to collect includes: 359 o Client Manufacturer 360 o Client Name 361 o Client Type 363 The KMS could also assign a KMS user number for an internal index, 364 label, or abbreviated name for associating data elements pertaining 365 to that user. This number is not sent to the client and is only used 366 by the KMS. 368 During this step the client is also assigned an identity, which the 369 KMS stores in its database. At a minimum the identity is an 370 identifier but it can also include additional information such as a 371 client's sponsor (e.g., Alexa Morris), the client's operator (e.g., 372 Alexa Morris), and the sponsor's organizational affiliation (e.g., 373 AMS). That is, the KMS MUST assign and record an identifier to the 374 client, but recording other client-related identity data is OPTIONAL. 375 Additionally: 377 o For cases where the sponsor isn't the entity that operates the 378 client, the identity can also include an indication of the entity 379 operating the client. This allows the network group to sponsor 380 the client, but the security group to operate the client (i.e., 381 network groups say it's okay to add client to the network but 382 doesn't want to manage the clients keys). 384 o For cases where the client can be transferred from one operator 385 to another, the identity MUST include identity of the previous 386 operator. This provides a "chain-of-control" over the device for 387 its lifetime. A KMS can support a wide variety of environments: 389 o For a KMS that support non-X.509 certificate and non-X.509 CRL 390 types, the identity SHOULD include an indication of certificate 391 type. 393 NOTE: This supports cases where the client uses alternate 394 certificate formats such as Pretty Good Privacy (PGP) [RFC4880]. 395 Alternative certificate formats are supported by many security 396 protocols including Internet Key Exchange v2 (IKEv2) [RFC5996], 397 TLS [RFC5246], and CMS [RFC5652]. 399 o For a KMS that supports humans as well as clients, the identity 400 SHOULD include an indication of the type of user (e.g., 401 client/device, human, administrator). 403 The KMS MUST ensure that the client identity is KMS-unique. That is, 404 the collection of data that comprises the client identity MUST NOT 405 match another client served by the KMS. After this check passes, the 406 final step in the registration process occurs: client IA certificate 407 issuance. The KMS MUST issue a certificate [RFC5280] to the client 408 that contains the client's permanent identifier (see Section 6). 409 NOTE: 1) The process for delivering the IA certificate directly to 410 the client is out-of-scope; 2) the format and protocol for 411 communicating the registration data is out-of-scope; and 3) the 412 client need not contribute to or respond to the supplied identity 413 information. 415 3.1.2. Distribution Service 417 The KMS employs the distribution service to provide clients' access 418 to their packages. The KMS provides access to packages through the 419 use of URIs, which uniquely refers to specifically CMS-wrapped 420 packages for delivery to the target client. The KMS generates a PAL 421 that clients can use to retrieve packages. Alternatively, the client 422 can directly access the package, but this assumes the client obtained 423 the URI(s) via another mechanism, which is out-of-scope. Packages 424 include symmetric key packages as well as centrally-generated 425 asymmetric key packages. 427 NOTE: Certificates associated with client generated asymmetric 428 keys (i.e., locally-generated public-private keys) are delivered 429 via the Certificate Management Service (See Section 3.1.3). 431 Figure 2 depicts an example ladder diagram for a protocol flow. The 432 first step is to establish a mutually authenticated HTTPS connection 433 between the client/agent and KMS. The client then requests their PAL 434 from the KMS (via HTTP GET). The KMS replies with the client's PAL 435 (via HTTP GET Response). Once a client has successfully downloaded 436 their PAL, it will process it to obtain the included packages(s). The 437 processing provided will depend on the PAL entry. Section 3.2 438 details the KMS-package requirements, Section 4 details clients- 439 package requirements, and Section 5 details agent-package 440 requirements. 442 | | 443 KMS | Establish HTTPS | Client or Agent 444 | Connection | 445 |<-------------------->| 446 | | 447 | Request PAL | 448 | (HTTP GET) | 449 |<---------------------| 450 |--------------------->| 451 | Deliver PAL with URI | 452 | (HTTP GET Response) | 453 | | 454 | Request packages by | 455 | specified URI | 456 | (HTTP GET) | 457 |<---------------------| 458 |--------------------->| 459 | Deliver requested | 460 | CMS package product | 461 | (HTTP GET Response) | 462 | | 464 Figure 2 - SODP Distribution Service Message Sequence 466 A device can request (via HTTP GET) and download (via HTTP GET 467 Response) any, or all, packages and new PALs by repeating the 468 necessary sequence of steps. When the client is finished, it SHOULD 469 terminate the connection. See Section 8 for more information on 470 SODP's HTTP requirements. 472 The KMS MUST support generation of a PAL. The KMS MUST support 473 access to client packages directly and through a PAL. 475 3.1.3. Publication Service 477 The KMS Publication Service provides clients that are PKI subscribers 478 and relying parties with a means to obtain publicly-available, 479 ancillary services related to PKIs namely: Certificates, CRLs, 480 Certificate Policies (CPs), and Certificate Practice Statements 481 (CPSs) packages. The KMS MUST support distribution of CRLs but MAY 482 support distribution of CPs and CPSs. 484 NOTE: CPs and CPSs are the one exception to the Package 485 definition found in section 1.1. CPs and CPSs are not 486 encapsulated in CMS, they are URIs to the location on the KMS for 487 the CP and CPS. 489 Certificates delivered can include additional CA certificates or peer 490 client certificate(s). 492 Clients may elect to obtain the CRLs that they rely on from sources 493 other than the (e.g., a local directory). 495 CRLs are offered in the form, or forms, produced by the responsible 496 Certification Authority (CA). The form of the CRL is transparent to 497 the KMS Publication Service. CAs may choose to publish compact 498 versions of CRLs (e.g., partitioned CRLs) that are compatible with a 499 disadvantaged client within the overall subscriber population. The 500 PAL provided to a client will always contain a URI for the most 501 current version of each CRL needed to verify the packages in the form 502 used by the particular client. The KMS Publication Service will not 503 list CRLs that a client does not need or cannot use. Based on its 504 capabilities, the freshness of currently held CRLs, and the 505 circumstances, the client will determine whether it needs to download 506 each offered CRL. KMS Publication Services packages will be signed, 507 but need not be encrypted. The information in the package is already 508 signed; CAs sign the certificates and CRLs so there is no need to 509 sign a package containing them. 511 NOTE: The KMS Publication Service is not meant to be a general 512 repository for all relying parties. Access is only provided to 513 registered clients. 515 3.1.4. Certificate Management Service 517 The KMS Certificate Management Service allows a client to develop an 518 asymmetric key pair and obtain the public key certificate associated 519 with the key pair. It additionally provides certificates and CRLs 520 necessary to validate the asymmetric key pair to an installed TA. 522 The KMS Certificate Management Service supports two kinds of 523 certificate management processes: 525 o Issuance: Where a new public/private key pair is established for 526 a KE certificate. 528 o Rekey: Where an existing IA certificate is provided with new 529 keying material. 531 CA MUST generate public key certificates in accordance with 532 [RFC5280]. A Registration Authority (RA) may be used to register 533 subscribers as well as assist the CA when issuing and rekeying 534 certificates for clients. 536 3.2. KMS Packages 538 The KMS Distribution, Publication, and Certificate Management 539 services translate into KMS packages. The primary packages are key 540 packages, but they also include firmware packages necessary to use 541 the key packages, TAMP packages to validate the package's source of 542 authority, publication packages that contain additional certificates 543 and CRLs, and collections of key packages. This section lists the 544 package requirements for the KMS. 546 There are many different key packages, but at their core there are 547 three types: 549 o Symmetric key packages are defined in [RFC6031]. A symmetric key 550 package can contain one or more symmetric keys. It also can 551 contain attributes that apply to one or more keys. The KMS MUST 552 support the ct-symmetric-key-package content type encapsulated in 553 a ct-signed-data content type [RFC5652][RFC5911]. 555 o Asymmetric key packages are defined in [RFC5958]. An asymmetric 556 key package can contains one or more private asymmetric keys and 557 associated algorithm parameters. It can also contain the public 558 key and other attributes. This key package is used in 559 conjunction with the certificate management packages when the KMS 560 generates the client's key pair. The KMS MUST support the ct- 561 asymmetric-key-package content type encapsulated in a ct-signed- 562 data content type. 564 o Certificate management packages are defined in 565 [RFC5272][RFC5912]. PKI Data and PKI Response content types are 566 used to manage public key certificates [RFC5280]. The KMS MUST 567 support the ct-PKIData and ct-PKIResponse content types. The KMS 568 MUST also support encapsulating ct-PKIData in the ct-signed-data 569 content type. 571 Distribution of the symmetric and asymmetric key packages require 572 that these keys be disclosed only to the client and to not to anyone 573 else. The key packages needs to be enveloped. The encrypted key 574 package [RFC6032] supports encrypting key packages in one of three 575 ways: with key exchange algorithms (i.e., using EnvelopedData), with 576 previously distributed symmetric algorithms (i.e., using 577 EncryptedData), and with authenticated-encryption algorithms (i.e., 578 using AuthEnvelopedData). The KMS MUST support the ct-encrypted-key- 579 package content type and the EnvelopedData choice (i.e., support ct- 580 enveloped-data). The KMS MUST support encapsulating ct-encrypted- 581 key-package in a ct-signed-data content type. 583 The KMS distributes object code for implementing one or more 584 cryptographic algorithms in a cryptographic module and software to 585 implement a communications protocol with the Firmware package 586 [RFC4108][RFC5911]. The KMS MUST support the ct-firmwarePacakge 587 content type. It MUST support receipt of the ct-firmwareLoadReceipt 588 and ct-firmwareLoadError content types. The KMS MUST support 589 encapsulating the ct-firmwarePackage content type in a ct-signed-data 590 content type. 592 To support sending multiple package types to a client, the KMS can 593 use the Content Collection [RFC4073] CMS content type. To allow the 594 KMS to apply additional attributes to the package the can use the 595 Content With Attributes [RFC4073] CMS content type. The KMS SHOULD 596 support the ct-contentCollection any MAY support the ct- 597 contentWithAttributes content type. The KMS MUST support 598 encapsulating these in a ct-signed-data content type. 600 The publication package is supported by the KMS with the "certs-only" 601 package [RFC5751], which is a CMS SignedData with no content just 602 CRLs and certificates. The KMS MUST support the "certs-only" package 603 with ct-data content type with no eContent. The KMS manages TAs to 604 support validating packages with the Trust Anchor Management Protocol 605 (TAMP) [RFC5934]. TAMP supports multiple formats for the TA. The 606 KMS MUST support the Certificate choice. The KMS MUST support the 607 tamp-update content type [RFC5934]. As specified in [RFC5934], tamp- 608 update MUST be encapsulated in a ct-signed-data content type. 610 TO DO: Add TAMP to Service Identifiers. 612 The KMS MUST support validating package signatures back to a TA 613 [RFC5652][RFC5280]. 615 4. Client 617 Clients use SODP to access the KMS-services and associated KMS- 618 generated packages. This section addresses client registration, use, 619 and package requirements. 621 4.1. Registration 623 Section 3.1.1 addresses client registration. As noted there, the 624 client need not contribute to or respond to the supplied identity 625 information. After registration is completed, the client is supplied 626 with an IA certificate. Prior to using this certificate, the client 627 MUST verify that the certificate back to an installed trust anchor. 628 The number of TAs is implementation KMS-specific, but in general: 630 o If the client supports locally-generated asymmetric keys, then it 631 MUST support at least one TA. 633 o If the client support centrally-generated asymmetric keys, then 634 it MUST also support at least one TA. 636 o If the client supports symmetric keys, then it MUST support two 637 TAs: one for symmetric keys and one for the asymmetric keys 638 (i.e., the PKI Root). 640 o If the client support firmware, the it MUST support two TAs: one 641 for the firmware and one for the asymmetric keys (i.e., the PKI 642 Root). 644 More complicated scenarios are possible. For example in Figure 3, a 645 KMS and client support centrally-generated asymmetric keys. The KMS 646 supports two TAs: one for the certificate and one for the asymmetric 647 keys (a Key TA (KTA)). The KTA delegates source authority to a Key 648 Source Authority (KSA) and distribution authority to a Key 649 Distribution Authority (KDA). The KSA creates the asymmetric key 650 places it in the symmetric key content type, signs it (signed data 651 content type), includes the corresponding certificate, and encrypts 652 it (encrypted key content type). The KDA applies an additional 653 signature layer around the encrypted data. Upon receipt the client 654 validates KDA's certificate and signature to the KTA, decrypt the 655 message, the KSA's signature and certificates to the KTA, the client 656 validates their certificate to the PKI TA, and the client checks that 657 the private key corresponds to the public key. 659 +-----+ +--------+ 660 | KTA | | PKI TA | 661 +-----+ +--------+ 662 | | 663 | Signs | Signs 664 | | 665 +-------------+ V 666 | | +----+ 667 V V | CA | 668 +-----+ +-----+ +----+ 669 | KSA | | KDA | | 670 +-----+ +-----+ | Signs 671 | | | 672 | Signs & | Optionally V 673 | Encrypts | Signs +-----+ 674 | | | PKC | 675 | | +-----+ 676 | V | 677 +---|-------------+ Included In | 678 | V SignedData | Key Package | 679 | +-------------+ | | 680 | | Key Package |<--------------------+ 681 | +-------------+ | 682 +-----------------+ 683 Figure 3 - Example Authority Architecture 685 4.2. Activation and Operation 687 The activation/operation phase of the client lifecycle is where the 688 client performs its prime mission (e.g., secure Voice Over IP (VoIP), 689 cable box). 691 Activation can occur immediately following registration, when the 692 client receives an IA certificate. Activation can also occur when 693 the client resides at and is associated with its intended operator 694 (i.e., the client is registered and sponsored in the Canada but not 695 activated by the operator until it arrives where they are located in 696 Greenland). In other words, the client can be immediately actived or 697 it can occur at a later time. 699 NOTE: A client only needs to be loaded with an IA key to perform 700 KMS Services. 702 If the client needs additional certificates (e.g., for 703 confidentiality or separate mission certificates), the client or 704 agent can retrieve them via the PAL. Client retrieval of packages 705 via the PAL is OPTIONAL. Clients may elect to obtain product package 706 URI information using a different mechanism (e.g., inputs from a 707 human or agent). 709 4.3. Packages 711 Client support for packages varies depending on the type of service 712 they desire. All clients MUST support the ct-signed-data content 713 type to ensure the packages source of authority can be determined. 714 They MUST also support validating package signatures back to a TA 715 [RFC5652][RFC5280]. 717 For clients that support symmetric key packages [RFC6031], they MUST 718 support the ct-symmetric-key-package content type. Additionally, 719 clients MUST support the ct-encrypted-key-package content type and 720 the EnvelopedData choice (i.e., support ct-enveloped-data) to support 721 encrypting the cleartext symmetric key. 723 For clients that support certificate management packages with 724 locally-generated keys, they MUST support certs-only 725 [RFC5751][RFC5911], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse 726 [RFC5272][RFC5912]. 728 Retrieval of CRLs and additional certificates via the certs-only 729 package, is OPTIONAL. Clients can retrieve CRLs and additional 730 certificate via other mechanisms. Client support for the ct- 731 contentCollection and the ct-contentWithAttributes content types is 732 OPTIONAL. 734 For clients that support firmware packages [RFC4108][RFC5911], they 735 MUST support the ct-firmwarePacakge content type. Client support for 736 the ct-firmwareLoadReceipt and ct-firmwareLoadError content types is 737 OPTIONAL, as per [RFC4108]. 739 For clients that support the Trust Anchor Management Protocol (TAMP) 740 [RFC5934], they MUST support the Certificate choice of the TA format 741 and MUST support the tamp-update content type [RFC5934]. 743 TO DO: Complete the following: 745 For clients that support certificate management packages with 746 centrally-generated keys, they MUST support ct-asymmetric-key-package 747 [RFC5958], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse 748 [RFC5272][RFC5912]. 750 5. Agents 752 Agents act on behalf of the client. Agents MUST support PAL 753 processing. 755 TO DO: Fill this out. 757 6. Electronic Serial Number 759 The Electronic Serial Number (ESN) is a permanent identifier that is 760 used to identify the client throughout its lifecycle. Certificates 761 include the ESN with the Hardware Module Name from [RFC4108] in the 762 Subject Alternative Name extension [RFC5280]. The hardware module 763 name form is an hwType (an object identifier) and hwSerialNumber 764 (octet string). The combination of the object identifier and octet 765 string guarantees global uniqueness. For example, a company uses 766 their private enterprise number they received from IANA and includes 767 their serial number the octet string. The KMS, clients, and agents 768 SHOULD support ESNs at least 8 octets in length. 770 7. Product Availability List 772 The PAL provides clients with: 774 o Advertisements for available packages and transactions that can 775 be retrieved from the KMS; 777 o Advertisement for another PAL. 779 TO DO: Add definition of Notification in Section 1.1. Need to 780 explain it's an exception the PAL including packages. 782 An example PAL is provided in Figure 4. The explanation of the 783 fields is explained in the subsequent text and sections. 785 786 787 788 TBD 789 00000000000000 790 1996 791 https://www.example.com/pki/12 792 793 794 100 795 00000000000000 796 0 797 DN of subject 798 799 800 TBD 801 00000000000000 802 2390 803 https://www.example.com/distribution/100 804 805 806 1 807 00000000000000 808 0 809 https://www.example.com/distribution/12345 810 811 813 Figure 4 - Example PAL 815 TO DO: Include legal encoding for DN in Figure 4. 817 PAL processing by clients is OPTIONAL, yet RECOMMENDED. PAL 818 retrieval can be performed by a client or by an agent that is 819 assisting the device. Agents that service clients which do not 820 process PALs, MUST process the PAL on behalf of the client. The 821 agent MUST retrieve and process the PAL from the KMS as well as the 822 packages advertised within the PAL. Once delivered to the agent, the 823 agent MUST provide the package to the target client in an 824 implementation specific manner. The method of delivery of the 825 package to the target client may or may not implement a PAL type 826 distribution mechanism. 828 When a client or agent requests a PAL, the KMS dynamically assembles 829 a PAL based on the current information and packages it has for the 830 requesting client or agent. The KMS servicing the request relies on 831 the knowledge of the requesting client's ESN, in order to amass the 832 proper list of items. 834 The following identifies the items for each KMS service the KMS could 835 include in a PAL for an identified Device: 837 o Publication: Anywhere from zero (0) to a maximum of i CA 838 certificates, client certificate, and CRLs or other issuers 839 offering public publications. 841 o Certificate: Anywhere from 0 to a maximum of j candidate entries 842 (i.e., pending certificate management transactions or certificate 843 notifications) where j <= the maximum number of certificates the 844 device can have. 846 o Distribution: Anywhere from zero (0) to a maximum of q packages 847 where q is less than or equal to the total number of 848 independently-deliverable keys, and bundled packages the client 849 is designed to accept. 851 An order of precedence for PAL offerings is based on the following 852 rationale: 854 o Publication packages are the most important because they support 855 validation decisions on certificates used to sign and encrypt 856 other listed PAL items. 858 o Certificate Management packages items are next in importance, 859 since they can impact an IA certificate used by the device to 860 sign CMS content or a KE certificate to establish keys for 861 encrypting content exchanged with the client. 863 * A client engaged in a certificate management should accept and 864 process CA-provided transactions as soon as possible to avoid 865 undue delays that might lead to protocol failure. 867 o Distribution packages containing keys and other types of products 868 are last. Precedence SHOULD be given to KMS packages that the 869 client has not previously downloaded. The items listed in a PAL 870 may not identify all of the packages available for a device. This 871 can be for any of the following reasons: 873 o The KMS may temporarily withhold some outstanding PAL items to 874 simplify client processing. 876 * Certificate Management PAL entries linked to a near-real-time 877 CA device protocol (i.e., not staged through intermediary media 878 devices or store and forward communication systems that may 879 significantly delay interactions) will be limited to one-at-a- 880 time. 882 * If a CA has more than one certificate ready to begin a 883 certificate management protocol with a client, the KMS will 884 provide a notice for one at a time. Pending notices will be 885 serviced in order of the earliest date when the certificate 886 will be used. 888 * The KMS will complete a certificate management activity for one 889 certificate, before beginning the process for another. At most 890 one pending certificate management transaction will be 891 advertised in the PAL at a time. 893 o A PAL is limited to a maximum of thirty-two entries. If more 894 than thirty-two entries are available for the client, additional 895 PALs will be identified in the last entry of the PAL. The first 896 PAL in the chain is identified as the Initial PAL. 898 o Packages will be removed when their contents are superseded or at 899 the direction of a KMS Manager. 901 The remainder of this section describes the PAL format and its use of 902 URIs. 904 7.1. PAL Format 906 The PAL furnishes information for KMS messages that are currently 907 available and authorized for retrieval by a client or an agent. The 908 PAL is used to identify the following information: 910 o The KMS Package type and unique package identifier of each 911 package available. 913 o The size of each package. 915 o The last time and date the device downloaded the data, if any. 917 o The presence of KMS notifications and the ancillary data the 918 client may need to respond to that notification. 920 o The availability of another PAL listing packages that were not 921 included on the current PAL. 923 o For those package delivered out of the KMS Distribution and KMS 924 Certificate Management Services, the KMS Service message type. 926 The initially offered PAL, will contain anywhere from zero to thirty- 927 two XML-encoded PAL entries following the XML Header. The PAL's XML 928 schema can be found in Section 12. Each PAL entry is composed of the 929 following four REQUIRED subcomponents: 931 o The Type subcomponent is provided for each PAL entry. The Type 932 uniquely identifies each KMS package defined within this 933 specification that a client may retrieve from KMS with a 4-digit 934 field. The Types are defined in Section 9 and registered in 935 Section 11. 937 o The Last Download Date subcomponent is provided for each PAL 938 entry. It is a 14-character field that contains either: 940 o The date and time (expressed as Generalized Time) that the client 941 last successfully downloaded the identified package from the KMS, 942 or 944 o All zeroes characters, if: 946 * There is no indication the device has successfully loaded the 947 identified KMS package, 949 o The PAL entry is a notification, or 951 o The PAL entry corresponds to a notification or pointer to a 952 next PAL. 954 o The Package Size subcomponent is provided for each PAL entry. If 955 the PAL entry is for a notification, this subcomponent will be 956 populated with a zero character. Otherwise, it indicates the 957 size of the identified package in bytes. The maximum size of 958 packages is 2.1 Gbytes. 960 o The Additional Information subcomponent will be provided for each 961 PAL entry and will either provide a Distinguished Name (DN) or a 962 URI of where the identified KMS package can be retrieved. When 963 the entry is a notification, the subcomponent is a DN that 964 identifies a certificate that is the subject of the notification. 966 When more than thirty-two PAL entries are available, an additional 967 PAL is advertised in the thirty second PAL entry. The additional PAL 968 will have between one and thirty-two PAL entries. 970 The Last Download Date MUST be represented in a form that matches the 971 dateTime production in "canonical representation" [XMLSCHEMA]. 972 Implementations SHOULD NOT rely on time resolution finer than 973 milliseconds and MUST NOT generate time instants that specify leap 974 seconds. 976 7.2. URIs 978 A client that supports the PAL will use URIs to obtain both the KMS 979 packages they need from the KMS, and to post device information KMS 980 requires. Clients that support PALs and agents MUST be capable of 981 using URIs [RFC3986]. 983 In order to GET or POST, the client or agent needs to have a 984 currently valid URI associated with that information. The URI can 985 correspond to: 987 o A PAL that provides a unique URI for each KMS package that the 988 KMS holds for the client and URIs identifying client actions that 989 need to be taken, or 991 o A KMS package that the client believes is being held by the KMS. 992 The data may contain product, a protocol-related transaction, or 993 a collection of packages with various contents. 995 When a client performs an HTTP POST operation, the URI indicates the 996 specific KMS Service that is targeted to process the information. A 997 client SHALL be capable of requesting information by providing a URI 998 in an HTTP GET request to a connected KMS. 1000 A client may know, or believe they know, a specific KMS package URI, 1001 because: 1003 o They discovered the URI on a PAL, 1005 o They are anticipating the next step in a protocol initiated by a 1006 prior URI submission, or 1008 o They were provided with the URI out-of-band by a human or an 1009 agent. Clients and agents MUST be capable of accepting a URI that 1010 uniquely identifies the location of a KMS Service package that is 1011 available for delivery. 1013 Clients and agents MUST be capable of accepting a URI that identifies 1014 an action that is to be taken by the client. 1016 In order to POST information, the client or agent supplies a URI that 1017 identifies associated information to the KMS. For example, the URI 1018 could correspond to a request to initiate, furnish intermediate 1019 results for, or conclude a certificate management protocol. 1021 Regardless of whether an HTTP GET or HTTP POST request is being made, 1022 URI components have consistent definitions and usage requirements. 1023 These are specified in the following subsections. Figure 5 provides 1024 a view of the URI components: 1026 scheme://Authority/Path/query|fragment 1027 | Host:Port | 1028 | | +---------+---------------+ 1029 | | | Path 1 | Path 2 (optional) 1030 | +- www.example.com | | 1031 +- https +- distribution +- unique package 1032 +- publication identifier 1033 +- certificate 1034 Figure 5 - PAL URI Components 1036 7.2.1. URI Scheme 1038 All HTTP GET and POST requests and responses MUST use "https" as the 1039 scheme [RFC2818]. All processing of scheme data will be case- 1040 insensitive as required in [RFC3986]. 1042 PALs that do not specify "https" as the URI scheme for every PAL 1043 entry MUST be rejected. 1045 7.2.2. URI Authority 1047 The authority component of a URI identifies the KMS that the client 1048 is requesting the specific KMS Service from. The authority component 1049 is in the form of a host name and an optional "https" port number. 1050 The host name identifies the HTTP server by name, and the port number 1051 identifies the HTTP server port that will service the request. 1052 Inclusion of the port number is OPTIONAL, as port 443 MUST be used. 1054 Clients and agents that access KMS Services are configured with the 1055 applicable registered name(s) or corresponding IP address(es) of the 1056 KMS with which they may establish a connection to. 1058 When generating a URI, the KMS SHALL populate the Authority Component 1059 of the URI with the registered name of the target KMS. 1061 When generating a URI, clients and agents SHALL populate the 1062 Authority Component of the URI with the registered name of the target 1063 KMS. 1065 Clients and agents SHALL reject the delivery of a received PAL, if 1066 any URI Authority Component contains a registered name that does not 1067 correspond to the connected KMS. 1069 7.2.3. URI Path 1071 The Path component of a URI identifies a resource that can be 1072 retrieved from, or a location that information can be posted to, at 1073 the KMS. Path components are presented in the hierarchical form of 1074 KMS Service Identifier followed by a Product Identifier. They adhere 1075 to the rules for path-absolute parsing as defined in [RFC3986]. 1077 Service Identifiers that constitute the first path (aka Path 1) 1078 segment in a URI received or generated by a device are listed below 1079 together will a brief description of their purpose: 1081 o distribution - This identifier is used for PALs, product 1082 packages, and bundled packages with one or more collections of 1083 content types as offered by the KMS Distribution Service. 1085 o publication - This identifier is used to obtain publicly- 1086 available CA, CRLs, and CPs as offered by the KMS Publication 1087 Service. 1089 o certificate - This identifier is used in PKI issuance and rekey 1090 protocols as offered by the KMS Certificate Management. 1092 The Product Identifier (aka Path 2), when present, is always the 1093 second path segment. It is formatted as an integer and represents 1094 the unique identifier the KMS has associated with the package to be 1095 retrieved. Message types are included in the Message Type registry 1096 found in Section 11. The Product Identifier is only present in the 1097 URIs that will be included in HTTP GET requests to obtain a package. 1098 The Product Identifier is not included in: 1100 o The URI a client uses to obtain the initial PAL, 1102 o The URI portion of a KMS Distribution Service PAL entry a KMS 1103 uses to point to other PALs beyond the initial PAL, 1105 o The KMS Certificate Service URIs that a KMS uses to provide 1106 the device notification for a suggested action, and 1108 o URIs that a device provides as a part of an HTTP POST request. 1110 A client SHALL reject the delivery of any PAL received that contains 1111 a URI with the first path component not equal to one of the following 1112 service names: 1114 o distribution, 1115 o pki, and 1116 o certificate. 1118 When generating a URI for the inclusion in a POST operation, a client 1119 SHALL only populate the first Path component of the URI. When 1120 generating a URI for the inclusion in a GET operation for the initial 1121 PAL, a client SHALL only populate the first Path component of the 1122 URI. When generating a URI, clients SHALL populate the first Path 1123 component of the URI with one of the service names defined by this 1124 specification. A client SHALL reject the delivery of any PAL received 1125 that contains a URI with the second path component not equal to an 1126 integer. 1128 7.2.4. URI Query and Fragments 1130 The KMS does not use Query and Fragment elements in support of KMS 1131 Services. They are not supported by clients in the processing of 1132 received URIs, or in the generation of URIs. 1134 The KMS MUST omit query and fragment components from PALs. 1136 The KMS SHOULD reject the delivery of any PAL that contains a URI 1137 with a query or fragment components. 1139 Clients and agents SHOULD reject the delivery of any PAL that 1140 contains a URI with a query or fragment component. 1142 When generating a URI, clients and agents MUST NOT populate the URI 1143 with any query or fragment components. 1145 8. SODP Transport Requirements 1147 This section provides the requirements for SODP interactions. 1149 8.1. KMS Requirements 1151 The KMS MUST support HTTP 1.1 [RFC2616]; the KMS MUST support 1152 generating HTTP GET and POST responses and receiving HTTP GET and 1153 POST requests; the KMS MUST support HTTPS [RFC2818] over TCP [RFC793] 1154 on port 443, and; the KMS MUST support both IPv4 [RFC791] and IPv6 1155 [RFC2460]. TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST be 1156 implemented in conjunction with HTTPS. To ensure only authorized 1157 clients and agents access the KMS, the KMS MUST support 1158 authentication with both client-side certificates and 1159 username/password. See Section 10 for cipher suite requirements. 1161 When the KMS receives and processes an HTTP request from a client, it 1162 will provide a response. HTTP responses include status information 1163 and may include a message body, when a request is successfully 1164 processed. The status information provided in responses to client 1165 requests will be restricted to the three-digit HTTP status code. 1167 HTTP response status codes fall into five general classes (where the 1168 class is indicated by the first digit of the code). 1170 o Informational - The KMS will not make use of the Informational 1171 class of status codes. Protocol switches and continued client 1172 processing are not expected. 1174 o Success - The KMS will return this class when the GET results in 1175 the requested information being returned or the POST action is 1176 successfully completed. 1178 o Redirection - The KMS will not make use of the Redirection class 1179 of status codes. The KMS will not ask a client to take further 1180 action to fulfill a request. 1182 o Client Error - The KMS will return this class when they cannot 1183 fulfill the requested GET or POST because of a client error. 1185 o Server Error - The KMS may return this class, when a valid POST 1186 or GET request was received, but the KMS cannot fulfill the 1187 request for other reasons. 1189 8.2. Client Requirements 1191 Clients MUST support HTTP 1.1 [RFC2616]; clients MUST support HTTP 1192 generating GET and POST requests and HTTP GET and POST responses; 1193 clients MUST support HTTPS [RFC2818] over TCP [RFC793] on port 443, 1194 and; clients MUST support either IPv4 [RFC791] or IPv6 [RFC2460] 1195 (IPv6 is preferred). TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST 1196 be implemented in conjunction with HTTPS. Clients MUST support 1197 client-side certificate authentication when connecting to the KMS. 1198 See Section 10 for cipher suite requirements. 1200 If a client receives an HTTP response with an Informational or 1201 Redirection class status code, it SHALL interpret the response as a 1202 request failure and terminate its session with the KMS. 1204 When an Informational or Redirection class status code is received, a 1205 client MAY, if configured for an alternate KMS, terminate the current 1206 session and attempt to connect with an alternate KMS to obtain the 1207 originally requested KMS Service. 1209 If a client receives an HTTP response with a Success class status 1210 code, it SHALL continue to process the response to determine the 1211 outcome of an HTTP POST request or to use the information contained 1212 in the included package. 1214 If a client receives an HTTP response with a Client Error class 1215 status code, it SHALL abandon the desired action and not repeat the 1216 same request to the same KMS during the connection session. 1218 The client can provide additional processing of Client Error class 1219 status codes for a given request; however, this is out-of-scope of 1220 this document. 1222 A client can attempt other (different) HTTP requests after a request 1223 that failed with a Client Error class status code. However, the 1224 client incorporate a means to limit the number of consecutive 1225 requests that fail for any reason in a given connection session with 1226 the KMS. 1228 If a client receives an HTTP response with a Server Error class 1229 status code, it SHOULD either: 1231 o Reattempt the request after a non-deterministic delay, or 1233 o Attempt the request with a different KMS. 1235 8.3. Agent Requirements 1236 Agent requirements are identical to those for clients with one 1237 exception and that is that agents MUST support either agent-side 1238 certificate authentication when connecting to the KMS or 1239 username/password. 1241 9. Message Sequences 1243 This section depicts message sequences when using a PAL. 1245 9.1. Distribution 1247 The KMS Distribution service instantiates itself with the 1248 distribution of symmetric key packages and firmware packages. The 1249 message types are defined as follows: 1251 Message Package 1252 Type 1253 -------- ------------- 1254 TBD Symmetric Key Package 1255 TBD Firmware Package 1257 An example PAL entry for a distribution package is as follows: 1259 1260 TBD 1261 00000000000000 1262 1996 1263 https://www.example.com/distribution/symmtrickey1 1264 1266 The message type TBD indicates the message is a symmetric key. The 1267 date and time indicates that the package has not been downloaded. The 1268 message size indicates the size of the package and the additional 1269 info element provides a link to the symmetric key. 1271 The sequence for both symmetric key and firmware packages is 1272 identical, as shown in Figure 6. The client or agent connects to the 1273 KMS, retrieves their PAL, and the requests the package from the URI 1274 provided in the additional info component. 1276 | | 1277 KMS | Establish HTTPS | Client or Agent 1278 | Connection | 1279 |<-------------------->| 1280 | | 1281 | Request PAL | 1282 | (HTTP GET) | 1283 |<---------------------| 1284 |--------------------->| 1285 | Deliver PAL with URI | 1286 | (HTTP GET Response) | 1287 | | 1288 | Request package by | 1289 | specified URI | 1290 | (HTTP GET) | 1291 |<---------------------| 1292 |--------------------->| 1293 | Deliver requested | 1294 | CMS package product | 1295 | (HTTP GET Response) | 1296 | | 1298 Figure 6 - SODP Distribution Service Message Sequence 1300 9.2. Publication 1302 The KMS Publication service instantiates itself with the distribution 1303 of additional certificates, CRLs, CPs, and CPSs. The message types 1304 are defined as follows: 1306 Message Package 1307 Type 1308 -------- ------------- 1309 TBD Root CRL 1310 TBD non-Root CRL 1312 TO DO: Add additional certificates, CPs, and CPSs. 1314 An example PAL entry for a publication package is as follows: 1316 1317 TBD 1318 00000000000000 1319 1996 1320 https://www.example.com/publication/Root.crl 1321 1323 The message type TBD indicates the message is a Root CRL. The date 1324 and time indicates that the package has not been downloaded. The 1325 message size indicates the size of the package and the additional 1326 info element provides a link to the Root CRL. The message sequence is 1327 identical to Figure 6. 1329 9.3. Certificate Management 1331 The KMS Certificate Management service instantiates itself with the 1332 distribution of notifications (i.e., start rekey), and CMC 1333 transactions. The message types are defined as follows: 1335 Message Package 1336 Type 1337 -------- ------------- 1338 100 IA Certificate Rekey Notification 1339 N/A IA Certificate Rekey Transaction One 1340 TBD IA Certificate Rekey Transaction Two (Success) 1341 TBD IA Certificate Rekey Transaction Two (Failure) 1342 TBD KE Certificate Issuance Notification 1343 N/A KE Certificate Issuance Transaction One 1344 TBD KE Certificate Issuance Transaction Two (Success) 1345 TBD KE Certificate Issuance Transaction Two (Failure) 1347 An example PAL entry for a publication package notification is as 1348 follows: 1350 1351 100 1352 00000000000000 1353 1996 1354 DN of IA certificate 1355 1357 TO DO: Get legal encoding of DN for IA certificate. 1359 The message type TBD indicates the message is a IA Certificate Rekey 1360 Notification. The date and time indicates that the package has not 1361 been downloaded. The message size indicates the size of the package 1362 and the additional info element provides a link to the rekey 1363 notification. 1365 The message sequence for certificate rekey and issuance is a three- 1366 step process. The initial step is client/agent retrieval of the PAL 1367 and then retrieval of a notification for either IA rekey or KE 1368 issuance. Step two is the client/agent posting of the CMC package. 1369 Step three is certificate request response (success or failure) from 1370 the KMS. Prior to each interaction with the KMS, the client/agent 1371 authenticates itself with the KMS. The three steps are depicted in 1372 Figures 7-9. 1374 Step 1 1376 KMS | Establish HTTPS | Client or Agent 1377 | Connection | 1378 |<-------------------->| 1379 | | 1380 | Request PAL | 1381 | (HTTP GET) | 1382 |<---------------------| 1383 |--------------------->| 1384 | Deliver PAL with URI | 1385 | (HTTP GET Response) | 1386 | | 1387 | Request IA | 1388 | Certificate Rekey | 1389 | Transaction One | 1390 | (HTTP GET) | 1391 |<---------------------| 1392 |--------------------->| 1393 | Deliver Transaction | 1394 | One | 1395 | (HTTP GET Response) | 1397 Figure 7 - SODP Certificate Management Service 1398 Message Sequence - Step 1 1400 Step 2 1402 KMS | Establish HTTPS | Client or Agent 1403 | Connection | 1404 |<-------------------->| 1405 | | 1406 | Deliver Transaction | 1407 | Two | 1408 | (HTTP POST) | 1409 |<---------------------| 1410 |--------------------->| 1411 | (HTTP Post Response) | 1413 Figure 8 - SODP Certificate Management Service 1414 Message Sequence Step 2 1415 Step 3 1417 KMS | Establish HTTPS | Client or Agent 1418 | Connection | 1419 |<-------------------->| 1420 | | 1421 | Request PAL | 1422 | (HTTP GET) | 1423 |<---------------------| 1424 |--------------------->| 1425 | Deliver PAL with URI | 1426 | (HTTP GET Response) | 1427 | | 1428 | Request IA | 1429 | Certificate Rekey | 1430 | Transaction Three | 1431 | (HTTP GET) | 1432 |<---------------------| 1433 |--------------------->| 1434 | Deliver Transaction | 1435 | Three | 1436 | (HTTP GET Response) | 1438 Figure 9 - SODP Certificate Management Service 1439 Message Sequence Step 3 1441 10. Cryptographic Algorithm Requirements 1443 This section defines the cryptographic algorithm requirements for 1444 SODP. There are three types: package protection requirements, TLS 1445 cipher suites, and certificate requirements. 1447 10.1. Package Protection 1449 For [RFC5958] algorithm requirements see [RFC5959]. 1451 For [RFC6031] algorithm requirements see [I-D.turner-cms- 1452 symmetrickeypackage-algs]. 1454 For [RFC6032] algorithm requirements see [RFC6033]. 1456 NOTE: The "cert-only" package does not have algorithm requirements 1457 because no cryptographic operations are performed while generating 1458 this package. 1460 TO DO: Include text or reference(s) for the following: 1462 For [RFC4108][RFC5911] algorithm requirements see [TO DO]. 1464 For [RFC5934] algorithm requirements see [TO DO]. 1466 For [RFC5280] algorithm requirements see [TO DO]. 1468 10.2. TLS Cipher Suites 1470 The following requirements apply to the KMS, client, and agent: 1472 o Cipher suites supported MUST include: "TLS_RSA_WITH_", "TLS_DH_", 1473 "TLS_DHE_", and "TLS_ECDH_". 1475 o Cipher suites that include "anon" MUST NOT be used. These suites 1476 do not support mutual authentication. 1478 o Cipher suite that include "EXPORT" and "DES" MUST NOT be used. 1479 These ciphers do not offer a sufficient level of protection; 40- 1480 bit crypto in '11 doesn't cut the mustard and the use of DES is 1481 deprecated. 1483 o When confidentially is supported (recall that is optional), the 1484 "AES_128" ciphers MUST be supported and "AES_256" cipher SHOULD 1485 be supported. 1487 o Cipher suites that include "SHA256" MUST be supported and 1488 "SHA384" SHOULD be supported. 1490 10.3. Certificates 1492 Client, agents, and the KMS MUST support certificate path validation 1493 on key packages and TLS connections [RFC5280]. 1495 TO DO: Need to add text that lines up algorithm requirements for 1496 packages with certificates. Also add CCC [RFC6010] as an OPTIONAL 1497 extension for source authorities. 1499 11. Security Considerations 1501 TO DO: Expand this section! 1503 This document relies on many other specifications. For IP and TCP 1504 security considerations see [RFC791], [RFC793], and [RFC2460]; for 1505 HTTP, HTTPS, and TLS security considerations see [RFC2616], 1506 [RFC2818], and [RFC5246]; for URI security considerations see 1507 [RFC3986]; for content type security considerations see [RFC4073], 1508 [RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5958], [RFC5934], 1509 [RFC6031], and [RFC6032]; for certificate security considerations see 1511 [RFC5280], [RFC5480], and [RFC6010], and; for algorithm security 1512 considerations see [RFC5959], [RFC6033], 1513 [I-D.turner-cms-symmetrickeypackage-algs]. 1515 TO DO: Probably more references are needed above for algorithms based 1516 on what gets added in Section 9.1. 1518 It is critical that the KMS encrypt symmetric keys and centrally- 1519 generated asymmetric private keys for the end client. Failure 1520 encrypt these keys will allow any intermediaries to intercept the key 1521 and eavesdrop and/or impersonate the client. 1523 When packages are encrypted, the source of the package must randomly 1524 generate package-encryption keys. Also, the generation of 1525 public/private signature key pairs relies on a random numbers. The 1526 use of inadequate pseudo-random number generators (PRNGs) to generate 1527 cryptographic keys can result in little or no security. An attacker 1528 may find it much easier to reproduce the PRNG environment that 1529 produced the keys, searching the resulting small set of 1530 possibilities, rather than brute-force searching the whole key space. 1531 The generation of quality random numbers is difficult. [RFC4086] 1532 offers important guidance in this area. 1534 12. IANA Considerations 1536 IANA is requested to perform four registrations: SODP Name Space, 1537 SODP XML Schema, SODP Message Types, and SODP URI String Types. 1539 12.1. SODP Name Space 1541 This section registers a new XML namespace, 1542 "urn:ietf:params:xml:ns:TBD" per the guidelines in [RFC3688]: 1544 TO DO: Fill in TBDs. 1546 URI: urn:ietf:params:xml:ns:TBD 1547 Registrant Contact: Sean Turner (turners@ieca.com) 1548 XML: 1549 BEGIN 1550 1551 1553 1554 1555 SODP Messages 1556 1557 1558

Namespace for SODP Messages

1559

urn:ietf:params:xml:ns:TBD

1560

See TBD

1561 1562 1563 END 1565 12.2. SODP Schema 1567 This section registers an XML schema as per the guidelines in 1568 [RFC3688]. 1570 TO DO: Fill in TBDs. 1572 URI: urn:ietf:params:xml:ns:TBD 1573 Registrant Contact: Sean Turner turners@ieca.com 1574 XML: 1575 1576 1582 1584 1586 1588 1589 1590 1592 1593 1594 1596 1597 1598 1599 1600 1601 1602 1603 1605 1606 1607 1608 1609 1610 1611 1613 1614 1615 1616 1617 1619 1620 1621 1622 1623 1624 1626 1627 1628 1630 1632 12.3. SODP Message Types 1634 This section registers the SODP Message Types. SODP Message Types 1635 registrations are to be subject to Specification Required, as per RFC 1636 5226 [RFC5226]. The registry has the following values: 1638 +-------+--------------------------------+---------------+ 1639 | Value | Message Type | Specification | 1640 +-------+--------------------------------+---------------+ 1641 | 0 | Reserved | This document | 1642 +-------+--------------------------------+---------------+ 1643 | 1 | Additional PAL value present | This document | 1644 +-------+--------------------------------+---------------+ 1645 | 100 | IA Rekey Notification | This document | 1646 +-------+--------------------------------+---------------+ 1647 | TBD | Symmetric Key Package | This document | 1648 +-------+--------------------------------+---------------+ 1649 | TBD | Firmware Package | This document | 1650 +-------+--------------------------------+---------------+ 1651 | TBD | Root CRL | This document | 1652 +-------+--------------------------------+---------------+ 1653 | TBD | non-Root CRL | This document | 1654 +-------+--------------------------------+---------------+ 1655 | TBD | IA Certificate Rekey | This document | 1656 | | Transaction Two - Success | | 1657 +-------+--------------------------------+---------------+ 1658 | TBD | IA Certificate Rekey | This document | 1659 | | Transaction Two - Fail | | 1660 +-------+--------------------------------+---------------+ 1661 | TBD | KE Certificate Issuance | This document | 1662 | | Transaction One | | 1663 +-------+--------------------------------+---------------+ 1664 | TBD | KE Certificate Issuance | This document | 1665 | | Transaction Three - Success | | 1666 +-------+--------------------------------+---------------+ 1667 | TBD | KE Certificate Issuance | This document | 1668 | | Transaction Three - Fail | | 1669 +-------+--------------------------------+---------------+ 1671 TO DO: Add values from Section 9 to the above table. 1673 12.4. SODP Path 1 String Values 1675 This section registers SODP Path String Types as per [RFC3688]. SODP 1676 Path 1 String Value registrations are to be subject to Specification 1677 Required, as per RFC 5226 [RFC5226]. The registry has the following 1678 structure: 1680 +----------------------------------------+ 1681 | SODP Message Types | Specification | 1682 +----------------------------------------+ 1683 | distribution | This document | 1684 +----------------------------------------+ 1685 | publication | This document | 1686 +----------------------------------------+ 1687 | certificate | This document | 1688 +----------------------------------------+ 1690 TO DO: Verify that specification required is appropriate. 1692 13. IANA Considerations 1694 None. Please remove this section prior to publication as an RFC. 1696 14. References 1698 14.1. Normative References 1700 [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet 1701 Program Protocol Specification", RFC 791, September 1981. 1703 [RFC793] Postel, J. (ed.), "Transmission Control Protocol," RFC 793, 1704 September 1981. 1706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1707 Requirement Levels", BCP 14, RFC 2119, March 1997. 1709 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 1710 (IPv6) Specification," RFC 2460, December 1998. 1712 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1713 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer 1714 Protocol -- HTTP/1.1", RFC 2616, June 1999 1716 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1718 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1719 January 2004. 1721 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1722 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1723 3986, January 2005. 1725 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1726 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1728 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1729 Protect Firmware Packages", RFC 4108, August 2005. 1731 [RFC5226] Naten, T., and H. Alvestrand, "Guidelines for Writing an 1732 IANA Considerations Section in RFCs", RFC 5226, May 2008. 1734 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1735 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1737 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1738 Housley, R., and W. Polk, "Internet X.509 Public Key 1739 Infrastructure Certificate and Certificate Revocation List 1740 (CRL) Profile", RFC 5280, May 2008. 1742 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R. and T. Polk, 1743 "Elliptic Curve Cryptography Subject Public Key 1744 Information", RFC 5480, March 2009. 1746 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1747 RFC 5652, September 2009. 1749 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1750 (CMC)", RFC 5272, June 2008. 1752 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1753 Mail Extensions(S/MIME) Version 3.2 Message Specification", 1754 RFC 5751, January 2010. 1756 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 1757 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 1758 June 2010. 1760 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1761 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1762 June 2010. 1764 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1765 Management Protocol (TAMP)", RFC 5934, August 2010. 1767 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1768 2010. 1770 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Packages", RFC 1771 5959, August 2010. 1773 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 1774 Message Syntax (CMS) Content Constraints Extension", RFC 1775 6010, September 2010. 1777 [RFC6031] Turner, S., and R. Housley, "Symmetric Key Package Content 1778 Type", RFC 6031, December 2010. 1780 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 1781 (CMS) Encrypted Key Package Content Type", RFC 6032, 1782 December 2010. 1784 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 1785 (CMS) Encrypted Key Package Content Type", RFC 6033, 1786 December 2010. 1788 [I-D.tls-ssl2-must-not] 1789 Turner, S., and T. Polk, "Prohibiting SSL Version 2.0", 1790 draft-ietf-tls-ssl2-must-not, work-in-progress. 1792 [I-D.turner-cms-symmetrickeypackage-algs] 1793 Turner, S., "Algorithms for Cryptographic Message Syntax 1794 (CMS) Protection of Symmetric Key Package Content Types", 1795 draft-turner-cms-symmetrickeypackage-algs, work-in- 1796 progress. 1798 [XMLSCHEMA] 1799 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1800 Second Edition", World Wide Web Consortium Recommendation 1801 REC-xmlschema-2-20041082, October 2004, 1802 . 1804 [TO DO] Insert references for Section 9.1. 1806 14.2. Informative References 1808 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 1809 "Randomness Requirements for Security", BCP 106, RFC 4086, 1810 June 2005. 1812 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1813 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1815 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 1816 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1817 September 2010. 1819 [XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in 1820 XML", World Wide Web Consortium FirstEdition REC-xml-names- 1821 19990114, January 1999, . 1824 Appendix A. Example Encodings 1826 TO DO: Include BASE64 encodings of ASN.1 encodings of selected 1827 packages. They're a lot smaller than the ASN.1 pretty prints and 1828 there are tons of available to tools to convert. 1830 Authors' Addresses 1832 Sean Turner 1833 IECA, Inc. 1834 3057 Nutley Street, Suite 106 1835 Fairfax, VA 22031 1836 USA 1838 EMail: turners@ieca.com