Network Working Group S. Turner
Internet-Draft IECA
Intended status: Standards Track March 7, 2011
Expires: September 6, 2011
Secure Object Delivery Protocol (SODP)
draft-turner-sodp-00.txt
Abstract
This document describes the Secure Object Delivery Protocol (SODP).
SODP enables clients to access secure packages produced by a Key
Management Systems (KMS). Client access is ideally direct and web-
based, but access via agents acting on behalf of clients is
supported.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Turner Expires 2011-09-06 [Page 1]
Internet-Draft SODP 2011-03-07
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. SODP Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Key Management System . . . . . . . . . . . . . . . . . . . . . 8
3.1. KMS Services . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Distribution Service . . . . . . . . . . . . . . . 10
3.1.3. Publication Service . . . . . . . . . . . . . . . . 11
3.1.4. Certificate Management Service . . . . . . . . . . 12
3.2. KMS Packages . . . . . . . . . . . . . . . . . . . . . . 13
4. Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Registration . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Activation and Operation . . . . . . . . . . . . . . . . 16
4.3. Packages . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Electronic Serial Number . . . . . . . . . . . . . . . . . . 18
7. Product Availability List . . . . . . . . . . . . . . . . . . 18
7.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . 23
7.2.2. URI Authority . . . . . . . . . . . . . . . . . . . 24
7.2.3. URI Path . . . . . . . . . . . . . . . . . . . . . . 24
7.2.4. URI Query and Fragments . . . . . . . . . . . . . . 25
8. SODP Transport Requirements . . . . . . . . . . . . . . . . . 26
8.1. KMS Requirements . . . . . . . . . . . . . . . . . . . . 26
8.2. Client Requirements . . . . . . . . . . . . . . . . . . . 27
8.3. Agent Requirements . . . . . . . . . . . . . . . . . . . 27
9. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Distribution . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Certificate Management . . . . . . . . . . . . . . . . . 30
10. Cryptographic Algorithm Requirements . . . . . . . . . . . . 32
10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32
10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . 33
10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . 34
12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . 35
12.3. SODP Message Types . . . . . . . . . . . . . . . . . . . 36
12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . 38
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
Turner Expires 2011-09-06 [Page 2]
Internet-Draft SODP 2011-03-07
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.1. Normative References . . . . . . . . . . . . . . . . . . 38
14.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
The Secure Object Delivery Protocol (SODP) enables clients to obtain
secured packages from a supporting Key Management System (KMS).
Client access is via the HyperText Transfer Protocol (HTTP) over
Transport Security Layer (TLS). Clients can directly access the KMS
or an agent can act on the client's behalf. Clients access the KMS
to retrieve a Product Availability List (PAL), which provides the
location of their packages with a User Resource Identifier (URI), or
can directly retrieve the package if the client obtains the URI via
another method. Packages are secured using the Cryptographic Message
Syntax (CMS).
The remainder of this document will explain the SODP model, provide
requirements for the KMS, client, and agent, as well specify the PAL
format.
1.1 Definitions
Agent: An entity that performs functions on behalf of a client.
Asymmetric Key Package: A package that includes an asymmetric key
content type [RFC5959].
Certificate Management Packages: A package that contains a PKI Data
or PKI Response content types [RFC5272][RFC5912].
Clients: An entity that contains one or more End Cryptographic Unit
(ECU). Clients consume products generated by the Key Management
System (KMS).
Encrypted Key Package: A package that includes an encrypted key
content type [RFC6032].
Firmware Package: A package that contains a firmware content type
[RFC4108][RFC5911].
NOTE: [RFC4108] defines the semantics for the firmware content
type's fields. [RFC5911] provides the 2002 ASN.1 definitions.
Identity and Authentication (IA) Key/Certificate: Key/Certificate
Turner Expires 2011-09-06 [Page 3]
Internet-Draft SODP 2011-03-07
used to support IA of the client, when the client communicates with
the KMS as well as with other end-entities. It provides the KMS or
other end-entities with an appropriate degree of confidence in the
client's identity before delivering products, services or sensitive
information to the client.
Key Exchange (KE) Key/Certificate: Key/Certificate used when the
client and the KMS or other end-entity must cooperatively create a
wrapping key to protect the delivery of products or sensitive
information for use by the client. It is also used to establish
secure sessions (e.g., TLS) from a client to the KMS. Other examples
include traffic encryption keys and transmission security keys.
Key Management System (KMS): A set of one or more components that is
designed to protect, manage, and distribute cryptographic products.
In this document, cryptographic products are referred to as packages.
Operator: A person who "runs" the device (e.g., network
administrator).
Package: An object that contains one or more CMS content types. At a
minimum, all packages are protected using the CMS [RFC5652]
SignedData structure. There are numerous types of packages:
Asymmetric, Certificate Management, Encrypted Key, Firmware,
Publication, and Symmetric Packages.
NOTE: This document does not define any packages they are all
defined elsewhere. Product Availability List (PAL): A PAL is an
XML file that furnishes information for KMS service messages that
are currently available and authorized for retrieval by a client
or agent.
Publication Package: A package that contains certificates and
Certificate Revocation Lists (CRLs). These are typically additional
CA certificates or CRLs not provided as part of other packages. The
package is a degenerate CMS SignedData, which is sometimes referred
to as a "certs-only" message.
Service Messages: KMS-produced packages are the instantiation of the
KMS services. This document defines three services that manifest in
three types of service messages: publication, distribution, and
certificate management. One, registration, does not manifest itself
in a service message.
Source Authority: A source authority is trusted by clients to
generate particular package types. Clients determine this by
validating the digital signature on the package back to a Trust
Anchor (TA).
Turner Expires 2011-09-06 [Page 4]
Internet-Draft SODP 2011-03-07
Sponsor: A person that is accountable for use of the client's
identity. This may or may not be the entity that operates the client
(i.e., the operator).
Symmetric Key Package: A package that contains a symmetric key
content type [RFC6031].
Trust Anchor (TA): From [RFC5934], a TA contains a public key that is
used to validate digital signatures. In this document, a TA
represents an authoritative entity via a public key and associated
data. The public key is used to verify digital signatures and the
associated data is used to constrain the types of information for
which the TA is authoritative. A relying party uses TAs to determine
if a digitally signed object is valid by verifying a digital
signature using the TA's public key, and by enforcing the constraints
expressed in the associated data for the TA.
1.2 Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. SODP Model
Figure 1 depicts the SODP model. It is comprised of three entities:
the key management system, one or more clients, and agents acting on
behalf of clients. KMS-to-client and KMS-to-agent protocol
interactions are in-scope; agent-to-client protocol interactions are
out-of-scope. KMS-to-client and KMS-to-agent interactions support
mutual authentication, provide integrity, and optionally provide
confidentiality through the use of HTTPS. Confidentiality for KMS-
to-client and KMS-to-agent interactions is OPTIONAL because when
confidentiality is needed the packages are encrypted for the client.
See Section 10 for requirements on cryptographic suites.
Turner Expires 2011-09-06 [Page 5]
Internet-Draft SODP 2011-03-07
<===> IP-Based Protocol Profile (in scope)
<- -> ECU-Specified Access Protocol (out of scope)
///// CMS-Protected Packages (in scope; full support)
\\\\\ CMS-Protected Packages (in scope; partial support;
requires validation of outer signature only)
+----------------+
| | +------------+
| Key | | Client A |
| Management | | +---+ |
| System |<=====>| /// |ECU| |
| | | /A/ | | |
| +-------+ /// | | /// | A | |
| |A's PAL| /A/ | | +---+ |
| +-------+ /// | +------------+
| |
| +-------+ /// | +-------+ +------------+
| |B's PAL| /B/ | | | | Client B |
| +-------+ /// | | | | +---+ |
| | | Agent |<- - ->| /// |ECU| |
| +-------+ /// | | | | /B/ | | |
| |C's PAL| /C/ | | | | /// | B | |
| +-------+ /// | | \\\ | | +---+ |
| |<=====>| \B\ | +------------+
| . . | | \\\ |
| . . | | | +------------+
| . . | | | | Client C |
| | | \\\ | | +---+ |
| +-------+ /// | | \C\ |<- - ->| /// |ECU| |
| |Z's PAL| /Z/ | | \\\ | | /C/ | | |
| +-------+ /// | | | | /// | C | |
| | | | | +---+ |
+----------------+ +-------+ +------------+
Figure 1 - SODP Model
Clients or agents access the KMS via HTTPS to retrieve and inspect
their PAL. The PAL is an XML file that contains Uniform Resource
Identifiers (URIs) for client packages. Retrieval of packages
referenced in the PAL delivers KMS services to the client.
Alternatively, clients can retrieve packages directly from the KMS if
they obtain URIs from another source. KMS services are discussed in
Section 2.1; the PAL and URI format are discussed in Section 5.
While the KMS is viewed as being a single entity, operationally the
issuance of different packages can be assigned to different
authorities within the KMS. These authorities are referred to as
source authorities. A source authority is trusted by clients to
Turner Expires 2011-09-06 [Page 6]
Internet-Draft SODP 2011-03-07
generate particular package types. Entities validate their source
authorities when validating the digital signature(s) in/on packages.
That is, when a client retrieves a package referred to in their PAL
the client ensures that the signatures in/on the package validate to
an installed trust anchor (TA). See Section 4.1 for more information
on clients' TAs.
Packages may be encrypted for the client. Packages that contain
cleartext (i.e., unencrypted) symmetric keys or asymmetric private
keys MUST be encrypted for the client to ensure that the keys are not
disclosed to another party. Relying on encrypted packages instead of
relying on HTTPS-encrypted links allows agents to further distribute
the packages to clients without disclosing the cleartext to the
agent. Encrypted packages also enable alternate distribution paths
such as store-and-forward, which is beyond the scope of this
document. Package requirements are discussed in Section 4.
Prior to clients accessing the KMS, clients need be registered with
the KMS. The process for this will vary. One possible process
involves sponsorship by an individual. This individual collects
information about the client and enters the information into the
KMS's database. Also during this time, the client is assigned an
initial identity. Once registered, the client is issued a
certificate, which is later used to access the KMS. Clients and
agents use what is referred to as IA certificates when communicating
with the KMS. An IA certificate provides the client's/agent's
identity and allows the KMS to authenticate that the entity accessing
the KMS is in fact the client/agent. The registration and client IA
certificate issuance process is described in more detail in Section
3.1. The format and protocol for communicating the registration data
and sending the initial IA certificate directly to client is out-of-
scope. The client authenticates itself to the KMS with this
certificate using HTTPS. After the IA certificate is installed, the
client requests a KE certificate. KE certificates allow clients to
perform key establishment with the KMS to decrypt/encrypt packages.
Some implementations may require further separation for some clients
who are issued another set of certificates that support client-to-
client interactions, which is the client's joie de vivre or the
client's mission. The initial certificate set is only used to
communicate with the KMS and the second set is only ever used to
communicate with other clients. In this case the first set is
referred to as IA(I)/KE(I) certificates for (I)nfrastructure
certificates and the second set is referred to as IA(M)/KE(M)
certificates for (M)ission certificates. Not all clients need the
second set of certificate, if clients only need symmetric key, then
only one set of certificates is issued. *(I) certificates are issued
to it and instead of IA(M)/KE(M) certificates issued later only
Turner Expires 2011-09-06 [Page 7]
Internet-Draft SODP 2011-03-07
symmetric key packages are provided.
3. Key Management System
The SODP is the interface to the KMS that clients use to access KMS-
services and associated KMS-generated packages. The internal
components of the KMS and their interactions are out-of-scope.
However, if a KMS provides all of the KMS packages (see Section 3.2),
it will need the capability to package trust anchors (TAs), generate
and package symmetric keys, package firmware, generate and package
asymmetric keys, issue and package public key certificates, and issue
and package Certificate Revocation Lists (CRLs). It will also need
to generate and receive packages, which includes generating and
verifying digital signatures on packages as well as encrypting and
decrypting of packages. Additionally, it will need a repository to
store information about clients and their packages.
The remainder of this section is split in to two parts. The first
part, Section 3.1, describes the KMS services and the second part,
Section 3.2, describes the KMS package requirements.
3.1. KMS Services
This section addresses the four services provided by the KMS:
Registration, Distribution, Publication, and Certificate Management.
The latter three services are instantiated in packages.
3.1.1. Registration Service
The KMS only provides services to clients that are KMS-registered.
Registration information collected is KMS-specific. However, the
information collected MUST include a permanent identifier that is
used to identify the client throughout its lifecycle. This permanent
identifier is referred to as an Electronic Serial Number (ESN). See
Section 6 for more information on ESNs.
Other OPTIONAL information to collect includes:
o Client Manufacturer
o Client Name
o Client Type
The KMS could also assign a KMS user number for an internal index,
label, or abbreviated name for associating data elements pertaining
to that user. This number is not sent to the client and is only used
by the KMS.
During this step the client is also assigned an identity, which the
Turner Expires 2011-09-06 [Page 8]
Internet-Draft SODP 2011-03-07
KMS stores in its database. At a minimum the identity is an
identifier but it can also include additional information such as a
client's sponsor (e.g., Alexa Morris), the client's operator (e.g.,
Alexa Morris), and the sponsor's organizational affiliation (e.g.,
AMS). That is, the KMS MUST assign and record an identifier to the
client, but recording other client-related identity data is OPTIONAL.
Additionally:
o For cases where the sponsor isn't the entity that operates the
client, the identity can also include an indication of the entity
operating the client. This allows the network group to sponsor
the client, but the security group to operate the client (i.e.,
network groups say it's okay to add client to the network but
doesn't want to manage the clients keys).
o For cases where the client can be transferred from one operator
to another, the identity MUST include identity of the previous
operator. This provides a "chain-of-control" over the device for
its lifetime. A KMS can support a wide variety of environments:
o For a KMS that support non-X.509 certificate and non-X.509 CRL
types, the identity SHOULD include an indication of certificate
type.
NOTE: This supports cases where the client uses alternate
certificate formats such as Pretty Good Privacy (PGP) [RFC4880].
Alternative certificate formats are supported by many security
protocols including Internet Key Exchange v2 (IKEv2) [RFC5996],
TLS [RFC5246], and CMS [RFC5652].
o For a KMS that supports humans as well as clients, the identity
SHOULD include an indication of the type of user (e.g.,
client/device, human, administrator).
The KMS MUST ensure that the client identity is KMS-unique. That is,
the collection of data that comprises the client identity MUST NOT
match another client served by the KMS. After this check passes, the
final step in the registration process occurs: client IA certificate
issuance. The KMS MUST issue a certificate [RFC5280] to the client
that contains the client's permanent identifier (see Section 6).
NOTE: 1) The process for delivering the IA certificate directly to
the client is out-of-scope; 2) the format and protocol for
communicating the registration data is out-of-scope; and 3) the
client need not contribute to or respond to the supplied identity
information.
Turner Expires 2011-09-06 [Page 9]
Internet-Draft SODP 2011-03-07
3.1.2. Distribution Service
The KMS employs the distribution service to provide clients' access
to their packages. The KMS provides access to packages through the
use of URIs, which uniquely refers to specifically CMS-wrapped
packages for delivery to the target client. The KMS generates a PAL
that clients can use to retrieve packages. Alternatively, the client
can directly access the package, but this assumes the client obtained
the URI(s) via another mechanism, which is out-of-scope. Packages
include symmetric key packages as well as centrally-generated
asymmetric key packages.
NOTE: Certificates associated with client generated asymmetric
keys (i.e., locally-generated public-private keys) are delivered
via the Certificate Management Service (See Section 3.1.3).
Figure 2 depicts an example ladder diagram for a protocol flow. The
first step is to establish a mutually authenticated HTTPS connection
between the client/agent and KMS. The client then requests their PAL
from the KMS (via HTTP GET). The KMS replies with the client's PAL
(via HTTP GET Response). Once a client has successfully downloaded
their PAL, it will process it to obtain the included packages(s).
The processing provided will depend on the PAL entry. Section 3.2
details the KMS-package requirements, Section 4 details clients-
package requirements, and Section 5 details agent-package
requirements.
Turner Expires 2011-09-06 [Page 10]
Internet-Draft SODP 2011-03-07
| |
KMS | Establish HTTPS | Client or Agent
| Connection |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET) |
|<---------------------|
|--------------------->|
| Deliver PAL with URI |
| (HTTP GET Response) |
| |
| Request packages by |
| specified URI |
| (HTTP GET) |
|<---------------------|
|--------------------->|
| Deliver requested |
| CMS package product |
| (HTTP GET Response) |
| |
Figure 2 - SODP Distribution Service Message Sequence
A device can request (via HTTP GET) and download (via HTTP GET
Response) any, or all, packages and new PALs by repeating the
necessary sequence of steps. When the client is finished, it SHOULD
terminate the connection. See Section 8 for more information on
SODP's HTTP requirements.
The KMS MUST support generation of a PAL. The KMS MUST support
access to client packages directly and through a PAL.
3.1.3. Publication Service
The KMS Publication Service provides clients that are PKI subscribers
and relying parties with a means to obtain publicly-available,
ancillary services related to PKIs namely: Certificates, CRLs,
Certificate Policies (CPs), and Certificate Practice Statements
(CPSs) packages. The KMS MUST support distribution of CRLs but MAY
support distribution of CPs and CPSs.
NOTE: CPs and CPSs are the one exception to the Package
definition found in section 1.1. CPs and CPSs are not
encapsulated in CMS, they are URIs to the location on the KMS for
the CP and CPS.
Certificates delivered can include additional CA certificates or peer
Turner Expires 2011-09-06 [Page 11]
Internet-Draft SODP 2011-03-07
client certificate(s).
Clients may elect to obtain the CRLs that they rely on from sources
other than the (e.g., a local directory).
CRLs are offered in the form, or forms, produced by the responsible
Certification Authority (CA). The form of the CRL is transparent to
the KMS Publication Service. CAs may choose to publish compact
versions of CRLs (e.g., partitioned CRLs) that are compatible with a
disadvantaged client within the overall subscriber population. The
PAL provided to a client will always contain a URI for the most
current version of each CRL needed to verify the packages in the form
used by the particular client. The KMS Publication Service will not
list CRLs that a client does not need or cannot use. Based on its
capabilities, the freshness of currently held CRLs, and the
circumstances, the client will determine whether it needs to download
each offered CRL. KMS Publication Services packages will be signed,
but need not be encrypted. The information in the package is already
signed; CAs sign the certificates and CRLs so there is no need to
sign a package containing them.
NOTE: The KMS Publication Service is not meant to be a general
repository for all relying parties. Access is only provided to
registered clients.
3.1.4. Certificate Management Service
The KMS Certificate Management Service allows a client to develop an
asymmetric key pair and obtain the public key certificate associated
with the key pair. It additionally provides certificates and CRLs
necessary to validate the asymmetric key pair to an installed TA.
The KMS Certificate Management Service supports two kinds of
certificate management processes:
o Issuance: Where a new public/private key pair is established for
a KE certificate.
o Rekey: Where an existing IA certificate is provided with new
keying material.
CA MUST generate public key certificates in accordance with
[RFC5280]. A Registration Authority (RA) may be used to register
subscribers as well as assist the CA when issuing and rekeying
certificates for clients.
Turner Expires 2011-09-06 [Page 12]
Internet-Draft SODP 2011-03-07
3.2. KMS Packages
The KMS Distribution, Publication, and Certificate Management
services translate into KMS packages. The primary packages are key
packages, but they also include firmware packages necessary to use
the key packages, TAMP packages to validate the package's source of
authority, publication packages that contain additional certificates
and CRLs, and collections of key packages. This section lists the
package requirements for the KMS.
There are many different key packages, but at their core there are
three types:
o Symmetric key packages are defined in [RFC6031]. A symmetric key
package can contain one or more symmetric keys. It also can
contain attributes that apply to one or more keys. The KMS MUST
support the ct-symmetric-key-package content type encapsulated in
a ct-signed-data content type [RFC5652][RFC5911].
o Asymmetric key packages are defined in [RFC5958]. An asymmetric
key package can contains one or more private asymmetric keys and
associated algorithm parameters. It can also contain the public
key and other attributes. This key package is used in
conjunction with the certificate management packages when the KMS
generates the client's key pair. The KMS MUST support the ct-
asymmetric-key-package content type encapsulated in a ct-signed-
data content type.
o Certificate management packages are defined in
[RFC5272][RFC5912]. PKI Data and PKI Response content types are
used to manage public key certificates [RFC5280]. The KMS MUST
support the ct-PKIData and ct-PKIResponse content types. The KMS
MUST also support encapsulating ct-PKIData in the ct-signed-data
content type.
Distribution of the symmetric and asymmetric key packages require
that these keys be disclosed only to the client and to not to anyone
else. The key packages needs to be enveloped. The encrypted key
package [RFC6032] supports encrypting key packages in one of three
ways: with key exchange algorithms (i.e., using EnvelopedData), with
previously distributed symmetric algorithms (i.e., using
EncryptedData), and with authenticated-encryption algorithms (i.e.,
using AuthEnvelopedData). The KMS MUST support the ct-encrypted-key-
package content type and the EnvelopedData choice (i.e., support ct-
enveloped-data). The KMS MUST support encapsulating ct-encrypted-
key-package in a ct-signed-data content type.
The KMS distributes object code for implementing one or more
Turner Expires 2011-09-06 [Page 13]
Internet-Draft SODP 2011-03-07
cryptographic algorithms in a cryptographic module and software to
implement a communications protocol with the Firmware package
[RFC4108][RFC5911]. The KMS MUST support the ct-firmwarePacakge
content type. It MUST support receipt of the ct-firmwareLoadReceipt
and ct-firmwareLoadError content types. The KMS MUST support
encapsulating the ct-firmwarePackage content type in a ct-signed-data
content type.
To support sending multiple package types to a client, the KMS can
use the Content Collection [RFC4073] CMS content type. To allow the
KMS to apply additional attributes to the package the can use the
Content With Attributes [RFC4073] CMS content type. The KMS SHOULD
support the ct-contentCollection any MAY support the ct-
contentWithAttributes content type. The KMS MUST support
encapsulating these in a ct-signed-data content type.
The publication package is supported by the KMS with the "certs-only"
package [RFC5751], which is a CMS SignedData with no content just
CRLs and certificates. The KMS MUST support the "certs-only" package
with ct-data content type with no eContent. The KMS manages TAs to
support validating packages with the Trust Anchor Management Protocol
(TAMP) [RFC5934]. TAMP supports multiple formats for the TA. The
KMS MUST support the Certificate choice. The KMS MUST support the
tamp-update content type [RFC5934]. As specified in [RFC5934], tamp-
update MUST be encapsulated in a ct-signed-data content type.
TO DO: Add TAMP to Service Identifiers.
The KMS MUST support validating package signatures back to a TA
[RFC5652][RFC5280].
4. Client
Clients use SODP to access the KMS-services and associated KMS-
generated packages. This section addresses client registration, use,
and package requirements.
4.1. Registration
Section 3.1.1 addresses client registration. As noted there, the
client need not contribute to or respond to the supplied identity
information. After registration is completed, the client is supplied
with an IA certificate. Prior to using this certificate, the client
MUST verify that the certificate back to an installed trust anchor.
The number of TAs is implementation KMS-specific, but in general:
o If the client supports locally-generated asymmetric keys, then it
MUST support at least one TA.
Turner Expires 2011-09-06 [Page 14]
Internet-Draft SODP 2011-03-07
o If the client support centrally-generated asymmetric keys, then
it MUST also support at least one TA.
o If the client supports symmetric keys, then it MUST support two
TAs: one for symmetric keys and one for the asymmetric keys
(i.e., the PKI Root).
o If the client support firmware, the it MUST support two TAs: one
for the firmware and one for the asymmetric keys (i.e., the PKI
Root).
More complicated scenarios are possible. For example in Figure 3, a
KMS and client support centrally-generated asymmetric keys. The KMS
supports two TAs: one for the certificate and one for the asymmetric
keys (a Key TA (KTA)). The KTA delegates source authority to a Key
Source Authority (KSA) and distribution authority to a Key
Distribution Authority (KDA). The KSA creates the asymmetric key
places it in the symmetric key content type, signs it (signed data
content type), includes the corresponding certificate, and encrypts
it (encrypted key content type). The KDA applies an additional
signature layer around the encrypted data. Upon receipt the client
validates KDA's certificate and signature to the KTA, decrypt the
message, the KSA's signature and certificates to the KTA, the client
validates their certificate to the PKI TA, and the client checks that
the private key corresponds to the public key.
Turner Expires 2011-09-06 [Page 15]
Internet-Draft SODP 2011-03-07
+-----+ +--------+
| KTA | | PKI TA |
+-----+ +--------+
| |
| Signs | Signs
| |
+-------------+ V
| | +----+
V V | CA |
+-----+ +-----+ +----+
| KSA | | KDA | |
+-----+ +-----+ | Signs
| | |
| Signs & | Optionally V
| Encrypts | Signs +-----+
| | | PKC |
| | +-----+
| V |
+---|-------------+ Included In |
| V SignedData | Key Package |
| +-------------+ | |
| | Key Package |<--------------------+
| +-------------+ |
+-----------------+
Figure 3 - Example Authority Architecture
4.2. Activation and Operation
The activation/operation phase of the client lifecycle is where the
client performs its prime mission (e.g., secure Voice Over IP (VoIP),
cable box).
Activation can occur immediately following registration, when the
client receives an IA certificate. Activation can also occur when
the client resides at and is associated with its intended operator
(i.e., the client is registered and sponsored in the Canada but not
activated by the operator until it arrives where they are located in
Greenland). In other words, the client can be immediately actived or
it can occur at a later time.
NOTE: A client only needs to be loaded with an IA key to perform
KMS Services.
If the client needs additional certificates (e.g., for
confidentiality or separate mission certificates), the client or
agent can retrieve them via the PAL. Client retrieval of packages
via the PAL is OPTIONAL. Clients may elect to obtain product package
URI information using a different mechanism (e.g., inputs from a
Turner Expires 2011-09-06 [Page 16]
Internet-Draft SODP 2011-03-07
human or agent).
4.3. Packages
Client support for packages varies depending on the type of service
they desire. All clients MUST support the ct-signed-data content
type to ensure the packages source of authority can be determined.
They MUST also support validating package signatures back to a TA
[RFC5652][RFC5280].
For clients that support symmetric key packages [RFC6031], they MUST
support the ct-symmetric-key-package content type. Additionally,
clients MUST support the ct-encrypted-key-package content type and
the EnvelopedData choice (i.e., support ct-enveloped-data) to support
encrypting the cleartext symmetric key.
For clients that support certificate management packages with
locally-generated keys, they MUST support certs-only
[RFC5751][RFC5911], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse
[RFC5272][RFC5912].
Retrieval of CRLs and additional certificates via the certs-only
package, is OPTIONAL. Clients can retrieve CRLs and additional
certificate via other mechanisms. Client support for the ct-
contentCollection and the ct-contentWithAttributes content types is
OPTIONAL.
For clients that support firmware packages [RFC4108][RFC5911], they
MUST support the ct-firmwarePacakge content type. Client support for
the ct-firmwareLoadReceipt and ct-firmwareLoadError content types is
OPTIONAL, as per [RFC4108].
For clients that support the Trust Anchor Management Protocol (TAMP)
[RFC5934], they MUST support the Certificate choice of the TA format
and MUST support the tamp-update content type [RFC5934].
TO DO: Complete the following:
For clients that support certificate management packages with
centrally-generated keys, they MUST support ct-asymmetric-key-package
[RFC5958], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse
[RFC5272][RFC5912].
5. Agents
Agents act on behalf of the client. Agents MUST support PAL
processing.
Turner Expires 2011-09-06 [Page 17]
Internet-Draft SODP 2011-03-07
TO DO: Fill this out.
6. Electronic Serial Number
The Electronic Serial Number (ESN) is a permanent identifier that is
used to identify the client throughout its lifecycle. Certificates
include the ESN with the Hardware Module Name from [RFC4108] in the
Subject Alternative Name extension [RFC5280]. The hardware module
name form is an hwType (an object identifier) and hwSerialNumber
(octet string). The combination of the object identifier and octet
string guarantees global uniqueness. For example, a company uses
their private enterprise number they received from IANA and includes
their serial number the octet string. The KMS, clients, and agents
SHOULD support ESNs at least 8 octets in length.
7. Product Availability List
The PAL provides clients with:
o Advertisements for available packages and transactions that can
be retrieved from the KMS;
o Advertisement for another PAL.
TO DO: Add definition of Notification in Section 1.1. Need to
explain it's an exception the PAL including packages.
An example PAL is provided in Figure 4. The explanation of the
fields is explained in the subsequent text and sections.
See TBD
END 12.2. SODP Schema This section registers an XML schema as per the guidelines in [RFC3688]. TO DO: Fill in TBDs. URI: urn:ietf:params:xml:ns:TBD Registrant Contact: Sean Turner turners@ieca.com XML: