Re: [Rats] Charra: certificate-name vs TPM-name

"Panwei (William)" <> Sun, 02 August 2020 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 589E03A0E57 for <>; Sun, 2 Aug 2020 07:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 w1lroP42DG2Q for <>; Sun, 2 Aug 2020 07:01:48 -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 E31723A0E58 for <>; Sun, 2 Aug 2020 07:01:47 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 44AEC93015633D8EB07D for <>; Sun, 2 Aug 2020 15:01:44 +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; Sun, 2 Aug 2020 15:01:43 +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; Sun, 2 Aug 2020 22:01:40 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Sun, 2 Aug 2020 22:01:40 +0800
From: "Panwei (William)" <>
To: "Eric Voit (evoit)" <>
CC: "" <>
Thread-Topic: Charra: certificate-name vs TPM-name
Thread-Index: AdZk7AdVjrhIJhH+SNGp+N2fr3/WmwBS28Jg
Date: Sun, 2 Aug 2020 14:01:40 +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_7a25c2715b5741018b0ed52ddfcde6e1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Rats] Charra: certificate-name vs TPM-name
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: Sun, 02 Aug 2020 14:01:50 -0000

Hi Eric,

I don't object to contain the certificate-name in the response, I just suggest to add the tpm-name in the response and use it as the key.
I don't believe that one TPM per router/switch is enough. From the security perspective, I think one TPM per line card is needed, or at least using more TPMs is the trend. So the YANG module should consider the forward compatibility.
By using the tpm-name as the key of the output (and containing the certificate-name in the output), there are several advantages:
1) It's easy for the readers to understand.
2) It's easy for the Verifier to distinguish which TPM each record corresponds to and which certificate that TPM uses.
3) If the re-keying happens and a new certificate-name is provided to the Verifier, the Verifier only needs to query the Attester about the certificates of the specific TPM and doesn't need to retrieve the certificates of all TPMs.
4) While using different TPM names is already required, this approach doesn't further require to use different certificate names for different TPMs.

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) []
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <>
Subject: Charra: certificate-name vs TPM-name

Hi Wei Pan,

During the RATS WG call you wondered why certificate-name should be used rather than tpm-name.  There are two reasons:

(1) In RFC places like:

      +---x tpm20-challenge-response-attestation {TPM20}?
         +--ro output
            +--ro tpm20-attestation-response* []
               +--ro certificate-name?           string
               +--ro quote?                              binary
               +--ro quote-signature              binary

if just the tpm-name is provided, how does a Verifier know when a re-keying happens?    With the current solution, when unknown certificate-name comes back from the RPC, you just need to query:

    +--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
                +--rw certificate-type?   enumeration

and then you can find the tpm-name, plus all the required info post-certificate upgrade in one place.  If the certificate-name is not in the RPC, a Verifier will have to make several guesses on what any failure of signature verification might mean.

(2) The most common implementations will have just one TPM per router/switch.  These implementations might never care about the tpm-name.  They will care about the certificate used on that router/switch.


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