ietf-rats-wg / draft-ietf-rats-ar4si Goto Github PK

There are several ways for this to be determined by the Verifier. But it is a hard problem. Is there consensus that solution-level trustworthiness claims are ready to be tackled by the RATS WG?

Prior to the start of the IETF meeting, IANA takes a look at the documents that will be discussed on the agendas for working groups and we do a quick review to see if there are any IANA Considerations related issues. We reviewed draft-voit-rats-attestation-results. The IANA Considerations section currently says "See body". Any actions being requested need to be included in the IANA Considerations section. This includes any new registries being created, registrations in existing registries or adding this document as a reference to existing registries or registrations. RFC8126 and https://www.iana.org/help/protocol-registration offers some guidance as to what to include in the IANA section.

Need to convert to affirming, warning, contraindicated vs 0 & 1

In April, Vinnie asked for an interaction model which doesn't require a Verifier. This is for things like SGX where the provable identity of the MRSIGNER is sufficient to the Relying Party. The specific comment was: The question then is whether we need some form of time interval tracking between Verifiers A & B. I believe it to be useful to understand the delta in time between the creation of the original Attestation Results, and their receipt on the Relying Party. The one time I can think of when this might not be necessary is when the Relying Party trusts that the Attester cannot be meaningfully changed from the outside over time. (E.g., a specific MRENCLAVE can expose no changing Evidence to Verifier A over time, and this MRENCLAVE is trusted to be unable to mimic another MRENCLAVE or replay Attestation Evidence about another MRENCLAVE.) In such a case, nonce#2 from figure 1 can be safely dropped. I will propose text to this effect into the draft.

As per the latest draft of AR4SI, specific Trustworthiness Claim enumeration for configuration is as under:

0: No assertion
1: Verifier cannot parse unexpected Evidence.
-1: Verifier malfunction
2: The configuration is a known and approved config.
3: The configuration includes or exposes no known vulnerabilities.
32: The configuration includes or exposes known vulnerabilities.
96: The configuration is unsupportable as it exposes unacceptable security vulnerabilities.
99: Cryptographic validation of the Evidence has failed.

However, there could be a use case where the Verifier is not aware of
a specific Attester Configuration. So it cannot say anything concrete about the
specific configuration.

Hence we propose, we add another enumeration example below:
36: The configuration is unknown to the Verifier

Thomas H has agreed to provide some text on the following issue:

In discussions in the GSA TIES trusted supply-chains group, there has been some usage of the term "trust score".

So there could be the situation in which (a) the supply-chain entities have their collective understanding of the "trust score" of the composition of BOM/SBOM items, and (b) the Verifier and RP have a slightly different (or very different) notion of "trust score" from folks in (a).

Should we RECOMMEND that new evidence formats that want to be compatible with AR4SI define which claims are relevant to each trustworthiness vector bucket?

(The recommendation could go as far as even suggest appropriate values for specific circumstances.)

For reference, we have started looking at this for PSA here

When we have the new CC-related definitions being worked in the CCC nailed down, we should update the draft accordingly.

EDIT: To be clear, here "terminology" refers to CC models and their mapping to Attester and Attesting Environments (i.e., §2.2.1 OF -03).

Every must is a MUST and will be fixed to all caps by rfced (if that syntax reaches that gateway function). The multi-person discussion has to happen and we do not have to do that now in this PR.

Ned asserts that specific wording appears to conflict with other adopted drafts. E.g., Section 2.1 – Non-reputable Identity Evidence and subsequent use of ‘non-reputable’ in the context of identifying the Attester or an Attesting Environment. Given a DAA key as Attesting Environment identity, the objective is to allow reputable Attester instance identity but non-reputable Attester class identity. Eric responded that in DAA, perhaps the term DAA credential should be formally defined. What DAA says now is "Attestation Evidence SHOULD be cryptographically associated with an identity document that is a randomised DAA credential." Additionally, perhaps the "Attester Identity ('attesterIdentity')" principle in Section 5 should be refined to "Anonymous Attester Identity"? In any case, DAA seems to have a more narrow definition of identity than draft-voit-rats-attestation-results. In this draft, the non-reputable class itself be considered a form of identity. So I think the intent of both sets of text don't conflict, even if we don't have all the terms right. Also draft-voit-rats-attestation-results could easily import terms like "Anonymous Attester Identity" from DAA as being a valid form of identity. Having the group being identified is quite useful.

Hi Laurence,

From: Laurence Lundblade, March 14, 2022 2:18 PM

Hi Eric,

Hashing is one thing and HSM security is another.

You can have an attester that has HSM security and does no hashing. An example of this is a purpose-built HW that just provides identity.

You can have an attester that does lots of hashing of lots of things and isn’t an HSM in any sense. An example of this is an attester built into an operating system.

In my opinion, it is mandatory for the RATS WG to provide guidance on what AR claims might be legitimately be made about from different categories of Attesters. The objective of ar4si section 2.2.1 is to differentiate categories of Attester. I do accept your point that there are HSMs which don't do hashing. This insight helps improve the document. So I have just added a tracking issue with a suggestion to change the category name to "tpm-pcr-hashing".

If you want to propose additional HSM types which generate non-hash based evidence, that would be helpful. The intention/goal of a category should be to help restrict what AR claims might legitimately be made about an Attester.

When I copied text from the security levels definition, it was all about hardware security, not hashing. I don’t think any sort of hashing in an attesters architecture can stand in for hardware security. (And the security levels text could probably be improved).

(You know what I mean about hardware security right? These are defenses against attacks on the HW. For example, extra electrical circuits that shutdown the chip if the supply voltage is too low to prevent manipulation of the supply voltage to get the hardware to execute incorrectly. There are lots of these.)

Can you point to a definition for Hardware security? While I know in general what it means, but you can't define just the term based on examples. Nor can you define it with by saying "substantial defense". What is needed are one or more sentences which says what is covered and what is not.

Eric