PKIX Key Attestation Format

3.1. Trust Anchor Key

A trust anchor key is a signing key held by a vendor. For the purposes of this document, a trust anchor may be a proper Trust Anchor as defined in [RFC5914], or a root certification authority as defined in [RFC5280]. It is used either to directly sign device identity keys as defined in Section 3.3 or to sign intermediate CA keys. A trust anchor key MUST be associated with a vendor identity.¶

Constraints:¶

• A trust anchor key MUST only be used for purposes consistent with signing intermediate CA keys or devices (i.e. signing delegation certificates, CRLs, etc).¶

3.2. Intermediate CA Key

An intermediate CA key is a signing key held by a vendor and certified by that vendor's trust anchor.¶

It can be used for one of two purposes:¶

• to certify device identity keys (see section Section 3.3) by signing device identity certificates (see section Section 4.3)¶
• to certify further intermediate CA keys¶

The exact configuration and management of trust anchor keys and intermediate CA keys is beyond the scope of this document. An example configuration is that a vendor have an offline trust anchor, and an intermediate CA in each of its manufacturing sites, certified by the trust anchor key when a manufacturing site is created or during maintenance or recovery activities.¶

It may be impossible recertify a device after manufacture, and it may be impossible for a manufacturer to know when a device has been retired from use. Therefore:¶

• an intermediate CA need not track and public revocation information¶
• intermediate CA keys MAY have a expiration date of 99991231235959Z ([RFC5280] section 4.1.2.5).¶

Constraints:¶

• An intermediate CA key MUST only be used for purposes consistent with certifying intermediate CA keys (i.e. signing delegation certificates, CRLs, etc) or devices.¶

3.3. Device Identity Key

A device identity key is a signing key held by a device. It is assumed that the key is unique to the device and cannot be extracted or used for any purpose other than the ones listed below. It is envisaged that this key will persist for the lifetime of the device.¶

It can be used for one of two purposes:¶

• to sign key attestations directly¶
• to sign device delegation certificates (see section Section 4.4), which are used to certify device certification subkeys (see section Section 3.4).¶

Constraints:¶

• A device identity key MUST NOT be used for any purpose other than signing key attestation certificates or device delegation certificates.¶

3.4. Device Certification Subkey

A device certification key is a signing key held by a device. It is assumed that the key is unique to the device and cannot be extracted or used for any purpose other than the ones listed below. Depending on the device architecture, it may also be limited to a particular context or partition of the device; in this case it is assumed to be unique to the particular context. A device certification key may have any lifetime, from single use to the lifetime of the device.¶

It can be used for one of two purposes:¶

• to sign key attestations directly¶
• to sign further device delegation certificates.¶

Constraints:¶

• A device certification subkey MUST NOT be used for any purpose other than signing key attestation certificates (see section Section 4.5) or device delegation certificates (see section Section 4.4).¶

3.5. Application Key

An application key is a key created and managed by a device (excluding the device identity key and device certification subkey described above). Its purpose and lifetime are arbitrary - in other words, it can be used for any purpose a user of the device wishes.¶

(MikeO: maybe I'm a noob here, but the distinction between this an a Device Certification Subkey could be stated more clearly. Maybe the distinction "This is envisioned for cases where a device needs an attested key which may be used for arbitrary purposes".)¶

(RJK: it's not really about what the device desires - these are the keys that we are trying to attest the origin of. The user has some higher-level purpose, e.g. code signing, which requires them to define a code signing key and attest to its origins in an HSM; from the point of view of this spec, their code-signing key is an application key. Keeping this comment open in the hope we can find a clear way of articulating this.)¶

4.1. Key Attestation Bundle

A key attestation consists of a nonempty sequence of [RFC5280] certificates, containing key attestation extensions as described below.¶

Specifically, a key attestation consists of:¶

• Zero or more intermediate certificates (see section Section 4.2)¶
• Exactly one device identity certificate (see section Section 4.3)¶
• Zero or more device delegation certificates (see section Section 4.4)¶
• Exactly one key attestation certificate (see section Section 4.5)¶

The first certificate (whether it is an intermediate certificate or the device identity certificate) is signed by a trust anchor key. A verifier must decide through its own policies and processes which trust anchors keys to trust and what policies to accept in key attestations certified by them. A trust anchor key MUST be associated with a vendor identity.¶

Constraints:¶

• A verifier MUST verify that each certificate is well-formed (except that expiry and revocation information need not be present)¶
• A verifier MUST verify that the first certificate is signed by a trust anchor key¶
• A verifier MUST verify that each certificate, apart from the first, is certified by the previous certificate in the key attestation.¶
• A verifier MUST verify that the ordering of certificates is as described above.¶

4.2. Intermediate CA Certificate

An intermediate CA delegation certificate certifies an intermediate CA. Apart from the absence of any constraints on expiry time and revocation, it is little different from any other intermediate CA's certificate.¶

It MUST have the [RFC5280] basic constraints extension with the cA boolean set to true.¶

It MAY have the [RFC5280] pathLenConstraint, and there is no change to the [RFC5280] interpretation this field. Therefore, if it is present, it must permit sufficiently many following certificates to account for certificates signed by the device i.e. device identity certificates (see section Section 4.3) and device delegation certificates (see section Section 4.4).¶

It MUST NOT have any of the extensions defined in the following sections (Section 4.3, Section 4.4 and Section 4.5). A verifier may detect an intermediate CA delegation by the presence of a true cA boolean and the absence of these extensions.¶

Constraints:¶

• A verifier MUST honor pathLenConstraint if present.¶
• There may be any number of intermediate CA certificates, including 0.¶

4.3. Device Identity Certificate

A device identity certificate certifies a specific device by binding its public device identity key (defined in Section 3.3) to a vendor-specific representation of device identity such as vendor name, model, and serial number. For a hardware device, it is envisaged that a manufacturing facility will use its trust anchor or intermediate CA to sign a device identity certificate for each device as it is manufactured.¶

A device identity certificate MUST contain a DeviceInformation extension, identified by id-device-information. This extension contains the vendor identity, device model and device serial. Together these are called the device identity and MUST uniquely define a particular device.¶

id-device-information OBJECT IDENTIFIER ::=
        { 1 3 6 1 4 1 54392 5 1567 }

DeviceInformation ::= SEQUENCE {
  vendor UTF8STring   -- manufacturer of device
  model UTF8STring    -- device model information
  serial UTF8STring   -- device instance information
}

• EDNOTE: this is a temporary OID for the purposes of prototyping. We are requesting IANA to assign a permanent OID, see Section 8.¶

A device identity certificate MUST have the [RFC5280] basic constraints extension with the cA boolean set to true (since the device is acting as a CA).¶

No significance is attached to the subject field of a device identity certificate.¶

Constraints:¶

• A verifier MUST reject any key attestation that does not contain exactly one device identity certificate.¶
• A verifier MUST reject any device identity certificate whose vendor identity as indicated in the vendor field does not match the one associated with the trust anchor used to verify the key attestation.¶
• Two distinct devices from the same vendor MUST NOT have the same device identity, i.e. they must have different values for at least one field of DeviceIdentity.¶
• Two distinct devices MUST NOT have the same device identity key.¶

As a matter of interpretation, it is envisaged that the uniquess requirement on device identity keys (and all other keys in this specification) is achieved by generating keys of adequate size, using a cryptographically secure pseudorandom number generators, rather than by maintaining an industry-wide database of all device identity keys.¶

4.4. Device Delegation Certificate

A device delegation certificate certifies that a specific certification subkey (defined in Section 3.4) belongs to a specific device by binding it to a vendor-specific representation of the device and the subkey's purpose. It is envisaged that a single hardware device may have multiple certification subkeys each being restricted to, for example, a single partition or application context. The device may create new certification subkeys and therefore new device delegation certificates over time, for instance when the device is re-initialized, or if the device supports dynamic creation of users or application contexts and needs to create distinct certification subkeys for each.¶

A device delegation certificate MUST contain a DeviceSubkeyInformation extension, identified by id-device-subkey-information. This contains the vendor identity, device model, device serial and key purpose. Note that this does not uniquely define the certification subkey.¶

id-device-subkey-information OBJECT IDENTIFIER ::=
        { 1 3 6 1 4 1 54392 5 1568 }

DeviceSubkeyInformation ::= SEQUENCE {
  vendor UTF8STring   -- manufacturer of device
  model UTF8STring    -- device model information
  serial UTF8STring   -- device instance information
  purpose UTF8String  -- description of subkey purpose
}

• EDNOTE: this is a temporary OID for the purposes of prototyping. We are requesting IANA to assign a permanent OID, see Section 8.¶

The meaning of the purpose field is entirely dependent on the device.¶

It MUST have the [RFC5280] basic constraints extension with the cA boolean set to true (since the device is acting as a CA).¶

No significance is attached to the subject field of a device delegation certificate.¶

Constraints:¶

• A verifier MUST reject any device delegation certificate whose device identity as indicated in the vendor, model and serial fields does not match the values from the device identity certificate.¶
• The purpose field may have any value.¶
• Two device delegation certificates signed by the same key MAY have the same purpose field.¶

4.5. Key Attestation Certificate

A key attestation certificate certifies that an application key was created in a particular device and is managed according to a particular policy.¶

A key attestation certificate MUST contain a ApplicationKeyInformation extension identified by id-application-key-information. This contains the vendor identity, device model, device serial, key use policy (see Section 5) and vendor-specific information.¶

id-policy-signature-only OBJECT IDENTIFIER ::=
        { 1 3 6 1 4 1 54392 5 1570 }

ApplicationKeyInformation ::= SEQUENCE {
  vendor UTF8STring         -- manufacturer of device
  model UTF8STring          -- device model information
  policy OBJECT IDENTIFIER  -- policy governing key use
  vendorinfo OCTET STRING   -- vendor-specific information
}

• EDNOTE: this is a temporary OID for the purposes of prototyping. We are requesting IANA to assign a permanent OID, see Section 8.¶

MikeO: I don't fully grok how the policy will be used. Should it be a list (SEQUENCE of OBJECT IDENTIFIER)? Can it be empty?¶

If the key attestation certificate contains the [RFC5280] basic constraints extension then it MUST have the cA boolean set to false.¶

No significance is attached to the subject field of a key attestation certificate.¶

Constraints:¶

• A verifier MUST reject any key attestation certificate whose device identity as indicated in the vendor, model and serial fields does not match the values from the device identity certificate.¶
• A verifier MUST reject any key attestation certificate whose policy is not in their list of acceptable policies.¶

5.1. Key Use Policy Variants

Each of the policies described below has two variants.¶

1. In the first, the policy means that a key may be used only in certain ways, and this cannot be overidden even by an administrator.¶
2. In the second, the policy means that a key may normally be used only in certain ways, but that an authorized administrator may override this in some way (for example, in order to facilitate disaster recovery).¶

For example, for a CA processing a key attestation bundle in a certificate request, normally only the first variant (no administrative override) would be acceptable. If the application key is lost then the application key owner can be expected to generate a new key and certify it. There is no need to recover the old key.¶

*(MikeO: I'm not sure I see the connection between the last two sentences and the first one above. Maybe need to make the connection clearer between losing your key, and key use policies, like mention above that non-exportability is one of the important policies?)¶

In other use cases, the weaker policy may be more appropriate.¶

5.2. Signature-Only Policy

This policy is identified by id-policy-signature-only. It means that the private key may only be used for signature, and MAY NOT be exported in plaintext outside the device.¶

(MikeO: for clarity, maybe name this id-keyattest-policy-sig-non-exportable or something like that?)¶

5.3. Signature-Only Policy with Administrator Override

This policy is identified by TODO. It means that the private key may normally only be used for signature (MikeO: and MAY NOT be exported?), but that an authorized administrator may override this in some way.¶

5.4. Vendor-Defined Key Use Policies

A vendor may define policies outside the list described in the list document, for example reflecting policies not envisaged by this document or to cover device-specific functionality. For example they may describe a policy in terms of their device's proprietary policy or access control syntax# and publish an OID reflecting that policy. A verifier MUST NOT accept such a vendor-defined policy unless they fully understand the intended meaning.¶

(MikeO: This description reinforces a question I asked above about whether this should allow a list of policies?)¶

*RJK: Probably yes, then we don't have to have a sign-and-decrypt policy.¶

9.1. Key Use Constraints

The key use constraints describe above are essential. For example if a device identity key could be used by a user to sign arbitrary messages, that user could forge key attestations.¶

9.2. Verification Model

An API that verifies a key attestion may be designed in a number of different ways.¶

1. It may accept just a key attestation. It will verify it, and return either an error indicator or the public trust anchor key, vendor identity, public application key, and the policy governing is use. The caller must check at least that the trust anchor key is acceptable; the vendor identity from the key attestation matches the one associated with the trust anchor; and that the policy is acceptable, before using the application key. If the caller is running in a context where there are multiple copies of the application key (for example, the certification request verification described in Section 6 it must also check that all copies of the appcalition key match.¶
2. It may accept a key attestation, trust anchor, vendor identity and at least one acceptable policy. It will verify the key attestation using the trust anchor, and check that the vendor identities in the key attestation match the trust anchor, and check that the policy is acceptable. It will return either an error indicator or the application key. If the caller is running in a context where there are multiple copies of the application key then it must also check that all copies of the appcalition key match. Apart from that it can use the application key without further checks.¶
3. It may accept a key attestation, trust anchor, vendor identity, application key and at least one acceptable policy. It will verify the key attestation using the trust anchor, and check that the vendor identities in the key attestation match the trust anchor, check that the policy is acceptable, and that the application key is the expected value. It will return either an error or a success indicator. The caller can use the application key without further checks.¶

In all of these models the same set of checks must be done, but in the first two some of the checks are delegated to the caller. The advantage of the later models is that they are more robust against the caller ommitting some of the necessary checks. For a publicly available API this robustness is particularly appropriate.¶

9.3. Policies with Administrator Override

No attempt is made to define the scope of administrator override in policies which include it. Depending on the device it may mean that, for example, a signature-only RSA key could additional be given decrypt permission, or it could mean that private key material could be exploited in plaintext. The range of possibilities is to broad to tie down in a device-independent specification.¶

It should be noted that placing trust in a key does mean generally placing trust in the operators and administrators of the device that contains it, even without any possibilty of administrator override of the policy governing its use. For example there is nothing in the signature-only policy to prevent a key owner exposing a signature oracle for their key, allowing anyone to sign with it. In other words, verifiers should not place undue weight on the distinction between the two classes of policy.¶

9.4. Uniqueness of Keys

It's generally assumed that all keys are unique. This is the expected outcome for properly generated cryptographic keys, and while a collision is in principle possible by chance, it's much more likely that a collision indicates a failure in the key generation process (for example, [DSA1571]).¶