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