PKI-based Attestation Evidence

4.1. Signing Procedure

1. The message to be signed is the TBSEvidenceStatement, including the SignatureInfo for each of the signatures to be performed.¶

2. Each signature is computed in parallel and placed into index of the signatureValues SEQUENCE that matches the position of the corresponding SignatureInfo in the signatureInfos sequence.¶

The signer MUST produce one signature per signatureInfo, it MUST NOT omit signatures and MUST NOT produce a subset of the signatures listed in signatureInfos.¶

4.2. Verification Procedure

1. The message to be verified is the TBSEvidenceStatement.¶

2. For each signatureInfo, the corresponding verification public key and signature algorithm is found according to the information contained in the SignatureInfo for that signature and any accompanying certificates or key material.¶

3. For each signature, the message is verified using the value from the corresponding element of the signatureValue sequence.¶

4. The PkixEvidenceStatement SHOULD be considered valid if and only if all signatures are valid; i.e. multiple signatures are to be treated as an AND mode. This item is a recommendation and not a hard requirement since verification policy is of course at the discretion of the Verifier.¶

EDNOTE: the major change here from the original Crypto4A QASM Attestation is that the original only includes the claims in the signature, whereas this includes everything, including the version, list of signature algorithms. This prevents possible attacks where those values are manipulated by attackers. We should debate whether the certificates should be protected by the signature. Pro: generally better for security to sign everything. Con: in some contexts, it may be difficult to have the certificates prior to signing, but that's ok because most evidence carrier formats also allow you to attach the signatures externally.¶

5.1. Platform Claims

| Claim          | OID      | Value        | Section           | Status       |
| --------       | -------- | ------------ | ----------------- | ------------ |
| Oemid          | TBD      | UTF8String   | {{sect-deviceID}} | RECOMMENDED  |
| Hwmodel        | TBD      | UTF8String   | {{sect-deviceID}} | RECOMMENDED  |
| Hwversion      | TBD      | UTF8String   | {{sect-deviceID}} | RECOMMENDED  |
| Hwserial       | TBD      | UTF8String   | {{sect-deviceID}} | RECOMMENDED  |
| Ueid           | TBD      | UTF8String   | {{sect-ueid}    } | OPTIONAL     |
| Sueid          | TBD      | UTF8String   | {{sect-sueid}}    | OPTIONAL     |
| EnvID          | TBD      | UTF8String   | {{sect-envID}}    | OPTIONAL     |
| Swname         | TBD      | UTF8String   | {{sect-swID}}     | RECOMMENDED  |
| Swversion      | TBD      | UTF8String   | {{sect-swID}}     | RECOMMENDED  |
| Oemboot        | TBD      | BOOLEAN      | {{sect-oemboot}}  | RECOMMENDED  |
| Location       | TBD      | ???          | {{sect-location}} | OPTIONAL     |
| Dbgstat        | TBD      | CHOICE       | {{sect-dbgstat}}  | RECOMMENDED  |
| Uptime         | TBD      | INTEGER      | {{sect-uptime}}   | OPTIONAL     |
| Bootcount      | TBD      | INTEGER      | {{sect-bootcount}}| OPTIONAL     |
| Bootseed       | TBD      | BIT STRING   | {{sect-bootseed}} | OPTIONAL     |
| Dloas          | TBD      | SEQUENCE OF Dloa | {{sect-dloas}}    | OPTIONAL     |
| Endorsements   | TBD      | SEQUENCE of Endorsement | {{sect-endorsements}} | OPTIONAL |
| Manifests      | TBD      | ??           | {{sect-manifests}} | OPTIONAL    |
| Measurements   | TBD      | ??           | {{sect-measurements}} | OPTIONAL    |
| Measres        | TBD      | ??           | {{sect-measres}}   | OPTIONAL    |
| Submods        | TBD      | ??           | {{sect-submods}}   | OPTIONAL    |
| Iat            | TBD      | Time         | {{sect-iat}}       | RECOMMENDED |
| FipsMode       | TBD      | Boolean      | {{sect-fipsmode}}  | RECOMMENDED |
| VendorInfo     | TBD      | TYPE-IDENTIFIER | {{sect-vendorinfo}}| OPTIONAL    |
| NestedEvidences| TBD      | SEQUENCE OF PkixEvidenceStatement | {{sect-nestedevidences}} | OPTIONAL |
| Nonce          | TBD      | OCTET STRING | {{sect-nonce}}     | OPTIONAL    |

5.2. Key Claims

| Claim          | OID      | Value        | Section           | Status       |
| --------       | -------- | ------------ | ----------------- | ------------ |
| KeyId          | TBD      | IA5String    | {{sect-keyid}}    | OPTIONAL     |
| PubKey         | TBD      | OCTET STRING | {{sect-pubkey}}   | RECOMMENDED  |
| Purpose        | TBD      | CHOICE       | {{sect-purpose}}  | RECOMMENDED  |
| NonExportable  | TBD      | BOOLEAN      | {{sect-nonexportable}} | RECOMMENDED |
| Imported       | TBD      | BOOLEAN      | {{sect-imported}} | RECOMMENDED  |
| KeyExpiry      | TBD      | Time         | {{sect-keyexpiry}}| OPTIONAL     |

Even though no specific claims are required, a Verifier or Relying Party MAY reject an Evidence claim if it is missing information required by the appraisal policy. For example, a Relying Party which requires a FIPS-certified device SHOULD reject Evidence if it does not contain sufficient information to determine the FIPS certification status of the device.¶

5.3. Device Identifier

Devices assigned a Universal Entity ID compliant with RATS EAT SHOULD provide this in the Ueid or Sueid claim. Devices with a traditional human-readable serial number SHOULD provide this in the Hwserial claim. Both MAY be provided.¶

The set {OemID, Hwmodel, Hwversion, Hwserial}, when provided, SHOULD represent a universally unique identification of the device. Where applicable, {OemID, Hwmodel, Hwversion} SHOULD match the way the device is identified in relevant endorsements, such as published FIPS or Common Criteria certificates.¶

   id-ce-evidence-ueid OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_ueid }

   claim_ueid ::= SEQUENCE {
       type    INTEGER ( RAND(1), EUI(2), IMEI(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-sueids OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_sueids }

   claim_sueids ::= SEQUENCE {
       label   OCTET STRING,
       type    INTEGER ( RAND(1), EUI(2), IMEI(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-oemid OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_oemid }

   claim_oemid ::= SEQUENCE {
       type    INTEGER ( PEN(1), IEEE(2), RANDOM(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-hwmodel OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_hwmodel }

   claim_hwmodel ::= OCTET STRING

   id-ce-evidence-hwversion OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_hwwversion }

   hwversion ::= OCTET STRING

5.4. Environment Identifier

EnvID EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBD

This claim MAY be used to identify a partition within a cryptographic device, or a logical environment that spans multiple cryptographic devices such as a Security World or a cloud tenant. The format of these identifiers will be vendor or environment specific.¶

5.5. Software Identifier

Swname EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.6
Swversion EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.7

SwName and Swversion together identify the device firmware and SHOULD match the way the firmware is identified in relevant endorsements, such as published FIPS or Common Criteria certificates.¶

5.6. OEM Boot

Oemboot EVIDENCE-CLAIM ::= BOOLEAN IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.8

5.7. Dbgstat (Debug Status)

The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities and diagnostic hardware built into chips. It applies to any software debug facilities related to privileged software that allows system-wide memory inspection, tracing or modification of non-system software like user mode applications.¶

See Section 4.2.9 of [I-D.ietf-rats-eat] for a description of this claim and the semantic of the values in the enumerated list.¶

The dbgstat claim is defined as follows:¶

Dbgstat EVIDENCE-CLAIM ::= CHOICE {
    enabled                         [0] IMPLICIT NULL,
    disabled                        [1] IMPLICIT NULL,
    disabled-Since-Boot             [2] IMPLICIT NULL,
    disabled-Permanently            [3] IMPLICIT NULL,
    disabled-Fully-and-Permanently  [4] IMPLICIT NULL
}
  -- semantics defined in rats-eat-4.2.9

5.8. Location

Location EVIDENCE-CLAIM ::= ???? IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.10

Most HSMs will likely not know their own physical location, but cryptographic modules on mobile devices may.¶

5.9. Uptime

The "uptime" claim contains the number of seconds that have elapsed since the entity or submodule was last booted.¶

Uptime EVIDENCE-CLAIM ::= INTEGER IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.11

5.10. Bootcount {sect-bootcount}

The "bootcount" claim contains a count of the number times the entity or submodule has been booted. Support for this claim requires a persistent storage on the device.¶

Bootcount EVIDENCE-CLAIM ::= INTEGER IDENTIFIER BY TBD
  -- semantics defined in rats-eat-4.2.12

5.11. Bootseed

The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (e.g., a certain UEID).¶

This value is usually public. It is not a secret and MUST NOT be used for any purpose that a secret seed is needed, such as seeding a random number generator.¶

Bootseed EVIDENCE-CLAIM ::= BIT STRING IDENTIFIED BY TBD
  -- semantics defined in rats-eat-4.2.13

5.12. dloas (Digital Letters of Approval)

The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA is a document that describes a certification that an entity has received. Examples of certifications represented by a DLOA include those issued by Global Platform and those based on Common Criteria. The DLOA is unspecific to any particular certification type or those issued by any particular organization.¶

Dloas EVIDENCE-CLAIM ::= SEQUENCE SIZE (1..MAX) OF Dloa

Dloa ::= SEQUENCE IDENTIFIED BY TBD {
    dloaRegistrar IA5STRING,
    dloaPlatformLabel UTF8STRING,
    dloaApplicationLabal [0] IMPLICIT UTF8String OPTIONAL
}
  -- semantics defined in rats-eat-4.2.14

5.13. Endorsements

This claim allows referencing third party endorsements; for example from the device vendor or a certification such as FIPS or Common Criteria. The content MAY be referenced by URI, or placed directly inline, but either way, the endorsement content or its URI MUST be known by the attester at the time that the evidence is generated.¶

Endorsements EVIDENCE-CLAIM ::= SEQUENCE SIZE (1..MAX) OF Endorsement

Endorsement ::= CHOICE IDENTIFIED BY TBD {
    uri     [0] IMPLICIT IA5String,
    content [1] IMPLICIT OCTET STRING
}

EDNOTE: this needs a bit of thought about what types of endorsements we will likely see, and whether OCTET STRING is the right format.¶

5.14. Manifests

TODO -- rats-eat-4.2.15¶

5.15. Measurements

TODO -- rats-eat-4.2.16¶

5.16. Measres (Software Measurement Results)

TODO -- rats-eat-4.2.17¶

5.17. Submods (Submodules)

TODO -- rats-eat-4.2.18¶

5.18. iat (Issuance Time)

The time at which the evidence was created. Here we differ from the iat claim in rats-eat-4.3.1 in that we use the PKIX time format Time instead of the 64-bit CBOR time structure.¶

Iat EVIDENCE-CLAIM ::= Time

It is recognized that many HSMs, especially if air-gapped, will not have an accurate system clock. If the system is not anticipated to have a reliable clock, then this claim SHOULD be omitted and the Nonce claim used instead.¶

5.19. intuse (Intended Use)

Intuse EVIDENCE-CLAIM ::= CHOICE IDENTIFIED BY TBD {
    generic              [1] IMPLICIT NULL,
    registration         [2] IMPLICIT NULL,
    provisioning         [3] IMPLICIT NULL,
    certificateIssuance  [4] IMPLICIT NULL,
    proofOfPossession    [5] IMPLICIT NULL
}
  -- semantics defined in rats-eat-4.3.3

Note: tags intentionally started at 1 to align with EAT. If the IANA registry of intended use claims is extended, then the this CHOICE MAY be extended using the same tag values as indicated in the EAT registry.¶

5.20. FipsMode

The cryptographic module was booted in FIPS mode, including the required self-tests and any other requiremnts of its FIPS certificate.¶

Note to verifiers and relying parties: "FIPS Mode" does not imply "FIPS Certified". For example, a device may have a FIPS Mode even if the device was never submitted for FIPS certification. This claim SHOULD only be taken in conjunction with a valid FIPS certification for this hardware and software version, and appraising any other claims as required by the FIPS certification.¶

FipsMode EVIDENCE-CLAIM ::= BOOLEAN IDENTIFIED BY TBD

5.21. VendorInfo

This claim provides a place for vendor to place propriatary data; i.e. any proprietary data that does not fit in any other claim.¶

VendorInfo ::= TYPE-IDENTIFIER IDENTIFIED BY TBD

Vendors must specify an OID and data type for their VendorInfo, and communicate this to verifiers who wish to parse this data.¶

5.22. NestedEvidences

NestedEvidences EVIDENCE-CLAIM ::= SEQUENCE OF PkixEvidenceStatement IDENTIFIED BY TBD

Composite devices may produce multiple signed evidence statements that need to be signed in a hiearchical manner. PkixEvidenceStatements MAY be nested.¶

5.23. Nonce

The "nonce" claim is used to provide freshness.¶

The Nonce claim is used to carry the challenge provided by the caller to demonstrate freshness of the generated token. The following constraints apply to the nonce-type:¶

• The length must be reasonable as it may be processed by end entities with limited resources. Therefore, it is RECOMMENDED that the length does not exceed 64 bytes.¶

• Only a single nonce value is conveyed.¶

The nonce claim is defined as follows:¶

Nonce EVIDENCE-CLAIM ::= OCTET STRING IDENTIFIED BY TBD

See Section 4.1 of [I-D.ietf-rats-eat] for a description of this claim.¶

5.24. KeyId

An identifier for the subject key. The format MAY be vendor-specific, but MUST be an ASCII value (IA5String).¶

KeyId EVIDENCE-CLAIM ::= IA5String IDENTIFIED BY TBD

5.25. PubKey

The subject public key being attested by this evidence.¶

PubKey EVIDENCE-CLAIM ::= OCTET STRING IDENTIFIED BY TBD

5.26. Purpose

TODO: align with PKCS#11 Purposes¶

Purpose EVIDENCE-CLAIM ::= CHOICE IDENTIFIED BY TBD {
   ... Sign, Decrypt, Unwrap, etc..

}

5.27. NonExportable

TODO align with PKCS#11¶

NonExportable EVIDENCE-CLAIM ::= BOOLEAN IDENTIFIED BY TBD

5.28. Imported

TODO align with PKCS#11¶

Imported EVIDENCE-CLAIM ::= BOOLIAN IDENTIFIED BY TBD

5.29. KeyExpiry

If the key has a known expiry time or "not after" date.¶

KeyExpiry EVIDENCE-CLAIM ::= Time

5.30. Unrecognized claims

This document does not define an exhaustive list of claims. New claims may be added in the future, including proprietary ones. As such, parsers SHOULD expect to encounter unrecognized claims, and to handle them gracefully.¶

In general, the correct behaviour for a verifier will be to start with an appraisal policy of claims to look for, and where appropriate the expected values (for example, FipsMode: true), and any additional claims that may be in the evidence SHOULD be ignored.¶

6.1. ASN.1 Module

This section provides an ASN.1 Module [X.680] for the Evidence Claims certificate extension, and it follows the conventions established in [RFC5912] and [RFC6268].¶

<CODE BEGINS>
     EvidenceClaimsCertExtn
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-evidenceclaims(TBD) }

     DEFINITIONS IMPLICIT TAGS ::=
     BEGIN

     IMPORTS
       EXTENSION
       FROM PKIX-CommonTypes-2009  -- RFC 5912
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkixCommon-02(57) } ;

     -- Evidence Claims Certificate Extension

     ext-EvidenceClaims EXTENSION ::= {
       SYNTAX EvidenceClaims
       IDENTIFIED BY id-pe-evidenceclaims }

     -- EvidenceClaims Certificate Extension OID

     id-pe-evidenceclaims OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-pe(1) 34 }

     -- Evidence Claims Certificate Extension Syntax

     EvidenceClaims ::= SET SIZE (1..MAX) OF EVIDENCE-CLAIM

     END

<CODE ENDS>

7.1. API for requesting evidence from an attesting device

While it is strictly outside the scope of this document to specify how a calling application can request evidence from a cryptographic device, two modes are suggested.¶

8.1. Publishing Evidence in a certificate

The extension MUST NOT publish in the certificate any privacy-sensitive information that could compromise the end device. What counts as privacy-sensitive will vary by use case. For example, consider a few scenarios:¶

First, consider a Hardware Security Module (HSM) backing a public code-signing service. The model and firmware patch level could be considered sensitive as it could give an attacker an advantage in exploiting known vulnerabilities against un-patched systems.¶

Second, consider a certificate issued to a end-user mobile computing device, any sort of unique identifier could be used as a super-cookie for tracking purposes.¶

Third, consider small IoT devices such as un-patchable wireless sensors. Here there may be no privacy concerns and in fact knowing exact hardware and firmware version information could help edge gateways to deny network access to devices with known vulnerabilities.¶

Beyond that, a CA MUST have a configurable mechanism to control which information is to be copied from the provided Evidence into the certificate, for example this could be configured within a certificate profile or Certificate Practice Statement (CPS) and this must be considered on a case-by-base basis. To protect end-user privacy, CA operators should err on the side of caution and exclude information that is not clearly essential for security verification by relying parties. Avoiding unnecessary claims also mitigates the risk of targeted attacks, where an attacker could exploit knowledge of hardware versions, models, etc.¶

10.1. OIDs for Evidence Claims Certificate Extension

For the EvidenceClaims certificate extension in Section 6, IANA is requested to assign an object identifier (OID) for the certificate extension. The OID for the certificate extension should be allocated in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1).¶

For the ASN.1 Module in Section 6.1, IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).¶