idnits 2.17.00 (12 Aug 2021) /tmp/idnits15691/draft-turner-sodp-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4108], [RFC5280], [RFC5934], [RFC5958], [RFC6031], [RFC5272]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 297 has weird spacing: '...package the c...' -- The document date (January 10, 2012) is 3777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6268' is mentioned on line 198, but not defined == Missing Reference: 'ID.turner-ct-keypackage-receipt-n-error' is mentioned on line 718, but not defined == Missing Reference: 'RFC791' is mentioned on line 1559, but not defined == Missing Reference: 'RFC793' is mentioned on line 1559, but not defined == Missing Reference: 'RC6160' is mentioned on line 1566, but not defined == Unused Reference: 'RFC4880' is defined on line 1904, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 1907, but no explicit reference was found in the text == Unused Reference: 'XMLNS' is defined on line 1911, 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 3023 (Obsoleted by RFC 7303) ** 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSCHEMA' == Outdated reference: draft-ietf-pkix-est has been published as RFC 7030 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 10 errors (**), 0 flaws (~~), 11 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 January 10, 2012 5 Expires: July 13, 2012 7 Secure Object Delivery Protocol (SODP) 8 draft-turner-sodp-02.txt 10 Abstract 12 This document describes the Secure Object Delivery Protocol (SODP). 13 SODP enables clients to obtain secured packages from a Secure Object 14 Management System (SOMS). Packages supported by a SOMS server 15 include but are not limited to: firmware packages [RFC4108], trust 16 anchor (TA) packages [RFC5934], symmetric key packages [RFC6031], 17 asymmetric key packages [RFC5958], encrypted key packages [RFC6031], 18 public key certificate enrollment packages [RFC5272], public key 19 certificates [RFC5280], and Certificate Revocation Lists (CRLs) 20 [RFC5280]. Client access is ideally direct and web-based, but access 21 via agents acting on behalf of clients is supported. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2. Secure Object Management System Model . . . . . . . . . . . . 6 61 3. Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. Server Package Requirements . . . . . . . . . . . . . . . 9 63 3.1.1. URI: /certificates . . . . . . . . . . . . . . . . . . 9 64 3.1.2. URI: /fullCMC . . . . . . . . . . . . . . . . . . . . 10 65 3.1.3. URI: /crls . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1.4. URI: /symmetricKey . . . . . . . . . . . . . . . . . . 11 67 3.1.5. URI: /firmware . . . . . . . . . . . . . . . . . . . . 12 68 3.1.6. URI: /tamp . . . . . . . . . . . . . . . . . . . . . . 13 69 3.1.7. Mixed Packages . . . . . . . . . . . . . . . . . . . . 13 70 3.2. Server Authentication Requirements . . . . . . . . . . . . 13 71 4. Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1. Client Package Requirements . . . . . . . . . . . . . . . 14 73 4.1.1. URI: /certificates . . . . . . . . . . . . . . . . . . 14 74 4.1.2. URI: /fullCMC . . . . . . . . . . . . . . . . . . . . 14 75 4.1.3. URI: /crls . . . . . . . . . . . . . . . . . . . . . . 15 76 4.1.4. URI: /symmetricKey . . . . . . . . . . . . . . . . . . 15 77 4.1.5. URI: /firmware . . . . . . . . . . . . . . . . . . . . 16 78 4.1.6. URI: /tamp . . . . . . . . . . . . . . . . . . . . . . 17 79 4.1.7 Mixed Packages . . . . . . . . . . . . . . . . . . . . 17 80 4.2. Authentication Requirements . . . . . . . . . . . . . . . 17 81 5. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 6. Universal Unique Identifiers . . . . . . . . . . . . . . . . . 18 83 7. Product Availability List . . . . . . . . . . . . . . . . . . 18 84 7.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 7.2.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . 23 87 7.2.2. URI Authority . . . . . . . . . . . . . . . . . . . . 23 88 7.2.3. URI Path . . . . . . . . . . . . . . . . . . . . . . . 24 89 7.2.4. URI Query and Fragments . . . . . . . . . . . . . . . 24 90 8. SODP Transport Requirements . . . . . . . . . . . . . . . . . 25 91 8.1. Server Requirements . . . . . . . . . . . . . . . . . . . 25 92 8.2. Client Requirements . . . . . . . . . . . . . . . . . . . 26 93 8.3. Agent Requirements . . . . . . . . . . . . . . . . . . . . 27 94 9. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 27 95 9.1. /certificates Package Types and Message Sequence . . . . . 27 96 9.2. /crls Package Type and Message Sequence . . . . . . . . . 27 97 9.3. /fullCMC Package Types and Message Sequence . . . . . . . 28 98 9.4. /symmetricKey Package Types and Message Sequences . . . . 30 99 9.5. /firmware Package Type and Message Sequences . . . . . . . 31 100 9.5. /tamp Message Types and Sequence . . . . . . . . . . . . . 32 101 10. Cryptographic Algorithm Requirements . . . . . . . . . . . . 32 102 10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32 103 10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . . 33 104 10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 106 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 107 12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . . 35 108 12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . . 35 109 12.3. SODP Package Types . . . . . . . . . . . . . . . . . . . 36 110 12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . . 37 111 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 112 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 114 14.2. Informative References . . . . . . . . . . . . . . . . . 41 115 Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 41 116 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 42 117 B.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . . 42 118 B.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . . 42 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 121 1. Introduction 123 The Secure Object Delivery Protocol (SODP) enables clients to obtain 124 secured packages from a Secure Object Management System (SOMS) 125 server. Packages supported by a SOMS server include but are not 126 limited to: firmware packages [RFC4108], Trust Anchor (TA) packages 127 [RFC5934], symmetric key packages [RFC6031], asymmetric key packages 128 [RFC5958], encrypted key packages [RFC6033], public key certificate 129 management packages [RFC5272], public key certificates [RFC5280], and 130 Certificate Revocation Lists (CRLs) [RFC5280]. Some are the end 131 product of multiple client-server interactions while some are simply 132 made by or on behalf of the SOMS for the client. All packages are at 133 a minimum digitally signed and some may be encrypted. Client 134 interactions with a SOMS server is via the HyperText Transfer 135 Protocol (HTTP) 1.1 [RFC2616] over Transport Security Layer (TLS) 136 [RFC5246] (HTTPS) [RFC2818]. Clients can directly access the SOMS or 137 an agent can act on the client's behalf. 139 A SOMS server provides access to packages based on Universal Resource 140 Identifiers (URIs) [RFC3986]. The Enrollment over Secure Transport 141 (EST) [ID.pkix-est] provides a framework that this document expands. 142 In addition, this document provides a mechanism, called a Product 143 Availability List (PAL), by which a client can be informed of the 144 location of all of its packages. Processing the packages in the 145 provided order ensures the client is provided the packages necessary 146 for it to operate. 148 1.1 Definitions 150 Terms are defined below as they are used in this document. They are 151 presented in alphabetical order. 153 Agent: An entity that performs functions on behalf of a client. 155 Asymmetric Key Package: A package that includes an asymmetric key 156 content type [RFC5958]. 158 Centrally-Generated Asymmetric Keys: Server-generated asymmetric key 159 pairs. Server provides both private key and public key certificate 160 in an asymmetric key package [ID.pkix-cmc-serverkeygeneration]. 162 Client: A cryptographic device/module that ultimately consumes and 163 uses the SOMS' products to enable communications. 165 Encrypted Key Package: A package that includes an encrypted key 166 content type [RFC6032]. 168 Firmware Package: A package that contains a firmware content type 169 [RFC4108][RFC5911]. 171 NOTE: [RFC4108] defines the semantics for the firmware content 172 type's fields. [RFC5911] provides the 2002 ASN.1 definitions. 173 Henceforth when referring to Firmware Packages only [RFC4108] will 174 be used. 176 Locally-Generated Asymmetric Key: Client-generated asymmetric key 177 pairs. Client provides the public key to the server for enrollment. 179 Notifications: Special entries in a PAL that tell the client to 180 initiate an action at the server (e.g., begin a certificate rekey). 182 Package: An object that contains one or more CMS content types. At a 183 minimum, all packages are protected using the CMS [RFC5652][RFC6268] 184 SignedData structure. There are numerous types of packages: 185 Asymmetric Key, Certificate Revocation Lists, Public Key Certificate 186 Management, Encrypted Key, Firmware, Public Key Certificates, and 187 Symmetric Key Packages. The notable exception to the CMS SignedData 188 rule are public key certificates and CRLs; these are not always 189 protected by CMS because they've already been signed by the 190 Certification Authority (CA). They can however be included in a 191 package that is protected using SignedData, which is often referred 192 to as a degenerate CMS or "certs-only" message [RFC5751][RFC6268]. 194 NOTE: This document does not define any packages; they are all 195 defined elsewhere. 197 NOTE: [RFC5652] defines the semantics for the SignedData content 198 type's fields. [RFC6268] provides the 2008 ASN.1 definitions. 199 Henceforth when referring to CMS SignedData only [RFC5652] will be 200 used and when referring to "certs-only" messages only [RFC5751] 201 will be used. 203 Product Availability List (PAL): A PAL is an XML (Extensible Markup 204 Language) [XML] file that furnishes information for packages that are 205 currently available and authorized for retrieval by a client or 206 agent. 208 NOTE: The exception to this are Notifications. 210 Public Key Certificate Management Packages: A package that contains a 211 Public Key Infrastructure (PKI) Data or a PKI Data Response content 212 type [RFC5272][RFC5912][RFC5273][RFC5274]. 214 NOTE: [RFC5272] defines the semantics for the PKI Data and Data 215 Response content types' fields. [RFC5912] provides the 2002 ASN.1 216 definitions. [RFC5273] defines the HTTP binding for CMC. 217 [RFC5274] defines the support requirements for CMC. Henceforth 218 when referring to CMC only [RFC5272] will be used. 220 Secure Object Management System (SOMS): A set of one or more 221 components that is designed to protect, manage, and distribute 222 cryptographic products. In this document, cryptographic products are 223 referred to as packages. 225 Source Authority: A source authority is trusted by clients to 226 generate particular package types. Clients determine this by 227 validating the digital signature on the package back to a Trust 228 Anchor (TA). 230 Symmetric Key Package: A package that contains a symmetric key 231 content type [RFC6031]. 233 Trust Anchor (TA): From [RFC5914], a TA contains a public key that is 234 used to validate digital signatures. In this document, a TA 235 represents an authoritative entity via a public key and associated 236 data. The public key is used to verify digital signatures and the 237 associated data is used to constrain the types of information for 238 which the TA is authoritative. A relying party uses TAs to determine 239 if a digitally signed object is valid by verifying a digital 240 signature using the TA's public key, and by enforcing the constraints 241 expressed in the associated data for the TA. 243 1.2 Key Words 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 247 "OPTIONAL" in this document are to be interpreted as described in 248 [RFC2119]. 250 2. Secure Object Management System Model 252 Figure 1 depicts the SODP model. It is comprised of three entities: 253 the SOMS server, one or more clients, and agents acting on behalf of 254 clients. Server-to-client and server-to-agent protocol interactions 255 are in-scope; agent-to-client protocol interactions are out-of-scope. 257 <===> IP-Based Protocol Profile (in scope) 258 <- -> Client-Specified Access Protocol (out of scope) 260 +-------------+ 261 | | 262 | Secure | 263 | Object | 264 | Management | 265 | System | 266 | | 267 | +-------+ | +----------+ 268 | |A's PAL| |<=====================>| Client A | 269 | +-------+ | +----------+ 270 | | 271 | +-------+ | +-------+ 272 | |B's PAL| | | | +----------+ 273 | +-------+ | | |<- - ->| Client B | 274 | | | Agent | +----------+ 275 | +-------+ | | | 276 | |C's PAL| | | | +----------+ 277 | +-------+ | | |<- - ->| Client C | 278 | |<=====>| | +----------+ 279 | . . | | | 280 | . . | | | . . 281 | . . | | | . . 282 | | | | . . 283 | +-------+ | | | 284 | |Z's PAL| | | | +----------+ 285 | +-------+ | | |<- - ->| Client Z | 286 | | | | +----------+ 287 +-------------+ +-------+ 289 Figure 1 - SODP Model 291 While the SOMS is viewed as being a single entity, operationally the 292 issuance of different packages can be assigned to different 293 authorities within the SOMS. These authorities are referred to as 294 source authorities. A source authority is trusted by clients to 295 generate particular package types. Entities validate their source 296 authorities when validating the digital signature(s) in/on packages. 297 That is, when a client retrieves a package the client ensures that 298 the signatures in/on the package validate to an installed trust 299 anchor (TA). 301 Figure 2 depicts an example ladder diagram for a protocol flow. The 302 first step is to establish a mutually authenticated HTTPS connection 303 between the client/agent and a SOMS server. The client then requests 304 their PAL, which is an XML file that contains URIs for client 305 packages, from the SOMS server via an HTTPS GET request. The server 306 replies with the client's PAL via an HTTPS GET response. Once a 307 client has successfully downloaded their PAL, it will process it to 308 retrieve the included packages(s). The processing provided will 309 depend on the PAL entry. Section 3 details the SOMS-package 310 requirements, Section 4 details clients-package requirements, and 311 Section 5 details agent-package requirements. Section 7 details the 312 PAL requirements. 314 | | 315 SOMS Server | Establish HTTPS | Client or Agent 316 | Connection | 317 |<-------------------->| 318 | | 319 | Request PAL | 320 | (HTTPS GET) | 321 |<---------------------| 322 |--------------------->| 323 | Deliver PAL with URI | 324 | (HTTPS GET Response) | 325 | | 326 | Request packages by | 327 | specified URI | 328 | (HTTPS GET) | 329 |<---------------------| 330 |--------------------->| 331 | Deliver requested | 332 | CMS package product | 333 | (HTTPS GET Response) | 334 | | 336 Figure 2 - Example SODP Message Sequence 338 3. Server 340 The SODP is the interface to the SOMS that clients use to access 341 SOMS-provided packages on a SOMS server. The internal components of 342 the SOMS server and their interactions are out-of-scope. However, if 343 a SOMS provides all of the packages, it will need the capability to 344 package trust anchors (TAs), generate and package symmetric keys, 345 package firmware, generate and package asymmetric keys, issue and 346 package public key certificates, and issue and package CRLs. It will 347 also need to generate and receive packages, which includes generating 348 and verifying digital signatures on packages as well as encrypting 349 and decrypting of packages. Additionally, it will need a repository 350 to store information about clients and to store the client's 351 packages. 353 Prior to interaction with the SOMS, the client needs to be registered 354 with the SOMS. During registration, information about the client is 355 collected an identity is assigned, which at a minimum includes an 356 identifier. There are only two registration requirements: 358 o The information collected MUST include a permanent identifier 359 that is used to identify the client throughout its lifecycle. 360 See Section 6. 362 o The SOMS MUST ensure that the client identity is SOMS-unique. 363 That is, the collection of data that comprises the client 364 identity MUST NOT match another client served by the SOMS. 366 The SOMS server MUST support the generation of a PAL. The SOMS 367 server MUST support access to client packages directly and through a 368 PAL. 370 After the client is registered the client is issued a public key 371 certificate [RFC5280]. 373 NOTE: 1) The process for delivering the certificate to the client 374 is out-of-scope; 2) the format and protocol for communicating the 375 registration data is out-of-scope; and 3) the client need not 376 contribute to or respond to the supplied identity information. 378 The remainder of this section describes the SOMS server package 379 requirements and the SOMS server authentication requirements. 381 3.1. Server Package Requirements 383 SOMS servers provide packages based on a URI. EST [ID.pkix-est] 384 defines 4 URIs. This document makes use of two defined therein (i.e, 385 /certificates, /simpleEnroll, /simpleReEnroll, and /fullCMC) but this 386 document specifies additional URIs: /crls, /symmetricKey, /firmware, 387 and /tamp. There are no additional requirements on /simpleEnroll and 388 /simpleReEnroll. 390 NOTE: I've suggested /crls be added to EST so if it's adopted 391 there it'll come out of here. 393 NOTE: I also suggested collapsing /simpleEnroll and 394 /simpleEnrollment in to one URI. 396 3.1.1. URI: /certificates 398 NOTE: The URI defined in EST -02 is /CACerts. As you might guess 399 the URI is used to distribute CA certificates. I think it ought 400 to be expanded to include arbitrary EE certificates. Therefore at 401 some point the name of this URI might change based on whether or 402 not the comment is accepted. 404 NOTE: I've also suggested that the /certificates (or whatever it 405 ends up being called) supports "certs-only" packages. If it's 406 adopted, then I'd take it out of here. 408 Servers use the /certificates URI to deliver CA certificates that a 409 client needs to validate package contents as well as EE certificates 410 that the client might need when communicating with other clients. 411 See section 5.1 of [ID.pkix-est]. 413 Certificates can also be in a "certs-only" package [RFC5751], which 414 is a CMS SignedData with no content just certificates. The SOMS 415 server MUST support the "certs-only" package by replying to the HTTPS 416 GET request with an HTTPS GET response that includes an HTTP Content- 417 Type of application/pkcs7-mime and a file type of .p7c, [RFC5751]. 419 Servers MUST support the /certificates URI. 421 3.1.2. URI: /fullCMC 423 NOTE: A comment has been entered to rename this URI in EST as 424 /fullEnrollment to line up better with /simpleEnrollment. Just 425 saying the name might change. 427 Servers use the /fullCMC URI to perform public key certificate 428 management using the Certificate Management over CMS (CMC) [RFC5272] 429 with Full PKI Request and Responses. SOMS servers MUST use the HTTP 430 binding defined in [RFC5273]. As a result, SOMS servers must 431 support: 433 o Receiving HTTPS POST requests with an HTTP Content-Type of 434 application/pkcs7-mime that contains a ct-PKIData encapsulated in 435 an ct-signed-data content type 437 o Generating HTTPS POST response with an HTTP Content-Type of 438 application/pkcs7-mime that contains a ct-PKIResponse 439 encapsulated in an ct-signed-data content type. 441 SOMS servers MUST support locally-generated keys. SOMS servers that 442 support centrally-generated keys MUST support [ID.pkix-cmc- 443 serverkeygeneration]. 445 The server MUST support validating signatures on /fullCMC packages 446 back to a TA [RFC5652][RFC5280]. 448 Servers MUST support the /fullCMC URI. 450 3.1.3. URI: /crls 452 Servers use the /crls URI to distribute CRLs, which are necessary to 453 validate certification paths back to a TA. Clients are however free 454 to elect to obtain the CRLs that they rely on from sources other than 455 the SOMS (e.g., a local directory). 457 CRLs are offered in the form, or forms, produced by the responsible 458 Certification Authority (CA). The form of the CRL is transparent to 459 the SOMS. CAs may choose to publish compact versions of CRLs (e.g., 460 partitioned CRLs) that are compatible with a disadvantaged client 461 within the overall subscriber population. 463 Servers MUST support receiving HTTPS GET requests and MUST support 464 generating HTTPS GET responses for CRLs. SOMS servers MUST support 465 returning CRLs: 467 o The HTTP Content-Type [RFC2616] is application/pkix-crl and a 468 file type of .crl [RFC2585], which contains a single CRL. 470 o The HTTP Content-Type [RFC2616] is application/pkcs7-mime and a 471 file type of .p7c [RFC5751], which contains either a single CRL 472 or multiple CRLs. 474 The PAL provided to a client will always contain a URI for the most 475 current version of each CRL needed to verify the packages in the form 476 used by the particular client. The SOMS will not list CRLs that a 477 client does not need or cannot use. Based on its capabilities, the 478 freshness of currently held CRLs, and the circumstances, the client 479 will determine whether it needs to download each offered CRL. 481 Servers MUST support the /crls URI. 483 3.1.4. URI: /symmetricKey 485 Servers use the /symmetricKey URI to distribute symmetric key 486 packages to clients and to receive receipts and errors about the 487 distributed symmetric key packages. Symmetric key packages are 488 defined in [RFC6031]. A symmetric key package can contain one or 489 more symmetric keys. It also can contain attributes that apply to 490 one or more keys. The SOMS server MUST encapsulate the ct-symmetric- 491 key-package content type in a ct-signed-data content type [RFC5652]. 493 Distribution of the symmetric key packages requires that these keys 494 be disclosed only to the client and to not to anyone else. The key 495 packages need to be enveloped. The encrypted key package [RFC6032] 496 supports encrypting key packages in one of three ways: with key 497 exchange algorithms (i.e., using EnvelopedData), with previously 498 distributed symmetric algorithms (i.e., using EncryptedData), and 499 with authenticated-encryption algorithms (i.e., using 500 AuthEnvelopedData). The server MUST support the ct-encrypted-key- 501 package content type and as specified in [RFC6032] the EnvelopedData 502 choice must be supported (i.e., support ct-enveloped-data). The 503 serer MUST also encapsulate the ct-encrypted-key-package in a ct- 504 signed-data content type. 506 Servers MUST support processing HTTPS GET requests and MUST support 507 generating HTTPS GET responses for key packages. The server MUST 508 support key packages by replying to the HTTPS GET request with an 509 HTTPS GET response that includes an HTTP Content-Type of 510 application/pkcs7-mime and a file type of .p7m, as specified in 511 [RFC5751]. 513 Servers MUST support processing HTTPS POST requests and MUST support 514 generating HTTPS POST responses for both key package receipts and key 515 package errors [ID.turner-ct-keypackage-receipt-n-error]. The server 516 MUST support key package error and key package receipt packages by 517 replying to the HTTPS GET request with an HTTPS GET response that 518 includes an HTTP Content-Type of application/pkcs7-mime and a file 519 type of .p7m, as specified in [RFC5751]. The server MUST reject 520 /symmetricKey errors and receipts whose signature fails to validate 521 back to a TA [RFC5652][RFC5280]. 523 Servers MUST support the /symmetricKey URI. 525 3.1.5. URI: /firmware 527 Servers distribute object code for implementing one or more 528 cryptographic algorithms in a cryptographic module and software to 529 implement a communications protocol with the firmware package 530 [RFC4108]. The server MUST support the ct-firmwarePacakge content 531 type. It MUST support receipt of the ct-firmwareLoadReceipt and ct- 532 firmwareLoadError content types. The SOMS server MUST encapsulate 533 the ct-firmwarePackage content type in a ct-signed-data content type 534 [RFC5652]. 536 Servers MUST support processing HTTPS GET requests and MUST support 537 generating HTTPS GET responses for firmware packages. The server 538 MUST support firmware packages by replying to the HTTPS GET request 539 with an HTTPS GET response that includes an HTTP Content-Type of 540 application/pkcs7-mime and a file type of .p7m, as specified in 541 [RFC5751]. 543 Servers MUST support HTTPS POST requests and MUST support HTTPS POST 544 responses for firmware receipts and errors. The server MUST support 545 firmware packages by replying to the HTTPS GET request with an HTTPS 546 GET response that includes an HTTP Content-Type of application/pkcs7- 547 mime and a file type of .p7m, as specified in [RFC5751]. The server 548 MUST reject /firmware error and receipt packages whose signature 549 fails to validate back to a TA [RFC5652][RFC5280]. 551 Servers MUST support the /firmware URI. 553 3.1.6. URI: /tamp 555 The SOMS manages TAs to support validating packages with the Trust 556 Anchor Management Protocol (TAMP) [RFC5934]. TAMP supports multiple 557 formats for the TA. The SOMS MUST support the Certificate choice. 558 The SOMS MUST support the HTTP binding described in [RFC5934]. As 559 specified in [RFC5934]: 561 o servers must support the tamp-update content type. And, the 562 tamp-update must be encapsulated in a ct-signed-data content 563 type. 565 o servers must support the trust-anchor-update-confirm and tamp- 566 error content types [RFC5934]. 568 The server MUST reject /tamp update-confirm and error packages whose 569 signature fail to validate back to a TA [RFC5652][RFC5280]. 571 Servers MUST support the /tamp URI. 573 3.1.7. Mixed Packages 575 NOTE: certs-only packages allow servers to package up both 576 certificates and CRLs in one package. Should mixed packages have 577 their own URI? This section is obviously TBD. 579 To support sending multiple package types to a client, the SOMS can 580 use the Content Collection [RFC4073] CMS content type. To allow the 581 SOMS to apply additional attributes to the package the can use the 582 Content With Attributes [RFC4073] CMS content type. The SOMS SHOULD 583 support the ct-contentCollection and MAY support the ct- 584 contentWithAttributes content type. The SOMS MUST support 585 encapsulating these in a ct-signed-data content type. 587 3.2. Server Authentication Requirements 589 SOMS-to-client and SOMS-to-agent interactions MUST use mutual 590 authentication, provide integrity, and optionally provide 591 confidentiality through the use of HTTP over Transport Security Layer 592 (HTTPS). Confidentiality for SOMS-to-client and SOMS-to-agent 593 interactions is OPTIONAL because when confidentiality is needed the 594 packages are encrypted for the client. See Section 10 for 595 requirements on cryptographic suites. 597 The one exception to the requirement for mutual authentication is 598 retrieval of certificates from /certificates and CRLs from /crls. 600 4. Client 602 Clients use SODP to access the SOMS. Clients need to be registered 603 prior to interacting with the SOMS. Clients need not contribute to 604 or respond to the supplied identity information. After registration 605 is completed, the client is supplied with a certificate. Prior to 606 using this certificate, the client MUST verify the certificate back 607 to an installed TA. The number of TAs a client supports is 608 implementation specific, but the client MUST support at least one TA. 610 The remainder of this section addresses client package and client 611 authentication requirements. 613 4.1. Client Package Requirements 615 Clients retrieve packages based on a URI. This section specifies the 616 package requirements for clients use of the URIs: /certificates, 617 /crls, /fullCMC, /symmetricKey, /firmware, and /tamp. 619 4.1.1. URI: /certificates 621 NOTE: The URI defined in EST -02 is /CACerts. As you might guess the 622 URI is used to distribute CA certificates. I think it ought to be 623 expanded to include arbitrary EE certificates. Therefore at some 624 point the name of this URI might change based on whether or not the 625 comment is accepted. 627 Clients use the /certificates URI to retrieve CA certificates needed 628 to validate package contents as well as other EE certificates that 629 the client might need. See section 5.1 of [ID.pkix-est]. 631 Certificates can also be in a "certs-only" package [RFC5751], which 632 is a CMS SignedData with no content just certificates. The client 633 MUST support the "certs-only" package by generating an HTTPS GET 634 request and receiving an HTTPS GET response that includes an HTTP 635 Content-Type of application/pkcs7-mime and a file type of .p7c, as 636 specified in [RFC5751]. 638 Clients SHOULD support the /certificates URI. 640 4.1.2. URI: /fullCMC 641 NOTE: A comment has been entered to rename this URI in EST as 642 /fullEnrollment to line up better with /simpleEnrollment. Just 643 saying the name might change. 645 Clients use the /fullCMC URI when they use the Full PKI Request and 646 Full PKI Responses [RFC5272]. Clients MUST use the HTTP binding 647 defined in [RFC5273]. As a result, clients must support: 649 o Generating HTTPS POST requests with an HTTP Content-Type of 650 application/pkcs7-mime that contains a ct-PKIData encapsulated in 651 an ct-signed-data content type 653 o Processing HTTPS POST response with an HTTP Content-Type of 654 application/pkcs7-mime that contains a ct-PKIResponse 655 encapsulated in an ct-signed-data content type 657 Clients that support centrally-generated keys MUST support [ID.pkix- 658 cmc-serverkeygeneration]. 660 Clients MUST reject /fullCMC packages whose signature fail to 661 validate back to a TA [RFC5652][RFC5280]. 663 Client MUST support the /fullCMC URI. 665 4.1.3. URI: /crls 667 Clients use the /crls URI to retrieve CRLs, which are necessary to 668 validate certification paths back to a TA. Clients are however free 669 to elect to obtain the CRLs that they rely on from sources other than 670 the SOMS (e.g., a local directory). 672 Clients MUST support generating HTTPS GET requests and MUST support 673 processing HTTPS GET responses for CRLs. Client MUST support 674 receiving CRLs with: 676 o The HTTP Content-Type [RFC2616] is application/pkix-crl and a 677 file type of .crl [RFC2585], which contains a single CRL. 679 o The HTTP Content-Type [RFC2616] is application/pkcs7-mime and a 680 file type of .p7c [RFC5751], which contains either a single CRL 681 or multiple CRLs. 683 Clients SHOULD support the /crls URI unless the client relies on an 684 alternate mechanism to retrieve CRLs. 686 4.1.4. URI: /symmetricKey 688 Clients use the /symmetricKey URI to retrieve key packages and to 689 return receipts and errors about the distributed symmetric key 690 packages. 692 Clients MUST support symmetric key packages defined in [RFC6031]. 693 Clients MUST support a ct-signed-data content type [RFC5652] 694 encapsulating a ct-symmetric-key-package content type. Clients MUST 695 reject ct-symmetric-key-package content types that are not 696 encapsulated in a ct-signed-data content type. Clients MUST reject 697 symmetric key packages whose signature fail to validate back to a TA 698 [RFC5652][RFC5280]. 700 Clients MUST support the encrypted key package [RFC6032] and the 701 EnvelopedData choice must be supported (i.e., support ct-enveloped- 702 data). Clients MUST support a ct-signed-data content type [RFC5652] 703 encapsulating a ct-encrypted-key-package content type. Clients MUST 704 reject ct-encrypted-key-package content types that are not 705 encapsulated in a ct-signed-data content type. Clients MUST reject 706 encrypted key packages whose signature fail to validate back to a TA 707 [RFC5652][RFC5280]. 709 Clients MUST support generating HTTPS GET requests and MUST support 710 processing HTTPS GET responses for key packages. Clients MUST 711 support key packages by submitting HTTPS GET requests and receiving 712 HTTPS GET response that includes an HTTP Content-Type of 713 application/pkcs7-mime and a file type of .p7m, as specified in 714 [RFC5751]. 716 Cients MUST support generating HTTPS POST requests and MUST support 717 processing HTTPS POST responses for both key package receipts and key 718 package errors [ID.turner-ct-keypackage-receipt-n-error]. Clients 719 MUST support key package error and key package receipt packages by 720 generating the HTTPS GET request and processing the HTTPS GET 721 response that includes an HTTP Content-Type of application/pkcs7-mime 722 and a file type of .p7m, as specified in [RFC5751]. 724 Clients MAY support the /symmetricKey URI. 726 4.1.5. URI: /firmware 728 Clients retrieve object code for implementing one or more 729 cryptographic algorithms in a cryptographic module and software to 730 implement a communications protocol with the Firmware package 731 [RFC4108]. Clients MUST support processing the ct-firmwarePacakge 732 content type. Clients MUST support generating the ct- 733 firmwareLoadReceipt and ct-firmwareLoadError content types. Clients 734 MUST support the ct-firmwarePackage content type encapsulated in a 735 ct-signed-data content type [RFC5652]. Clients MUST reject ct- 736 firmware-package content-type whose signature fails to validate back 737 to a TA [RFC5652][RFC5280]. 739 Clients MUST support generating HTTPS GET requests and MUST support 740 processing HTTPS GET responses for firmware packages. Clients MUST 741 support firmware packages by generating to the HTTPS GET request and 742 processing an HTTPS GET response that includes an HTTP Content-Type 743 of application/pkcs7-mime and a file type of .p7m, as specified in 744 [RFC5751]. 746 Clients MUST support generating HTTPS POST requests and MUST support 747 processing HTTPS POST responses for firmware receipts and errors. 748 Clients MUST support firmware packages by generating to the HTTPS GET 749 request with an HTTPS GET response that includes an HTTP Content-Type 750 of application/pkcs7-mime and a file type of .p7m, as specified in 751 [RFC5751]. Clients MUST reject /firmware error and receipt packages 752 whose signature fails to validate back to a TA [RFC5652][RFC5280]. 754 Clients MAY support the /firmware URI. 756 4.1.6. URI: /tamp 758 Client's TAs are managed with the Trust Anchor Management Protocol 759 (TAMP) [RFC5934]. TAMP supports multiple formats for the TA. 760 Clients MUST support the Certificate choice. Clients MUST support 761 the HTTP binding described in [RFC5934]. As specified in [RFC5934]: 763 o Clients must support the tamp-update content type [RFC5934]. 764 And, the tamp-update must be encapsulated in a ct-signed-data 765 content type. 767 o Clients must support the trust-anchor-update-confirm and tamp- 768 error content types [RFC5934]. 770 Clients MUST reject /tamp packages whose signature fail to validate 771 back to a TA [RFC5652][RFC5280]. 773 Clients MAY support the /tamp URI. 775 4.1.7 Mixed Packages 777 Client MAY support for the ct-contentCollection [RFC4073] and the ct- 778 contentWithAttributes [RFC4073] content types. 780 4.2. Authentication Requirements 782 Clients MUST use client-side certificate-based TLS authentication 783 when communicating with the server. Clients MUST support processing 784 certificate-based TLS authentication. The exception to this rule is 785 when the client uses the /certificates and /crls URIs, clients need 786 not use client authentication during these exchanges. 788 5. Agents 790 Agents act on behalf of the client. The requirements for agents are 791 identical to those of clients with the following exceptions: 793 o Agents MUST support PAL processing. 794 o Agents MUST support the /symmetricKey URI. 795 o Agents MUST support the /firmware URI. 796 o Agents MUST support the /tamp URI. 798 Agent Authentication requirements go here. 800 6. Universal Unique Identifiers 802 The Universal Unique Identifier (UUID) is a permanent identifier that 803 is used to identify the client throughout its lifecycle. 804 Certificates include the UUID with the Hardware Module Name from 805 [RFC4108] in the Subject Alternative Name extension [RFC5280]. The 806 hardware module name form is an hwType (an object identifier) and 807 hwSerialNumber (octet string). The hwSerialNumber is a Universal 808 Unique Identifier (UUID) [RFC4122]. The server, clients, and agents 809 SHOULD support UUIDs at least 16 octets in length. 811 7. Product Availability List 813 The PAL provides clients with: 815 o Advertisements for available packages that can be retrieved from 816 the server; 818 o Notifications for public key certificate management, and; 820 o Advertisement for another PAL. 822 An example PAL is provided in Figure 3. The explanation of the 823 fields is explained in the subsequent text and sections. 825 826 827 828 TBD 829 00000000000000 830 1996 831 https://www.example.com/certificates/12 832 833 834 0100 835 00000000000000 836 0 837 DN of subject 838 839 840 TBD 841 00000000000000 842 2390 843 https://www.example.com/symmetricKey/100 844 845 846 0001 847 00000000000000 848 0 849 https://www.example.com/symmetricKey/12345 850 851 853 Figure 3 - Example PAL 855 PAL processing by clients is OPTIONAL, yet RECOMMENDED. PALs MUST 856 use the application/xml media type [RFC3023]. PAL retrieval can be 857 performed by a client or by an agent that is assisting the client. 858 Agents that service clients which do not process PALs, MUST process 859 the PAL on behalf of the client. The agent MUST retrieve and process 860 the PAL from the SOMS as well as the packages advertised within the 861 PAL. Once delivered to the agent, the agent MUST provide the package 862 to the target client in an implementation specific manner. The 863 method of delivery of the package to the target client may or may not 864 implement a PAL type distribution mechanism. 866 When a client or agent requests a PAL, the server dynamically 867 assembles a PAL based on the current information and packages it has 868 for the requesting client or agent. The server relies on the 869 knowledge of the requesting client's ESN, in order to amass the 870 proper list of items. PALs can contain zero (0) or more entries for 871 a package type. 873 An order of precedence for PAL offerings is based on the following 874 rationale: 876 o /certificates and /crls packages are the most important because 877 they support validation decisions on certificates used to sign 878 and encrypt other listed PAL items. 880 o /fullCMC packages items are next in importance, since they can 881 impact an certificate used by the device to sign CMS content or a 882 certificate to establish keys for encrypting content exchanged 883 with the client. 885 * A client engaged in a certificate management SHOULD accept and 886 process CA-provided transactions as soon as possible to avoid 887 undue delays that might lead to protocol failure. 889 o /symmetricKey, /firmware, /tamp packages containing keys and 890 other types of products are last. Precedence SHOULD be given to 891 packages that the client has not previously downloaded. The 892 items listed in a PAL may not identify all of the packages 893 available for a device. This can be for any of the following 894 reasons: 896 * The server may temporarily withhold some outstanding PAL items 897 to simplify client processing. 899 * /fullCMC PAL entries linked to a near-real-time CA device 900 protocol (i.e., not staged through an agent) will be limited to 901 one-at-a-time. 903 * If a CA has more than one certificate ready to begin a 904 certificate management protocol with a client, the server will 905 provide a notice for one at a time. Pending notices will be 906 serviced in order of the earliest date when the certificate 907 will be used. 909 * The SOMS will complete a certificate management activity for 910 one certificate, before beginning the process for another. At 911 most one pending certificate management transaction will be 912 advertised in the PAL at a time. 914 o A PAL is limited to a maximum of thirty-two entries. If more 915 than thirty-two entries are available for the client, additional 916 PALs will be identified in the last entry of the PAL. The first 917 PAL in the chain is identified as the Initial PAL. 919 o Packages will be removed when their contents are superseded or at 920 the direction of a server administrator. 922 The remainder of this section describes the PAL format and its use of 923 URIs. 925 7.1. PAL Format 927 The PAL furnishes information for SOMS packages that are currently 928 available and authorized for retrieval by a client or an agent. The 929 initially offered PAL, will contain anywhere from zero to thirty-two 930 XML-encoded PAL entries following the XML Header. The PAL's XML 931 schema can be found in Section 12. Each PAL entry is composed of the 932 following four REQUIRED elements: 934 o The element uniquely identifies each package defined 935 within this specification that a client may retrieve from server 936 with a 4-digit field. The Package Types are defined in Section 9 937 and registered in Section 12. 939 o The element is a 14-character field that contains either: 941 o The date and time (expressed as Generalized Time: YYYY-MM- 942 DDTHH:MM:SSZ) that the client last successfully downloaded the 943 identified package from the server, or 945 o 0001-01-01T00:00:00 (i.e., 0), if 947 o There is no indication the device has successfully loaded the 948 identified package, or 950 o The PAL entry corresponds to a notification or pointer to a 951 next PAL. 953 o The element indicates the size of the package. If the 954 entry is for a notification, this element will be populated with 955 a zero character (i.e., "0" without the quotes). Otherwise, it 956 indicates the size of the identified package in bytes. 958 o The element provides either a Distinguished Name (DN) or a 959 URI of where the identified package can be retrieved. When the 960 entry is a notification, the subcomponent is a DN that identifies 961 a certificate that is the subject of the notification. 963 When more than thirty-two PAL entries are available, an additional 964 PAL is advertised in the thirty second PAL entry. The additional PAL 965 will have between one and thirty-two PAL entries. 967 When the element is not zero (i.e., 0001-01-01T00:00:00) it 968 MUST be represented in a form that matches the dateTime production in 969 "canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT 970 rely on time resolution finer than milliseconds and MUST NOT generate 971 time instants that specify leap seconds. 973 7.2. URIs 975 A client that supports the PAL will use URIs to obtain both the 976 packages they need from the SOMS, and to post device information the 977 SOMS requires. Clients and agents that support PALs MUST be capable 978 of using URIs [RFC3986]. 980 In order use HTTPS GET or HTTPS POST, the client or agent needs to 981 have a currently valid URI associated with that information. The URI 982 can correspond to: 984 o A PAL that provides a unique URI for each package that the SOMS 985 holds for the client and URIs identifying client actions that 986 need to be taken, or 988 o A package that the client believes is being held by the SOMS. 989 The data may contain product, a protocol-related transaction, or 990 a collection of packages with various contents. 992 When a client performs an HTTPS POST operation, the URI indicates the 993 specific package that is targeted to process the information. A 994 client SHALL be capable of requesting information by providing a URI 995 in an HTTPS GET request to a connected SOMS. 997 A client may know, or believe they know, a specific package URI, 998 because: 1000 o They discovered the URI on a PAL, 1002 o They are anticipating the next step in a protocol initiated by a 1003 prior URI submission, or 1005 o They were provided with the URI out-of-band by a human or an 1006 agent. 1008 Clients and agents MUST be capable of accepting a URI that uniquely 1009 identifies the location of a SOMS package that is available for 1010 delivery. 1012 Clients and agents MUST be capable of accepting a URI that identifies 1013 an action that is to be taken by the client. In order to POST 1014 information, the client or agent supplies a URI that identifies 1015 associated information to the SOMS. For example, the URI could 1016 correspond to a request to initiate, furnish intermediate results 1017 for, or conclude a certificate management protocol. 1019 Regardless of whether an HTTPS GET or HTTPS POST request is being 1020 made, URI components have consistent definitions and usage 1021 requirements. These are specified in the following subsections. 1022 Figure 4 provides a view of the URI components: 1024 scheme://Authority/Path/query|fragment 1025 | Host:Port | 1026 | | +---------+---------------+ 1027 | | | Path 1 | Path 2 (optional) 1028 | +- www.example.com | | 1029 +- https +- certificates +- unique package 1030 +- crls identifier 1031 +- fullCMC 1032 +- symmeticKey 1033 +- firmware 1034 +- tamp 1036 Figure 4 - PAL URI Components 1038 7.2.1. URI Scheme 1040 All HTTPS GET and POST requests and responses MUST use "https" as the 1041 scheme [RFC2818]. All processing of scheme data will be case- 1042 insensitive as required in [RFC3986]. 1044 PALs that do not specify "https" as the URI scheme for every PAL 1045 entry MUST be rejected. 1047 7.2.2. URI Authority 1049 The authority component of a URI identifies the server that the 1050 client is requesting the specific SOMS Service from. The authority 1051 component is in the form of a host name and an optional port number. 1052 The host name identifies the HTTPS server by name, and the port 1053 number identifies the HTTPS server port that will service the 1054 request. Inclusion of the port number is OPTIONAL, as the scheme 1055 component MUST always be "https". 1057 Clients and agents that access servers are configured with the 1058 applicable registered name(s) or corresponding IP address(es) of the 1059 server with which they may establish a connection to. 1061 When generating a URI, the server SHALL populate the Authority 1062 Component of the URI with the registered name of the target server. 1063 See Sections 7.2.3 and 12. 1065 When generating a URI, clients and agents SHALL populate the 1066 Authority Component of the URI with the registered name of the target 1067 server. 1069 Clients and agents SHALL reject the delivery of a received PAL, if 1070 any URI Authority Component contains a registered name that does not 1071 correspond to the connected server. 1073 7.2.3. URI Path 1075 The Path component of a URI identifies a resource that can be 1076 retrieved from, or a location that information can be posted to, at 1077 the SOMS. Path components are presented in the hierarchical form of 1078 SOMS Service Identifier followed by a Product Identifier. They 1079 adhere to the rules for path-absolute parsing as defined in 1080 [RFC3986]. 1082 Service Identifiers that constitute the first path (aka Path 1) 1083 segment in a URI received or generated by a device are: 1084 /certificates, /crls, /fullCMC, /symmetricKey, /firmware, /tamp. 1086 The Package Type (aka Path 2), when present, is always the second 1087 path segment. It is formatted as a four digit integer and represents 1088 the unique identifier the server has associated with the package to 1089 be retrieved. Package types are included in the Package Type 1090 registry found in Section 12. The Product Identifier is only present 1091 in the URIs that will be included in HTTPS GET requests to obtain a 1092 package. 1094 The Package Type is not included in: 1096 o The URI a client uses to obtain the initial PAL, 1098 o The URI portion of /certificates and /crls PAL entries or an 1099 entry the server uses to point to other PALs beyond the initial 1100 PAL, 1102 o The /fullCMC URIs that a SOMS server uses to provide the client 1103 notification for a suggested action, and 1105 o URIs that a client provides as a part of an HTTPS POST requests. 1107 When generating a URI, clients SHALL populate the first Path 1108 component of the URI with one of the URIs defined by this 1109 specification. When generating a URI for the inclusion in a HTTPS 1110 POST operation, a client SHALL only populate the first Path component 1111 of the URI (i.e., the client does not include the package type). 1112 When generating a URI for the inclusion in a HTTPS GET operation for 1113 the initial PAL, a client SHALL only populate the first Path 1114 component of the URI (i.e., the client does not include the package 1115 type). A client SHALL reject the delivery of any PAL received that 1116 contains a URI with the second path component not equal to an 1117 integer. 1119 7.2.4. URI Query and Fragments 1120 Servers do not use Query and Fragment elements. Servers MUST omit 1121 query and fragment components from PALs. Servers SHOULD reject the 1122 delivery of any PAL that contains a URI with a query or fragment 1123 components. 1125 Query and Fragments are not supported by clients in the processing of 1126 received URIs, or in the generation of URIs. Clients and agents 1127 SHOULD reject the delivery of any PAL that contains a URI with a 1128 query or fragment component. When generating a URI, clients and 1129 agents MUST NOT populate the URI with any query or fragment 1130 components. 1132 8. SODP Transport Requirements 1134 This section provides the requirements for SODP interactions. 1136 8.1. Server Requirements 1138 The server MUST support processing HTTPS GET and POST requests and 1139 generating HTTPS GET and HTTPS POST responses [RFC2818]. TLS 1.2 1140 [RFC5246][RFC6176] MUST be implemented in conjunction with HTTPS. To 1141 ensure only authorized clients and agents access the SOMS, the SOMS 1142 MUST support authentication with both client-side certificates and 1143 username/password. See Section 10 for cipher suite requirements. 1145 When the server receives and processes an HTTPS GET or POST request 1146 from a client, it will provide a response. HTTP responses include 1147 status information and may include a message body, when a request is 1148 successfully processed. The status information provided in responses 1149 to client requests will be restricted to the three-digit HTTP status 1150 code. 1152 HTTP response status codes fall into five general classes (where the 1153 class is indicated by the first digit of the code). 1155 o Informational - The SOMS will not make use of the Informational 1156 class of status codes. Protocol switches and continued client 1157 processing are not expected. 1159 o Success - The SOMS will return this class when the GET results in 1160 the requested information being returned or the POST action is 1161 successfully completed. 1163 o Redirection - The SOMS will not make use of the Redirection class 1164 of status codes. The SOMS will not ask a client to take further 1165 action to fulfill a request. 1167 o Client Error - The SOMS will return this class when they cannot 1168 fulfill the requested GET or POST because of a client error. 1170 o Server Error - The SOMS may return this class, when a valid POST 1171 or GET request was received, but the SOMS cannot fulfill the 1172 request for other reasons. 1174 8.2. Client Requirements 1176 Clients MUST support generating HTTPS GET and POST requests and 1177 receiving HTTPS GET and POST responses [RFC2818]. TLS 1.2 1178 [RFC5246][RFC6176] MUST be implemented in conjunction with HTTPS. 1179 Clients MUST support client-side certificate authentication when 1180 connecting to the server. See Section 10 for cipher suite 1181 requirements. 1183 If a client receives an HTTPS response with an Informational or 1184 Redirection class status code, it SHALL interpret the response as a 1185 request failure and terminate its session with the SOMS. 1187 When an Informational or Redirection class status code is received, a 1188 client MAY, if configured for an alternate SOMS server, terminate the 1189 current session and attempt to connect with an alternate SOMS. 1191 If a client receives an HTTPS response with a Success class status 1192 code, it SHALL continue to process the response to determine the 1193 outcome of an HTTPS POST request or to use the information contained 1194 in the included package. 1196 If a client receives an HTTP response with a Client Error class 1197 status code, it SHALL abandon the desired action and not repeat the 1198 same request to the same SOMS during the connection session. 1200 The client can provide additional processing of Client Error class 1201 status codes for a given request; however, this is out-of-scope of 1202 this document. 1204 A client can attempt other (different) HTTP requests after a request 1205 that failed with a Client Error class status code. However, the 1206 client incorporate a means to limit the number of consecutive 1207 requests that fail for any reason in a given connection session with 1208 the SOMS. 1210 If a client receives an HTTPS response with a Server Error class 1211 status code, it SHOULD either: 1213 o Reattempt the request after a non-deterministic delay, or 1215 o Attempt the request with a different server. 1217 8.3. Agent Requirements 1219 Agent requirements are identical to those for clients with one 1220 exception and that is that agents MUST support either agent-side 1221 certificate authentication or username/password when connecting to 1222 the SOMS. 1224 9. Message Sequences 1226 This section depicts package types when using a PAL. 1228 NOTE: Package types are not defined for packages that a client 1229 posts to a server: Key Package Receipts, Key Package Errors, 1230 Firmware Package Receipts, and Key Package Errors. 1232 9.1. /certificates Package Types and Message Sequence 1234 The /certificates URI is used to distribute certificates. The package 1235 types are defined as follows: 1237 Package Package 1238 Type 1239 -------- ---------------------------- 1240 TBD X.509 CA Public Key Certificate 1241 TBD X.509 EE Public Key Certificate 1243 An example PAL entry for a /certificates package is as follows: 1245 1246 TBD 1247 00000000000000 1248 1996 1249 https://www.example.com/certificates/mycert.cer 1250 1252 The package type TBD indicates the message is an X.509 CA Public Key 1253 Certificate. The date and time indicates that the package has not 1254 been downloaded. The package size indicates the size of the package 1255 and the additional info element provides a link to the CA Public Key 1256 Certificate. 1258 The message sequence is identical to Figure 2. 1260 9.2. /crls Package Type and Message Sequence 1262 The /crls URI is used to distribute CRLs. The package types are 1263 defined as follows: 1265 Package Package 1266 Type 1267 -------- ------------- 1268 TBD Root ARL 1269 TBD non-Root CRL 1271 An example PAL entry for a /crls package is as follows: 1273 1274 TBD 1275 00000000000000 1276 1996 1277 https://www.example.com/crls/Root.crl 1278 1280 The package type TBD indicates the package is a Root CRL. The date 1281 and time indicates that the package has not been downloaded. The 1282 package size indicates the size of the package and the additional 1283 info element provides a link to the Root CRL. 1285 The message sequence is identical to Figure 2. 1287 9.3. /fullCMC Package Types and Message Sequence 1289 The /fullCMC URI is used to distribute notifications (i.e., start 1290 rekey) and to manage public key certificates. The package types are 1291 defined as follows: 1293 Package Package 1294 Type 1295 -------- ------------------------------------------------- 1296 0100 Certificate Rekey Notification 1297 N/A DS Certificate Rekey Transaction One 1298 TBD DS Certificate Rekey Transaction Two (Success) 1299 TBD DS Certificate Rekey Transaction Two (Failure) 1300 N/A KE Certificate Issuance Transaction One 1301 TBD KE Certificate Issuance Transaction Two (Success) 1302 TBD KE Certificate Issuance Transaction Two (Failure) 1304 An example PAL entry for a /fullCMC package notification is as 1305 follows: 1307 1308 0100 1309 00000000000000 1310 1996 1311 DN of DS certificate 1312 1314 The package type TBD indicates the package is a Certificate Rekey 1315 Notification. The date and time indicates that the package has not 1316 been downloaded. The package size indicates the size of the package 1317 and the additional info element provides a link to the rekey 1318 notification. The info element tells the client which certificate to 1319 request a rekey for by the DN. 1321 The message sequence for certificate rekey and issuance is a two-step 1322 process. The initial step is client/agent retrieval of the PAL and 1323 then retrieval of a notification for a certificate rekey. Step two 1324 is the client/agent posting of the CMC package followed by the 1325 certificate request response (success or failure) from the server. 1326 Prior to each interaction with the server, the client/agent 1327 authenticates itself with the server. The two steps are depicted in 1328 Figures 5 and 6. 1330 Step 1 1332 SOMS | Establish HTTPS | Client or Agent 1333 | Connection | 1334 |<--------------------->| 1335 | | 1336 | Request PAL | 1337 | (HTTPS GET Request) | 1338 |<----------------------| 1339 |---------------------->| 1340 | Deliver PAL with URI | 1341 | (HTTPS GET Response) | 1342 | | 1343 | Request Certificate | 1344 | Rekey Transaction | 1345 | One | 1346 | (HTTPS GET Request) | 1347 |<----------------------| 1348 |---------------------->| 1349 | Deliver Transaction | 1350 | One | 1351 | (HTTPS GET Response) | 1353 Figure 5 - SODP Certificate Management Service 1354 Message Sequence - Step 1 1355 Step 2 1357 SOMS | Establish HTTPS | Client or Agent 1358 | Connection | 1359 |<--------------------->| 1360 | | 1361 | Deliver Transaction | 1362 | Two | 1363 | (HTTPS POST Request) | 1364 |<----------------------| 1365 |---------------------->| 1366 | Deliver Transaction | 1367 | Three | 1368 | (HTTPS POST Response) | 1370 Figure 6 - SODP Certificate Management Service 1371 Message Sequence Step 2 1373 9.4. /symmetricKey Package Types and Message Sequences 1375 The /symmetricKey URI is used to distribute symmetric and centrally- 1376 generated asymmetric key packages. The package types are defined as 1377 follows: 1379 Package Package 1380 Type 1381 -------- ---------------------- 1382 TBD Symmetric Key Package 1384 An example PAL entry for a /symmetricKey package is as follows: 1386 1387 TBD 1388 00000000000000 1389 1996 1390 https://www.example.com/symmetricKey/symmtrickey1 1391 1393 The package type TBD indicates the message is a symmetric key. The 1394 date and time indicates that the package has not been downloaded. 1395 The package size indicates the size of the package and the additional 1396 info element provides a link to the symmetric key. The info element 1397 indicates the location of the package. 1399 The sequence for both symmetric key and asymmetric key packages is 1400 identical, shown in Figure 2. The client or agent connects to the 1401 SOMS, retrieves their PAL, and the requests the package from the URI 1402 provided in the additional info component. 1404 Error and receipt message sequence is as shown in Figure 7. 1406 SOMS | Establish HTTPS | Client or Agent 1407 | Connection | 1408 |<--------------------->| 1409 | | 1410 | Deliver Receipt or | 1411 | Error | 1412 | (HTTPS POST Request) | 1413 |<----------------------| 1414 |---------------------->| 1415 | (HTTPS POST Response) | 1417 Figure 7 - SODP Certificate Management Service 1418 Message Sequence Step 2 1420 9.5. /firmware Package Type and Message Sequences 1422 The /firmware URI is used to distribute firmware packages. The 1423 package types are defined as follows: 1425 Package Package 1426 Type 1427 -------- ----------------------- 1428 TBD Firmware Package 1430 An example PAL entry for a /firmware package is as follows: 1432 1433 TBD 1434 00000000000000 1435 2056 1436 https://www.example.com/firmware/1234 1437 1439 The message type TBD indicates the message is a firmware package. 1440 The date and time indicates that the package has not been downloaded. 1441 The message size indicates the size of the package and the 1442 additional info element provides a link to the symmetric key. 1444 The sequence for firmware packages is identical, as shown in Figure 1445 2. The client or agent connects to the SOMS, retrieves their PAL, 1446 and the requests the package from the URI provided in the additional 1447 info component. 1449 Errors and receipts message sequence are as shown in Figure 7. 1451 9.5. /tamp Message Types and Sequence 1453 The /tamp URI is used to distribute TAMP packages. The message types 1454 are defined as follows: 1456 Message Package 1457 Type 1458 -------- -------------------- 1459 TBD TAMP Package 1461 An example PAL entry for a distribution package is as follows: 1463 1464 TBD 1465 00000000000000 1466 2056 1467 https://www.example.com/tamp/1234 1468 1470 The package type TBD indicates the message is a TAMP package. The 1471 date and time indicates that the package has not been downloaded. 1472 The package size indicates the size of the package and the additional 1473 info element provides a link to the TAMP package. 1475 The sequence for TAMP packages is identical, as shown in Figure 2. 1476 The client or agent connects to the SOMS, retrieves their PAL, and 1477 the requests the package from the URI provided in the additional info 1478 component. 1480 Errors and receipts message sequence are as shown in Figure 7. 1482 10. Cryptographic Algorithm Requirements 1484 This section defines the cryptographic algorithm requirements for 1485 SODP. There are three types: package protection requirements, TLS 1486 cipher suites, and certificate requirements. 1488 10.1. Package Protection 1490 For [RFC5958] algorithm requirements see [RFC5959][RFC6162]. 1492 For [RFC6031] algorithm requirements see [RFC6160]. 1494 For [RFC6032] algorithm requirements see [RFC6033][RFC6161]. 1496 NOTE: The "cert-only" package does not have algorithm requirements 1497 because no cryptographic operations are performed while generating 1498 this package (i.e., that is there is no signature applied to the 1499 message - the signature is already on the certificates and/or CRLs 1500 included in the package). 1502 For [RFC4108] algorithm requirements see [RFC6160]. 1504 NOTE: The algorithm requirements for [RFC4108] are for symmetric 1505 keys, but equally apply to firmware packages. Note the only 1506 required algorithm is RSA for generating the SignedData that 1507 encapsulates the firmware package. 1509 For [RFC5934] algorithm requirements see [RFC6160]. 1511 NOTE: The algorithm requirements for [RFC4108] are for symmetric 1512 keys, but equally apply to tamp packages. Note the only required 1513 algorithm is RSA for generating the SignedData that encapsulates 1514 the tamp package. 1516 For [RFC5272] algorithm requirements see [RFC5274]. 1518 10.2. TLS Cipher Suites 1520 The following requirements apply to servers, clients, and agents: 1522 o Cipher suites supported MUST include: "TLS_RSA_WITH_", "TLS_DH_", 1523 "TLS_DHE_", and "TLS_ECDH_". 1525 o Cipher suites that include "anon" MUST NOT be used. These suites 1526 do not support mutual authentication. 1528 o Cipher suite that include "EXPORT" and "DES" MUST NOT be used. 1529 These ciphers do not offer a sufficient level of protection; 40- 1530 bit crypto in '11 doesn't cut the mustard and the use of DES is 1531 deprecated. 1533 o When confidentially is supported (recall that is optional), the 1534 "AES_128" ciphers MUST be supported and "AES_256" cipher SHOULD 1535 be supported. 1537 o Cipher suites that include "SHA256" MUST be supported and 1538 "SHA384" SHOULD be supported. 1540 10.3. Certificates 1542 Client, agents, and servers MUST support certificate path validation 1543 on all packages and HTTPS sessions [RFC5280]. 1545 To support the algorithm requirements in Section 10.1, the following 1546 are the public key certificate requirements, which alight with 1547 [RFC5959], [RFC6033], [RFC6160], [RFC6161], and [RFC6162]: 1549 "If an implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, 1550 or Diffie- Hellman, then it MUST support key lengths from 1024-bit 1551 to 2048-bit, inclusive. If an implementation supports ECDSA or 1552 ECDH, then it MUST support keys on P-256." 1554 11. Security Considerations 1556 TO DO: Expand this section! 1558 This document relies on many other specifications. For IP and TCP 1559 security considerations see [RFC791], [RFC793], and [RFC2460]; for 1560 HTTP, HTTPS, and TLS security considerations see [RFC2616], 1561 [RFC2818], and [RFC5246]; for URI security considerations see 1562 [RFC3986]; for content type security considerations see [RFC4073], 1563 [RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5958], [RFC5934], 1564 [RFC6031], and [RFC6032]; for certificate security considerations see 1565 [RFC5280], [RFC5480], and [RFC6010], and; for algorithm security 1566 considerations see [RFC5959], [RFC6033], [RC6160], [RFC6161], 1567 [RFC6162]. 1569 TO DO: Probably more references are needed above for algorithms based 1570 on what gets added in Section 10.1. 1572 It is critical that the SOMS encrypt symmetric keys and centrally- 1573 generated asymmetric private keys for the end client. Failure to 1574 encrypt these keys will allow intermediaries to intercept the key and 1575 eavesdrop and/or impersonate the client. 1577 When packages are encrypted, the source of the package must randomly 1578 generate package-encryption keys. Also, the generation of 1579 public/private signature key pairs relies on a random numbers. The 1580 use of inadequate pseudo-random number generators (PRNGs) to generate 1581 cryptographic keys can result in little or no security. An attacker 1582 may find it much easier to reproduce the PRNG environment that 1583 produced the keys, searching the resulting small set of 1584 possibilities, rather than brute-force searching the whole key space. 1585 The generation of quality random numbers is difficult. [RFC4086] 1586 offers important guidance in this area. 1588 12. IANA Considerations 1590 IANA is requested to perform four registrations: SODP Name Space, 1591 SODP XML Schema, SODP Message Types, and SODP URI String Types. 1593 12.1. SODP Name Space 1595 This section registers a new XML namespace, 1596 "urn:ietf:params:xml:ns:TBD" per the guidelines in [RFC3688]: 1598 TO DO: Fill in TBDs after name space is registered. 1600 URI: urn:ietf:params:xml:ns:TBD 1601 Registrant Contact: Sean Turner (turners@ieca.com) 1602 XML: 1603 BEGIN 1604 1605 1607 1608 1609 SODP Messages 1610 1611 1612

Namespace for SODP Messages

1613

urn:ietf:params:xml:ns:sodp

1614

See RFC TBD

1615 1616 1617 END 1619 12.2. SODP Schema 1621 This section registers an XML schema as per the guidelines in 1622 [RFC3688]. 1624 TO DO: Fill in TBDs after the name space is registered. 1626 URI: urn:ietf:params:xml:schema:sodp 1628 Registrant Contact: Sean Turner turners@ieca.com 1630 XML: 1631 1632 1638 1640 1641 1643 1644 1645 1647 1648 1649 1651 1652 1653 1654 1655 1656 1657 1658 1660 1662 1663 1664 1665 1666 1667 1669 1671 1672 1673 1674 1675 1677 1678 1679 1681 1683 12.3. SODP Package Types 1685 This section registers the SODP Package Types. Future SODP Package 1686 Types registrations are to be subject to Specification Required, as 1687 defined in RFC 5226 [RFC5226]. 1689 The registry has the following values: 1691 +-------+--------------------------------+---------------+ 1692 | Value | Package Type | Specification | 1693 +-------+--------------------------------+---------------+ 1694 | 0000 | Reserved | This document | 1695 +-------+--------------------------------+---------------+ 1696 | 0001 | Additional PAL value present | This document | 1697 +-------+--------------------------------+---------------+ 1698 | 0100 | DS Rekey Notification | This document | 1699 +-------+--------------------------------+---------------+ 1700 | TBD | X.509 CA Public Key Certificate| This document | 1701 +-------+--------------------------------+---------------+ 1702 | TBD | X.509 EE Public Key Certificate| This document | 1703 +-------+--------------------------------+---------------+ 1704 | TBD | Root CRL | This document | 1705 +-------+--------------------------------+---------------+ 1706 | TBD | non-Root CRL | This document | 1707 +-------+--------------------------------+---------------+ 1708 | TBD | DS Certificate Rekey | This document | 1709 | | Transaction Two - Success | | 1710 +-------+--------------------------------+---------------+ 1711 | TBD | DS Certificate Rekey | This document | 1712 | | Transaction Two - Fail | | 1713 +-------+--------------------------------+---------------+ 1714 | TBD | KE Certificate Issuance | This document | 1715 | | Transaction One | | 1716 +-------+--------------------------------+---------------+ 1717 | TBD | KE Certificate Issuance | This document | 1718 | | Transaction Three - Success | | 1719 +-------+--------------------------------+---------------+ 1720 | TBD | KE Certificate Issuance | This document | 1721 | | Transaction Three - Fail | | 1722 +-------+--------------------------------+---------------+ 1723 | TBD | Symmetric Key Package | This document | 1724 +-------+--------------------------------+---------------+ 1725 | TBD | Firmware Package | This document | 1726 +-------+--------------------------------+---------------+ 1727 | TBD | TAMP Package | This document | 1728 +-------+--------------------------------+---------------+ 1730 12.4. SODP Path 1 String Values 1732 This section registers SODP Path String Types as per [RFC3688]. SODP 1733 Path 1 String Value registrations are to be subject to Specification 1734 Required, as defined in RFC 5226 [RFC5226]. The registry has the 1735 following structure: 1737 +----------------------------------------+ 1738 | SODP Service Types | Specification | 1739 +----------------------------------------+ 1740 | certificates | This document | 1741 +----------------------------------------+ 1742 | crls | This document | 1743 +----------------------------------------+ 1744 | fullCMC | This document | 1745 +----------------------------------------+ 1746 | symmetricKey | This document | 1747 +----------------------------------------+ 1748 | firmware | This document | 1749 +----------------------------------------+ 1750 | tamp | This document | 1751 +----------------------------------------+ 1753 13. Acknowledgements 1755 Thanks, in alphabetical order, go to Paul Hoffman, Brad McInnis, Max 1756 Pritikin, and Francois Rousseau for their helpful comments. 1758 14. References 1760 14.1. Normative References 1762 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1763 Requirement Levels", BCP 14, RFC 2119, March 1997. 1765 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1766 (IPv6) Specification", RFC 2460, December 1998. 1768 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1769 Infrastructure Operational Protocols: FTP and HTTP", 1770 RFC 2585, May 1999. 1772 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1773 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer 1774 Protocol -- HTTP/1.1", RFC 2616, June 1999. 1776 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1778 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1779 Types", RFC 3023, January 2001. 1781 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1782 January 2004. 1784 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1785 Resource Identifier (URI): Generic Syntax", STD 66, 1786 RFC 3986, January 2005. 1788 [RFC4073] Housley, R., "Protecting Multiple Contents with the 1789 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 1791 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1792 Protect Firmware Packages", RFC 4108, August 2005. 1794 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1795 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1797 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1798 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1799 2008. 1801 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1802 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1804 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1805 (CMC)", RFC 5272, June 2008. 1807 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1808 (CMC): Transport Protocols", RFC 5273, June 2008. 1810 [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages 1811 over CMS (CMC): Compliance Requirements", RFC 5274, June 1812 2008. 1814 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1815 Housley, R., and W. Polk, "Internet X.509 Public Key 1816 Infrastructure Certificate and Certificate Revocation List 1817 (CRL) Profile", RFC 5280, May 2008. 1819 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1820 "Elliptic Curve Cryptography Subject Public Key 1821 Information", RFC 5480, March 2009. 1823 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1824 RFC 5652, September 2009. 1826 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1827 Mail Extensions (S/MIME) Version 3.2 Message 1828 Specification", RFC 5751, January 2010. 1830 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 1831 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 1832 June 2010. 1834 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1835 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1836 June 2010. 1838 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1839 Format", RFC 5914, June 2010. 1841 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1842 Management Protocol (TAMP)", RFC 5934, August 2010. 1844 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 1845 2010. 1847 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 1848 Type", RFC 5959, August 2010. 1850 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 1851 Message Syntax (CMS) Content Constraints Extension", 1852 RFC 6010, September 2010. 1854 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 1855 (CMS) Symmetric Key Package Content Type", RFC 6031, 1856 December 2010. 1858 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 1859 (CMS) Encrypted Key Package Content Type", RFC 6032, 1860 December 2010. 1862 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 1863 (CMS) Encrypted Key Package Content Type", RFC 6033, 1864 December 2010. 1866 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 1867 (CMS) Protection of Symmetric Key Package Content Types", 1868 RFC 6160, April 2011. 1870 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 1871 Message Syntax (CMS) Encrypted Key Package Content Type", 1872 RFC 6161, April 2011. 1874 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 1875 Message Syntax (CMS) Asymmetric Key Package Content Type", 1876 RFC 6162, April 2011. 1878 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 1879 (SSL) Version 2.0", RFC 6176, March 2011. 1881 [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth 1882 Edition)", W3C Recommendation, November 2008, 1883 . 1885 [XMLSCHEMA] 1886 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1887 Second Edition", World Wide Web Consortium Recommendation 1888 REC-xmlschema-2-20041082, October 2004, 1889 . 1891 [ID.pkix-est] Pritikin, M, and P. Yee, "Enrollment over Secure 1892 Transport", work-in-progress, draft-ietf-pkix-est-00. 1894 [ID.pkix-cmc-serverkeygeneration] 1895 Schaad, J., Turner, S., and P. Timmel, "CMC Extensions: 1896 Server Key Generation", work-in-progress, draft-ietf-pkix- 1897 cmc-serverkeygeneration-00. 1899 14.2. Informative References 1901 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness 1902 Requirements for Security", BCP 106, RFC 4086, June 2005. 1904 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1905 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1907 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 1908 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1909 September 2010. 1911 [XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in 1912 XML", World Wide Web Consortium FirstEdition REC-xml-names- 1913 19990114, January 1999, . 1916 Appendix A. Example Encodings 1918 TO DO: Include BASE64 encodings of ASN.1 encodings of selected 1919 packages. They're a lot smaller than the ASN.1 pretty prints and 1920 there are tons of available to tools to convert. 1922 Appendix B. Change Log 1924 [[RFC EDITOR: Please delete this Appendix prior to publication.]] 1926 B.1. Changes from -01 to -02 1927 Removed the term Key Management System. SODP is about more than just 1928 keys. 1930 Beefed up the introduction to provide more context. 1932 Refined/Removed some definitions: ECU concept scrubbed, IA/KE 1933 Certificates, KMS, Operator, Sponsor, and Service Messages. 1935 Added some definitions: Centrally-Generated Asymmetric Keys, Locally- 1936 Generated Asymmetric Keys, Notifications, and PAL. 1938 Significantly shorted the description of the SODP Model, but removing 1939 the optional concept of having two sets of certificates: one for 1940 communicating with the infrastructure and another for communicating 1941 with peers. 1943 Removed the distraction about services being instantiated by 1944 packages. Now it just talks about packages served from a URI. But, 1945 maintained the split of Server, Client, and Agent. 1947 Embraced the EST concept by replacing /pki with /fullCMC, adding 1948 /certificates (EST calls it /CAcerts), and recommending /crls. 1950 Centrally-generated keys are now distributed via the /fullCMC URI. 1951 This made sense as the draft describing centrally-generated keys uses 1952 CMC. 1954 Allowed clients to retrieve from /certificates and /crls without 1955 client authentication. 1957 Added in Agent requirements. 1959 Replaced ESN with UUID from RFC 4122. 1961 PAL changes: corrected the date fields in the PAL to be compliant 1962 with the XMLSCHEMA, removed 2.1 Gbyte size constraint, changed 1963 encoding from us-ascii to UTF-8. 1965 B.2. Changes from -00 to -01 1967 Keep alive draft. Only the issue and expiry dates changed. 1969 Authors' Addresses 1971 Sean Turner 1972 IECA, Inc. 1973 3057 Nutley Street, Suite 106 1974 Fairfax, VA 22031 1975 USA 1977 EMail: turners@ieca.com