[Rats] pub-key-id or certificate-name (was RE: Some new comments for CHARRA YANG module)

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 14 August 2020 20:26 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 50DDA3A07E8; Fri, 14 Aug 2020 13:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.588
X-Spam-Level:
X-Spam-Status: No, score=-9.588 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=bMrGI+j2; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=pUt1zxTI
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 3i4dvV802l1c; Fri, 14 Aug 2020 13:26:53 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B3D3A07E7; Fri, 14 Aug 2020 13:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32659; q=dns/txt; s=iport; t=1597436813; x=1598646413; h=from:to:cc:subject:date:message-id:mime-version; bh=7Si5UVZSDMEiXl5+m+IxZIgw/r9rGhXNwZvmuDKKwnY=; b=bMrGI+j2ReDLoT7iJwFWVJ6kGa1LkRICAAMIRfpEi5z/Zv+c8IHLXGvS odPygleTBloy2EMuNpj2ISpxmemFtKz3t+OT8g+FnTMhsYNueHEcfYOjM iA1zdohdkEbODESo38kmgENnRMJSq0F7OnLtqrVI+vZIAqUWZ7vAQO9Yw 0=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AgArVyBWwP+OEBgv6is79Iwjd37nV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuflFkOHR9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Zo2a56ngZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADD8jZf/5hdJa1eGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgSMvUQdwKy0vLAqHcwONVYdekQmCUwN?= =?us-ascii?q?VBAcBAQEJAwEBLQIEAQGBNYMXAoJHAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAy?= =?us-ascii?q?FcQEBAQMTGxMBATcBBA0BGQQBASEHCTAUCQkBBAENBQgGFIMFgX5NAw4RDwG?= =?us-ascii?q?oGQKBOYhhdIE0gwEBAQWFNBiCBwcJgTiBU4EeiiwagUE/gRFDgwuEPxUfgxS?= =?us-ascii?q?CLZAbiW+BGZsPCoJihDiCXJMsgn+JW5NFkjifPAIEAgQFAg4BAQWBaiOBV3A?= =?us-ascii?q?VO4JpUBcCDY4fDBcUgzqKVnQ3AgYKAQEDCXyPFgGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.76,313,1592870400"; d="p7s'?scan'208,217";a="559161791"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 20:26:52 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EKQpw1017787 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 20:26:52 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 15:26:51 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 15:26:51 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 16:26:50 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UnAy7FMPcCy7govOrSSwlUezBugPUmBskSJNl59c6EX3WeT5FELRbSz7TSgg1MHgT+IXZPCV5n4ue6qABp6Oig1iIpd40CWl0prqZoAQdwLV/9hZxeusLoJR6Xj5prEOr2bIfm+26wCHQGtiextBfmG79niof6BlH2QtEDDGEXd3I5zW2toycv4P8zDmwXg3aMfMaCbfddg4DPJxOedF2FfX+P47vH8cRHhKLBGgIjT8KGMTjhCGOZV8awFTBJ1EEK/Y14QGNkhJPBnh+VgDCEOBAN9PJV4n2nBhZ9NrJsTirdvGezeQGbdkfECW2ZMuD3tGbDWjvU4l19l1/uA9Ww==
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=fWSE3HOpExoAHuixGbUtUBQllHPD7K+5D0Nq82PKjT4=; b=Y1tfoweFbanyd+GYnW9Q7QTDIkVfCagB+OT/HXW2dLoVCRw301/uDtvoWqn5STC6RQWXYUsxIKn+uOc5XXQS9I/JBIzri8LBnksNhguK9HQuERGqu5kGHKD+FgMYGIYwnN9PsjYbar22ybPl0HNiTyzopvydN8mwY70MjlxIJAl++4k46pikcQSa2ujaGErivQ768CPVyp/noV0s5KuHBrq7+0VCeFrQ6STwHHtPZV0GBET2qC7mxEcrNEwEsuMymhIFP6itPcPCtid3i3M8id1coivNqgrFwpAIFKyrhA5rL9TannKlkExAzEX4A/O31GT/v+4vT9AeSqH+DVRpkQ==
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=fWSE3HOpExoAHuixGbUtUBQllHPD7K+5D0Nq82PKjT4=; b=pUt1zxTIorVWwufMYx97wsksXvZPFZUparS5emb0KE/qRKWjegu+6vOgFj+slRnAMvSUVT5xYGMeAAkBPL+yvl1ogsorsFMnnmPk9pMXES0nTxs13Cri+jDYj9pNPuElq5r5LQJaub8xH/jegZtrPtfq1P20HaYe3xOvKNKmLgE=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3041.namprd11.prod.outlook.com (2603:10b6:208:32::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 20:26:49 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::fcd5:b07d:e935:8956]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::fcd5:b07d:e935:8956%7]) with mapi id 15.20.3283.016; Fri, 14 Aug 2020 20:26:49 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "Panwei (William)" <william.panwei@huawei.com>, "draft-ietf-rats-yang-tpm-charra@ietf.org" <draft-ietf-rats-yang-tpm-charra@ietf.org>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: pub-key-id or certificate-name (was RE: Some new comments for CHARRA YANG module)
Thread-Index: AdZydYr3bRAH3uXPRXC7Q/7yPynr1A==
Date: Fri, 14 Aug 2020 20:26:49 +0000
Message-ID: <BL0PR11MB31229F61506488D13059C5DCA1400@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ac94fb7b-0645-4fd0-9f3b-08d840905f5b
x-ms-traffictypediagnostic: BL0PR11MB3041:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR11MB3041B46962BA41BABF0286C7A1400@BL0PR11MB3041.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: Ts03Orw2+HMmRupBDy0jP5cOqqkTjP2jO1JWBHqcVRSW7QIhoWJyEMogUWpqy7UoHkvOyDDnoi9WGR0f2Mkp8cVXFg794GXA/bI+shdiwamC/y8cOA0TPm1BKeEAHNoRzVHQOUaCIiBN8znoCuNlEiGYeJUU3FhIo9KEhYl/+Q+T5xzycKhL5LEIk4Sxm+zXaePtyd339aSJG6sbw2umuratMwq8mfNl5hiCVDrNpu6Sb2cv53iJJqcQ61bfLlEuwNmck4Z1+jrqHZzblvG3zxXB3R/AZjKDl1TSpfbCmCkqXqQxdVvvvdxq3bROdVp3npkx1A9oQvD2AOCk9K4pfQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(346002)(376002)(366004)(7696005)(4326008)(110136005)(6506007)(66556008)(316002)(8936002)(33656002)(26005)(5660300002)(52536014)(66946007)(53546011)(186003)(66446008)(66616009)(66476007)(64756008)(76116006)(86362001)(55016002)(9686003)(83380400001)(2906002)(8676002)(71200400001)(99936003)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 5U/4VwKA3pOlacqR5H4/WcFrJMdOstdKLDsGfkIXadfcpRN2YjhXSPHvRtfnwS0A6egrOFEtkQb5dHUJlGxpbwqsOtMBfmB7HJ27qJQN0OKRdSYvvAPVXWZ5ULobTG4IsVRHYRVvlB0Qddeh3rA9S9C4/TFAnYx4WPxb3kMHET0MB/XbDwGsLeg56ImL7wpRCsz4iRbC6Hrs3MnVNvb7DqAHA1UaBmUZFq217Wd4AqYHI4ZV/F5si3HbPS38qiLlQDul8LMaCfx+lt9uluBd4G9rbvR4FcABPWqVUGvB4ZTPLgm94d2063oJ3QZ4JX2ZsxMu5ec3hRhlMAUDeUSwuDSnyn/kEYMeSMna1myvQqHUZY77GSjD7Bp6EerJN4C/xgUSvh4UjlOrpAdrLdBf3O4bzatTp9YMqUQCb9D+bk3R8wXGDgf/Gt6vb3BjVrxsBBU7GfUt/9nEhh+ztfb63NvhQjjIqsYt1C7Yn4vA/bj2jPQnkqdtZUWKPhP2PkD9ZKlV6ISevbrOQwk6c/B7i8p0HlxB26twqZDCzBIzIlVXnJLSdrENaTTXsu5+6AeFJXTh3Os0mhMILVrj5CRgTWn6OXMy/rT0ryoAivQ/BMTMGKNR/Ft2BUsIaoTmd1+0HFybNr1Lm2qTKlpt/SmezA==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01EC_01D67257.467062E0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac94fb7b-0645-4fd0-9f3b-08d840905f5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 20:26:49.0736 (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: x7E9OlRqCnIEauI5XKiGUsD31N42S8imrq0yAxfui1BfBL8qrFYPMIHtjcwrl2aC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3041
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/3TvpUiULrkAHxZGu3xYoN4E05I0>
Subject: [Rats] pub-key-id or certificate-name (was RE: Some new comments for CHARRA YANG module)
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, 14 Aug 2020 20:26:57 -0000

Hi Shwetha, Panwei, and other Charra authors,

 

On another parallel but related question, should we use <certificate-name>
rather than <pub-key-id> in the RPC inputs below?   Either choice is *only*
required when a subset of TPMs are being quoted, or keys from something
other than a default AIK are desired.

 

The reason I think this might be good is that the current charra model has
the following elements in the data nodes:

    +--rw rats-support-structures

       +--rw tpms* [tpm-name]

          +--rw tpm-name                     string

          +--rw certificates

             +--rw certificate* [certificate-name]

                +--rw certificate-name    string

                +--rw certificate-ref?    leafref

 

With <certificate-name> you directly know the TPM.  With some <pub-key-id>,
you will need to go externally to:

   module: ietf-keystore

     +--rw keystore

        +--rw asymmetric-keys

           +--rw asymmetric-key* [name]

              +--rw name                                    string

              +--rw public-key                              binary

and do some conversions to match the RPC's <pub-key-id> (binary) to  <name>
(string).  With <name> you would get the list of certificates, and then use
those to find the proper TPM  (which seems complex and unnecessary). Plus
you will still need to determine the proper the <certificate-name> for the
RPC output anyway.     I would guess that implementers and YANG doctors are
likely to complain.

 

Thoughts?

Eric

 

From: Eric Voit (evoit) 
Sent: Friday, August 14, 2020 3:26 PM
To: Panwei (William) <william.panwei@huawei.com>om>; Shwetha Bhandari
(shwethab) <shwethab@cisco.com>
Cc: rats@ietf.org; draft-ietf-rats-yang-tpm-charra@ietf.org
Subject: Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG
module)

 

Hi Wei Pan,

 

Just slightly related to the question you asked previously, I have a
question on the model/tree you sent back (in-line...)

 

> From: Panwei, August 14, 2020 6:01 AM

> To: Eric Voit (evoit) <evoit@cisco.com <mailto:evoit@cisco.com> >; Shwetha
Bhandari (shwethab)

> 

> Hi Eric,

> 

> Thanks for your reply, please see inline.

> 

> Regards & Thanks!

> Wei Pan

> 

> From: Eric Voit (evoit) [ <mailto:evoit@cisco.com> mailto:evoit@cisco.com]

> Sent: Thursday, August 13, 2020 10:32 PM

> To: Panwei (William) < <mailto:william.panwei@huawei.com>
william.panwei@huawei.com>gt;; Shwetha Bhandari

> (shwethab) < <mailto:shwethab@cisco.com> shwethab@cisco.com>

> Cc:  <mailto:rats@ietf.org> rats@ietf.org;
<mailto:draft-ietf-rats-yang-tpm-charra@ietf.org>
draft-ietf-rats-yang-tpm-charra@ietf.org

> Subject: RE: Some new comments for CHARRA YANG module

> 

> Hi Wei Pan,

> 

> From: Panwei (William), August 13, 2020 8:29 AM Hi Eric,

> 

> 

> 2. The styles of challenge input for TPM1.2 and TPM2.0 are different.

>       +---x tpm20-challenge-response-attestation {TPM20}?

>       |  +---w input

>       |  |  +---w tpm20-attestation-challenge

>       |  |     +---w nonce-value          binary

>       |  |     +---w challenge-objects* []

>       |  |        +---w pcr-list* [TPM2_Algo]

>       |  |        |  +---w TPM2_Algo        identityref

>       |  |        |  +---w pcr-index*       tpm:pcr

>       |  |        +---w TPM2_Algo?          identityref

>       |  |        +---w (key-identifier)?

>       |  |        |  +--:(public-key)

>       |  |        |  |  +---w pub-key-id?   binary

>       |  |        |  +--:(uuid)

>       |  |        |     +---w uuid-value?   binary

>       |  |        +---w tpm-name*           string

> In the TPM2.0 challenge input, the nonce is put aside and the
challenge-objects

> is a list. So you can challenge for different pcr-lists of different TPMs
in one

> challenge input.

>       +---x tpm12-challenge-response-attestation {TPM12}?

>       |  +---w input

>       |  |  +---w tpm1-attestation-challenge

>       |  |     +---w pcr-index*              pcr

>       |  |     +---w nonce-value             binary

>       |  |     +---w TPM12_Algo?             identityref

>       |  |     +---w (key-identifier)?

>       |  |     |  +--:(public-key)

>       |  |     |  |  +---w pub-key-id?       binary

>       |  |     |  +--:(TSS_UUID)

>       |  |     |     +---w TSS_UUID-value

>       |  |     |        +---w ulTimeLow?       uint32

>       |  |     |        +---w usTimeMid?       uint16

>       |  |     |        +---w usTimeHigh?      uint16

>       |  |     |        +---w bClockSeqHigh?   uint8

>       |  |     |        +---w bClockSeqLow?    uint8

>       |  |     |        +---w rgbNode*         uint8

 

UUID is represented differently in the TPM1.2 and TPM2 models.   In fact in
the TPM1.2 modeling has the UUID broken into constituent parts, none of
which are mandatory where other UUID parts exist.  Shwetha told me that the
UUID structures originally came from Huawei.    A few questions:

 

(1) UUID only appears in RPCs.  It doesn't appear in the datanodes.   Nor
does UUID appear in draft-ietf-netconf-keystore.  As a result it is hard to
see how it might correspond to a key, at least in an IETF YANG ecosystem.
Is support for UUID really essential?   Why?

 

(2) Assuming you really want UUIDs, I am hoping the datatypes can be
reconciled between TPM1.2 and TPM2 RPCs.    Is there reason you wouldn't
just use the uuid YANG typedef of RFC6991 for both?

 

(3) Assuming you really want UUIDs, you need to propose how a UUID might
relate to keys within the IETF ecosystem of YANG models.  

 

BTW: If you don't need UUIDs, we could always drop them from the model.
(Leaving them to vendor specific augmentations if necessary.)

 

Thanks,

Eric

 

>       |  |     +---w add-version?            boolean

>       |  |     +---w tpm-name*               string