Re: [Rats] Which Asymmetric algorithms for Charra?

"Panwei (William)" <> Wed, 12 August 2020 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9F533A0D91 for <>; Wed, 12 Aug 2020 00:58:50 -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 SJ4omO94SyBO for <>; Wed, 12 Aug 2020 00:58:49 -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 A26673A0D90 for <>; Wed, 12 Aug 2020 00:58:48 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 7902969B22A60E750FA7 for <>; Wed, 12 Aug 2020 08:58:46 +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; Wed, 12 Aug 2020 08:58:45 +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; Wed, 12 Aug 2020 15:58:43 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Wed, 12 Aug 2020 15:58:43 +0800
From: "Panwei (William)" <>
To: "Eric Voit (evoit)" <>
CC: "" <>
Thread-Topic: Which Asymmetric algorithms for Charra?
Thread-Index: AdZwFfR0sMtRnzzORw2twimiOLxijgAX+Paw
Date: Wed, 12 Aug 2020 07:58:43 +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_d323dbd7a24c46f0bb5074f7aad4903dhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?
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: Wed, 12 Aug 2020 07:58:51 -0000

Hi Eric,

Generally, I'm fine with your proposal. I have only one question below.

The TCG_Algorithm_Registry_r1p32_pub defines a variety of SHA algorithms named with key length as a suffix, it also defines the ID values for the different curves used for elliptic curve cryptography. But it seems like that the TCG_Algorithm_Registry_r1p32_pub doesn't specify the key length of the RSA algorithm. So do we need to define fine-granular RSA algorithms in the YANG module?

Regards & Thanks!
Wei Pan

From: RATS [] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
Subject: [Rats] Which Asymmetric algorithms for Charra?

During the charra presentation at IETF 108, we said we were going to ask the following question to the list: "Should the algorithm set defined in YANG be reduced to just those asymmetric algorithms currently exposed in the current TPM 1.2 and 2 specifications?"

This is reflected seen in, Slide 7.

The proposal I would like to make is as follows:

  *   The TCG tracked algorithms supportable by a TPM should be the only ones included in a charra maintained list of YANG identities.

     *   This identity set needs to be extendable to new algorithms for any YANG models which augment charra.

  *   TCG Algorithm Registry Revision 01.32, Table 3 at contains the algorithms we should encode.

     *   There are other types of information within this table, and we might as well encode the full table within a YANG model.   That way we can explicitly make the scope of a "ietf-tcg-algs.yang" model the contents this TCG table encoded in YANG.

  *   The YANG model will indicate what TCG algorithms are deprecated by the IETF.  However identities for these deprecated algorithms from the TCG table will be assigned.  (e.g., SHA-1)

Are there any objections/questions/comments on this proposal?    I have a strawman YANG file posted at:<>

Henk also is thinking of encoding this same Table information within CDDL.  That could be inserted as an additional informational element of the document for where people prefer CDDL.


Eric Voit
Principal Engineer
.:|:.:|:. Cisco Systems, Inc.