Re: [Rats] Reducing YANG output objects with the tpm12-challenge-response-attestation RPC

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 09 October 2020 12:39 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06233A0F00; Fri, 9 Oct 2020 05:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UYr4Xtvh; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=hmMOAaMg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luGiwyZ6pjCz; Fri, 9 Oct 2020 05:39:57 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEED3A0EF6; Fri, 9 Oct 2020 05:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31736; q=dns/txt; s=iport; t=1602247197; x=1603456797; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H9+DAQZG9Kur2prupam1spzoiSlQqH+tG9lMIKe85ok=; b=UYr4Xtvhmih6Z9d3JLjhOouGq0gY/74Y+OX+tkzaQCfifDdy4MFvkAFp vUGV8gf1n3gug4vsWe8RyrtALU5Ofn6WTYjE7/F9O/pk+q8FrwVtY2XX6 /MTIVheI3/8haRg9UN1Q1/X0083b4oZC8Mn3DcZc9/ntZdzRCPVIW0nVW I=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A0zNU2xX1sBAVLnC1OkKgugS9xe/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+Huf5BgvDd9aHtRWJG5oyO4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/vjIXEw?= =?us-ascii?q?/0cwt4OuqzHZTd3Iy70umo8MjVZANFzDO2fbJ1KkCwqgPc/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQDHWYBf/5hdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BIy8jLgdwDh4tLywKh3kDjVGHZo4tgmiBQoERA1UEBwE?= =?us-ascii?q?BAQoDAQEnBgIEAQGESgKCEwIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQE?= =?us-ascii?q?BAQISGxMBASUEDgEPAgEIEQQBASEHBwIwFAkIAQEEDgUIBhSDBTiBRk0DHw8?= =?us-ascii?q?BDp18AoE5iGF0gTQTgm4BAQWBNFEDgyQYggkHAwaBOIFTgR+GMYQSG4FBP4E?= =?us-ascii?q?RQ4IfLj6BeWMDgSkBEgEjKwmDFIItkCOCZodngRmbVQqCaIRLgl+BVpIJoTa?= =?us-ascii?q?THIpwlTECBAIEBQIOAQEFgWsjZ3BwFYMkUBcCDY4fCwEXFIM6hRSFQnQCEiM?= =?us-ascii?q?CBgoBAQMJfIsILYEGAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.77,355,1596499200"; d="p7s'?scan'208,217";a="575359182"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 12:39:54 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 099CdswL027214 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2020 12:39:54 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 07:39:53 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 07:39:53 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 9 Oct 2020 07:39:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lk+jm0tt9XBKp+c9560YGbQtgqbX3BkjPJTsu5+ZFp1Qc2TrKPo32kYCLgl6qxdSswFZwqnsztbmhZeYWrYXvNvEHxKMxFKR/rg8lUS4AAovJP+ZrGksFjCYifjrectYtc+zZHfua9j3SDOJtPDcQ8XlPjnsOR2ELUlQnlIhBTW8+LEbTXzwSZp5wCkFkh9A953+08pm8oSBvVg4VrmMfn/UCQ8MgUdcLrRa4RIl7xwk1Kxs5E1BoM541X7Kc8yZ87mwZSXKTQjqKeYSBJC5HDk/m5iKP43aga/pRS3lQPD6kAkulLlRSjYaK8HoULStJvrYrwkCZvO+2x53lzqShw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vilBK7c7cxS/2un0zbV0cpbchM3HWmr9gmfRu1FRa48=; b=TKq3J5+neQVeVSqNW1+SP53BYopXrspXCk3w2lFCph9moS1+xc3r0bsptuxvAdSnuWXWO90rSOA/TC+YwJrjUrSSvgzDjcHZr7CM17BpCY9KxJDfM6Gr9xcinV9JP64cOxkUAFhdC94EnVGrexrSuXI6nULe1p3xKvrv8GvGgRKyQi5wS4Wc6KEzRWq45G83S74WhU2CplVpof93jBoAKk3GndjIYC3RoJiDaedBsSKtRycRwlEH+vRVVyLhQK7rOVJ0Tix8buI+KU32H03UrMPG9v+pUhqhj25J4e4J5dwe6k5zFPMVD8wXlV+h/n71NPGWrXDE+wzLIVpuMEimPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vilBK7c7cxS/2un0zbV0cpbchM3HWmr9gmfRu1FRa48=; b=hmMOAaMgc6mIl19eYh+wT560TFGnKUx8gYfK8iFvU70Xsi54rSrpsJv4m5Wz66boyzHtRcoNhkxdrbx4F+QWd4ZITgbWl0h2G6ep/yLSEBiyiRulk5npT7Lx3BmkEbDyILJkMj+CnXBA2RqLHSemHiCqEnelUkrAsvmIm+D3N5A=
Received: from SN6PR11MB3135.namprd11.prod.outlook.com (2603:10b6:805:d5::20) by SN6PR11MB2847.namprd11.prod.outlook.com (2603:10b6:805:55::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Fri, 9 Oct 2020 12:39:52 +0000
Received: from SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::b819:72bd:80b2:d2e0]) by SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::b819:72bd:80b2:d2e0%4]) with mapi id 15.20.3455.027; Fri, 9 Oct 2020 12:39:52 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Guy Fedorkow <gfedorkow=40juniper.net@dmarc.ietf.org>, "Laffey, Tom (HPE Aruba)" <tom.laffey@hpe.com>
CC: "rats@ietf.org" <rats@ietf.org>, "draft-ietf-rats-yang-tpm-charra@ietf.org" <draft-ietf-rats-yang-tpm-charra@ietf.org>, Puru Kulkarni <puruk@juniper.net>, William Bellingrath <wbellingrath@juniper.net>, "Panwei (William)" <william.panwei@huawei.com>, "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>, "Eckel, Michael" <michael.eckel@sit.fraunhofer.de>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>
Thread-Topic: Reducing YANG output objects with the tpm12-challenge-response-attestation RPC
Thread-Index: Adac5ZonsmNnYPBmSvKhkjUhhfk9pgBUi8jwAABCQOA=
Date: Fri, 9 Oct 2020 12:39:52 +0000
Message-ID: <SN6PR11MB3135C1D1E78C3E4DF58046C0A1080@SN6PR11MB3135.namprd11.prod.outlook.com>
References: <BYAPR11MB312522739A09FA46937D8F29A10A0@BYAPR11MB3125.namprd11.prod.outlook.com> <BLAPR05MB7378320B18D303CAD8E41970BA080@BLAPR05MB7378.namprd05.prod.outlook.com>
In-Reply-To: <BLAPR05MB7378320B18D303CAD8E41970BA080@BLAPR05MB7378.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-09T12:34:25Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e4e2e2a8-03b2-418e-9127-5aec8bf4cc1c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.18.114.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d0a04e8b-f304-4641-04ef-08d86c506b25
x-ms-traffictypediagnostic: SN6PR11MB2847:
x-microsoft-antispam-prvs: <SN6PR11MB28475FFC57E3E014931D0048A1080@SN6PR11MB2847.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AHKNYf5tXNoFFMa5lbJDGjgz07o4lDQIc8n/n35ajf2WTiap5QS/TpdXF6h3hQtES2/rj6jGyYM2aE3RfP72eA/hyvbqesHJMe6l/sYhF6AdNg5wUns3P055JrqLKZsTtNVaHsb3xudzfFUeWb4yllg/vYa9KJANbNBZ/eamQaGoBTnQrheqLqza/XVuN/9BJPEA5W6aBoQaWnPH9CdJ68fIruzYa110NZh/Tz98mRLp4EAg/4lVjzrmpHqKq3sqyInVJhC+AbJInvLA+JwOWLnuhmAHAgGEHqy3IyKF+k5zD8bjvQSswFFLQFdDrqFy1vAcriHIj6TnPtEgKMcOMNEjFfbrtkcmCI+6QcpAhWWZv4YpXTh19D4+EuxoFpo12RSvDUujuGonkhjS23XCL7RyVQWgM/sgVf0TMe9EqHU8vJ4j2n8QOFwu1YPcUjtt3yiCALaIotfZhydQcC+m6PWcrVA2jsN4hyZWxqL8QUo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3135.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(366004)(376002)(346002)(316002)(52536014)(4326008)(66476007)(53546011)(110136005)(66616009)(5660300002)(86362001)(6506007)(76116006)(66946007)(33656002)(66446008)(55016002)(66556008)(83380400001)(966005)(64756008)(186003)(26005)(478600001)(166002)(7696005)(99936003)(83080400001)(7416002)(8936002)(54906003)(9686003)(71200400001)(2906002)(8676002)(15398625002)(43620500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: CMHypmTQNk5pKXfCa4xky6RiqtUkQhx24pJ/bqE8/2faxzYtKjFbzzSpW+H9oOQUm77KJCA7WM2glJ0sMydgGWgOe2YmVUDdZhIwD0fJFZpPSjU7JAVsUBuJXP6wwUDwtm9y1RzJUzqa/kpaX5M1rr+wa71o9HtPCSGEpLHdGFX2oLcGj25A1dbPG0AfD1gBX/ByqXGkUqiyQKK7Qr97i+9PuGtm1wd645GCzWHmSFCm/JSKqp8HLh3293XhX0iV4cHyMqsVwqD0CEdChTp6Zm8Hyg2fiaM8InAedhw11TyzyH87QNYdpUZQzAKkBqQH6scvM3XR0PKoQtt4AoD41Zu8sfJWOOnNI6jfWBtvTmreBTT1e30kNMnibDwFW63Hw3P4sE8wSt7SJK3zDIxNPQFe0f6BE4/OY3/8sx1Xq+rRLwTjBTt6aip+DtOgNxREq4B8NBQEBf7Q2cCdnneOwBHo2iVPmcX9NkJkQUEzbImvPsh7En0pY5lJe+o363QUNa/VCsvIVNiA1ufIZ2TFGjsYF2nzEh7PGofr9utg/JDVdkIChisfvsLzWzBEWMPe+1bC3lA3zGErhAyQNqZR3NRcexFDkItH4DgXO7D0ywwMiCtCG1ti3mjD6kQnokqiMa0Vmi2piXrULPPBIlBo4g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="----=_NextPart_000_1269_01D69E17.BF687A20"; protocol="application/x-pkcs7-signature"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3135.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d0a04e8b-f304-4641-04ef-08d86c506b25
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 12:39:52.1668 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: taok/4zw2FXcSGTM8vBZ3RHnHExWz9a+dWYVDReBIxRstFcmtKtpVxAO0aZUdBwM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2847
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/-kN1j2UH8pWSPb3GgqZkiY1D498>
X-Mailman-Approved-At: Fri, 09 Oct 2020 05:41:03 -0700
Subject: Re: [Rats] Reducing YANG output objects with the tpm12-challenge-response-attestation RPC
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 12:40:00 -0000

I am very happy to keep the TPM1.2s.   I am just trying to make sure our
design drives minimized operations and development efforts.

 

Eric

 

From: Guy Fedorkow, October 9, 2020 8:34 AM



Hi Eric,

  We have a lot of TPM1.2's out there - I'd be reluctant to obsolete them to
save a paragraph in the YANG model.

As to the structure of the model; Tom Laffey is probably the world's expert
(sorry Tom), but I'll find an internal reviewer for an informed opinion.

Thanks

/guy

 

 

 

Juniper Business Use Only

From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> > On Behalf
Of Eric Voit (evoit)
Sent: Wednesday, October 7, 2020 4:36 PM
To: Panwei (William) <william.panwei@huawei.com
<mailto:william.panwei@huawei.com> >; Birkholz, Henk
<henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> >;
Eckel, Michael <michael.eckel@sit.fraunhofer.de
<mailto:michael.eckel@sit.fraunhofer.de> >; Guy Fedorkow
<gfedorkow@juniper.net <mailto:gfedorkow@juniper.net> >; Laffey, Tom (HPE
Aruba) <tom.laffey@hpe.com <mailto:tom.laffey@hpe.com> >;
frank.xialiang@huawei.com <mailto:frank.xialiang@huawei.com> 
Cc: rats@ietf.org <mailto:rats@ietf.org> ;
draft-ietf-rats-yang-tpm-charra@ietf.org
<mailto:draft-ietf-rats-yang-tpm-charra@ietf.org> 
Subject: [Rats] Reducing YANG output objects with the
tpm12-challenge-response-attestation RPC

 

[External Email. Be cautious of content]

 

I am hoping we can simplify what is in Charra's TPM1.2 quote into something
similar to what is now in the TPM2.0 quote.    Does anyone know who wrote
the original TPM1.2 RPC for the Charra YANG module?   If you did, can you
chime in on the questions below?

 

More specifics on the request:

Right now in the tpm20-challenge-response-attestation RPC output are TPM
protected objects enclosed within TPMS_QUOTE_INFO.  

 


Definition of TPMS_QUOTE_INFO Structure

--------------------------------------------------------- 

typedef struct { 

    TPML_PCR_SELECTION pcrSelect; 

    TPM2B_DIGEST pcrDigest; } 

TPMS_QUOTE_INFO;

 

See Table 115 - of 

https://trustedcomputinggroup.org/wp-content/uploads/TCG_TSS_Overview_Common
_Structures_v0.9_r03_published.pdf

 

The enclosed TPM2B_DIGEST is calculated across multiple PCRs.  Having to
verify across multiple PCRs does not necessarily make it easy for a Verifier
to appraise just the minimum set of PCR information which has changed since
the last received TPM2B_DIGEST.  Put another way, why should a Verifier
reconstruct the proper value of all PCR Quotes when only a single PCR has
changed?  

 

To help this happen, if the Attester does know specific PCR values, the
Attester can provide these individual values via "unsigned-pcr-values".   By
comparing this information to the what has previously been validated, it is
possible for a Verifier to confirm the Attester's signature while
eliminating significant processing.  Additionally, processing where KGVs are
exposed can be safely eliminated.

 

This is a long way of asserting that there is not redundant TPM information
carried in tpm20-challenge-response-attestation RPC response.   This is a
good thing.

 

We should provide the same level of scrutiny to the TPM1.2 objects.  We
should eliminate redundant objects from the
tpm12-challenge-response-attestation RPC.

 

If we were to eliminate redundant objects from the TPM1.2 Quote Response, I
am know that we can eliminate the following objects:

*	leaf major
*	leaf minor
*	leaf rev-Minor
*	leaf rev-Minor

 

I also think we can eliminate the following:

*	fixed  -- at this is a response to the RPC question
*	locality-at-release

 

Looking beyond these obvious objects, I am wondering if there is anyone
needing to differentiate between tpm12-quote1 and tpm12-quote2.   As TPM1.2
is going to be phased out as equipment gets changed, it seems to make little
sense to support both variants if both are not being actively championed by
someone.  In fact, I suspect that the YANG model can be updated so that it
need not care about quote1 and quote2.   Can whomever included both quote1
and quote2 articulate why the must be a market need to support both going
forward?   

 

If we can eliminate either quote1 or quote2 specifics, I suspect we could
use the exact same structure as part of the RPC response as was used for
TPM2.   It would look something like:

 

  + tpm12-challenge-response-attestation

    ...

         +--ro output

            +--ro tpm12-attestation-response* []

               +--ro certificate-name?      certificate-name-ref

               +--ro TPMS_QUOTE_INFO        binary

               +--ro quote-signature?       binary

               +--ro up-time?               uint32

               +--ro node-id?               string

               +--ro node-physical-index?   int32 {ietfhw:entity-mib}?

               +--ro unsigned-pcr-values* []

                  +--ro TPM20-hash-algo?   identityref

                  +--ro pcr-values* [pcr-index]

                     +--ro pcr-index    pcr

                     +--ro pcr-value?   binary

 

I would love to get people's thoughts on what is above, and what might be
mandatory to support in tpm12-challenge-response-attestation RPC output.

 

Thanks,

Eric

 

 

Eric Voit 

Principal Engineer

.:|:.:|:. Cisco Systems, Inc.