Re: [Rats] WGLC for draft-ietf-rats-tpm-based-network-device-attest

"Panwei (William)" <> Mon, 12 October 2020 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC4F53A0E71; Mon, 12 Oct 2020 08:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y9XEZ_zkRBc3; Mon, 12 Oct 2020 08:58:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61C923A0E6D; Mon, 12 Oct 2020 08:58:36 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 2245EF4F6A8F2E88DBF4; Mon, 12 Oct 2020 16:58:32 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 16:58:31 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 23:58:29 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Mon, 12 Oct 2020 23:58:29 +0800
From: "Panwei (William)" <>
To: "" <>
CC: "" <>
Thread-Topic: WGLC for draft-ietf-rats-tpm-based-network-device-attest
Thread-Index: AQHWj7vQmCquGJdJ8UCU7FSWkWcz36mULaRQ
Date: Mon, 12 Oct 2020 15:58:28 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_bbacd6e97a74452a9d3e08b7b834a078huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Rats] WGLC for draft-ietf-rats-tpm-based-network-device-attest
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Oct 2020 15:58:39 -0000

Hi authors,

I’ve reviewed the -04 doc and I have some comments which I wish to be resolved before forwarding the doc to IESG.

1.      About the terminology, some new terms are introduced into the architecture doc recently (please see github), including Reference Values and Reference Values Provider. And the term Endorser or Endorsement doesn’t cover the concept of reference measurements any more. So this RIV doc may also need to update the use of terms correspondently.

2.      In section 1.4, it says:

   5.  Finally, Appraisal of Evidence occurs.  As the Verifier and

       Relying Party roles are often combined within RIV, this is the

       process of verifying the Evidence received by a Verifier from the

       Attesting device, and using an Appraisal Policy to develop an

       Attestation Result, used to inform decision making.  In practice,

       this means comparing the device measurements reported as Evidence

       with the Attester configuration expected by the Verifier.

       Subsequently the Appraisal Policy for Attestation Results might

       match what was found against Reference Integrity Measurements

       (aka Golden Measurements) which represent the intended configured

       state of the connected device.

In the sentence “Subsequently the Appraisal Policy for Attestation Results might match what was found against Reference Integrity Measurements”, I think “the Appraisal Policy for Attestation Results” should be “the Appraisal Policy for Evidence”.

3.      About the PCR assignment figure in Section 2.1.1, is this assignment a reference for the implementers? Or is this a normative rule that all implementers need to follow? If latter, I think it’s more appropriate to standardize this assignment in TCG.

4.      In section 2.1.2, it says “It is important to recognize that PCR[0] is critical”. By saying so, what’s the real reason of why PCR[0] is critical? Is it critical because the position of the PCR (i.e., the PCR[0] is critical regardless of its usage), or because it is used to store the measurement of the Root of Trust for Measurement?

5.      In section 2.2, it says “In TPM application, the Attestation key MUST be protected by the TPM, and the DevID SHOULD be as well.” Here says the DevID “SHOULD” be protected by the TPM, while other places use “MUST”, like section 2.3 and section 3.1.1.

6.      There are two terms “Attestation Key (AK)” and “Attestation Identity Key (AIK)” used in different places, but I think they are the same thing. So I suggest only using one term.

7.      There are some asymmetrical brackets in the doc, e.g., the last paragraph of section 2.2, the brackets after “[EFI-TPM]” in section 2.3 and 2.4.2.

8.      The reference of [Platform-DevID-TPM-2.0] can be updated, I think its current name is “TPM 2.0 Keys for Device Identity and Attestation” and its link is Please correct me if I’m wrong.

Regards & Thanks!
Wei Pan

From: RATS [] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, September 21, 2020 10:06 AM
Subject: [Rats] WGLC for draft-ietf-rats-tpm-based-network-device-attest

RATs participants,

This is a WGLC for draft-ietf-rats-tpm-based-network-device-attest, please provide comments and feedback by October 12, 2020.
The draft can be found in:

Best, Nancy (on behalf of the RATs chairs)