From nobody Sat Aug 1 08:49:03 2020 Return-Path: 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 2700C3A0C64 for ; Sat, 1 Aug 2020 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZhHDN4AGi02M for ; Sat, 1 Aug 2020 08:48:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D743A0C68 for ; Sat, 1 Aug 2020 08:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E7D9389B4 for ; Sat, 1 Aug 2020 11:28:19 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4ednF_0cbmEJ for ; Sat, 1 Aug 2020 11:28:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0D6D389B3 for ; Sat, 1 Aug 2020 11:28:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25F4C9A for ; Sat, 1 Aug 2020 11:48:52 -0400 (EDT) From: Michael Richardson To: rats@ietf.org In-Reply-To: References: <4445014C-A191-4885-BE67-5502EF3E551F@intel.com>, <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Rats] should base architecture mandate a distributed structure for Endorsements X-BeenThere: rats@ietf.org 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: Sat, 01 Aug 2020 15:49:01 -0000 --=-=-= Content-Type: text/plain There is some discussion in private, on github and in the architecture DT calls around the question of Endorsements. There is a pull request at: https://github.com/ietf-rats-wg/architecture/pull/94 text. The text is https://github.com/ietf-rats-wg/architecture/pull/94/files, and I suggest that new readers go to the three dots and unselect "Show comments" But, I include the text: - An Endorsement is a secure statement that some entity (e.g., a - manufacturer) vouches for the integrity of the - device's signing capability. For example, if the signing capability is in hardware, then - an Endorsement might be a manufacturer certificate that signs a public key whose corresponding - private key is only known inside the device's hardware. + An Endorsement input to a Verifier is always required. An Endorsement is + what allows a Verifier to trust an Attester and in turn to trust the Evidence + produced by an Attester. Without Endorsements a Verifier cannot function. + Said another way, an Attester for which there is no Endorsement is not + useful since there is no good basis by which a Verifier can trust it. + One of the Endorsements for an Attester will just about always contain + cryptographic key material. + This key material will correspond to key material that is put in the Attester. + The key material is the basis for the Verifier trusting the Attester. + This architecture does not dictate any particular cryptographic protocol + for establishing this trust, hence the key material can be symmetric or + asymmetric, a single key, multiple keys, key hierarchies, X.509 cert or + chains or other. I think that we get into conflict immediately on the first sentence. There ARE many use cases in which we WILL need input to the Verifier from a variety of manufacturers in a signed artifact form.(A) There are other use cases in which the Verifier will be configured with all the information that it needs. Is a configuration file, loaded by a trusted operator, a "secure statement"? I think so, and this is why we used this wording. (B) When I read the changes above, it seems to me that it contains aspirational text that intends to make case (A) universal. I think that a number of us believe that an Endorsement is the name for a signed artifact. This may be the basis for our disagreement: I'm not entirely sure. Our definition of "Endorsement" does not say that, so it may be that I read too much into the proposed changes. I firmly believe that we will need an Architecture for Distributed Endorsements. I also think that we can do this separately, and that there are probably reasons for some industrial verticals to do this on their own. It could be that this is not the goal of the above text. I do not think we need this level of detail in this part of the architecture. It's not wrong, it's just not helpful, I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8ljuMACgkQgItw+93Q 3WWiKggAtZdjuhZETCiL6RQ3HcBpg9R6Tvk42pv//7M6rdH8xgP7SvyYjGvsB7LV u2qNtwsvEXqsT9uXbulhnI6hh4kYlOKnNri49OSzHHqVwqz7SXfDDRUe96zzVsPt lr2xJYQbK6NfwAh9G0zTjUvLI9vXl/uns7Kt5TZ0XGXz9O3tv2hhgcyJGXxXmhim hJr0wmQuvj6roNV25ZXrOCx5LN0sq5YMPQTC6OQ4Hb1O4LjzHVwHVsvmIrQi3dUp E2yq6FFrPX3wcM4YqsYnM0kuelFoIBemcCkki3zKO6SnM9AyDHZg9wP85vFDskv+ m13tAr/vxl2yXsPDcx/PZHGak6leYA== =VNBG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 1 12:38:02 2020 Return-Path: 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 E2D963A0E33 for ; Sat, 1 Aug 2020 12:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1f0sle60e6aN for ; Sat, 1 Aug 2020 12:37:58 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C703A0A47 for ; Sat, 1 Aug 2020 12:37:57 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 1xKOk5v1okJGJ1xKPkPQcf; Sat, 01 Aug 2020 12:37:57 -0700 X-CMAE-Analysis: v=2.3 cv=ALzgjvLx c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=0XtbOteLAAAA:20 a=48vgC7mUAAAA:8 a=wTG7bLQe12m023skbw0A:9 a=P1nuf23abXufK0IX:21 a=gey1BJEXaJ6aVbDA:21 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: <2900.1596296932@localhost> Date: Sat, 1 Aug 2020 12:37:56 -0700 Cc: rats@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7A5BB0EB-BA4F-4210-87C0-E9F9C6C23979@island-resort.com> References: <4445014C-A191-4885-BE67-5502EF3E551F@intel.com> <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> <2900.1596296932@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfHk9X+JUbVW6YlC+ed0TfXP4WXAm7v7LqHqvmm4rcGif2OuI/yOUfuoe5jNdkNizsAbSPwJQmXJ9HL8b1wY4JrIlxhG/VDQz1xzzsf4v08CVF8Y3gwe+ wULLJpf/HBMtUm39krXXrJvnTF0fiqpYcp18isHPh3nXdbI60hh4GjjkMATz1F1jonxeFVdPgdGYAB4sRuNsoHgT8nPRwtml2Ek= Archived-At: Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements X-BeenThere: rats@ietf.org 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: Sat, 01 Aug 2020 19:38:00 -0000 > On Aug 1, 2020, at 8:48 AM, Michael Richardson = wrote: >=20 >=20 > There is some discussion in private, on github and in the architecture = DT > calls around the question of Endorsements. >=20 > There is a pull request at: > https://github.com/ietf-rats-wg/architecture/pull/94 > text. The text is > https://github.com/ietf-rats-wg/architecture/pull/94/files, > and I suggest that new readers go to the three dots and unselect "Show = comments" >=20 > But, I include the text: >=20 > - An Endorsement is a secure statement that some entity (e.g., a > - manufacturer) vouches for the integrity of the > - device's signing capability. For example, if the signing = capability is in hardware, then > - an Endorsement might be a manufacturer certificate that signs a = public key whose corresponding > - private key is only known inside the device's hardware. >=20 > + An Endorsement input to a Verifier is always required. An = Endorsement is > + what allows a Verifier to trust an Attester and in turn to trust = the Evidence > + produced by an Attester. Without Endorsements a Verifier cannot = function. > + Said another way, an Attester for which there is no Endorsement is = not > + useful since there is no good basis by which a Verifier can trust = it. >=20 > + One of the Endorsements for an Attester will just about always = contain > + cryptographic key material. > + This key material will correspond to key material that is put in = the Attester. > + The key material is the basis for the Verifier trusting the = Attester. > + This architecture does not dictate any particular cryptographic = protocol > + for establishing this trust, hence the key material can be = symmetric or > + asymmetric, a single key, multiple keys, key hierarchies, X.509 = cert or > + chains or other. >=20 > I think that we get into conflict immediately on the first sentence. >=20 > There ARE many use cases in which we WILL need input to the > Verifier from a variety of manufacturers in a signed artifact form.(A) >=20 > There are other use cases in which the Verifier will be configured = with all > the information that it needs. Is a configuration file, loaded by a = trusted > operator, a "secure statement"? > I think so, and this is why we used this wording. (B) My view is that the arrows in the diagram show the complete and = exhaustive inputs of relevance to attestation. The one and only input = from the Manufacturer/Endorser to the Verifier is the Endorsement. If = there is a configuration file (with keys) transferred from the = Manufacturer/Endorser to the Verifier, it would be going over the arc = labeled Endorser in the diagram.=20 I think this is true of every arrow/arc in Figure 1. I don=E2=80=99t = think are alternate channels. It seems confusing to tacitly expect the = reader to assume them. Even if it weren=E2=80=99t true, the key material is critical and = fundamental to attestation that its transfer needs to upfront and clear. = You can do attestation with just a key and a nonce and nothing else. You = can=E2=80=99t do attestation without a key and nonce. We have pages of = discussion on nonces. The most important thing transferred from Manufacturer/Endorser to the = Verifier is the verification key material. It should be characterized = clearly and should allow for all types of keys and transfer scenarios. >=20 > When I read the changes above, it seems to me that it contains = aspirational > text that intends to make case (A) universal. >=20 > I think that a number of us believe that an Endorsement is the name = for a > signed artifact. This may be the basis for our disagreement: I'm not = entirely sure. > Our definition of "Endorsement" does not say that, so it may be that I = read > too much into the proposed changes. Endorsement being a =E2=80=9Csigned artifact=E2=80=9D seems like common = understanding in the TCG world to me. If we want to stick with that definition, that is fine, but that = excludes Endorsements as a means to convey symmetric keys, databases of = keys and the operation of a key look up service and a hash verification = service. So then we need to switch to a term like Verifier Input with = Endorsements being one form of Verifier Input. >=20 > I firmly believe that we will need an Architecture for Distributed = Endorsements. > I also think that we can do this separately, and that there are = probably > reasons for some industrial verticals to do this on their own. Agree with that.=20 I=E2=80=99m only after a few paragraphs of high-level characterization. = Nothing as detailed as the nonce discussion. >=20 > It could be that this is not the goal of the above text. >=20 > I do not think we need this level of detail in this part of the = architecture. > It's not wrong, it's just not helpful, I think. What=E2=80=99s different about the Endorser-Verifer-Attester trust = relationship is that it is transitive in a unique and important way for = attestation. I think bringing that to light in a clear way is necessary. LL >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats From nobody Sun Aug 2 07:01:52 2020 Return-Path: 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 589E03A0E57 for ; Sun, 2 Aug 2020 07:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1lroP42DG2Q for ; Sun, 2 Aug 2020 07:01:48 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31723A0E58 for ; Sun, 2 Aug 2020 07:01:47 -0700 (PDT) Received: from lhreml737-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 44AEC93015633D8EB07D for ; Sun, 2 Aug 2020 15:01:44 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml737-chm.china.huawei.com (10.201.108.187) 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 nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) 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 nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Sun, 2 Aug 2020 22:01:40 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" 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: <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.254.73] 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-BeenThere: rats@ietf.org 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 --_000_7a25c2715b5741018b0ed52ddfcde6e1huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, I don't object to contain the certificate-name in the response, I just sugg= est 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 mo= re TPMs is the trend. So the YANG module should consider the forward compat= ibility. By using the tpm-name as the key of the output (and containing the certific= ate-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 correspo= nds to and which certificate that TPM uses. 3) If the re-keying happens and a new certificate-name is provided to the V= erifier, the Verifier only needs to query the Attester about the certificat= es 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) [mailto:evoit@cisco.com] Sent: Tuesday, July 28, 2020 11:30 PM To: Panwei (William) Cc: rats@ietf.org Subject: Charra: certificate-name vs TPM-name Hi Wei Pan, During the RATS WG call you wondered why certificate-name should be used ra= ther 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-certifi= cate upgrade in one place. If the certificate-name is not in the RPC, a Ve= rifier will have to make several guesses on what any failure of signature v= erification might mean. (2) The most common implementations will have just one TPM per router/switc= h. These implementations might never care about the tpm-name. They will c= are about the certificate used on that router/switch. Thanks, Eric Eric Voit .:|:.:|:. Cisco Systems, Inc. --_000_7a25c2715b5741018b0ed52ddfcde6e1huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

I don’t object to contain the certif= icate-name in the response, I just suggest to add the tpm-name in the respo= nse and use it as the key.

I don’t believe that one TPM per rou= ter/switch is enough. From the security perspective, I think one TPM per li= ne card is needed, or at least using more TPMs is the trend. So the YANG module should consider the forward compatibility.<= /o:p>

By using the tpm-name as the key of the ou= tput (and containing the certificate-name in the output), there are several= advantages:

1) It’s easy for the readers to unde= rstand.

2) It’s easy for the Verifier to dis= tinguish which TPM each record corresponds to and which certificate that TP= M uses.

3) If the re-keying happens and a new cert= ificate-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.<= /o:p>

4) While using different TPM names is alre= ady required, this approach doesn’t further require to use different = certificate names for different TPMs.

 

Regards & T= hanks!

Wei Pan

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats@ietf.org
Subject: Charra: certificate-name vs TPM-name

 

Hi Wei Pan,

 

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

 

(1) In RFC places like:

 

 &= nbsp;    +---x tpm20-challenge-response-attestation {TPM= 20}?

  =        +--ro output

 &= nbsp;          +--ro tpm20= -attestation-response* []

      =          +--ro certificate= -name?           string

 &= nbsp;           &nbs= p; +--ro quote?         &n= bsp;            &nbs= p;       binary

 &= nbsp;            &nb= sp;+--ro quote-signature        &nbs= p;     binary

 

if just the tpm-name is provide= d, how does a Verifier know when a re-keying happens?    Wit= h the current solution, when unknown certificate-name comes back from the R= PC, you just need to query:

 

 &= nbsp;  +--rw rats-support-structures

 &= nbsp;     +--rw tpms* [tpm-name]<= /p>

 &= nbsp;        +--rw tpm-name &nb= sp;            =        string

 &= nbsp;        +--rw certificates=

 &= nbsp;           +--rw= certificate* [certificate-name]

     &= nbsp;          +--rw certi= ficate-name    string

     &= nbsp;          +--rw certi= ficate-ref?    leafref

     &= nbsp;          +--rw certi= ficate-type?   enumeration

 

and then you can find the tpm-n= ame, 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 s= everal guesses on what any failure of signature verification might mean.

 

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

 

Thanks,

Eric

 

Eric Voit

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

 

--_000_7a25c2715b5741018b0ed52ddfcde6e1huaweicom_-- From nobody Mon Aug 3 08:22:48 2020 Return-Path: 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 AC93D3A0B8F for ; Mon, 3 Aug 2020 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NyQTlotY_Coj for ; Mon, 3 Aug 2020 08:22:45 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0853A0B84 for ; Mon, 3 Aug 2020 08:22:45 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q75so30736414iod.1 for ; Mon, 03 Aug 2020 08:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xXfcZfGt6Gzxar4xqiGie2kc9bYJhsP8N/znhdBWd0U=; b=S1qAb3E2V8yNjxDbBtiYxLChYzUzSKdkwJiLJrSrfx6VoojcPDvIUkWAOa0UtEyxMy lgy7+zQ0YGkmi9zYJ/28799ppTdoWovxjLCvnG9VbDxFxvqwPBa9icssnCpJSJUyPK6P WFfdtiv/68VA3bXQ9RlLHeHMWdjE5eOnbtxalucBWAuNtOTVSiPoqYu4jyL6ZMyjz0IF kNr+w0JiHBBjzJZW3wXZJo8iM+quDnD3xcKI9HhOTHuPv3rjXZn1u428dBgVZKbvUpPU frp39HTsxSc3LvOGjIMxlFW2QlzkgEH2WVOR0U8oTgWMuSALeYfdZdOczXTfX5MNbJ92 pO5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xXfcZfGt6Gzxar4xqiGie2kc9bYJhsP8N/znhdBWd0U=; b=QB75tnkmMCtumCqaWDWlcsMCM70zscJ3ZTYyAsmiuWDYLgr+ekYgrD7E76icE6rXpN IWnFmi/GsJWlhd1L742I50kb9/vnXGEKmYwL+hIj0y6v8t+PY+45cyQohPsUqCl+APjS ZQP9Y952AQdwrAwKHJ4+T5wegH7DxjZxrcsDS89EIEJV9Lqgqrrtnnl72FuaXHH/gCtL sdKAWjJyR1RlyNnwf6sA7uCeC5YPqvX7Uedy1djk7FDaIPfXDg59IfYczfJ0t6hCEs+H z4z6gK3OGfK8nBj59oQWoUkKW4p3Hjro8awSA4y07hu95MB+CiDO3tRr7seNgKacF7IU 9+Zg== X-Gm-Message-State: AOAM5312Eq089zUCEh6v27AEftatcU3LfUkuJNObuRoj/NY8R/v9X2wp ptkDo2F4R/3WKNUcUs6didd9ts9aQSILHPD4Khjg90aY X-Google-Smtp-Source: ABdhPJzJ9GhB5r8C1WBl73N+DPOam29RkwayvtcWkUWRJ4Jb/bBDxC/xglqZToVMyeV4knyX/9BeqhXnY68/570cOwU= X-Received: by 2002:a5e:dd44:: with SMTP id u4mr368780iop.192.1596468164555; Mon, 03 Aug 2020 08:22:44 -0700 (PDT) MIME-Version: 1.0 From: Kathleen Moriarty Date: Mon, 3 Aug 2020 11:22:08 -0400 Message-ID: To: rats@ietf.org Content-Type: multipart/alternative; boundary="000000000000d7f95605abfab56a" Archived-At: Subject: [Rats] Review of draft-ietf-rats-tpm-based-network-device-attest/ X-BeenThere: rats@ietf.org 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, 03 Aug 2020 15:22:47 -0000 --000000000000d7f95605abfab56a Content-Type: text/plain; charset="UTF-8" Thank you to Jess and Guy for a very well written document. I have 2 comments for the security considerations section. You may want to make note that preventing collision attacks with digital signatures is important (algorithm and key size selection). While rare, this type of attack will be more important to protect against as this technology is further adopted. This type of attack was successfully conducted with STUXNET and yes, is very sophisticated. The second item I think that is worth calling out is the attack vector in the supply chain. If the measurements provided are subverted in the development phase where a compromise is embedded, it will be really hard to detect. Supply chain security, safe coding, QA, and other measures should be in place. It may be that this remains a potential vector, but calling it out as a consideration could be important. I had passed this along our internal path to TCG as well, just so it is noted. You get at this second point a little, but I think expanding it may help. "Attestation depends on an unbroken chain of measurements, starting from the very first measurement. That first measurement is made Fedorkow, et al. Expires January 14, 2021 [Page 27] Internet-Draft Network Device RIV July 2020 by code called the Root of Trust for Measurement, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique." Best regards, Kathleen --000000000000d7f95605abfab56a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you to Jess and Guy for a very well written document= .=C2=A0 I have=C2=A02 comments for the security considerations=C2=A0section= .

You may want to make note that preventing collision at= tacks with digital signatures is important (algorithm and key size selectio= n).=C2=A0 While rare, this type of attack will be more important to protect= against as this technology is further adopted.=C2=A0 This type of attack w= as successfully conducted with STUXNET and yes, is very sophisticated.

The second item I think that is worth calling out is t= he attack vector in the supply chain.=C2=A0 If the measurements provided ar= e subverted in the development phase where a compromise is embedded, it wil= l be really hard to detect.=C2=A0 Supply chain security, safe coding, QA, a= nd other=C2=A0measures should be in place.=C2=A0 It may be that this remain= s a potential vector, but calling it out as a consideration could be import= ant.=C2=A0 I had passed this along our internal path to TCG as well, just s= o it is noted.

You get at this second point a litt= le, but I think expanding it may help.

=C2=A0 =C2= =A0 =C2=A0 "Attestation depends on an unbroken chain of measurements, = starting
=C2=A0 =C2=A0 =C2=A0 from the very first measurement.=C2=A0 Tha= t first measurement is made

Fedorkow, et al. =C2=A0 =C2=A0 =C2=A0 = =C2=A0Expires January 14, 2021 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 27]
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Network Device RIV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2020

=C2=A0 =C2=A0 =C2=A0 by code called the Root of = Trust for Measurement, typically done
=C2=A0 =C2=A0 =C2=A0 by trusted fi= rmware stored in boot flash.=C2=A0 Mechanisms for
=C2=A0 =C2=A0 =C2=A0 m= aintaining the trustworthiness of the RTM are out of scope for
=C2=A0 = =C2=A0 =C2=A0 RIV, but could include immutable firmware, signed updates, or= a
=C2=A0 =C2=A0 =C2=A0 vendor-specific hardware verification technique.= "

Best regards,
K= athleen
--000000000000d7f95605abfab56a-- From nobody Mon Aug 3 09:42:00 2020 Return-Path: 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 3A2E83A0FE7 for ; Mon, 3 Aug 2020 09:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.698 X-Spam-Level: X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[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, 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=FA7sUt4N; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=KRLaFK08 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 PEd7MtrqnEP5 for ; Mon, 3 Aug 2020 09:41:56 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABCB3A0FC2 for ; Mon, 3 Aug 2020 09:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34165; q=dns/txt; s=iport; t=1596472916; x=1597682516; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iS7ksUsZUCerfh/OwQ/5+5mfr7/DlPgvtkBarfQYp4o=; b=FA7sUt4NxMk9t73uSko4Cc1khoKdeb3igp0u+6mL33KX7fgC1g5gDlwu NBK3mLWIVpaK41EylP0kXAdZ7ozNpI3SKaSoOdWuQa/oQU4xXo9i411a4 nYu0c298WHQNUc4TVbupbYP/lUyMCpEMkvC12cFxKXUy/Yv1Tq1z+0BKi Q=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3ACs3Hlh0NRorQQVnWsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbBQD+PChf/5BdJa1WChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgSMvUQdvKy0vLAqHcQONUIdakQmCUwNVBAcBAQEJAwE?= =?us-ascii?q?BLQIEAQGETAKCOgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEEEhsTAQE?= =?us-ascii?q?3AQ8CAQgRBAEBIQcHAjAUCQgBAQQOBQgGDQeDBYF+TQMfDwGnUwKBOYhhdIE?= =?us-ascii?q?0gwEBAQWFIBiCBwcJgTiBU4Edih4agUE/gRFDgk0+hBAvFR+DE4ItjzlUiWy?= =?us-ascii?q?BGZsACoJhhDiCW5MXn3qxSgIEAgQFAg4BAQWBaiOBV3AVO4JpUBcCDY4fg3G?= =?us-ascii?q?KVnQ3AgYIAQEDCXyNDi2BBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,430,1589241600"; d="p7s'?scan'208,217";a="533490104" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Aug 2020 16:41:55 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 073Gftsu004815 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2020 16:41:55 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 11:41:55 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 12:41:54 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 3 Aug 2020 11:41:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y7fi9tvv1Ul7HrEAAFeyffoIYtjiVD+g62bP+0cLH2O/eAPOiUNHrwdYrGJPZLI9/uOSc6bHbupxwDIQHARRvUrcB/ip335crgv5kruDbnJVKJa8gDMWw/KJDhqvXeRY3s+K2BQQAlkp+tzKXkZ1JEa/M49lMPsaLffp34Wvj555/3eKxC32xvAY0TRqqasMxF/DAo7WN5kcUvXcKfywI9vQhBmMQrtfNMQjBKOhKAuXtf7WlYB0QfPo04ClygSzTOvFVeXUW+Ml5b5lvH1yPrElKqSOdZzYAQZZCFNViAwVBQDg6RdmjbXWdDnUXxw5T8h0YOyDA9BuGeClwVmsSg== 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=vnzmNGWJFvx4MFQIOcFmCg/omF1JEf+MPDRMLabFPxA=; b=hVMnPE3jYvTnyKQxH0q90lricFdgmPUsF56tAklIJblZQtEt1K53jBjiLeyAXy7mc3gKkcYmbYmRvCjE4QHhLLnPiuYI5MK4auYjHM7KlydbNjQCE1dZqOvmlDidKy5qbS7ISfGuF4LLj6A8lu/FIchqrFym0Jbppr6Jo3a78PzJF87ONLZ9g/IFhsR9AkcosexRhVHtgzmiQetO91uZcdsgyTfuu29s6RvhNKg2AlqGPHC2i77qXwz6Eh9W/R/1P16FxyawziupmfvBkRY/MJI9225RGbJ7B5nM6tquO30RQv+W+YeBezhCGohJ5wVgR0UDQ4UIOCqHyxkXsWGCdA== 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=vnzmNGWJFvx4MFQIOcFmCg/omF1JEf+MPDRMLabFPxA=; b=KRLaFK08+9j3rrcbOc/XbAr56cegMzzuO94v1FO962rZuFqk+WRD5hYdOLJ9FKDIJnGtusC7eO+UK5esFFg/xWaFwzmypZhiLNVpGldYgI0B0QrIxb7y/dcQI1oDl10pXWGYHSpk9uuIDkgSFvHdaKLYDLAkSd9Q+8FUVAGyWm8= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2916.namprd11.prod.outlook.com (2603:10b6:208:72::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Mon, 3 Aug 2020 16:41:53 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 16:41:53 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" CC: "rats@ietf.org" Thread-Topic: Charra: certificate-name vs TPM-name Thread-Index: AdZk7AdVjrhIJhH+SNGp+N2fr3/WmwBS28JgANYNhuA= Date: Mon, 3 Aug 2020 16:41:52 +0000 Message-ID: References: <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> In-Reply-To: <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bda63c38-ff68-4339-e284-08d837cc2078 x-ms-traffictypediagnostic: BL0PR11MB2916: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RtelIGYS9iX5IYP+QPSp12SDwQtiFYTkr9H2Rurx9tRZdU7bacijbk9f/JQHqkk9HDgQibWhNEh1tyClDpVdRy8J6WbowR5gF/lL6ijtJuKlWlRxAKqXdDfP5wlsLrsYuhGe+X+M3FZIRqIz0nnmOEj4j1VV/lGAIoGJvrl8Dyqqj0xfFJ05/dsPeKjn+BMpgvlL7aPMV30dLUfwJuSUvTMmNWnGchrtFV6ciOoaXr9PwuRd8GjNgMEEQjtrDvlgQB8Q/hZ5PAJvGFVEFaX3GbqNxUY9zbaW7myxDYXd+KdeT5C2Y6qlxCeL1IM3dauUiqMseI7sEl01Lcy6A/IH4Q== 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; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(8936002)(8676002)(64756008)(66556008)(66476007)(66616009)(478600001)(7696005)(186003)(76116006)(66946007)(53546011)(6506007)(33656002)(99936003)(9686003)(4326008)(55016002)(66446008)(26005)(66574015)(83380400001)(86362001)(71200400001)(5660300002)(2906002)(52536014)(6916009)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Oc17sqPq+3eSBeL2iaHbxmz5aJm8zHhXTGYGwZqE9TJIsKPyj68/JNTf9gTIG3ItumCY2eiOQgrr/3hjzxn5sd7PxfkMahlPqgO3GmnD577ckhkn86aDvyaoWMYGUxkCjohQBUMZqJD/0iqQhKyOYzig9EBRHV6+H1IHVFB4R++aESOv6nIsPB78gu16xIUsXrsvwGXnkNGkbr5+TmLo/PKfIxl3U98lFCgT9FA6zzgy3636CYQzl1DlYNa2SOrrrfNyIHlkA/k+zKR28s4D/PuIPjEYpQlp/FcIgF2BlFyod+3FNFwmoNlcLD7KqINQja8MsAtKuT6Wpa3mYFvC6VIBJAmyzr/nkCHOXGLKxMIv9As0rtIEzktKJFaji+RyulrEWWCKtPwm9evj16A9QVBMQx1MI0wHrHk/REBQc2Zkyh47m52nGHdhZyMHtkvvvfzBTzBwaW2Mgg/utot3lFPFf86VyXAiAB8s5nevqMX7KCQGuc0y1w+FKy2bzY8iv2/wr8XtBn7PKv760EiHG92feW1V4fXumCbLeEso65phof6AEf3/meCQEiz3YoacygZkTb+iacQBm1HbU+rwIIccOZCcsmVY7xsNdcUCWYF5X6C0kJNTP5OF139NBgoOMIAQfUe/jV1iTd4eLzH9kw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05E4_01D66993.74B44AD0" 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: bda63c38-ff68-4339-e284-08d837cc2078 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 16:41:52.8925 (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: yJBSm0qNdGKeZkuoa3XkqPuUyg7IhpMiQe36e4UiANa9pPMeeEIvbE6ZP27RdzKL X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2916 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Rats] Charra: certificate-name vs TPM-name X-BeenThere: rats@ietf.org 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, 03 Aug 2020 16:41:59 -0000 ------=_NextPart_000_05E4_01D66993.74B44AD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05E5_01D66993.74B44AD0" ------=_NextPart_001_05E5_01D66993.74B44AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, I fully agree that multiple line cards per switch/router is necessary. The current model does support this, as the RPC output is a list. Lists are identified by the "[]" in the tree diagram. So for any current list entry, a which is unique to an individual TPM can be placed within this list. The real difference I see between our proposals is that you want explicitly listed in the RPC response, and I thought a unique which doesn't require users of single TPM devices to understand is preferable. I.e., some complexity is hidden within the router so that a class of developers need not care. Below are some extensive thoughts on both options. In the end I really am fine with both. To start with, I believe some useful context comes from the ietf-keystore.yang YANG model which is currently under WGLC as part of draft-ietf-netconf-keystore-17. Here the following structure can be used to identify a unique certificate independent of any TPM: module: ietf-keystore.yang +--rw keystore +--rw asymmetric-keys +--rw asymmetric-key* [name] +--rw name string +--rw certificates +--rw certificate* [name] +--rw name string In this model, the certificate's name is accessed without any TPM information. The next level in the hierarchy is the key name. Note that in this model, certificate's object different than currently in charra. The charra leaf can point to that keystore: path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:certificates/ks:certificate/ks:name"; This means we have access to all the certificate info which a keystore would support. More after your questions... From: Panwei, August 2, 2020 10:02 AM 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. I believe it harder. You still need to make mandatory. Otherwise you likely need to acquire and test multiple keys from a keystore to find the right one. Note: by mandating the key of in your proposal you are enforcing that only one response using a single key from TPM may be included. Perhaps this is a good thing. It is not a good thing if anyone ever wants to return two tpm quotes using different TPM keys as part of the same RPC response. 2) It's easy for the Verifier to distinguish which TPM each record corresponds to and which certificate that TPM uses. In both cases you need to get to the key itself from a keystore. A certificate points to a key, which is associated with a particular TPM. The key is already required for validating the signature of returned results. 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. This is not required for the existing model. All you need to do is a get on the existing model with the provided . 4) While using different TPM names is already required, this approach doesn't further require to use different certificate names for different TPMs. If we make dependent on , then we have the nested keys which we are trying to avoid for those devices which only have a single TPM. The main question I see from above is whether making the (which is system generated) unique across TPMs. Again I believe this is helpful for those devices with just one TPM. Eric Regards & Thanks! Wei Pan From: Eric Voit (evoit) [ mailto:evoit@cisco.com] Sent: Tuesday, July 28, 2020 11:30 PM To: Panwei (William) < william.panwei@huawei.com> Cc: rats@ietf.org 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. Thanks, Eric Eric Voit .:|:.:|:. Cisco Systems, Inc. ------=_NextPart_001_05E5_01D66993.74B44AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wei = Pan,

 

I fully agree that = multiple line cards per switch/router is necessary. The current model = does support this, as the RPC output is a list.  Lists are = identified by the "[]" in the tree = diagram.   So for any current list entry, a = <certificate-name> which is unique to an individual TPM can be = placed within this list.

 

The real difference I = see between our proposals is that you want <tpm-name> explicitly = listed in the RPC response, and I thought a unique = <certificate-name> which doesn't require users of single TPM = devices to understand <tpm-name> is preferable.  I.e., some = complexity is hidden within the router so that a class of developers = need not care.

 

Below are some = extensive thoughts on both options.  In the end I really am fine = with both.

 

To start with, I = believe some useful context comes from the ietf-keystore.yang YANG model = which is currently under WGLC as part of = draft-ietf-netconf-keystore-17.   Here the following structure = can be used to identify a unique certificate independent of any = TPM:   

   module: =
ietf-keystore.yang
     +--rw =
keystore
        +--rw =
asymmetric-keys
        =
   +--rw asymmetric-key* =
[name]
        =
      +--rw =
name           &nb=
sp;           &nbs=
p;            =
string
        =
      +--rw =
certificates
        =
         +--rw certificate* =
[name]
        =
            +=
--rw =
name           &nb=
sp;          =
string

In this model, the = certificate's name is accessed without any TPM information.  The = next level in the hierarchy is the key name.  Note that in this = model, certificate's <name> object different than currently in = charra.   The charra leaf <certificate-ref> can point to = that keystore:

         &= nbsp;    path = "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"<= /span>

         &= nbsp;       + = "/ks:certificates/ks:certificate/ks:name";

This means we have = access to all the certificate info which a keystore would = support.

 

More after your = questions...

 

From: Panwei, August 2, 2020 10:02 = AM

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.

 

<eric> I believe it harder.   You still need = to make <certificate-name> mandatory.   Otherwise you = likely need to acquire and test multiple keys from a keystore to find = the right one.   

 

Note: by mandating the key of <tpm-name> in your = proposal you are enforcing that only one response using a single key = from TPM may be included.  Perhaps this is a good thing.  It = is not a good thing if anyone ever wants to return two tpm quotes using = different TPM keys as part of the same RPC = response.

 

2) It’s easy for the Verifier to distinguish which TPM = each record corresponds to and which certificate that TPM = uses.

 

<eric> In both cases you need to get to the key itself = from a keystore.   A certificate points to a key, which is = associated with a particular TPM.  The key is already required for = validating the signature of returned results.

 

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.

 

<eric> This is not required for the existing = model.  All you need to do is a get on the existing model with the = provided <certificate-name>.

 

4) While using different TPM names is already required, this = approach doesn’t further require to use different certificate = names for different TPMs.

 

<eric> If we make <certificate-name> dependent on = <tpm-name>, then we have the nested keys which we are trying to = avoid for those devices which only have a single TPM.   The = main question I see from above is whether making the = <certificate-name> (which is system generated) unique across = TPMs.   Again I believe this is helpful for those devices with = just one TPM.

 

Eric

 

Regards & Thanks!

Wei Pan

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, July = 28, 2020 11:30 PM
To: Panwei (William) <william.panwei@huawei.com= >
Cc: rats@ietf.org
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:

 

   &nbs= p;  +---x tpm20-challenge-response-attestation = {TPM20}?

  =        +--ro = output

   &nbs= p;        +--ro = tpm20-attestation-response* []

      =          +--ro = certificate-name?         &n= bsp; string

   &nbs= p;           +--ro = quote?           &= nbsp;          =         binary<= /p>

   &nbs= p;           +--ro = quote-signature      =         binary<= /p>

 

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

   &nbs= p;   +--rw tpms* [tpm-name]

   &nbs= p;      +--rw = tpm-name           = ;          = string

   &nbs= p;      +--rw = certificates

   &nbs= p;         +--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.

 

Thanks,

Eric

 

Eric Voit =

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

 

------=_NextPart_001_05E5_01D66993.74B44AD0-- ------=_NextPart_000_05E4_01D66993.74B44AD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODAzMTY0MTQ5WjAjBgkqhkiG 9w0BCQQxFgQU2LzEHMqpceY/DvZDI6+2Bl2VDOswSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAxan8j9r0E86lsf3ZqNl3Y6f6v+TEcJ5FD4H0JP3/qtK7oaN1oQ9dE3E47FzpDOs6X exNZp/9WJQkYh2d/YLLEUdh4DbMAQr24hxyQ9iMJuqUcf8xmPcmOZKLPSseXVGhS4i8p8Io1MAkz itXWveK5mKNLMcD9Wy81UsluQTdKPebP3l3jOmcxS81vF+MRD+rveRluPrWJjezLO/YnEFxhI3Ul Gn49Y5y0xwdfiOjPVI4GVn0GdMBjJapSh4czaWR39skftJG5XkZiR2g6oRbRauV21mz7g8e09VLn KdPZdaYEQC5dipG1/+yKhVjZWo42if22Kdn2QxHt2hGqJtmwAAAAAAAA ------=_NextPart_000_05E4_01D66993.74B44AD0-- From nobody Mon Aug 3 11:59:10 2020 Return-Path: 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 8FE723A0A3B for ; Mon, 3 Aug 2020 11:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ueh4I87zDVu5 for ; Mon, 3 Aug 2020 11:59:05 -0700 (PDT) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204C53A0A6A for ; Mon, 3 Aug 2020 11:59:00 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 2ffnkqFuZoraZ2ffnkGKDv; Mon, 03 Aug 2020 11:58:59 -0700 X-CMAE-Analysis: v=2.3 cv=PZqBeRpd c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=mE7JM0AAAAAA:8 a=BM-95ODdJa3X30QArsMA:9 a=ZIdEE5YbPCf3Leim:21 a=7oIFj7L-xEes53XR:21 a=QEXdDO2ut3YA:10 a=kViqyZy1v31e6LSPT28A:9 a=IwOSapfIirHiE0Yq:21 a=_W_S_7VecoQA:10 a=sjx5D4xYqjbV_PqBlxw0:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_5247168A-2B95-4D04-A869-F098AB7A93F2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> Date: Mon, 3 Aug 2020 11:58:58 -0700 To: rats@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfCrwCJyeib9GPKJk6KEn0+zKmSvVAetdGJcIO5c5FJj4rdm0nikBROdNy9e76dqo8WeBkr9yVHEI2vLjN2fibs15fdia7A+OB+O67ASieuiI1l4ROdAS T4YYOfHvgoCmjF5+n4AM4Wze5aSRcQUXvTM+9uXV9azWDNjEmb59dDRm Archived-At: Subject: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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, 03 Aug 2020 18:59:09 -0000 --Apple-Mail=_5247168A-2B95-4D04-A869-F098AB7A93F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is to introduce discussion about the use of TLS/HTTPS versus = Attestation. I=E2=80=99ve seen a few places where Attestation is being = proposed for use where I think TLS/HTTPS is probably sufficient or a = better fit. Reviewing the trust relationships described in the architecture document = got me thinking about sharpening a distinction between device = attestation (e.g., EAT for phone) and service authenticity (e.g. HTTPS = for a web site): Device Attestation Focus is on the implementation, the HW and SW The legal entity of interest is the device manufacturer The claims are about the HW and the SW, not the device owner Example: a mobile phone (not its owner/user) Example: integrity of a remote device Service Authenticity Focus is on the provider of the service, not the HW or SW The legal entity of interest is the service provider There is no equivalent of claims, but if there was they would be about = the business or person operating the service Example: a web site Example: an email provider (IMAP service) Service providers (e.g., web sites) use whatever HW and SW they want to = use. As a user of the service we don=E2=80=99t care what HW and SW they = select. We trust the service provider to pick good HW and SW and to = configure and operate it correctly. They might change the HW and the SW = and as a user we won=E2=80=99t know. For example we trust Bank of Xxx = to operate their banking web site correctly with little concern for = their HW. This is why attestation of the HW and SW is not so useful to = the user of a service. Users of mobile phones and IoT devices are not trustworthy to pick = secure HW and SW. They are not professionals like the people running web = sites. There is little accountability against them if they pick bad SW = and HW. Therefor we want attestation for these usage scenarios. This is = why EAT, FIDO and Android Attestation exist. I don=E2=80=99t think the line between device attestation and service = authenticity is completely black and white. In some use cases = attestation may be bent to provide some service authenticity. But I = don=E2=80=99t think it makes sense to add attestation to the millions of = web sites out there, add support for it to browsers and make attestation = an extra layer of security for web browsing. I think it is fine for a service provider to use attestation inside = their service to monitor integrity and such of the HW and SW providing = the service. But usually that won=E2=80=99t be manifest outside the = service. It could be awkward for the user to the service to have to re = evaluate the service every time the service provider changes HW. Another way to look at this is from a certification / regulatory view. = If the thing you're looking at is a candidate for implementation = certification such as Common Criteria, FIPS, FIDO certification, then it = probably lines up with device attestation. On the other hand, if the = thing your are looking at lines up with regulation (e.g., banking = regulation, GDPR,...) and to some degree OWASP , = then it probably lines up with service authenticity.=20 I think the RATS architecture document should probably have text that = describes when attestation is applicable and when it is not, for example = saying something like =E2=80=9Cattestation is not a replacement or = augmentation for HTTPS/TLS" I think the RATS architecture should be clear which of its components = are services and which are targets of attestation. In particular, I = think the Verifier and Endorser/Manufacturer are services and that = service authenticity is more appropriate for them than attestation (I = would consider a signed Endorsement a form of service authenticity). LL --Apple-Mail=_5247168A-2B95-4D04-A869-F098AB7A93F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is to introduce discussion about the use of TLS/HTTPS versus = Attestation. I=E2=80=99ve seen a few places where Attestation is being = proposed for use where I think TLS/HTTPS is probably sufficient or a = better fit.

Reviewing the = trust relationships described in the architecture document got me = thinking about sharpening a distinction between device = attestation (e.g., EAT for phone) and service = authenticity (e.g. HTTPS for a web site):

Device Attestation
  • Focus is on the = implementation, the HW and SW
  • The legal entity of = interest is the device manufacturer
  • The claims are = about the HW and the SW, not the device owner
  • Example: = a mobile phone (not its owner/user)
  • Example: = integrity of a remote device

Service Authenticity
  • Focus is on the = provider of the service, not the HW or SW
  • The legal = entity of interest is the service provider
  • There is = no equivalent of claims, but if there was they would be about the = business or person operating the service
  • Example: a = web site
  • Example: an email provider (IMAP = service)

Service providers (e.g., web sites) use whatever HW and SW = they want to use. As a user of the service we don=E2=80=99t care what HW = and SW they select. We trust the service provider to pick good HW and SW = and to configure and operate it correctly. They might change the HW and = the SW and as a user we won=E2=80=99t know.  For example we trust = Bank of Xxx to operate their banking web site correctly with little = concern for their HW. This is why attestation of the HW and SW is not so = useful to the user of a service.

Users of mobile phones and IoT devices = are not trustworthy to pick secure HW and SW. They are not professionals = like the people running web sites. There is little accountability = against them if they pick bad SW and HW. Therefor we want attestation = for these usage scenarios. This is why EAT, FIDO and Android Attestation = exist.

I = don=E2=80=99t think the line between device attestation and service = authenticity is completely black and white. In some use cases = attestation may be bent to provide some service authenticity. But I = don=E2=80=99t think it makes sense to add attestation to the millions of = web sites out there, add support for it to browsers and make attestation = an extra layer of security for web browsing.

I think it is fine for a service = provider to use attestation inside their service to monitor integrity = and such of the HW and SW providing the service. But usually that = won=E2=80=99t be manifest outside the service. It could be awkward for = the user to the service to have to re evaluate the service every time = the service provider changes HW.

Another way to look at this is from a = certification / regulatory view. If the thing you're looking at is a = candidate for implementation certification such as Common Criteria, = FIPS, FIDO certification, then it probably lines up with device = attestation. On the other hand, if the thing your are looking at lines = up with regulation (e.g., banking regulation, GDPR,...) and to some = degree OWASP, then it = probably lines up with service authenticity. 

I think the RATS = architecture document should probably have text that describes when = attestation is applicable and when it is not, for example saying = something like =E2=80=9Cattestation is not a replacement or augmentation = for HTTPS/TLS"

I= think the RATS architecture should be clear which of its components are = services and which are targets of attestation. In particular, I think = the Verifier and Endorser/Manufacturer are services and that service = authenticity is more appropriate for them than attestation (I would = consider a signed Endorsement a form of service authenticity).

LL




= --Apple-Mail=_5247168A-2B95-4D04-A869-F098AB7A93F2-- From nobody Mon Aug 3 12:03:30 2020 Return-Path: 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 4C4063A1068 for ; Mon, 3 Aug 2020 12:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 mw5H8F6leaUE for ; Mon, 3 Aug 2020 12:03:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43DA3A1062 for ; Mon, 3 Aug 2020 12:03:27 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 073J2NLc008812; Mon, 3 Aug 2020 20:03:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=/G8DQbwjpTvege86/BQCwG1asSpzv9VKypPhbF8/heY=; b=ff+NALfRjZhVd7PPPcj+Y1RBBy5Wamt4lIjuKsybMDlmGCfrqFGWQbcJ+ZlJCRjY4bfa LY5x8sAgeNtn0INEFK2RXuH49D4f9S27aD3ukOdrB9Jgfx3skTxFIEZHx1wEnbZkwWCt r/6m7dZh9q42GdhSQl/ZI+bSq35iwUoRQZaxFKkkysrfhDRmAn4MqmJSxfIL6+8Ts1TT QC82LzaOgsdQX70rrpn6KwnkHnEPtH/J4oIAOy3nZ0xN8aa/ZvVZMMpWElsw/jCJaFuD VPbpPc0+jz/jEOczOMkK9Vp6o5nTfWZpkyL6QVuOnkr7QxXmnc9D1bfBvbswG6r8mQ9T 2g== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 32n6y3wh1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 20:03:26 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 073IohR8019531; Mon, 3 Aug 2020 15:03:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 32n3qxq373-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 15:03:26 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 14:03:25 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Mon, 3 Aug 2020 14:03:25 -0500 From: "Salz, Rich" To: Laurence Lundblade , "rats@ietf.org" Thread-Topic: [Rats] Attestation of implementation vs authenticity of service Thread-Index: AQHWacguz/u1iJJ1nUmvdh+W841NEqkmzrkA Date: Mon, 3 Aug 2020 19:03:25 +0000 Message-ID: <002D1F7F-4894-44B0-82E6-5EBD80C698E4@akamai.com> References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> In-Reply-To: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.156] Content-Type: multipart/alternative; boundary="_000_002D1F7F489444B082E65EBD80C698E4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_15:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=960 adultscore=0 suspectscore=0 malwarescore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_15:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 clxscore=1011 mlxlogscore=928 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030132 Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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, 03 Aug 2020 19:03:29 -0000 --_000_002D1F7F489444B082E65EBD80C698E4akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQW5vdGhlciB3YXkgdG8gbG9vayBhdCB0aGlzIGlzIGZyb20gYSBjZXJ0aWZpY2F0aW9u IC8gcmVndWxhdG9yeSB2aWV3LiBJZiB0aGUgdGhpbmcgeW91J3JlIGxvb2tpbmcgYXQgaXMgYSBj YW5kaWRhdGUgZm9yIGltcGxlbWVudGF0aW9uIGNlcnRpZmljYXRpb24gc3VjaCBhcyBDb21tb24g Q3JpdGVyaWEsIEZJUFMsIEZJRE8gY2VydGlmaWNhdGlvbiwgdGhlbiBpdCBwcm9iYWJseSBsaW5l cyB1cCB3aXRoIGRldmljZSBhdHRlc3RhdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSB0 aGluZyB5b3VyIGFyZSBsb29raW5nIGF0IGxpbmVzIHVwIHdpdGggcmVndWxhdGlvbiAoZS5nLiwg YmFua2luZyByZWd1bGF0aW9uLCBHRFBSLC4uLikgYW5kIHRvIHNvbWUgZGVncmVlIE9XQVNQPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fb3dhc3Au b3JnJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0 c0tJLXcmbT1pMkhIeDdNNXNoWHZVWm1ibzJIOUpXRk5haDFjUVlSOVFMOHhTVVRKSGN3JnM9RDdu Y0x2UnEtYmNZc3I3MjJxWWt3Yk5VU3lpMmkxQXA3cnN0alNZLXpaMCZlPT4sIHRoZW4gaXQgcHJv YmFibHkgbGluZXMgdXAgd2l0aCBzZXJ2aWNlIGF1dGhlbnRpY2l0eS4NCg0KVGhhdCBpcyBhICp2 ZXJ5KiBpbnRlcmVzdGluZyB3YXkgdG8gc2xpY2UgdGhpbmdzOyBJ4oCZbGwgaGF2ZSB0byB0aGlu ayBhYm91dCBpdCBtb3JlLiBUaGFua3MhDQoNCg0KICAqICAgSSB0aGluayB0aGUgUkFUUyBhcmNo aXRlY3R1cmUgZG9jdW1lbnQgc2hvdWxkIHByb2JhYmx5IGhhdmUgdGV4dCB0aGF0IGRlc2NyaWJl cyB3aGVuIGF0dGVzdGF0aW9uIGlzIGFwcGxpY2FibGUgYW5kIHdoZW4gaXQgaXMgbm90LCBmb3Ig ZXhhbXBsZSBzYXlpbmcgc29tZXRoaW5nIGxpa2Ug4oCcYXR0ZXN0YXRpb24gaXMgbm90IGEgcmVw bGFjZW1lbnQgb3IgYXVnbWVudGF0aW9uIGZvciBIVFRQUy9UTFMiDQoNCkV4Y2VsbGVudCBwb2lu dC4gIERvaW5nIHNvIHdpbGwgbGlrZWx5IGF2b2lkIGEgcm91bmQtdHJpcCB3aXRoIHRoZSBzZWN1 cml0eSBBROKAmXMuDQoNCg== --_000_002D1F7F489444B082E65EBD80C698E4akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MDAzNjkwNDI7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ0MjI2OTg4NCAxNzc2NTkz Mzg2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6MTg1MDU1ODU2MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNzM4NjA5MjI7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjIwNDM5NDE1Mjk7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjExMDg4NzE0MjA7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi PkFub3RoZXIgd2F5IHRvIGxvb2sgYXQgdGhpcyBpcyBmcm9tIGEgY2VydGlmaWNhdGlvbiAvIHJl Z3VsYXRvcnkgdmlldy4gSWYgdGhlIHRoaW5nIHlvdSdyZSBsb29raW5nIGF0IGlzIGEgY2FuZGlk YXRlIGZvciBpbXBsZW1lbnRhdGlvbiBjZXJ0aWZpY2F0aW9uIHN1Y2ggYXMgQ29tbW9uIENyaXRl cmlhLCBGSVBTLA0KIEZJRE8gY2VydGlmaWNhdGlvbiwgdGhlbiBpdCBwcm9iYWJseSBsaW5lcyB1 cCB3aXRoIGRldmljZSBhdHRlc3RhdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSB0aGlu ZyB5b3VyIGFyZSBsb29raW5nIGF0IGxpbmVzIHVwIHdpdGggcmVndWxhdGlvbiAoZS5nLiwgYmFu a2luZyByZWd1bGF0aW9uLCBHRFBSLC4uLikgYW5kIHRvIHNvbWUgZGVncmVlJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19v d2FzcC5vcmcmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9 NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1pMkhIeDdNNXNoWHZVWm1ibzJIOUpXRk5haDFj UVlSOVFMOHhTVVRKSGN3JmFtcDtzPUQ3bmNMdlJxLWJjWXNyNzIycVlrd2JOVVN5aTJpMUFwN3Jz dGpTWS16WjAmYW1wO2U9Ij5PV0FTUDwvYT4sDQogdGhlbiBpdCBwcm9iYWJseSBsaW5lcyB1cCB3 aXRoIHNlcnZpY2UgYXV0aGVudGljaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIGEgKjxiPnZlcnk8L2I+KiBpbnRlcmVzdGluZyB3 YXkgdG8gc2xpY2UgdGhpbmdzOyBJ4oCZbGwgaGF2ZSB0byB0aGluayBhYm91dCBpdCBtb3JlLiBU aGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5JIHRoaW5rIHRoZSBSQVRTIGFyY2hpdGVjdHVy ZSBkb2N1bWVudCBzaG91bGQgcHJvYmFibHkgaGF2ZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIHdoZW4g YXR0ZXN0YXRpb24gaXMgYXBwbGljYWJsZSBhbmQgd2hlbiBpdCBpcyBub3QsIGZvciBleGFtcGxl IHNheWluZyBzb21ldGhpbmcgbGlrZSDigJxhdHRlc3RhdGlvbiBpcw0KIG5vdCBhIHJlcGxhY2Vt ZW50IG9yIGF1Z21lbnRhdGlvbiBmb3IgSFRUUFMvVExTJnF1b3Q7PG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4Y2VsbGVudCBwb2ludC4mbmJzcDsgRG9pbmcg c28gd2lsbCBsaWtlbHkgYXZvaWQgYSByb3VuZC10cmlwIHdpdGggdGhlIHNlY3VyaXR5IEFE4oCZ cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_002D1F7F489444B082E65EBD80C698E4akamaicom_-- From nobody Mon Aug 3 12:59:56 2020 Return-Path: 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 8E9203A0B83 for ; Mon, 3 Aug 2020 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pUdNDwQMVouk for ; Mon, 3 Aug 2020 12:59:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862E93A10DF for ; Mon, 3 Aug 2020 12:59:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A497438996 for ; Mon, 3 Aug 2020 15:39:06 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cdt7xYQ20eUh for ; Mon, 3 Aug 2020 15:39:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5856838995 for ; Mon, 3 Aug 2020 15:39:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9DD1463E for ; Mon, 3 Aug 2020 15:59:42 -0400 (EDT) From: Michael Richardson To: rats@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Rats] Architecture Design Team meetings X-BeenThere: rats@ietf.org 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, 03 Aug 2020 19:59:53 -0000 --=-=-= Content-Type: text/plain I'd like a week off, many of you probably do too. Let's resume weekly August 11. That doesn't mean you can't edit pull requests. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8obK4ACgkQgItw+93Q 3WUR9Af+NiuOAXcc5p0N5rMfcaZhAZCS2dUYaumQZm0ggOAZzLMnJjQlej3NAZHL /eS3HJhXClSyYkOJzuEhrpCtfv/oAJt2QS3CQU5qhiVAou9zrvYey6SpIsyOo00u 55aLu2cK7CxLFanHk/5KgZZzFcjqBTH/gpVO8haWKZXffj6hdMm8Lv3wZvQ7OQqw w4laiD2tqW/RR9+D9taDI/f5tzGEWr7MNkRFGvfnK8+5CeGxzuw+R95pijPGilmw yQr7DUr7f3TkPbc7pIQOBxijtXd9+8wQHRIKQpJhnrTVUm91+S3tZM+xAr/TDpdt IstgwIGcI13yYHIqM6NplX/O00CWBQ== =YcXq -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 17:47:15 2020 Return-Path: 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 B828F3A11C3 for ; Mon, 3 Aug 2020 17:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3Hsg1taKSTmg for ; Mon, 3 Aug 2020 17:47:11 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340453A11BE for ; Mon, 3 Aug 2020 17:47:11 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id y8so13954141vsq.8 for ; Mon, 03 Aug 2020 17:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Eqi+VoL8UGgWnJ//zaAbBdHdKYIWf2QLzOH1LmzYXA=; b=T084tq61F5+PZWQvGinBXo+IgW+5G3+Wy5CKURD3cyZ8c3LtjOVHFyvtQb4CXwX3c5 wYlcmoiEYimwaeetQIW8Ybm5L9jNLh6TG8LZfUnuu3vD7D5siYAp78sLH04Y0MEtFoqP bMAE+lilrnhNR0RiR8NrxS4Pe959E37kkFGexXh+ubfa+yiOC2XJmhiEajxA8CrLXPIx tduPfOvdrzfAn+X03CLdSxBgSunoxS/jY/hJugRm5JpZ4VZ5UWwlEmeFEFSjidqPMJ5D 42XkLDbbfMBf7RpcCnejWY1DMLxEkfyxPewUxwWmuf5Z5b7yrfOEtAdq8rfDGVkzPd9J Z74Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Eqi+VoL8UGgWnJ//zaAbBdHdKYIWf2QLzOH1LmzYXA=; b=Vz44PG9Y/MrcjFQGPXQhJ/aONMntHS1OFD+Gz5Ix3GuCmIOPzPqGwFhTtCrtgM29Xl 6c/ZH5MiRwqKWoLrglSS/3HE/0FY6m3F9Oc0ZWaZrTobG/wGZ3CR2RWE8yvV3D4vDLgC lMdjYjkoJB1Gv79I5Uu6EwS7gy1WGP0zVTKVqKA1ztMKPIGzJyBtkBlLilgOtYdX6kDV RWQA+8FkIR5mphYQxIHaTuLHzfplfEPXFBTXSVD7o6w+YES0RqQjc9ka8jqdf5qjQewb 623PvgtGPMCehwJ6HJ98WMivA1U6HtoTdvRK4QdL2Z3niSaSeCTUmPplR2IapMxvTHNS 65jw== X-Gm-Message-State: AOAM53392k50Sm7vLaByzVNjaL4ZpYN4A/CKlMQmikBh83G5OaPfeZrM 79IRUNpaISa2D38PHRrm2Uwx3BVKYDtmu1Pta6Q= X-Google-Smtp-Source: ABdhPJy0eYFBMF6YzKdiXHJZIUm/3gXB5WTcDnFANENe7jWKLVLLIZHng+/aC271pYXgxXXgxogMC6XvkmpqwDkFIQw= X-Received: by 2002:a67:f5ce:: with SMTP id t14mr12125270vso.240.1596502030263; Mon, 03 Aug 2020 17:47:10 -0700 (PDT) MIME-Version: 1.0 References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <002D1F7F-4894-44B0-82E6-5EBD80C698E4@akamai.com> In-Reply-To: <002D1F7F-4894-44B0-82E6-5EBD80C698E4@akamai.com> From: Ira McDonald Date: Mon, 3 Aug 2020 20:46:59 -0400 Message-ID: To: "Salz, Rich" , Ira McDonald Cc: Laurence Lundblade , "rats@ietf.org" Content-Type: multipart/alternative; boundary="00000000000065a9d805ac02982e" Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 00:47:13 -0000 --00000000000065a9d805ac02982e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, +1 to Laurence's insight here on Attestation for Devices versus TLS/HTTPS for Services. Cheers, - Ira On Mon, Aug 3, 2020 at 3:03 PM Salz, Rich wrote: > > - Another way to look at this is from a certification / regulatory > view. If the thing you're looking at is a candidate for implementation > certification such as Common Criteria, FIPS, FIDO certification, then = it > probably lines up with device attestation. On the other hand, if the t= hing > your are looking at lines up with regulation (e.g., banking regulation= , > GDPR,...) and to some degree OWASP > , > then it probably lines up with service authenticity. > > > > That is a **very** interesting way to slice things; I=E2=80=99ll have to = think > about it more. Thanks! > > > > - I think the RATS architecture document should probably have text > that describes when attestation is applicable and when it is not, for > example saying something like =E2=80=9Cattestation is not a replacemen= t or > augmentation for HTTPS/TLS" > > > > Excellent point. Doing so will likely avoid a round-trip with the > security AD=E2=80=99s. > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --00000000000065a9d805ac02982e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

+1 to Laurence's ins= ight here on Attestation for Devices versus
TLS/HTTPS for Service= s.

Cheers,
- Ira



On Mon, Aug 3, 2020 at 3:03 PM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote= :
  • Another way to look at this is from a certification / regulatory v= iew. If the thing you're looking at is a candidate for implementation c= ertification such as Common Criteria, FIPS, FIDO certification, then it probably lines up with device attestation. On = the other hand, if the thing your are looking at lines up with regulation (= e.g., banking regulation, GDPR,...) and to some degree=C2=A0OWASP, then it probably lines up with service authenticity.=C2=A0

=C2=A0

That is a *very* interesting way to slice thi= ngs; I=E2=80=99ll have to think about it more. Thanks!

=C2=A0

  • I think the RATS architecture document should probably have text t= hat describes when attestation is applicable and when it is not, for exampl= e saying something like =E2=80=9Cattestation is not a replacement or augmentation for HTTPS/TLS"

=C2=A0

Excellent point.=C2=A0 Doing so will likely avoid a = round-trip with the security AD=E2=80=99s.

=C2=A0

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--00000000000065a9d805ac02982e-- From nobody Mon Aug 3 22:18:35 2020 Return-Path: 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 3E2A33A0C7B for ; Mon, 3 Aug 2020 22:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnpUpJSYCwIw for ; Mon, 3 Aug 2020 22:18:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10EF13A0C77 for ; Mon, 3 Aug 2020 22:18:28 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 798FB3E44D4E6C33FCD0 for ; Tue, 4 Aug 2020 06:18:25 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 06:18:24 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 13:18:22 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 13:18:22 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" Thread-Topic: Charra: certificate-name vs TPM-name Thread-Index: AdZk7AdVjrhIJhH+SNGp+N2fr3/WmwBS28JgANYNhuAAG/cWAA== Date: Tue, 4 Aug 2020 05:18:22 +0000 Message-ID: References: <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_d9338204e8ff4adc8670033197774f1dhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Charra: certificate-name vs TPM-name X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 05:18:32 -0000 --_000_d9338204e8ff4adc8670033197774f1dhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for your reply. After a twice thinking, I realize it's true that the= difference between our proposals is that whether to contain in = the response and whether to make unique across different= TPMs. Some thoughts please see inline. Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, August 4, 2020 12:42 AM To: Panwei (William) Cc: rats@ietf.org Subject: Re: [Rats] Charra: certificate-name vs TPM-name Hi Wei Pan, I fully agree that multiple line cards per switch/router is necessary. The = current model does support this, as the RPC output is a list. Lists are id= entified by the "[]" in the tree diagram. So for any current list entry, = a which is unique to an individual TPM can be placed wit= hin this list. The real difference I see between our proposals is that you want = explicitly listed in the RPC response, [Wei] Indeed. and I thought a unique which doesn't require users of si= ngle TPM devices to understand is preferable. I.e., some comple= xity is hidden within the router so that a class of developers need not car= e. [Wei] But I think some new complexities for multi-TPM devices have also eme= rged. The first complexity is that the certificate name should be unique across T= PMs. Imagine this case: there are two TPMs and each one has a certificate, e.g.,= tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA cha= nges its certificate, it releases the name 'cert1' and names the new certif= icate 'cert3'. Right after that tpmB changes its certificate, and names the= new certificate 'cert1' because 'cert1' is unique right now. But you can s= ee a potential problem here, if the Verifier receives the attestation respo= nse before receiving the updates of the certificates, it will wrongly match= the record according to the certificate-name, as it doesn't know the owner= of 'cert1' is changed. Although the Verifier will fail to verify the signa= ture, but it doesn't know what's the real problem. So, the second complexity is that the certificate name should not be reused= by other TPMs. There may be other complexities that I didn't come up with. But if adding the tpm-name in the response, there is no need to make the ce= rtificate-name unique across TPMs, and no need to consider other TPMs when = naming a certificate. This also won't complex single-TPM devices. Because for these devices, the = tpm-name can be arbitrary, even using a NULL string may also be acceptable. Below are some extensive thoughts on both options. In the end I really am = fine with both. To start with, I believe some useful context comes from the ietf-keystore.y= ang YANG model which is currently under WGLC as part of draft-ietf-netconf-= keystore-17. Here the following structure can be used to identify a uniqu= e certificate independent of any TPM: module: ietf-keystore.yang +--rw keystore +--rw asymmetric-keys +--rw asymmetric-key* [name] +--rw name string +--rw certificates +--rw certificate* [name] +--rw name string In this model, the certificate's name is accessed without any TPM informati= on. The next level in the hierarchy is the key name. Note that in this mo= del, certificate's object different than currently in charra. The = charra leaf can point to that keystore: path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:certificates/ks:certificate/ks:name"; This means we have access to all the certificate info which a keystore woul= d support. [Wei] Understood. There are 'certificate-name' and 'certificate-ref' in cha= rra and there is certificate's 'name' in the keystore. The 'certificate-nam= e' in charra can't be used to find the actual certificate, but the 'certifi= cate-ref' should be used to find the matched certificate in the keystore. W= hen the Verifier receives the response output, it first uses the certificat= e-name to search the local rats-support-structures database to find the cor= responded TPM and get the certificate-ref, then it uses the certificate-ref= to get the actual certificate in the keystore. More after your questions... From: Panwei, August 2, 2020 10:02 AM Hi Eric, I don't object to contain the certificate-name in the response, I just sugg= est 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 securit= y perspective, I think one TPM per line card is needed, or at least using m= ore TPMs is the trend. So the YANG module should consider the forward compa= tibility. By using the tpm-name as the key of the output (and containing the certific= ate-name in the output), there are several advantages: 1) It's easy for the readers to understand. I believe it harder. You still need to make man= datory. Otherwise you likely need to acquire and test multiple keys from = a keystore to find the right one. [Wei] The is also mandatory. But for the readers, they w= ill firstly know which TPM this record matches with, and secondly know whic= h certificate this TPM uses. I think this hierarchy is more logical for rea= ding. Note: by mandating the key of in your proposal you are enforcing= that only one response using a single key from TPM may be included. Perha= ps this is a good thing. It is not a good thing if anyone ever wants to re= turn two tpm quotes using different TPM keys as part of the same RPC respon= se. [Wei] I agree using the tpm-name as the key is not so necessary. Just addin= g the tpm-name into the response is enough. 2) It's easy for the Verifier to distinguish which TPM each record correspo= nds to and which certificate that TPM uses. In both cases you need to get to the key itself from a keystore. A= certificate points to a key, which is associated with a particular TPM. T= he key is already required for validating the signature of returned results= . [Wei] Got it. The key is stored in the keystore. To get the key, the Verifi= er needs to use the to match against the certificate's in the keystore. To get the , the Verifier needs to u= se the in the response to match against the in the rats-support-structures. 3) If the re-keying happens and a new certificate-name is provided to the V= erifier, the Verifier only needs to query the Attester about the certificat= es of the specific TPM and doesn't need to retrieve the certificates of all= TPMs. This is not required for the existing model. All you need to do is = a get on the existing model with the provided . [Wei] Yes, I figured it out after the twice thinking. But here requires the= to be unique across TPMs. 4) While using different TPM names is already required, this approach doesn= 't further require to use different certificate names for different TPMs. If we make dependent on , then we have = the nested keys which we are trying to avoid for those devices which only h= ave a single TPM. The main question I see from above is whether making th= e (which is system generated) unique across TPMs. Agai= n I believe this is helpful for those devices with just one TPM. [Wei] Actually, I think my approach makes the independen= t with the . Because when you name a certificate within one TPM, = you don't need to care about other TPMs to make the certificate-name unique= across TPMs. Previously, the module uses the and as the nested keys= to identify the TPM, this is unnecessary for the devices which only have a= single TPM. But this approach only uses the to identify the TPM= . The may be a little redundant for the devices which only have = a single TPM, but it's not harm, I think. Eric Regards & Thanks! Wei Pan From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Tuesday, July 28, 2020 11:30 PM To: Panwei (William) > Cc: rats@ietf.org Subject: Charra: certificate-name vs TPM-name Hi Wei Pan, During the RATS WG call you wondered why certificate-name should be used ra= ther 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-certifi= cate upgrade in one place. If the certificate-name is not in the RPC, a Ve= rifier will have to make several guesses on what any failure of signature v= erification might mean. (2) The most common implementations will have just one TPM per router/switc= h. These implementations might never care about the tpm-name. They will c= are about the certificate used on that router/switch. Thanks, Eric Eric Voit .:|:.:|:. Cisco Systems, Inc. --_000_d9338204e8ff4adc8670033197774f1dhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Thanks for your reply. After a twice think= ing, I realize it’s true that the difference between our proposals is= that whether to contain <tpm-name> in the response and whether to make <certificate-name> unique across different TPMs.

Some thoughts please see inline.

 

Regards & T= hanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats@ietf.org
Subject: Re: [Rats] Charra: certificate-name vs TPM-name<= /span>

 

Hi Wei = Pan,

&n= bsp;

I fully= agree that multiple line cards per switch/router is necessary. The current= model does support this, as the RPC output is a list.  Lists are iden= tified by the "[]" in the tree diagram.   So for any current list entry, a <cert= ificate-name> which is unique to an individual TPM can be placed within = this list.

&n= bsp;

The rea= l difference I see between our proposals is that you want <tpm-name> = explicitly listed in the RPC response,

 

[Wei] Indeed.

 

and I t= hought a unique <certificate-name> which doesn't require users of sin= gle TPM devices to understand <tpm-name> is preferable.  I.e., s= ome complexity is hidden within the router so that a class of developers need not care.

 

[Wei] But I think some new complexities fo= r multi-TPM devices have also emerged.

The first complexity is that the certifica= te name should be unique across TPMs.

Imagine this case: there are two TPMs and = each one has a certificate, e.g., tpmA’s certificate is cert1 and tpm= B’s certificate is cert2. When tpmA changes its certificate, it releases the name ‘cert1’ and names the new certificate = 216;cert3’. Right after that tpmB changes its certificate, and names = the new certificate ‘cert1’ because ‘cert1’ is uniq= ue right now. But you can see a potential problem here, if the Verifier rec= eives the attestation response before receiving the updates of the certificates,= it will wrongly match the record according to the certificate-name, as it = doesn’t know the owner of ‘cert1’ is changed. Although th= e Verifier will fail to verify the signature, but it doesn’t know what’s the real problem.

So, the second complexity is that the cert= ificate name should not be reused by other TPMs.

There may be other complexities that I did= n’t come up with.

 

But if adding the tpm-name in the response= , there is no need to make the certificate-name unique across TPMs, and no = need to consider other TPMs when naming a certificate.

This also won’t complex single-TPM d= evices. Because for these devices, the tpm-name can be arbitrary, even usin= g a NULL string may also be acceptable.

&n= bsp;

Below a= re some extensive thoughts on both options.  In the end I really am fi= ne with both.

&n= bsp;

To star= t with, I believe some useful context comes from the ietf-keystore.yang YAN= G model which is currently under WGLC as part of draft-ietf-netconf-keystor= e-17.   Here the following structure can be used to identify a unique certificate independent of any TPM: &nbs= p; 

   module: i=
etf-keystore.yang
     &#=
43;--rw keystore
    &nb=
sp;   +--rw asymmetric-keys
    &nb=
sp;      +--rw asymmetric-key* [name]
    &nb=
sp;         +--rw name &nb=
sp;            =
            &nb=
sp;         string
    &nb=
sp;         +--rw certificates<=
o:p>
    &nb=
sp;            +=
--rw certificate* [name]
    &nb=
sp;             =
;  +--rw name        =
            &nb=
sp; string

In this= model, the certificate's name is accessed without any TPM information.&nbs= p; The next level in the hierarchy is the key name.  Note that in this= model, certificate's <name> object different than currently in charra.   The charra leaf <certificate-ref> c= an point to that keystore:

     &= nbsp;        path "/ks:keystore/ks:= asymmetric-keys/ks:asymmetric-key"

     &= nbsp;           + &qu= ot;/ks:certificates/ks:certificate/ks:name";

This me= ans we have access to all the certificate info which a keystore would suppo= rt.

&nbs= p;

[Wei] Understood. There are ‘certifi= cate-name’ and ‘certificate-ref’ in charra and there is c= ertificate’s ‘name’ in the keystore. The ‘certifica= te-name’ in charra can’t be used to find the actual certificate, but the ‘certificate-refR= 17; should be used to find the matched certificate in the keystore. When th= e Verifier receives the response output, it first uses the certificate-name= to search the local rats-support-structures database to find the corresponded TPM and get the certificate-ref, then it= uses the certificate-ref to get the actual certificate in the keystore.

 

More af= ter your questions...

 

From: Panwei, August 2, 2020 10:02 AM

Hi Eric,

 

I don’t object to contain the certif= icate-name in the response, I just suggest to add the tpm-name in the respo= nse and use it as the key.

I don’t believe that one TPM per rou= ter/switch is enough. >From the security perspective, I think one TPM pe= r line card is needed, or at least using more TPMs is the trend. So the YANG module should consider the forward compatibility.<= /o:p>

 

By using the tpm-name as the key of the ou= tput (and containing the certificate-name in the output), there are several= advantages:

1) It’s easy for the readers to unde= rstand.

 

<eric> I believe it harder. &= nbsp; You still need to make <certificate-name> mandatory.  = ; Otherwise you likely need to acquire and test multiple keys from a keysto= re to find the right one.   

 

[Wei] The <certificate-name> is also= mandatory. But for the readers, they will firstly know which TPM this reco= rd matches with, and secondly know which certificate this TPM uses. I think this hierarchy is more logical for reading.

 

Note: by mandating the key of <tpm-na= me> in your proposal you are enforcing that only one response using a si= ngle key from TPM may be included.  Perhaps this is a good thing.  It is not a good thing if anyone ever wants to return tw= o tpm quotes using different TPM keys as part of the same RPC response.

 

[Wei] I agree using the tpm-name as the ke= y is not so necessary. Just adding the tpm-name into the response is enough= .

 

2) It’s easy for the Verifier to dis= tinguish which TPM each record corresponds to and which certificate that TP= M uses.

 

<eric> In both cases you need to g= et to the key itself from a keystore.   A certificate points to a= key, which is associated with a particular TPM.  The key is already required for validating the signature of returned results.

 

[Wei] Got it. The key is stored in the key= store. To get the key, the Verifier needs to use the <certificate-ref>= ; to match against the certificate’s <name> in the keystore. To get the <certificate-ref>, the Verifier needs to use the <cert= ificate-name> in the response to match against the <certificate-name&= gt; in the rats-support-structures.

 

3) If the re-keying happens and a new cert= ificate-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.<= /o:p>

 

<eric> This is not required for th= e existing model.  All you need to do is a get on the existing model w= ith the provided <certificate-name>.

 

[Wei] Yes, I figured it out after the twic= e thinking. But here requires the <certificate-name> to be unique acr= oss TPMs.

 

4) While using different TPM names is alre= ady required, this approach doesn’t further require to use different = certificate names for different TPMs.

 

<eric> If we make <certificate-= name> dependent on <tpm-name>, then we have the nested keys which = we are trying to avoid for those devices which only have a single TPM.   The main question I see from above is whether making the = <certificate-name> (which is system generated) unique across TPMs.&nb= sp;  Again I believe this is helpful for those devices with just one T= PM.

 

[Wei] Actually, I think my approach makes = the <certificate-name> independent with the <tpm-name>. Because= when you name a certificate within one TPM, you don’t need to care about other TPMs to make the certificate-name unique across TPMs. =

Previously, the module uses the <tpm-na= me> and <node-id> as the nested keys to identify the TPM, this is = unnecessary for the devices which only have a single TPM. But this approach only uses the <tpm-name> to identify the TPM. The <= tpm-name> may be a little redundant for the devices which only have a si= ngle TPM, but it’s not harm, I think.

 

Eric

 

Regards & T= hanks!

Wei Pan

 

From: Eric Voit (evoit) [mailto:ev= oit@cisco.com]
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats@ietf.org
Subject: Charra: certificate-name vs TPM-name

 

Hi Wei Pan,

 

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

 

(1) In RFC places like:

 

 &= nbsp;    +---x tpm20-challenge-response-attestation {TPM= 20}?

  =        +--ro output

 &= nbsp;          +--ro tpm20= -attestation-response* []

      =          +--ro certificate= -name?           string

 &= nbsp;           &nbs= p; +--ro quote?         &n= bsp;            &nbs= p;       binary

 &= nbsp;            &nb= sp;+--ro quote-signature        &nbs= p;     binary

 

if just the tpm-name is provide= d, how does a Verifier know when a re-keying happens?    Wit= h the current solution, when unknown certificate-name comes back from the R= PC, you just need to query:

 

 &= nbsp;  +--rw rats-support-structures

 &= nbsp;     +--rw tpms* [tpm-name]<= /p>

 &= nbsp;        +--rw tpm-name &nb= sp;            =        string

 &= nbsp;        +--rw certificates=

 &= nbsp;           +--rw= certificate* [certificate-name]

     &= nbsp;          +--rw certi= ficate-name    string

     &= nbsp;          +--rw certi= ficate-ref?    leafref

     &= nbsp;          +--rw certi= ficate-type?   enumeration

 

and then you can find the tpm-n= ame, 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 s= everal guesses on what any failure of signature verification might mean.

 

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

 

Thanks,

Eric

 

Eric Voit

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

 

--_000_d9338204e8ff4adc8670033197774f1dhuaweicom_-- From nobody Mon Aug 3 22:44:56 2020 Return-Path: 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 156643A0CB8 for ; Mon, 3 Aug 2020 22:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8RN94xXvEwsL for ; Mon, 3 Aug 2020 22:44:52 -0700 (PDT) Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64273A0CB7 for ; Mon, 3 Aug 2020 22:44:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GkBgD/9Chf/xmnZsBgHgEBCxIMQIE?= =?us-ascii?q?/CwKBeYEegTMKhCuRGptRNAkLAQEBAQEBAQEBBgEBGAsKAgQBAQKBVIJ2AoI?= =?us-ascii?q?8ASQ3Bg4CEAEBBgEBAQEBBgQCAoZFDEMBEAGCHWGBAwEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEgINNh43EgEeAQEBAQIBAQEhDwEFNgQHBQsLDgQGAgImAgI?= =?us-ascii?q?nIAIOBgEJAwEFAgEBgyIBglwgBAuxaHaBMoRQQEKDPYE6BoEOKgGGToYwDw+?= =?us-ascii?q?BTD+BEScPgiwuPoJcAQGEdYJgBI9gEYMChwSbFVwpB4FagQqBCQQLh0mRHAU?= =?us-ascii?q?KHoJ8jk8GKI4BkiaKM5RxAgQCCQIVgWmBfE0kT4JpUBcCDY4qARcUbgECgkm?= =?us-ascii?q?FFIVEcjcCBgEHAQEDCXyHb4YgAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2GkBgD/9Chf/xmnZsBgHgEBCxIMQIE/CwKBeYEegTMKh?= =?us-ascii?q?CuRGptRNAkLAQEBAQEBAQEBBgEBGAsKAgQBAQKBVIJ2AoI8ASQ3Bg4CEAEBB?= =?us-ascii?q?gEBAQEBBgQCAoZFDEMBEAGCHWGBAwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?gINNh43EgEeAQEBAQIBAQEhDwEFNgQHBQsLDgQGAgImAgInIAIOBgEJAwEFA?= =?us-ascii?q?gEBgyIBglwgBAuxaHaBMoRQQEKDPYE6BoEOKgGGToYwDw+BTD+BEScPgiwuP?= =?us-ascii?q?oJcAQGEdYJgBI9gEYMChwSbFVwpB4FagQqBCQQLh0mRHAUKHoJ8jk8GKI4Bk?= =?us-ascii?q?iaKM5RxAgQCCQIVgWmBfE0kT4JpUBcCDY4qARcUbgECgkmFFIVEcjcCBgEHA?= =?us-ascii?q?QEDCXyHb4YgAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,433,1589234400"; d="scan'208";a="23345081" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2020 07:44:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6BwDG9Chf/1lIDI1gHgEBCxIMQIE?= =?us-ascii?q?/CwKBeS9vA1QwLAqEK5EZnA4LAQMBAQEBAQYBARgLCgIEAQGBVoJ2AoI6AiQ?= =?us-ascii?q?3Bg4CEAEBBQEBAQIBBgRthVwMQwEQAYUcAQEBAwEBASEPAQU2BAcFCwsOBAY?= =?us-ascii?q?CAiYCAicgAg4GAQkDAQUCAQGDIgGCXCQLsWh2gTKEUEBCgz2BOgaBDioBhk6?= =?us-ascii?q?GMA8PgUw/gREnD4IsLj6CXAEBhHWCYASPYBGDAocEmxVcKQeBWoEKgQkEC4d?= =?us-ascii?q?JkRwFCh6CfI5PBiiOAZImijOUcQIEAgkCFYFpJIFXTSRPgmlQFwINjioBFxR?= =?us-ascii?q?uAQKCSYUUhURBMTcCBgEHAQEDCXyHb4YgAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,433,1589234400"; d="scan'208";a="87538169" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2020 07:44:44 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0745ihCU000566 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 4 Aug 2020 07:44:43 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 4 Aug 2020 07:44:38 +0200 To: Laurence Lundblade , Michael Richardson CC: References: <4445014C-A191-4885-BE67-5502EF3E551F@intel.com> <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> <2900.1596296932@localhost> <7A5BB0EB-BA4F-4210-87C0-E9F9C6C23979@island-resort.com> From: Henk Birkholz Message-ID: <88357bf6-5fe0-ebd3-fd2a-4383223715f5@sit.fraunhofer.de> Date: Tue, 4 Aug 2020 07:44:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7A5BB0EB-BA4F-4210-87C0-E9F9C6C23979@island-resort.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 05:44:55 -0000 A single vital comment in-line: On 01.08.20 21:37, Laurence Lundblade wrote: > > >> On Aug 1, 2020, at 8:48 AM, Michael Richardson wrote: >> >> >> There is some discussion in private, on github and in the architecture DT >> calls around the question of Endorsements. >> >> There is a pull request at: >> https://github.com/ietf-rats-wg/architecture/pull/94 >> text. The text is >> https://github.com/ietf-rats-wg/architecture/pull/94/files, >> and I suggest that new readers go to the three dots and unselect "Show comments" >> >> But, I include the text: >> >> - An Endorsement is a secure statement that some entity (e.g., a >> - manufacturer) vouches for the integrity of the >> - device's signing capability. For example, if the signing capability is in hardware, then >> - an Endorsement might be a manufacturer certificate that signs a public key whose corresponding >> - private key is only known inside the device's hardware. >> >> + An Endorsement input to a Verifier is always required. An Endorsement is >> + what allows a Verifier to trust an Attester and in turn to trust the Evidence >> + produced by an Attester. Without Endorsements a Verifier cannot function. >> + Said another way, an Attester for which there is no Endorsement is not >> + useful since there is no good basis by which a Verifier can trust it. >> >> + One of the Endorsements for an Attester will just about always contain >> + cryptographic key material. >> + This key material will correspond to key material that is put in the Attester. >> + The key material is the basis for the Verifier trusting the Attester. >> + This architecture does not dictate any particular cryptographic protocol >> + for establishing this trust, hence the key material can be symmetric or >> + asymmetric, a single key, multiple keys, key hierarchies, X.509 cert or >> + chains or other. >> >> I think that we get into conflict immediately on the first sentence. >> >> There ARE many use cases in which we WILL need input to the >> Verifier from a variety of manufacturers in a signed artifact form.(A) >> >> There are other use cases in which the Verifier will be configured with all >> the information that it needs. Is a configuration file, loaded by a trusted >> operator, a "secure statement"? >> I think so, and this is why we used this wording. (B) > > My view is that the arrows in the diagram show the complete and exhaustive inputs of relevance to attestation. Probably adjusting the expectations of the arrows in the diagrams wrt to "completeness" can mitigate this issue at it's root? > The one and only input from the Manufacturer/Endorser to the Verifier is the Endorsement. If there is a configuration file (with keys) transferred from the Manufacturer/Endorser to the Verifier, it would be going over the arc labeled Endorser in the diagram. > > I think this is true of every arrow/arc in Figure 1. I don’t think are alternate channels. It seems confusing to tacitly expect the reader to assume them. > > Even if it weren’t true, the key material is critical and fundamental to attestation that its transfer needs to upfront and clear. You can do attestation with just a key and a nonce and nothing else. You can’t do attestation without a key and nonce. We have pages of discussion on nonces. > > The most important thing transferred from Manufacturer/Endorser to the Verifier is the verification key material. It should be characterized clearly and should allow for all types of keys and transfer scenarios. > >> >> When I read the changes above, it seems to me that it contains aspirational >> text that intends to make case (A) universal. >> >> I think that a number of us believe that an Endorsement is the name for a >> signed artifact. This may be the basis for our disagreement: I'm not entirely sure. >> Our definition of "Endorsement" does not say that, so it may be that I read >> too much into the proposed changes. > > Endorsement being a “signed artifact†seems like common understanding in the TCG world to me. > > If we want to stick with that definition, that is fine, but that excludes Endorsements as a means to convey symmetric keys, databases of keys and the operation of a key look up service and a hash verification service. So then we need to switch to a term like Verifier Input with Endorsements being one form of Verifier Input. > > >> >> I firmly believe that we will need an Architecture for Distributed Endorsements. >> I also think that we can do this separately, and that there are probably >> reasons for some industrial verticals to do this on their own. > > Agree with that. > > I’m only after a few paragraphs of high-level characterization. Nothing as detailed as the nonce discussion. > >> >> It could be that this is not the goal of the above text. >> >> I do not think we need this level of detail in this part of the architecture. >> It's not wrong, it's just not helpful, I think. > > What’s different about the Endorser-Verifer-Attester trust relationship is that it is transitive in a unique and important way for attestation. I think bringing that to light in a clear way is necessary. > > LL > > >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > From nobody Mon Aug 3 23:31:29 2020 Return-Path: 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 B3CFE3A0EEA; Mon, 3 Aug 2020 23:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AxlYa0FxW2Lw; Mon, 3 Aug 2020 23:31:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A553A0EE9; Mon, 3 Aug 2020 23:31:26 -0700 (PDT) Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 68EA530947F0C9252121; Tue, 4 Aug 2020 07:31:25 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 07:31:24 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 14:31:22 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 14:31:22 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Comments on the changes of CHARRA YANG module Thread-Index: AdZWpd3aUHkm/3I1RKafnNj2CppmIwAHwgsgAAAIMzAAAASPEASf77EQABwSseAAG9AKEA== Date: Tue, 4 Aug 2020 06:31:22 +0000 Message-ID: <701283a1d6214c789a5e3e8dd3d09d6e@huawei.com> References: <4e2e0b53d2be47009b1958758620914c@huawei.com> <3cac223f282f47f882f6da0507b0b841@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Comments on the changes of CHARRA YANG module X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 06:31:29 -0000 Hi Eric, I'm forwarding this thread to the rats mailing list. Other comments but the below one are discussed in the other thread.=20 > This is not a problem, the question is then do we make this a case > statement, or use XPATH. Either one works. Do you want to propose the > YANG model change? Sure, I can propose a change in the github. Regards & Thanks! > -----Original Message----- > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Tuesday, August 4, 2020 12:54 AM > To: Panwei (William) ; > draft-ietf-rats-yang-tpm-charra@ietf.org > Cc: rats-chairs@ietf.org > Subject: RE: Comments on the changes of CHARRA YANG module >=20 > Hi Wei Pan, >=20 > > Hi Eric, > > > > Thanks for your reply, and sorry for my late reply, please see inline. > > > > Regards & Thanks! > > Wei Pan > > > > > -----Original Message----- > > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > > > Sent: Friday, July 10, 2020 11:24 PM > > > To: Panwei (William) > > > Cc: rats-chairs@ietf.org > > > Subject: RE: Comments on the changes of CHARRA YANG module > > > > > > Hi Wei Pan, > > > > > > Thanks for the comments. Some thoughts in-line... > > > > > > > From: Panwei (William), July 10, 2020 6:39 AM > > > > > > > > Hi Eric, > > > > > > > > I've read the YANG modules you changed, actually I didn't get how > > > > the > > > new > > > > modules worked when I read it the first time. After reading it a fe= w > > > > times and discussion with others, I kind of figured out how it work= ed: > > > > > > It seems like it would be good to add some text which explains common > > > operations outside of the YANG model. I will propose some text to > the > > > draft based on your thoughts lower in the thread. > > > > Thanks. > > > > > > 1. The Verifier (or Relying Party) uses the "rats-support-structure= s" > > > > datastore structure to retrieve the hardware information, i.e., all > > > > the compute-nodes and all the TPMs, from the Attester. Then the > > > > Verifier can establish the relationship between the TPM and its > > > > compute-node info > > > and > > > > certificates info. Further, the Verifier can identify the TPM > > > > according to the certificate-name and/or the compute-node. > > > > > > Yes. A large benefit we don't send redundant information in a > continuous > > > set of RPC replies. And by sending the certificate as the unique > > > identifier, it becomes easy to handle certificate upgrades, as when > > > you see a new certificate being used, you then can retrieve the > > > information from the Attester. > > > > I agree with the design that sending the certificate identifier instead= of > the > > actual certificate. As I explained in another email, I just suggest tha= t > adding the > > tpm-name as the key. >=20 > We can work that one in the other thread. >=20 > > > > 2. Next, the Verifier uses the RPC structures to get Evidence in a > > > > challenge-response fashion. In the challenge input, the Verifier ca= n > > > > use > > > the > > > > leaf "key-identifier" to ask Evidence of one specific TPM based on > > > > this TPM's unique credential, or it can use the leaf-list "tpm-name= " > > > > to ask Evidence of one or more TPMs based on these TPMs' names. > > > > > > The absence of either should result in the acquisition of PCR > > > information for all physical TPMs. This is a benefit from the > > > previous version where we explicitly had a 'tpm-name' of 'ALL'. That > > > is the purpose of the YANG model > > > text: > > > > > > "Name of one or more unique TPMs on a device. If this > object > > > exists, > > > a selection should pull only the objects related to these > TPM(s). > > > If > > > it does not exist, all qualifying TPMs that are 'hardware-bas= ed' > > > equals true on the device are selected."; > > > > Yes, agreed. > > > > > > 3. In the response output, the Attester returns the Evidence. If th= e > > > > input contains only one TPM, then the output can match that TPM > > > > anyway. But > > > if > > > > the > > > > input contains several "tpm-name", then the output is a set of > > > > Evidence of these TPMs, in this situation, the Verifier needs to us= e > > > > the "certificate-name" and/or "node-id" in each Evidence to identif= y > > > > which > > > TPM > > > > produced it. > > > > > > This is correct. > > > > > > > If my understanding is right, then the YANG modules after changed > > > > have some assumptions which aren't explicitly said, I conclude them > > > > below: > > > > 1. The Verifier must retrieve the datastore first before initiate > > > > the challenge request. > > > > > > With the current version, this is not the case. (As there is not a > > > required key of 'tpm-name' mandatory in the RPC.) > > > > > > What needs to happen is that there is a secure method of provisioning > > > on the certificate on the Verifier. And if you receive an unknown > > > certificate, you > > > have a choice of how to then acquire that information. The current > YANG > > > model points to ' ietf-keystore.yang' as a potential place to get tha= t > > > information. > > > > If so, what's the purpose of the certificates in rats-support-structure= s? > I assume > > to use this module to get the certificates. >=20 > You need to store much common info about certificate (in the keystore > draft), but you also need to know which TPM has what certificates (and th= is > given to you by the ). Additionally different certifica= tes > might have different purposes with a TPM (here you populate > ). >=20 > > > > 2. Every TPM should have a unique name, at least be unique in an > > > Attester. > > > > > > Yes. And this could be a random system generated string. It cannot > > > be a TPM path, as this could change on a reboot. > > > > > > > 3. Every certificate should have a unique name. It should be unique > > > > in an Attester if the certificate-name can identify the TPM, or > > > > should be unique in a compute node if the certificate-name and the > > > > node-id are used > > > together > > > > to identify the TPM. > > > > > > The certificate-name should be unique within a Attester. I will add > > > that as a constraint to the YANG model via XPATH. Good catch, I had > > > not explicitly said this is required. > > > > I'd like to say that if you using the tpm-name as the key for the outpu= t, > there is > > no need to require the certificate-name to be unique within a Attester. >=20 > See other thread. >=20 > > > > 4. For the input, if you choose to use the "key-identifier", then > > > > the list-leaf "tpm-name" must have only one value. > > > > My suggestion would be to have a section to describe the workflow o= r > > > > the example of how to use this YANG module. Also, explicitly > > > > pointing out the assumptions would be much better. > > > > > > I agree. In fact, I would argue that you should not allow both > > > 'key-identifier' and 'tpm-name*' in the same query. What happen if > they > > > conflict? If you agree, we could make an explicitly choice allowing > either > > > one or the other. > > > > Agree, a choice is much better. >=20 > This is not a problem, the question is then do we make this a case > statement, or use XPATH. Either one works. Do you want to propose the > YANG model change? >=20 > > > > Generally, I agree with the idea that don't use nested keys to > > > > identify > > > the > > > > TPM (and its position) in RPCs. This has a significant benefit of > > > > scalability. Because if in the future more dimensions are needed to > > > identify > > > > the TPM (and its position), the RPC structures don't need to be > > > > changed, only modifying the datastore structure is enough. But the > > > > current RPCs > > > also > > > > have a disadvantage that the key is very obscure and implicit, > > > > > > I assert this is a very large benefit. You do not have to identify > > > the key at all in the query. > > > > > > > for example, > > > > you need to use "certificate-name" and "node-id" as the key in the > > > output. > > > I > > > > suggest that we can just use the "tpm-name" as the key of output. > > > > > > 'tpm-name' is an internal structure to the Attester, and need not be > > > used by the Verifier where there is only one TPM. This is a signific= ant > benefit > > of > > > getting rid of the key. And for implementations with only one TPM, > life is > > > much simpler. > > > > As I explained in another email, I feel like that adding the 'tpm-name'= in > the > > output is useful, even if it is not used as the key. >=20 > Let's work this on the other thread. >=20 > > > > Two > > > > advantages would be: easier for readers to understand, the Verifier > > > doesn't > > > > need to search the database to find out the matched TPM. > > > > > > There is another simplifying advantage of the current structure. Whe= n > > > a certificate changes, you then can simply fetch the corresponding tp= m > > > info from the datastore. Certificate management/upgrades should > > > become easier. > > > > But in current design, you need to fetch all TPMs info of an Attester. = If > the > > output contains the tpm-name, you can only fetch this specific TPM info= . >=20 > This is not correct. You can fetch based on the . >=20 > > > > Other comments: > > > > 1. Some elements in the "rats-support-structures" are changed from > > > > read- only to read-write, e.g., the "supported-algos" and > > > > "certificates" of TPM. Why these elements can be configured now? > > > > > > On "supported-algos": an operator might want to limit the universe o= f > > > supported-algos from the full set which might be available from a > vendor. > > > > > > On "certificates": YANG has some structural issues with how config > > > data can be exposed. I believe that an Attesting device should allow > > > new certificates to be provisioned in a place like ' > > > ietf-keystore.yang'. > > > However I am not sure if YANG allows non-config leafrefs to point to > > > configuration data. I get an error if I try to make these objects > > > system generated. Any suggestions on how automatically update > things > > > here? I do know there are implications to NMDA (RFC-8342). > > > > > > > 2. The outputs of RPC "tpm12-challenge-response-attestation" and > > > > "tpm20-challenge-response-attestation" contains the "node-id" and > > > > "node-physical-index". Can these two elements be omitted in the > > > output? > > > > Because they can be get through the datastore. > > > > > > I believe these can be removed. Perhaps we can ask everyone during > > > the IETF session if they have any objections? > > > > I also agree to remove these elements. >=20 > Thanks. I have added the other authors to see if they have any issue wit= h > this? >=20 > Eric >=20 >=20 > > > > 3. The output of RPC "log-retrieval" doesn't contain the "node-id" > > > > or "node-physical-index", and this is different with the outputs of > > > > other two RPCs. I wonder whether here is right and other two RPCs > > > > need to delete > > > the > > > > two elements. > > > > > > Agree. The answer to the above question should be true here as well= . > > > > > > Thanks! > > > Eric > > > > > > > Regards & Thanks! > > > > Wei Pan From nobody Tue Aug 4 09:14:04 2020 Return-Path: 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 877FB3A0ADC for ; Tue, 4 Aug 2020 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=ms6if8y+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=W0Q2sn5a 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 XIQJ2wiyN-jz for ; Tue, 4 Aug 2020 09:14:00 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F623A0A12 for ; Tue, 4 Aug 2020 09:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27527; q=dns/txt; s=iport; t=1596557640; x=1597767240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TTT/oiJgiWxETGh/iwYT17fZ47HlzZ/gS/hJ8B7avtw=; b=ms6if8y+/wAHAP8EUCllWWwgDLlAB5xe9dLH2SBz0ZIO+5LHMjEUxzya ETOv6lNF9c7yV1yt9RXjlHE29VDBqSyNu/QFgeDoORzhWcFESg79jzNUV 1K3wTwUsBz/O7U+ixPVj4wUXG3agXAzHp77pOOfmDuIvjiMKBYd2bSHrz A=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3Ajc2Nnh+qq6MxC/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZAQCtiClf/5hdJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoEjL1EHbystLywKh3EDjVGHWpEJglMDVQQHAQE?= =?us-ascii?q?BCQMBAS0CBAEBhEwCgiQCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBBI?= =?us-ascii?q?bEwEBNwEPAgEIEQQBASEHBwIwFAkIAQEEDgUIBhSDBYF+TQMfDwGndQKBOYh?= =?us-ascii?q?hdIE0gwEBAQWFHRiCBwcJgTiBU4Edih4agUE/gRFDgk0+hD80gxOCLZl8gRm?= =?us-ascii?q?bAgqCYoQ4gluTGYJ8iU6TMbFLAgQCBAUCDgEBBYFqI4FXcBU7gmlQFwINjh8?= =?us-ascii?q?MF4NOilZ0NwIGCAEBAwl8jkcBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,434,1589241600"; d="p7s'?scan'208,217";a="522133183" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Aug 2020 16:13:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 074GDxAo024526 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2020 16:13:59 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 11:13:58 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 11:13:58 -0500 Received: from NAM11-DM6-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; Tue, 4 Aug 2020 12:13:58 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/R93ngUQvJW6sxOA50vNdAPuvS1LBGqSsosYJcvnY+ve5f50D37mSO+TAEwFpDve8t1cf+a97wr5joqm6rbz1GC4q5LadvDcxikaP5k7xGfAWJObosNAtdYm3Ual6iN8zSB9i+UBmQtfReIPkJr+X4Xdh/j436RJ/1yDpQ/GiIgL3y/4GCz58MFvMKze4pxEKZB+40IIOyc3VB+oMaM9zoOUWTlINjMRzSMPQXApEwxFDb6Xu6mWXWVpi5C0qPEBCbgHCFo/QlSEcEO1e3SnTykJ0OellJbRgPS61eGXSSy8QGp6oqrT10JBU/WxJG3jYhyZdTmMq3w92THf3IZww== 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=XhfpeSn7nTgzosUetI6UNCXOOy6AIGjpQu+O5dAfRHY=; b=ns+t5jqXWJHro/DCQVaND9j3/otfBaxhLgFdIVCmpiNq/uYxTQ9r1przyLI1QMxT37NSdo4lXAF1K/2mEZySmMC+orkn3FPYU7JU42g9+lWuS07MGK42v7KJohsQ+Ahj3iWaDhdfFm6dJXk9BqClk6IiQkm4pjbBNYJmfIUlQ6zPWJkVfbVXDZg2j2Rxem1uCwxqXuaRQipUN2XwI3DhuzesXOjgnrbRJ0YiiKYYsGu7VqJxwn8uT6uyfR2/XYOzJnpECy1rNJrIOa+bV9mEWIJOZaTp6SN3me+813JEgGAWvKd3YhVIcG/3aj3z2cxnA0uDgO+1F2VHGjVEpGukPQ== 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=XhfpeSn7nTgzosUetI6UNCXOOy6AIGjpQu+O5dAfRHY=; b=W0Q2sn5aTS4VoiCtgSTRdbtaRe+rPpwyEz6uqTfymU4MkzD9Jl0pJ+xuHTvxT867bHEWeK+v4uvqNUIzg4jm6H8gOlfHgXMxs/0s6omgRgIfzkJVNBU4iDF+6011pfak7CmVdtq4I0aagXb4kZeSElKAsEhahsJk01SZ85T8scE= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4175.namprd11.prod.outlook.com (2603:10b6:208:153::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Tue, 4 Aug 2020 16:13:57 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3239.022; Tue, 4 Aug 2020 16:13:57 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" CC: "rats@ietf.org" Thread-Topic: Charra: certificate-name vs TPM-name Thread-Index: AdZk7AdVjrhIJhH+SNGp+N2fr3/WmwBS28JgANYNhuAAG/cWAAAaz+Iw Date: Tue, 4 Aug 2020 16:13:56 +0000 Message-ID: References: <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5c9b588-9cac-4681-68a1-08d8389163e2 x-ms-traffictypediagnostic: MN2PR11MB4175: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2hmxE7B+1yJWHWim7dQ3/dHIloos5T5AYE8p2MYFOZBzTeRIBvvOT7hVHSHPCGEWaRoAGtCx2WfL709t3sHyRAmrMardbZnydmg+28MZ9VyaQoCRO3uy803pdTxYLuVrDYGILFNN8dLSmQ5jkOo47utljVLefdOmlPdBHbKas0Vwh4tUJCjBxtjT307x3zuMuyW4ZoQ68KBReYPcnkBDOYKA8cfKUN6+CIAvZ2Rc8KK2rrWslNc4Qhiqh3zlzU7OXh9wJhfkrcGyeUozLcRZtLOB2XzjAvG0lQe8VIE9pwOiDCgb6ER4CYX/99iFHtAwP+6uOPuebIzvCzrJScz1wQ== 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; SFTY:; SFS:(4636009)(366004)(346002)(396003)(376002)(39860400002)(136003)(52536014)(9686003)(55016002)(66446008)(99936003)(7696005)(76116006)(26005)(186003)(33656002)(6506007)(5660300002)(66946007)(64756008)(66616009)(66476007)(66556008)(53546011)(8936002)(66574015)(71200400001)(316002)(83380400001)(478600001)(6916009)(4326008)(2906002)(8676002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DXw1Fx2ErQ7IpizKkjA7fCXztcdTV27DlDlPC5mpWfA/HJqC3WcXs2qNViy1P199hTwLoQVS3og2Ew0U/zWpFltYqCf5D+FnAzshE984yMSqaxeLoAuyTc3A03y91h12wQOIWroTNITVCbYu6KAANJYk/B5VqWo4ZR4Sqdy73QZ0+Q+cG/6dh3B8aRsYR1hHEAmgvlc2kmgGI8BkWVW7m+d66II6/TkF7P7CV2k0QP86sSfV/TFnNXeaf4VRJyvqoDyqwGgGmrB86uuSIOLQ4v9ga80dRVfzJV9XlGz0B3ibcqv8Ib3RuBfebqsLZj1E0A2WlO1MpHnOAuHu3g4AUX/p7hgNHiWXqRiBaLc98Wy82njXxKqkwO3jhj8hqPQcuKYOVBYtioWfQtA9k8iVEHmhpkMmrtOAjJS5KLo5p9EkagiKZndLt2S+QjPoJ9Cnl7yr6MuTzX5G9Gp7k4dlspgAI57XWAgfimsi+KK447PQYoz4MVNcuyYtLQi0vB3vH78JAh5WgWjoR7yF7pEtoOsZdBeE5m5iyLBsFUVdfzCEUUcL4aYMspErVvvSehBmS4nx5rO5P4anXhvunxjtvyLt2Z+T++qtPn8u/cr6kaH9Svf485L8R/o99RXAFTscrpLYcT+Ldg839vBPVeUjkQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0090_01D66A58.B2EDBF00" 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: b5c9b588-9cac-4681-68a1-08d8389163e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 16:13:56.7492 (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: 2YCOuziI4f1ex+ZSyAbpIh+AmqT2GYKEOwrUvSQQUGdrj8mcDzf09eswy7h8uBmS X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4175 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Rats] Charra: certificate-name vs TPM-name X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 16:14:03 -0000 ------=_NextPart_000_0090_01D66A58.B2EDBF00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0091_01D66A58.B2EDBF00" ------=_NextPart_001_0091_01D66A58.B2EDBF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, Below I cut the thread to the last bit of difference. I think we agree on everything else. From: Panwei (William), August 4, 2020 1:18 AM Hi Eric, Thanks for your reply. After a twice thinking, I realize it's true that the difference between our proposals is that whether to contain in the response and whether to make unique across different TPMs. Some thoughts please see inline. Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, August 4, 2020 12:42 AM To: Panwei (William) > Cc: rats@ietf.org Subject: Re: [Rats] Charra: certificate-name vs TPM-name Hi Wei Pan, I fully agree that multiple line cards per switch/router is necessary. The current model does support this, as the RPC output is a list. Lists are identified by the "[]" in the tree diagram. So for any current list entry, a which is unique to an individual TPM can be placed within this list. The real difference I see between our proposals is that you want explicitly listed in the RPC response, [Wei] Indeed. and I thought a unique which doesn't require users of single TPM devices to understand is preferable. I.e., some complexity is hidden within the router so that a class of developers need not care. [Wei] But I think some new complexities for multi-TPM devices have also emerged. The first complexity is that the certificate name should be unique across TPMs. Imagine this case: there are two TPMs and each one has a certificate, e.g., tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA changes its certificate, it releases the name 'cert1' and names the new certificate 'cert3'. Right after that tpmB changes its certificate, and names the new certificate 'cert1' because 'cert1' is unique right now. But you can see a potential problem here, if the Verifier receives the attestation response before receiving the updates of the certificates, it will wrongly match the record according to the certificate-name, as it doesn't know the owner of 'cert1' is changed. Although the Verifier will fail to verify the signature, but it doesn't know what's the real problem. So, the second complexity is that the certificate name should not be reused by other TPMs. There may be other complexities that I didn't come up with. If the charra model's were populated with something like "cert1", I would absolutely agree with you. But that is not what I am proposing. Stepping back, perhaps the conventions used for YANG object naming are causing some mis-communications here. In the example below, use: * "ks" as the prefix for ietf-keystore.yang * "tpm" as the prefix for charra points to an instance of "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ks:certificates/ks:certif icate/ks:name" It is over in ietf-keystore.yang, you would have that be something human readable like "cert1". But we likely wouldn't want two human readable names for the same certificate in different yang models. Looking back at the path from ietf-keystore.yang, you can see that there is no TPM differentiator in that YANG datastore for asymmetric keys. In other words the primary repository for asymmetric-key information does not use anything like as part of its key. This is why I believe that is best system generated, and need not be human readable. So what I would do in implementation for is to populate it with the value of "/ks:asymmetric-key/ks:name" appended with the value of "/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name". This long a string isn't necessary, but it works and requires no additional human configuration. Other protections could be put into place as well, such as an XPATH constraint on so that it is never the same as "../../tpm:tpm-name/tpm:certificate-name". Again, I wouldn't be overly upset if the WG did have a preference for the nested key option of and . It is less efficient, and exposes extra complexity to the receiver (nested identifiers and the need for single TPM devices to expose a TPM-name). But it has the benefit of being simple to understand. /Eric2 ------=_NextPart_001_0091_01D66A58.B2EDBF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wei = Pan,

 

Below I cut the thread = to the last bit of difference.  I think we agree on everything = else.

 

From: Panwei (William), August 4, = 2020 1:18 AM

Hi Eric,

 

Thanks for your reply. After a twice thinking, I realize = it’s true that the difference between our proposals is that = whether to contain <tpm-name> in the response and whether to make = <certificate-name> unique across different = TPMs.

Some thoughts please see inline.

 

Regards & Thanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] = On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, = 2020 12:42 AM
To: Panwei (William) <william.panwei@huawei.com&g= t;
Cc: rats@ietf.org
Subject: Re: = [Rats] Charra: certificate-name vs = TPM-name

 

Hi Wei = Pan,

 

I fully agree that = multiple line cards per switch/router is necessary. The current model = does support this, as the RPC output is a list.  Lists are = identified by the "[]" in the tree = diagram.   So for any current list entry, a = <certificate-name> which is unique to an individual TPM can be = placed within this list.

 

The real difference I = see between our proposals is that you want <tpm-name> explicitly = listed in the RPC response,

 

[Wei] Indeed.

 

and I thought a = unique <certificate-name> which doesn't require users of single = TPM devices to understand <tpm-name> is preferable.  I.e., = some complexity is hidden within the router so that a class of = developers need not care.

 

[Wei] But I think some new complexities for multi-TPM devices = have also emerged.

The first complexity is that the certificate name should be = unique across TPMs.

Imagine this case: there are two TPMs and each one has a = certificate, e.g., tpmA’s certificate is cert1 and tpmB’s = certificate is cert2. When tpmA changes its certificate, it releases the = name ‘cert1’ and names the new certificate = ‘cert3’. Right after that tpmB changes its certificate, and = names the new certificate ‘cert1’ because = ‘cert1’ is unique right now. But you can see a potential = problem here, if the Verifier receives the attestation response before = receiving the updates of the certificates, it will wrongly match the = record according to the certificate-name, as it doesn’t know the = owner of ‘cert1’ is changed. Although the Verifier will fail = to verify the signature, but it doesn’t know what’s the real = problem.

So, the second complexity is that the certificate name should = not be reused by other TPMs.

There may be other complexities that I didn’t come up = with.

 

<eric2> If the = charra model's <certificate-name> were populated with something = like "cert1", I would absolutely agree with you.  =  But that is not what I am proposing.  =

 

Stepping back, = perhaps the conventions used for YANG object naming are causing some = mis-communications here. 

 

In the example below, = use:

  • "ks" as the prefix for = ietf-keystore.yang
  • "tpm" as the prefix for = charra

 

<tpm:certificate-re=
f> points to an instance of 

 "/ks:keystore/ks:asym= metric-keys/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name"= ;

 

It is over in = ietf-keystore.yang, you would have that <ks:name> be something = human readable like "cert1".  But we likely wouldn't want = two human readable names for the same certificate in different yang = models.

 

Looking back at the = path from ietf-keystore.yang, you can see that there is no TPM = differentiator in that YANG datastore for asymmetric keys.  In = other words the primary repository for asymmetric-key information does = not use anything like <tpm:tpm-name> as part of its key. =  This is why I believe that <tpm:certificate-name> is best = system generated, and need not be human readable.  So what I would = do in implementation for <tpm:certificate-name> is to populate it = with the value of "/ks:asymmetric-key/ks:name&= quot; appended with the = value of "/ks:asymmetric-key/ks:certi= ficates/ks:certificate/ks:name".  This long a = string isn't necessary, but it works and requires no additional human = configuration.  Other protections could be put into place as well, = such as an XPATH constraint on <tpm:certificate-name> so that it = is never the same as "../../tpm:tpm-name/t= pm:certificate-name".

 

Again, I wouldn't be = overly upset if the WG did have a preference for the nested key option = of <tpm:tpm-name> and <tpm:certificate-name>.  It is = less efficient, and exposes extra complexity to the receiver (nested = identifiers and the need for single TPM devices to expose a = TPM-name).  But it has the benefit of being simple to = understand.

 

/Eric2

------=_NextPart_001_0091_01D66A58.B2EDBF00-- ------=_NextPart_000_0090_01D66A58.B2EDBF00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODA0MTYxMzQ0WjAjBgkqhkiG 9w0BCQQxFgQUJu3IsYi63iubo/YYQoN/zACQdbwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAOUNPY4IFD1xUggsjjQoE0eRvTcCaC8hdxGk/OG9vIxiwsD7wtDlljhCOAE2JERv0Q R6SmQaeuYVH763qwLG/sZ+lvRxdI1dxrwofw+CQrjE9SHniaWYq33Ee5J0RTsyeVd+n35CJyF3xv 1XgdoqiEId7CWi9SG351ZYcYch3/VrOlKeKP8MVCKFaHspj30DLEUBJtu/hfBqCp9vU0tdA4H6Lu QOINv7PTJy8tOqba3NixcjYSyd8N4sXRlYPpQdwwZWbDqQ3oWe/I6I670d65Bt4oktj3o+NAWYlU LcmIB0pIk4onelvNhBZgUypo2ROak9Tm8IalXwenkaBtshcQAAAAAAAA ------=_NextPart_000_0090_01D66A58.B2EDBF00-- From nobody Tue Aug 4 10:29:07 2020 Return-Path: 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 D33043A0DBC; Tue, 4 Aug 2020 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=VZ2zHghj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=LSA0gf3G 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 V6ih20QDg9Pt; Tue, 4 Aug 2020 10:29:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A298B3A0DB7; Tue, 4 Aug 2020 10:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33912; q=dns/txt; s=iport; t=1596562143; x=1597771743; h=from:to:cc:subject:date:message-id:mime-version; bh=Uzi/7XLvG2E8kovcHaPsNRVJZQiQU09mEiuQKJrhnSk=; b=VZ2zHghjMveloqdUA/xxLgWj+QsIKSDkgfalMHwVxqxpN5iYIZOPQyn2 c+x3KRHR6XEjySmpnMfZsGQ1d8wbdevKzEJY00GKvYqETo788c1JlDgRY oLONbBwMhFLhqNWa7Od/SG9bM6lLpcLLDCqw70ny4t8KYqY0RnaKSvwEE s=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AVnilIh30SS3qB2CwsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSBQBBmilf/4sNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBIy9RB28rLS8sCodxA5UrkQmCUwNVBAcBAQEJAwEBLQI?= =?us-ascii?q?EAQGETAKCJAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEWGxMBATAHARE?= =?us-ascii?q?BGQEDAQEhBwkwFAMGCQEEAQ0FCAYNB4MFgX5NAx8PAagWAoE5iGF0gTSDAQE?= =?us-ascii?q?BBYUhGIIHBwmBOIFTgR2KHhqBQT+BEUODC4QVKgwoAgKDD4ItmXyBGZsCCoJ?= =?us-ascii?q?ihDiCW5MZgnyJTpMxkiafJQIEAgQFAg4BAQWBaiOBV3AVO4JpUBcCDY4fDBe?= =?us-ascii?q?DTopWdDcCBggBAQMJfI0TgTQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,434,1589241600"; d="p7s'?scan'208,217";a="807503256" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Aug 2020 17:29:01 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 074HT2Hw027703 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2020 17:29:02 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 12:29:01 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 13:29:00 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 4 Aug 2020 12:29:00 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eef2QSfpF1nIbvvYgoukKZ22GPw8bpS3qCg3YJd2AVnfnu8L90nr8Ngwyq9bkfcbNoR3X1qLHbI4iPNsOJ4vhxZFIzTZceGj60mW4NK32GCWiBXblGsX7OVkgWzEZeXzt4fAt3VZD+SU4nQaVXtIwL6I9swTCdN0pPHCxrq4Bq1TNcXNHZdqu3bvwEqX/jc1jo3qPL8UIIbD3Y7if5zwlllysLMMsCudBxal1ZDRGh2jqDgehu+554dUSaA3h3R4JfJAexVhw7OgOO3TojYBmMCGsqga1WYx3s+dpDyOaMcmaRtPB5wsima8tpRH0lrCifYaKHaD2oYN8pLlpfcMbw== 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=Vry/qExkQJ6sM6Suz+gjREdUpUGPZsxmkaLE+RZAjCo=; b=FoLPUh5pEOUFiYLkw9RkbqHDp8o+CD9YRd7rHXFMps+RipoW9p+MeUqZ32OIwEEmmxZNCxbABOfTl0ep3i9V5bmHIsXIJwvKET4ii9wYzrDRJdNhLgB6OKU4hi+DISdjiyHwqXPPQ8RaneKbtSytRYtO40/VrpcNTVVbVSmrT5N1D7ETKgSrRvtCCkyfmA/98SkgifZjGCyuBqw+5dx3BpD11RKBW3OfVlDMqjKYqPaZbqWFS2MtDgws5kNZCDqFdhODbXvm22UE3FZ8XMXx7Bvdvf7prHPl7Zczr7UMWjd9rDvFBNZGZu27svj49QX7mjrypxbeLXozYURhgrlMkw== 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=Vry/qExkQJ6sM6Suz+gjREdUpUGPZsxmkaLE+RZAjCo=; b=LSA0gf3GWqSgJbobK4PnskF4RvOxdXa7uKUIb1jIcYv9LKF1fHLTetKRvmhHo1wpawdv3zMYbaG4NL3MXhWL2L+Bq8gu87ARSoTcJjn7il84u3UA7esHENKe+EPnoiX8mt3+WpKXkIVqJD7APqupDaVuPPYqaL8BxCK3Zwn3YqI= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4480.namprd11.prod.outlook.com (2603:10b6:208:191::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Tue, 4 Aug 2020 17:28:59 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3239.022; Tue, 4 Aug 2020 17:28:59 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" , "draft-ietf-rats-yang-tpm-charra@ietf.org" CC: "rats@ietf.org" Thread-Topic: Multi-line card? (was RE: Charra: certificate-name vs TPM-name) Thread-Index: AdZqhEE3A+htPcigTJ6yGgEuz8Go2g== Date: Tue, 4 Aug 2020 17:28:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e8d4b79-af33-4410-f6fc-08d8389bdf61 x-ms-traffictypediagnostic: MN2PR11MB4480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B1sojDAAO/RPzNg0qm75gRwMJvF9FjqnIKeUyAP9caz4MJhMsVBjm4kRA5FYhZ/O0dg/+s41e7ZQzEsahYOWtGM4gsf8OaPbgBpCOL8xPdTyEUsEA6Tcvoov0HFUtiwRcSIPIvFRZOmj45MbwvLf2K57s5s+RgyJZIO2snxKWn/V5H/vMx5Dqb30Z6N9rfYWqPV1c4rUauw2LQRUrD4Y0yNqI7Dg/xDp7iNimF7Ccf4JjNJy8qrFl4WFEutbM2H+pByfmH0o2L3wfIXSKNJ9H9Bv1+9fHXTV+WQyE9eB5P7V22VNL1iU3P/LAFKTQi/rTkxPDR1geLPeHOTyjg4e7A== 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; SFTY:; SFS:(4636009)(376002)(366004)(346002)(136003)(396003)(39860400002)(66446008)(478600001)(64756008)(8676002)(52536014)(33656002)(4326008)(66946007)(76116006)(71200400001)(26005)(83380400001)(99936003)(7696005)(9686003)(2906002)(8936002)(66616009)(53546011)(66476007)(316002)(66556008)(110136005)(6506007)(86362001)(186003)(66574015)(55016002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9MruUUCmtLGaxCal8pwWFEMoon4dtCLPchI/8kNs7kO0SfJYUd4CsWlJrgEHpEL1dzY4KJrs1VXWTYeBIXNt0vMo1v+WT3NfwbOceX4wzQ1QCuslmbnByWp0fgwZUew4buPl1i0EmPUqIeqt5faemqGYa3ndBMhoqCr/nxQDBz5ooXfafnGSMjS31nVW+qWjgji6BnWPoG5DY9rcVV7uYzmaOyB+BFkyHvGX+fcB9oOVGgpO2xmdMWiBG756WhG29/AkCcbdxXN6gMwEJEyrWS3QzgfA1NuNnXvFtuheCyM+2VsUD6LJgw6G9oi7dqsEYLfODsQ6Z/mj6HCIG4pMr4w41Ixd9A/yy49QJAuuIBzigP71RkU5CaG7Wmn1khBC6fOY4zhMEFT+EmnVRTMHMuXcM3zZ8Fgz4W4z5FoGOoArY+PufDpYQ5JlXv9h6+Texm8DSmts+in1iYtk9barOJFrTg79NtjnkQD6hLrobQXNsquWxj678jgD9ystd8hFVOJNZGrsiqwN+EDyRoLACpuM44f3EZXQf8PAooeblkweBzVJsbzUFzw/O5d7Gu/nZxLE1V9xx0eZH+mZFWnMlwTp5TI3ukwFtyyYsS8bG7erYKsravodhOuw5HhQulFZ9Muvnow8Rhb+EKXRRBqf9g== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FF_01D66A62.BC2A33F0" 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: 1e8d4b79-af33-4410-f6fc-08d8389bdf61 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 17:28:58.9851 (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: Y/I3WuzStN7SiCRgQQro/eMBmR/ArWwg6s8/at4a4YyUGOvq6Ea6jtYtrDO/6b35 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4480 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [Rats] Multi-line card? (was RE: Charra: certificate-name vs TPM-name) X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 17:29:06 -0000 ------=_NextPart_000_00FF_01D66A62.BC2A33F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0100_01D66A62.BC2A33F0" ------=_NextPart_001_0100_01D66A62.BC2A33F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, I didn't want to couple the general Multi-line card topic you have been advocating in the architecture draft with the charra RPC response structures. But they are related. One of the things not currently in the scope of Charra are the roles and relationships between redundant supervisor cards and line cards. As you have pointed out, each of these cards might have their own TPM. As was thinking about the issue below, I considered adding a constraint to the RPC output list which would limit including in the RPC to only those times when there were two or more instantiated in the configuration datastore nodes. (This should be fine as we agree need not be a key object.) Opening up the discussion into such constraints needs to be done carefully as they have the potential to limit future solutions to how to structure roles/relationships between TPMs. I don't think that this is a topic ready to bring into charra as we are trying to get it to WGLC. But at some point we will need draft which defines how to securely advertise/discover the relationships between multiple line cards and supervisors. I.e., if a Verifier has a certificate for a supervisor, can information stored in that supervisor's TPM can safely expose the relationships between TPMs in that device? How do you refresh this view when the line cards in a device change. This is a worthwhile problem to solve. Eric Hi Wei Pan, Below I cut the thread to the last bit of difference. I think we agree on everything else. From: Panwei (William), August 4, 2020 1:18 AM Hi Eric, Thanks for your reply. After a twice thinking, I realize it's true that the difference between our proposals is that whether to contain in the response and whether to make unique across different TPMs. Some thoughts please see inline. Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, August 4, 2020 12:42 AM To: Panwei (William) > Cc: rats@ietf.org Subject: Re: [Rats] Charra: certificate-name vs TPM-name Hi Wei Pan, I fully agree that multiple line cards per switch/router is necessary. The current model does support this, as the RPC output is a list. Lists are identified by the "[]" in the tree diagram. So for any current list entry, a which is unique to an individual TPM can be placed within this list. The real difference I see between our proposals is that you want explicitly listed in the RPC response, [Wei] Indeed. and I thought a unique which doesn't require users of single TPM devices to understand is preferable. I.e., some complexity is hidden within the router so that a class of developers need not care. [Wei] But I think some new complexities for multi-TPM devices have also emerged. The first complexity is that the certificate name should be unique across TPMs. Imagine this case: there are two TPMs and each one has a certificate, e.g., tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA changes its certificate, it releases the name 'cert1' and names the new certificate 'cert3'. Right after that tpmB changes its certificate, and names the new certificate 'cert1' because 'cert1' is unique right now. But you can see a potential problem here, if the Verifier receives the attestation response before receiving the updates of the certificates, it will wrongly match the record according to the certificate-name, as it doesn't know the owner of 'cert1' is changed. Although the Verifier will fail to verify the signature, but it doesn't know what's the real problem. So, the second complexity is that the certificate name should not be reused by other TPMs. There may be other complexities that I didn't come up with. If the charra model's were populated with something like "cert1", I would absolutely agree with you. But that is not what I am proposing. Stepping back, perhaps the conventions used for YANG object naming are causing some mis-communications here. In the example below, use: * "ks" as the prefix for ietf-keystore.yang * "tpm" as the prefix for charra points to an instance of "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ks:certificates/ks:certif icate/ks:name" It is over in ietf-keystore.yang, you would have that be something human readable like "cert1". But we likely wouldn't want two human readable names for the same certificate in different yang models. Looking back at the path from ietf-keystore.yang, you can see that there is no TPM differentiator in that YANG datastore for asymmetric keys. In other words the primary repository for asymmetric-key information does not use anything like as part of its key. This is why I believe that is best system generated, and need not be human readable. So what I would do in implementation for is to populate it with the value of "/ks:asymmetric-key/ks:name" appended with the value of "/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name". This long a string isn't necessary, but it works and requires no additional human configuration. Other protections could be put into place as well, such as an XPATH constraint on so that it is never the same as "../../tpm:tpm-name/tpm:certificate-name". Again, I wouldn't be overly upset if the WG did have a preference for the nested key option of and . It is less efficient, and exposes extra complexity to the receiver (nested identifiers and the need for single TPM devices to expose a TPM-name). But it has the benefit of being simple to understand. How about add a XPATH constraint on within the RPC to allow the inclusion of this object when /Eric2 ------=_NextPart_001_0100_01D66A62.BC2A33F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wei = Pan,

 

I didn't want to couple = the general Multi-line card topic you have been advocating in the = architecture draft with the charra RPC response structures.  But = they are related.

 

One of the things not = currently in the scope of Charra are the roles and relationships between = redundant supervisor cards and line cards.  As you have pointed = out, each of these cards might have their own TPM.  As was thinking = about the issue below, I considered adding a constraint to the RPC = output list which would limit including <tpm-name> in the RPC to = only those times when there were two or more <tpm-name> = instantiated in the configuration datastore nodes.  (This should be = fine as we agree <tpm-name> need not be a key = object.)

 

Opening up the discussion = into such constraints needs to be done carefully as they have the = potential to limit future solutions to how to structure = roles/relationships between TPMs.  I don't think that this is a = topic ready to bring into charra as we are trying to get it to WGLC. =  But at some point we will need draft which defines how  to = securely advertise/discover the relationships between multiple line = cards and supervisors.  I.e., if a Verifier has a certificate for a = supervisor, can information stored in that supervisor's TPM can safely = expose the relationships between TPMs in that device?  How do you = refresh this view when the line cards in a device change.  This is = a worthwhile problem to solve.

 

Eric

 

Hi Wei = Pan,

 

Below I cut the thread = to the last bit of difference.  I think we agree on everything = else.

 

From: = Panwei (William), August 4, 2020 1:18 AM

Hi Eric,

 

Thanks for your reply. After a twice thinking, I realize = it’s true that the difference between our proposals is that = whether to contain <tpm-name> in the response and whether to make = <certificate-name> unique across different = TPMs.

Some thoughts please see inline.

 

Regards & Thanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] = On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, = 2020 12:42 AM
To: Panwei (William) <william.panwei@huawei.com&g= t;
Cc: rats@ietf.org
Subject: Re: = [Rats] Charra: certificate-name vs = TPM-name

 

Hi Wei = Pan,

 

I fully agree that = multiple line cards per switch/router is necessary. The current model = does support this, as the RPC output is a list.  Lists are = identified by the "[]" in the tree = diagram.   So for any current list entry, a = <certificate-name> which is unique to an individual TPM can be = placed within this list.

 

The real difference I = see between our proposals is that you want <tpm-name> explicitly = listed in the RPC response,

 

[Wei] Indeed.

 

and I thought a = unique <certificate-name> which doesn't require users of single = TPM devices to understand <tpm-name> is preferable.  I.e., = some complexity is hidden within the router so that a class of = developers need not care.

 

[Wei] But I think some new complexities for multi-TPM devices = have also emerged.

The first complexity is that the certificate name should be = unique across TPMs.

Imagine this case: there are two TPMs and each one has a = certificate, e.g., tpmA’s certificate is cert1 and tpmB’s = certificate is cert2. When tpmA changes its certificate, it releases the = name ‘cert1’ and names the new certificate = ‘cert3’. Right after that tpmB changes its certificate, and = names the new certificate ‘cert1’ because = ‘cert1’ is unique right now. But you can see a potential = problem here, if the Verifier receives the attestation response before = receiving the updates of the certificates, it will wrongly match the = record according to the certificate-name, as it doesn’t know the = owner of ‘cert1’ is changed. Although the Verifier will fail = to verify the signature, but it doesn’t know what’s the real = problem.

So, the second complexity is that the certificate name should = not be reused by other TPMs.

There may be other complexities that I didn’t come up = with.

 

<eric2> If the = charra model's <certificate-name> were populated with something = like "cert1", I would absolutely agree with you.  =  But that is not what I am proposing.  =

 

Stepping back, = perhaps the conventions used for YANG object naming are causing some = mis-communications here. 

 

In the example below, = use:

  • "ks" as the prefix for = ietf-keystore.yang
  • "tpm" as the prefix for = charra

 

<tpm:certificate-re=
f> points to an instance of 

 "/ks:keystore/ks:asym= metric-keys/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name"= ;

 

It is over in = ietf-keystore.yang, you would have that <ks:name> be something = human readable like "cert1".  But we likely wouldn't want = two human readable names for the same certificate in different yang = models.

 

Looking back at the = path from ietf-keystore.yang, you can see that there is no TPM = differentiator in that YANG datastore for asymmetric keys.  In = other words the primary repository for asymmetric-key information does = not use anything like <tpm:tpm-name> as part of its key. =  This is why I believe that <tpm:certificate-name> is best = system generated, and need not be human readable.  So what I would = do in implementation for <tpm:certificate-name> is to populate it = with the value of "/ks:asymmetric-key/ks:name&= quot; appended with the = value of "/ks:asymmetric-key/ks:certi= ficates/ks:certificate/ks:name".  This long a = string isn't necessary, but it works and requires no additional human = configuration.  Other protections could be put into place as well, = such as an XPATH constraint on <tpm:certificate-name> so that it = is never the same as "../../tpm:tpm-name/t= pm:certificate-name".

 

Again, I wouldn't be = overly upset if the WG did have a preference for the nested key option = of <tpm:tpm-name> and <tpm:certificate-name>.  It is = less efficient, and exposes extra complexity to the receiver (nested = identifiers and the need for single TPM devices to expose a = TPM-name).  But it has the benefit of being simple to = understand.

 

<Eric3>   How about = add a XPATH constraint on <tpm:tpm-name> within the RPC to allow = the inclusion of this object when

 

/Eric2

------=_NextPart_001_0100_01D66A62.BC2A33F0-- ------=_NextPart_000_00FF_01D66A62.BC2A33F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODA0MTcyNTM1WjAjBgkqhkiG 9w0BCQQxFgQUexHw4/yHmAULJ6abnmk6cTH0d4kwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAi0zRXp0b7+jiRIVbzkXdiLjQwTcF3XKtRu2gfxRYHD8+qdeR9ycQzQBk/XJBJE6wb 2GXMdDk0VAQekIWwbW3uuCLvnE70L+kZ54Hoy/2KgJtRhim5vn3JbE2BvVm4U/NC69dY7f+dK474 fXKIgbilA64UsIJhvtl6j8dzL0yDDWnS4ghZys34/qPsocfOy2bjcQfA3vSTMxVCfDFAer1tlR/x nPcF3NztH3CugGaNI7ddAa5IYO/QDE4X98aPNme7BKLr/zW+83OcvuXFwFrC8Bmr2Imi0vWtnFhC k4pglILrqxLd5ErEXla57ngMytgnygM6CNa2zQyPqSkNzjZDAAAAAAAA ------=_NextPart_000_00FF_01D66A62.BC2A33F0-- From nobody Tue Aug 4 13:07:40 2020 Return-Path: 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 1FAE03A1168 for ; Tue, 4 Aug 2020 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kgpjXuRL5hmn for ; Tue, 4 Aug 2020 13:07:36 -0700 (PDT) Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5333A1158 for ; Tue, 4 Aug 2020 13:07:36 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 33DjkrhjRAJJp33DkkFXBy; Tue, 04 Aug 2020 13:07:36 -0700 X-CMAE-Analysis: v=2.3 cv=Sd6JicZu c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=4ks2tv--jYo28uDXHD0A:9 a=QEXdDO2ut3YA:10 a=NmqXcKuUeqDqKi5QXWUA:9 a=QW3tplsSD7MnHZjy:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <64EC2783-2E6A-49BE-901F-9A0B8581F9AA@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D5136D-3D81-4AD7-85AE-B0F20709A4BB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Aug 2020 13:07:35 -0700 In-Reply-To: <88357bf6-5fe0-ebd3-fd2a-4383223715f5@sit.fraunhofer.de> Cc: Michael Richardson , rats@ietf.org To: Henk Birkholz References: <4445014C-A191-4885-BE67-5502EF3E551F@intel.com> <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> <2900.1596296932@localhost> <7A5BB0EB-BA4F-4210-87C0-E9F9C6C23979@island-resort.com> <88357bf6-5fe0-ebd3-fd2a-4383223715f5@sit.fraunhofer.de> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfLgLA5hsB0cCC/SkhlsgbNy6PiLwJiWMksZBKeOBPS1SemcCNiWfEi1uGCovIKq+0EU3tV8SMNTmaPsMYkTN0KdgBoeIgdpgv+UL/Lxj4N/pyjILYZKi 7vKOnFSG+vx3FK4u3cIkeDZgATaXU693DTLjpAka4/GNBj5pMJ1G92gND9Ht2laXDpu27w9LppKQAXgJLt6lecCritzVpyzes2Xl9IFU07RrAciQKyw6gx6a HmAmYUs45J91eBFnkWyKMQ== Archived-At: Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements X-BeenThere: rats@ietf.org 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: Tue, 04 Aug 2020 20:07:38 -0000 --Apple-Mail=_A9D5136D-3D81-4AD7-85AE-B0F20709A4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 below. > On Aug 3, 2020, at 10:44 PM, Henk Birkholz = wrote: >=20 > A single vital comment in-line: >=20 > On 01.08.20 21:37, Laurence Lundblade wrote: >>> On Aug 1, 2020, at 8:48 AM, Michael Richardson = wrote: >>>=20 >>> ... >>>=20 >>> There are other use cases in which the Verifier will be configured = with all >>> the information that it needs. Is a configuration file, loaded by a = trusted >>> operator, a "secure statement"? >>> I think so, and this is why we used this wording. (B) >> My view is that the arrows in the diagram show the complete and = exhaustive inputs of relevance to attestation. >=20 > Probably adjusting the expectations of the arrows in the diagrams wrt = to "completeness" can mitigate this issue at it's root? Not sure what you=E2=80=99re thinking.=20 My main thought is that verification key material is one of the most = important things in the architecture. It should be explicitly discussed = in the architecture (like nonces) and it must be go over the arrow = between the Endorser/Manufacturer and the Verifier. LL --Apple-Mail=_A9D5136D-3D81-4AD7-85AE-B0F20709A4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
below.

On Aug 3, 2020, at 10:44 PM, Henk Birkholz = <henk.birkholz@sit.fraunhofer.de> wrote:

A single vital comment = in-line:

On 01.08.20 = 21:37, Laurence Lundblade wrote:
On= Aug 1, 2020, at 8:48 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

...

There are other use cases in = which the Verifier will be configured with all
the = information that it needs.  Is a configuration file, loaded by a = trusted
operator, a "secure statement"?
I = think so, and this is why we used this wording. (B)
My view is that the arrows in the diagram show = the complete and exhaustive inputs of relevance to attestation.

Probably adjusting the expectations of the arrows in the = diagrams wrt to "completeness" can mitigate this issue at it's = root?

Not sure what = you=E2=80=99re thinking. 

My = main thought is that verification key material is one of the most = important things in the architecture. It should be explicitly discussed = in the architecture (like nonces) and it must be go over the arrow = between the Endorser/Manufacturer and the Verifier.

LL

= --Apple-Mail=_A9D5136D-3D81-4AD7-85AE-B0F20709A4BB-- From nobody Wed Aug 5 04:47:20 2020 Return-Path: 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 8C8B23A145F for ; Wed, 5 Aug 2020 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8XNzvBFI_cfE for ; Wed, 5 Aug 2020 04:47:13 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0983A145D for ; Wed, 5 Aug 2020 04:47:13 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BM8xC2zZTzytS; Wed, 5 Aug 2020 13:47:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> Date: Wed, 5 Aug 2020 13:47:09 +0200 Cc: rats@ietf.org X-Mao-Original-Outgoing-Id: 618320829.004822-df18f8a91d321a372e68729ca238c2e5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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, 05 Aug 2020 11:47:18 -0000 On 2020-08-03, at 20:58, Laurence Lundblade = wrote: >=20 > Service Authenticity > =E2=80=A2 Focus is on the provider of the service, not the HW or = SW > =E2=80=A2 The legal entity of interest is the service provider > =E2=80=A2 There is no equivalent of claims, but if there was = they would be about the business or person operating the service > =E2=80=A2 Example: a web site > =E2=80=A2 Example: an email provider (IMAP service) >=20 Hi Laurence, if you are talking about HTTPS, there is exactly one claim: The service = is speaking for a specific name (e.g., facebook.com). All other claims = are funneled through this one very special one. Of course, the TLS = handshake could be leveraged to do more than this one claim, but that is = not what happens in HTTPS. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 5 12:42:36 2020 Return-Path: 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 8907A3A0EE4 for ; Wed, 5 Aug 2020 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8vsgmTU5cP1a for ; Wed, 5 Aug 2020 12:42:31 -0700 (PDT) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B633A0EE2 for ; Wed, 5 Aug 2020 12:42:31 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 3PJ0kBiOuOuJf3PJ0kH2nW; Wed, 05 Aug 2020 12:42:31 -0700 X-CMAE-Analysis: v=2.3 cv=MuosFFSe c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=3j4BkbkPAAAA:8 a=vZedWt0RVwdtpxjTqWIA:9 a=o-csBJJfispoz6G8:21 a=dM9xpabJHE6P-Yp2:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: Date: Wed, 5 Aug 2020 12:42:30 -0700 Cc: rats@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfJU/U831n3hX4mraTHOyuZy8vkongDk49lHCiA+6G7NoV9DtI4Sa65l8s7irICpBYpaggVPaqvIcueuqSB9zjeStFzcK/JUAOjGci4EPHZD+pqVt5daQ RdAF2E3FVoVjSEq1rfRR4zzI3FNK9Zv3j2r9moOyaUL90gJkfxYT98NHRT1e9YxJU04+AAS5mDWV2w== Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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, 05 Aug 2020 19:42:34 -0000 > On Aug 5, 2020, at 4:47 AM, Carsten Bormann wrote: >=20 > On 2020-08-03, at 20:58, Laurence Lundblade = wrote: >>=20 >> Service Authenticity >> =E2=80=A2 Focus is on the provider of the service, not the HW or = SW >> =E2=80=A2 The legal entity of interest is the service provider >> =E2=80=A2 There is no equivalent of claims, but if there was = they would be about the business or person operating the service >> =E2=80=A2 Example: a web site >> =E2=80=A2 Example: an email provider (IMAP service) >>=20 >=20 > Hi Laurence, >=20 > if you are talking about HTTPS, there is exactly one claim: The = service is speaking for a specific name (e.g., facebook.com). All other = claims are funneled through this one very special one. Of course, the = TLS handshake could be leveraged to do more than this one claim, but = that is not what happens in HTTPS. Yes, agreed. Any notion of trustworthiness, regulatory compliance and such for a = service is implied. We make heavy use of that implication and that is = mostly OK. For example, knowing that facebook.com is Facebook Inc allows = us to assume lots about the service from what we know of the company.=20 The equivalent for attestation would be just to name the manufacturer of = the HW or SW. However, we are going far beyond that with all the Claims = in the Evidence and Results. Maybe we should have Claims about services? For example, what regulatory = statutes they meet. Where are they incorporated. A reference to their = terms of service and privacy policy. That however seems like a new WG, not RATS. LL From nobody Thu Aug 6 11:38:55 2020 Return-Path: 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 96CDF3A0DD4 for ; Thu, 6 Aug 2020 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.com 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 kVwVG-51muFt for ; Thu, 6 Aug 2020 11:38:51 -0700 (PDT) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE553A0DD1 for ; Thu, 6 Aug 2020 11:38:49 -0700 (PDT) IronPort-SDR: BWKZiTOX0I4MCvES6O7K9lx1EaZifNGpN9BqwEeWf5bbxOqFvVm2mmYjqPx89XCxgsvdKCw+aS bb4TMdCSS0Iw== X-IronPort-AV: E=McAfee;i="6000,8403,9705"; a="140493682" X-IronPort-AV: E=Sophos;i="5.75,441,1589266800"; d="scan'208";a="140493682" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2020 11:38:49 -0700 IronPort-SDR: JwvSpVkdqT/mPAondwgqhlwpWAkg69Hyyip6DAPr3JaZGCi2bRV2DbtX13erBEvQigpavb3mM/ CB0+XtyBCrnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,441,1589266800"; d="scan'208";a="323521722" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga008.jf.intel.com with ESMTP; 06 Aug 2020 11:38:49 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 6 Aug 2020 11:38:48 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 6 Aug 2020 11:38:48 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.171) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 6 Aug 2020 11:38:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZNxmhFveuc5W7ilPFtBx8dGsHwYOOOJfFKfvrZ9CDOnZTAJjgIql5uDfbkh69uaa94oe9VdyGktCWiL+tnF8i8mK2clPWtT6DjO6GIpvJXAFaU0w0JzyWM0AzzgPXc+8rhHTUkoUQWjJl16/nmMhrhwODyDy8W2TwrO5gSPzlSMYeuOt9s4sv7/XHgWXABdgVhtooytkDjlNPBIepGdMmT+ZBW4d0cuYYo7GajfKfWg0St5DIudPUPQ3+auirc9KkF/P1c2ZwLNs2KqBVbOJmFHlnkgJS31OeS+M8q3M8+zy70VlCgANwUhxeBH1pfujKzjbmbLD5Zv/18iIxJWrHw== 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=5Iy25sQ2h4lE2YbsjmDvYNF5YI7VpQpkgshnxjem5k0=; b=eNQqQGqlzRiziewvajZ5wWAMgX7+TyZjaCHLw+UtAbidMbgBmPm4bKvLdutFiebl2IWJLUSletQjh3bRZxgrPa6imzbFTQkMfd9MPAcjgVFGqczbqis8zR4OP1KeThdemIDLH8+z6G7Gv/kE87UFjZr8sM1hJzfXwI5UPNyv7KTOhMgHPpKIOxtTeCe/M2eNb+yztbWANuC5CbhzbC3dPUGvJPRmlTL8LsLtfYdR0QWd5JI5EeWyAA6cwgBt/jH6MlWZD9BIoh00nlWBChcjt6MlMsXIqsRXMQwDS9+gURR3z5Yr7iV7zlQxDLvcIySEsF0X9SYJiHZ5gHUo4i72SQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Iy25sQ2h4lE2YbsjmDvYNF5YI7VpQpkgshnxjem5k0=; b=g847qTowcmLL5/aetYTH+V18F7V/AGwkyCoBpK/dDoGhf4tyHWiAagM9hdlAMQdxUPzbFOaHwWz77jG9mvradkW33l4OK6ZpBmYpnk5Jkr783melZMPREnhp7fC0yxoFI6wWgRWthixQCXXoccd+AEFfqDsPUiIcSdkRmk+MpP0= Received: from MWHPR11MB1439.namprd11.prod.outlook.com (2603:10b6:301:9::20) by MWHPR11MB1679.namprd11.prod.outlook.com (2603:10b6:301:f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Thu, 6 Aug 2020 18:38:44 +0000 Received: from MWHPR11MB1439.namprd11.prod.outlook.com ([fe80::1fe:5ef0:8591:7fef]) by MWHPR11MB1439.namprd11.prod.outlook.com ([fe80::1fe:5ef0:8591:7fef%8]) with mapi id 15.20.3261.019; Thu, 6 Aug 2020 18:38:44 +0000 From: "Smith, Ned" To: Laurence Lundblade , Carsten Bormann CC: "rats@ietf.org" Thread-Topic: [Rats] Attestation of implementation vs authenticity of service Thread-Index: AQHWacg67ZPAUzhGPkunDF3Tboxri6kpaLyAgACEzwCAAQsqgA== Date: Thu, 6 Aug 2020 18:38:44 +0000 Message-ID: References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> In-Reply-To: <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [50.53.43.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0520ed02-ecfe-4ae3-a410-08d83a37f2bb x-ms-traffictypediagnostic: MWHPR11MB1679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /VJf89WlJJL8JKrcraLClaLRxQdKawIcgr5u1K/xJjERBDC/c0DlixAOkwWylGZeqqY/X9aPhO3srgrpLCnjmIEXtrAo1MQmIdMha1+mWuXdJNCd2AdYw6dmwJbqHmS+c3Fwcwui7aSxTCdwcJ3hdYyjI1K+1IWbWhlJd7fUUjHgiB5ZeIvSBLhx0LK+UPdKY2157CWqToLKhoHMD3lnoP7GEZBhY2W+ADkhOzgt8EIVlP1CF/86TXRFNoBU8tC+v5VC1DI2Lmy7TOZUvspxQNwqjKQGbCdWM33sIxrnKlpc5MAehAZX6meBWwgo3X/040q7AvEwN5kpHviwo1i7ki2cYfezLJ2fzIDVN6603s0kfluuJp/69Jbe3eslo2av6AxrTWpNO5RVcZyltfAwMg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1439.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(86362001)(966005)(76116006)(66946007)(91956017)(66556008)(66446008)(8936002)(2616005)(36756003)(110136005)(66476007)(64756008)(8676002)(316002)(26005)(478600001)(83380400001)(71200400001)(2906002)(6486002)(186003)(33656002)(6512007)(4326008)(5660300002)(53546011)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: gJClFzMJgZZb0ca2OUXcoysoYVIlBL7V7F1yIhbdRNaRZOW7x98L0AAnk3YtgSRzTFZ7bLnUn7yq4zsTp9Uhl0KCXXCn6WrPeWLYdd0t+YwAtTrPwRBu0tr+FmL44FPlT3E4wSTv7m7tsae/7lGfPTqdYk9N+1V0tZq4/VUyOAOOQYG0MuHqpRxJuRhrKUBfzotosbauigDuntaidzBtgiiSb7nQSTJ1k2KFS74/6e+toFP0wq36FViRci/zWviUSrrVANgxS4p5MpJI2pzVLhN2py9r2SMXQdmoPRLTZxPyOUNZD8OujpQf0UVQRY2v/EIHMbpKEfTSGsVv9/Lrzd2tJM3nuMk4zeT4HXVo4ouWKc34U53fgAyXKU2iUOYtPASXEqVs09IglItI8o1U6IJAf+KEfUL3eW8fq4SWDYPsIT7fYD4oQsdjz3YCq/ZHa/9pwiekBZExshx4URMueRIqLyIG72eUaunzngwZFyF2LhAJpLV+Np0Hm6lvs6byDRmL9ypPi5OUi+pmwaFB7Tx6HC6ZTBmI/tghKyUJf6HErd+53jyqw8P1aLUKOJyi0mh/cBF1hDCejFNDPa1yDUSe89ScRX1ucWD0wARfxXPkmV7MqP7XfkCp/ihtNhY3xyNgsJu54/8garKJhqGnPg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1439.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0520ed02-ecfe-4ae3-a410-08d83a37f2bb X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 18:38:44.1921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eu8znsRxY/a0bUeWLRdmz6iNxv5ThHzIwuj8HpI6IehvrK7wfF+6U7zlFCdoNTenONI7N7vpITZBMkROUbUeuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1679 X-OriginatorOrg: intel.com Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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: Thu, 06 Aug 2020 18:38:55 -0000 VGhlIFJBVFMgY2hhcnRlciByZWZlcnMgdG8gInN5c3RlbSBjb21wb25lbnQiIGFzIHRoZSBpbml0 aWFsIGZvY3VzIGZvciBkZWZpbml0aW9uOyB3aGljaCBpbmNsdWRlcyBjbGFpbXMgZGVmaW5pdGlv bi4gVGhlIGFyY2hpdGVjdHVyZSBtYWtlcyBpdCBjbGVhciB0aGF0IGNsYWltcyBjYW4gb3JpZ2lu YXRlIGVsc2V3aGVyZSBhcyB3ZWxsLiBJdCBzZWVtcyByZWFzb25hYmxlIHRoYXQgY2xhaW1zIGFi b3V0IHNlcnZpY2VzIGNvdWxkIGJlIGRlZmluZWQgZWxzZXdoZXJlLCBidXQgc3RpbGwgYmUgY29u dmV5ZWQgLyBhcHByYWlzZWQgdXNpbmcgUkFUUyBXRyBkZWZpbmVkIGFyY2hpdGVjdHVyZSBhbmQg dGVjaG5vbG9neS4gQWx0ZXJuYXRpdmVseSBpdCBjb3VsZCBiZSBkZWZpbmVkIGluIFJBVFMsIGJ1 dCBwb3NzaWJseSB3aXRoIHNvbWUgY2hhcnRlciBhZGp1c3RtZW50cyB0byBhbGxvdyAic2Vydmlj ZXMiIHNjb3BlPw0KDQotTmVkDQoNCu+7v09uIDgvNS8yMCwgMTI6NDIgUE0sICJSQVRTIG9uIGJl aGFsZiBvZiBMYXVyZW5jZSBMdW5kYmxhZGUiIDxyYXRzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGxnbEBpc2xhbmQtcmVzb3J0LmNvbT4gd3JvdGU6DQoNCg0KDQogICAgPiBPbiBBdWcg NSwgMjAyMCwgYXQgNDo0NyBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3Rl Og0KICAgID4gDQogICAgPiBPbiAyMDIwLTA4LTAzLCBhdCAyMDo1OCwgTGF1cmVuY2UgTHVuZGJs YWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb20+IHdyb3RlOg0KICAgID4+IA0KICAgID4+IFNlcnZp Y2UgQXV0aGVudGljaXR5DQogICAgPj4gCeKAoiBGb2N1cyBpcyBvbiB0aGUgcHJvdmlkZXIgb2Yg dGhlIHNlcnZpY2UsIG5vdCB0aGUgSFcgb3IgU1cNCiAgICA+PiAJ4oCiIFRoZSBsZWdhbCBlbnRp dHkgb2YgaW50ZXJlc3QgaXMgdGhlIHNlcnZpY2UgcHJvdmlkZXINCiAgICA+PiAJ4oCiIFRoZXJl IGlzIG5vIGVxdWl2YWxlbnQgb2YgY2xhaW1zLCBidXQgaWYgdGhlcmUgd2FzIHRoZXkgd291bGQg YmUgYWJvdXQgdGhlIGJ1c2luZXNzIG9yIHBlcnNvbiBvcGVyYXRpbmcgdGhlIHNlcnZpY2UNCiAg ICA+PiAJ4oCiIEV4YW1wbGU6IGEgd2ViIHNpdGUNCiAgICA+PiAJ4oCiIEV4YW1wbGU6IGFuIGVt YWlsIHByb3ZpZGVyIChJTUFQIHNlcnZpY2UpDQogICAgPj4gDQogICAgPiANCiAgICA+IEhpIExh dXJlbmNlLA0KICAgID4gDQogICAgPiBpZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgSFRUUFMsIHRo ZXJlIGlzIGV4YWN0bHkgb25lIGNsYWltOiAgVGhlIHNlcnZpY2UgaXMgc3BlYWtpbmcgZm9yIGEg c3BlY2lmaWMgbmFtZSAoZS5nLiwgZmFjZWJvb2suY29tKS4gIEFsbCBvdGhlciBjbGFpbXMgYXJl IGZ1bm5lbGVkIHRocm91Z2ggdGhpcyBvbmUgdmVyeSBzcGVjaWFsIG9uZS4gIE9mIGNvdXJzZSwg dGhlIFRMUyBoYW5kc2hha2UgY291bGQgYmUgbGV2ZXJhZ2VkIHRvIGRvIG1vcmUgdGhhbiB0aGlz IG9uZSBjbGFpbSwgYnV0IHRoYXQgaXMgbm90IHdoYXQgaGFwcGVucyBpbiBIVFRQUy4NCg0KICAg IFllcywgYWdyZWVkLg0KDQogICAgQW55IG5vdGlvbiBvZiB0cnVzdHdvcnRoaW5lc3MsIHJlZ3Vs YXRvcnkgY29tcGxpYW5jZSBhbmQgc3VjaCBmb3IgYSBzZXJ2aWNlIGlzIGltcGxpZWQuIFdlIG1h a2UgaGVhdnkgdXNlIG9mIHRoYXQgaW1wbGljYXRpb24gYW5kIHRoYXQgaXMgbW9zdGx5IE9LLiBG b3IgZXhhbXBsZSwga25vd2luZyB0aGF0IGZhY2Vib29rLmNvbSBpcyBGYWNlYm9vayBJbmMgYWxs b3dzIHVzIHRvIGFzc3VtZSBsb3RzIGFib3V0IHRoZSBzZXJ2aWNlIGZyb20gd2hhdCB3ZSBrbm93 IG9mIHRoZSBjb21wYW55LiANCg0KICAgIFRoZSBlcXVpdmFsZW50IGZvciBhdHRlc3RhdGlvbiB3 b3VsZCBiZSBqdXN0IHRvIG5hbWUgdGhlIG1hbnVmYWN0dXJlciBvZiB0aGUgSFcgb3IgU1cuIEhv d2V2ZXIsIHdlIGFyZSBnb2luZyBmYXIgYmV5b25kIHRoYXQgd2l0aCBhbGwgdGhlIENsYWltcyBp biB0aGUgRXZpZGVuY2UgYW5kIFJlc3VsdHMuDQoNCiAgICBNYXliZSB3ZSBzaG91bGQgaGF2ZSBD bGFpbXMgYWJvdXQgc2VydmljZXM/IEZvciBleGFtcGxlLCB3aGF0IHJlZ3VsYXRvcnkgc3RhdHV0 ZXMgdGhleSBtZWV0LiBXaGVyZSBhcmUgdGhleSBpbmNvcnBvcmF0ZWQuIEEgcmVmZXJlbmNlIHRv IHRoZWlyIHRlcm1zIG9mIHNlcnZpY2UgYW5kIHByaXZhY3kgcG9saWN5Lg0KDQogICAgVGhhdCBo b3dldmVyIHNlZW1zIGxpa2UgYSBuZXcgV0csIG5vdCBSQVRTLg0KDQogICAgTEwNCg0KDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBSQVRT IG1haWxpbmcgbGlzdA0KICAgIFJBVFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JhdHMNCg0K From nobody Thu Aug 6 12:09:54 2020 Return-Path: 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 3878A3A0E0E for ; Thu, 6 Aug 2020 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ABBPXvDKH0Ll for ; Thu, 6 Aug 2020 12:09:51 -0700 (PDT) Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2D23A0E0B for ; Thu, 6 Aug 2020 12:09:51 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 3lGwkPxI4e1cf3lGxkCFna; Thu, 06 Aug 2020 12:09:51 -0700 X-CMAE-Analysis: v=2.3 cv=U5vs8tju c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=3j4BkbkPAAAA:8 a=qWX2815_JrchmU1UgoQA:9 a=t-6OkMMwBgOnfhEF:21 a=9D5VBP6m7CVHqV40:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: Date: Thu, 6 Aug 2020 12:09:50 -0700 Cc: Carsten Bormann , "rats@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> To: "Smith, Ned" X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfLD9A6/QBXnM+tNvKKZ/iXZbHDk4rP8XgbmclBvWK4hpZST5NH7Ava9KWicFq75nuDma854A2JqFFJ6QK4urTvvFte+tw6FAf1LiQxCesd3V2o82YcFb /dZUAEavYycQKx/6QACp332GEFuVhtLRz2+JZ4XuTTlHl2V7kQfgTx4UrycBj2jxzwcMul5WE32bH3o25TPIWC/YfBPeeEewJiAvOxzWEmZlgZ3Dq2O8FLyk Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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: Thu, 06 Aug 2020 19:09:53 -0000 Yes, the RATS architecture seems highly applicable to = claims-about-services (for lack of a better term). It would be dumb to = have an IETF architecture for claims-about-services that didn=E2=80=99t = re use the RATS architecture at least partially. By my read of the charter, claims-about-services are not explicitly = excluded, but also not quite in the spirit of it. Maybe the work done is = done in RATS with a re charter? The bottom line for me, is that I really don=E2=80=99t want to put any = claims about services in EAT. There is enough work to do already :-) LL > On Aug 6, 2020, at 11:38 AM, Smith, Ned wrote: >=20 > The RATS charter refers to "system component" as the initial focus for = definition; which includes claims definition. The architecture makes it = clear that claims can originate elsewhere as well. It seems reasonable = that claims about services could be defined elsewhere, but still be = conveyed / appraised using RATS WG defined architecture and technology. = Alternatively it could be defined in RATS, but possibly with some = charter adjustments to allow "services" scope? >=20 > -Ned >=20 > =EF=BB=BFOn 8/5/20, 12:42 PM, "RATS on behalf of Laurence Lundblade" = wrote: >=20 >=20 >=20 >> On Aug 5, 2020, at 4:47 AM, Carsten Bormann wrote: >>=20 >> On 2020-08-03, at 20:58, Laurence Lundblade = wrote: >>>=20 >>> Service Authenticity >>> =E2=80=A2 Focus is on the provider of the service, not the HW or = SW >>> =E2=80=A2 The legal entity of interest is the service provider >>> =E2=80=A2 There is no equivalent of claims, but if there was = they would be about the business or person operating the service >>> =E2=80=A2 Example: a web site >>> =E2=80=A2 Example: an email provider (IMAP service) >>>=20 >>=20 >> Hi Laurence, >>=20 >> if you are talking about HTTPS, there is exactly one claim: The = service is speaking for a specific name (e.g., facebook.com). All other = claims are funneled through this one very special one. Of course, the = TLS handshake could be leveraged to do more than this one claim, but = that is not what happens in HTTPS. >=20 > Yes, agreed. >=20 > Any notion of trustworthiness, regulatory compliance and such for a = service is implied. We make heavy use of that implication and that is = mostly OK. For example, knowing that facebook.com is Facebook Inc allows = us to assume lots about the service from what we know of the company.=20 >=20 > The equivalent for attestation would be just to name the = manufacturer of the HW or SW. However, we are going far beyond that with = all the Claims in the Evidence and Results. >=20 > Maybe we should have Claims about services? For example, what = regulatory statutes they meet. Where are they incorporated. A reference = to their terms of service and privacy policy. >=20 > That however seems like a new WG, not RATS. >=20 > LL >=20 >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats From nobody Fri Aug 7 07:01:22 2020 Return-Path: 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 984F93A0BE4 for ; Fri, 7 Aug 2020 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6z_5zeOF9f9e for ; Fri, 7 Aug 2020 07:01:20 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304503A0BE3 for ; Fri, 7 Aug 2020 07:01:20 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id a26so2212056ejc.2 for ; Fri, 07 Aug 2020 07:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wBJ1LJpxMmP5FOkDcVCfO0WoO7Xr0Kz6JYFVEt8lCik=; b=uEbOU4q6OSbzp2Ux6jsgKAEnnbAdEXOsaddOgzEldsZH8teGSkG1GPPlsd8ulvuVpF 7LYpWuqVSKK/UHliSYH25Ef98T30qTx2m0MJLGREUQgAbxNEiyNjTr0tutWyYotAhTTb tf8qTLpg8rqS4LYdqQswtMnWFAXw6ZVb4p8BtHoLI3j8tHvDKPyY9gFU/CmkrD+975Wo +QI/4N5ebx3sfPkfv1d1x7hV6GnvQukS6GYg8Gm+6yM8jbIFTXjEVP1P16zeS96pxcFf bLuxl7yvyxiIS0zvHP1ccmCzHgd5wYR/RQ9KJBYqtge2KT/cqWpd/RhmEqeivD/ogshF cs+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wBJ1LJpxMmP5FOkDcVCfO0WoO7Xr0Kz6JYFVEt8lCik=; b=rgGYQo2W0yMlrhPRNJbtODLOiYhbpkAyvfmQUBbpzxsNO2PXs+xfwuOzjNDMMt9i9B xLx+C8RS76IAdUhzz4M1Dx8sble9rfBFOA0dXSVBLouR0EU3/VpZOVory5eLkiQ+mbNH ZzAwUxlElFmDBc4bDltfD/9up4N2+MagkdYdN5RNTMXQOImFtAUjiYNCLw+GRoxgOAM0 xDVtqLkD7KL2pZsFyKnevCBn4TlnnlQdeibpGSkfU1mOfDAkSghJFwGN0bYWdJdNmYyL VnODBhgNETOb0PyD5e8vbUYASEKE1aUejBOxOi4eUD6CVl9ppqEgOni2ZKPPrLdJmcjB Topw== X-Gm-Message-State: AOAM533CYyPjVKYAHSykK/WCYwhbi56Px1ZlDK6HZCQIiecjThzIEfWd uJ5ISQcRx5osPfx0KBk0CootH2LL3yU9OU70oeAwRQM+//Y= X-Google-Smtp-Source: ABdhPJw8AY0f6G/bFwyzXtmbBIjyYybHa5wRlfSWn+J0UoVLGAVNTKWMv4jhkrOeF/XrwoMN3UMueIQwIkfolFCxGKg= X-Received: by 2002:a17:906:7f0e:: with SMTP id d14mr9353985ejr.400.1596808878184; Fri, 07 Aug 2020 07:01:18 -0700 (PDT) MIME-Version: 1.0 From: Jessica Fitzgerald-McKay Date: Fri, 7 Aug 2020 10:01:07 -0400 Message-ID: To: rats@ietf.org Cc: Michael Jenkins , Jessica Fitzgerald-McKay Content-Type: multipart/alternative; boundary="000000000000f55ea905ac4a09e8" Archived-At: Subject: [Rats] comments on draft-birkholz-rats-uccs X-BeenThere: rats@ietf.org 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: Fri, 07 Aug 2020 14:01:22 -0000 --000000000000f55ea905ac4a09e8 Content-Type: text/plain; charset="UTF-8" Hi, UCCS authors, Mike Jenkins and I reviewed the UCCS draft. Our comments are below. Happy to talk through any of them with the group. Thanks, Jess The intent of this draft is similar to the key concept of EST - use the authentication of the secure session connection. Most schemes build on this concept leave a lot of banana peels laying around, some of which we describe here. In general, this does not seem appropriate to the scope of RATS. We feel that COSE might be a more appropriate work group to think these issues through. - If you're using a static symmetric key for authentication (as one might with highly-constrained devices), you can only authenticate a net, not an entity. The receiver cannot differentiate between authenticating the sender and authenticating itself. - The authentication happens at the secure channel termination, not in the channel-contents-using application. It's important how the termination process vouches the authentication to the application. (In EST, this question is how the EST server vouches the requestor's identity to the CA server.) - A TEE only helps if the TEE application can punch through the REE and set up the secure channel completely on its own. If the TEE relies on the REE to set up the secure channel, you might as well just operate in the REE. - There is a comment at the end of the introduction (!) about transitioning back and forth between self-protected and channel-protected CWT, "in a well-defined scope". Define the security characteristics of that scope or get rid of the comment. You're handing someone an awful lot of rope there. - The claims set should be treated as ephemeral by the recipient. It shouldn't be stored, and can't be forwarded except as data originated by the recipient. As soon as it emerges from the secure channel, it's no more valid or meaningful than any other piece of unprotected data in the application environment. --000000000000f55ea905ac4a09e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, U= CCS authors,

=
Mike Jenkins and= I reviewed the UCCS draft. Our comments are below. Happy to talk through a= ny of them with the group.

Th= anks,
Jess
<= div class=3D"gmail_default" style=3D"color:#000000">
The intent of this draft is similar to the key concept of EST - use the au= thentication of the secure session connection. Most schemes build on this c= oncept leave a lot of banana peels laying around, some of which we describe= here. In general, this does not seem appropriate to the scope of RATS. We = feel that COSE might be a more appropriate work group to think these issues= through.

- If you're using a static= symmetric key for authentication (as one might with highly-constrained dev= ices), you can only authenticate a net, not an entity. The receiver=C2=A0ca= nnot differentiate between authenticating the sender and authenticating its= elf.

- The authentication happens at the= secure channel termination, not in the channel-contents-using application.= It's important how the termination process vouches the authentication = to the application. (In EST, this question is how the EST server vouches th= e requestor's identity to the CA server.)

- A TEE only helps if the TEE application can punch through the REE a= nd set up the secure channel completely on its own. If the TEE relies on th= e REE to set up the secure channel, you might as well just operate in the R= EE.

- There is a comment at the end of t= he introduction (!) about transitioning back and forth between self-protect= ed and channel-protected CWT, "in a well-defined scope". Define t= he security characteristics of that scope or get rid of the comment. You= 9;re handing someone an awful lot of rope there.

- The claims set should be treated as ephemeral by the recipient. = It shouldn't be stored, and can't be forwarded except as data origi= nated by the recipient. As soon as it emerges from the secure channel, it&#= 39;s no more valid or meaningful than any other piece of unprotected data i= n the application environment.
--000000000000f55ea905ac4a09e8-- From nobody Fri Aug 7 09:46:16 2020 Return-Path: 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 59E3F3A0CCF for ; Fri, 7 Aug 2020 09:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cuQB2729cjSC for ; Fri, 7 Aug 2020 09:46:13 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76853A0CC7 for ; Fri, 7 Aug 2020 09:46:13 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 45VUk3t4EbZIF45VUkbMKa; Fri, 07 Aug 2020 09:46:13 -0700 X-CMAE-Analysis: v=2.3 cv=E9CzWpVl c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=oumihVu1M68n9TQdrkcA:9 a=QEXdDO2ut3YA:10 a=gdVDRX3PWmuWimQ2:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <23B2F64A-A32D-4060-94FB-43D688105DFC@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C298B9C9-3922-4EE1-B726-86EEE8BFABBA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Aug 2020 09:46:12 -0700 In-Reply-To: Cc: rats@ietf.org, Jessica Fitzgerald-McKay , Michael Jenkins To: Jessica Fitzgerald-McKay References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfAOpPS8I07LPTmro4i6JjvdxvuJOMJRoLabdKkp4ia0ptSZtLy9/EbtR7GA+JGE+6WkU4zxQtn+tXwcRUBQtws9nkcU0g7mqpWBT9WVRogsZ+kWN/fyh NY4RFW89IQgFtQceccCzX6jn40b1iyC+8dIBxaYMtLe3XOCDemBi1qt37F3RgWuvNg2g5XcDTgxPwxS/s90EmX32m0qq+m6urIItz3+D4tMJyFAoGY+kuRZR 2vAw80j1CUJud6L/52yvkNRE5espPxBfwWIcOq51kK0= Archived-At: Subject: Re: [Rats] comments on draft-birkholz-rats-uccs X-BeenThere: rats@ietf.org 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: Fri, 07 Aug 2020 16:46:15 -0000 --Apple-Mail=_C298B9C9-3922-4EE1-B726-86EEE8BFABBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seems to me that one of these is also characteristic of CWT/COSE = (character of symmetric keys) and the rest are potentially true of = CWT/COSE. Personally, I don=E2=80=99t think it is the IETF=E2=80=99s job to = explain to implementers how to correctly use a TEE, SE, HSM or other = restricted operating environments. That=E2=80=99s not a job that can be = completed in a protocol document. Most implementers working with TEEs = and similar already have the rope and we can=E2=80=99t really take it = away from them. When I went to intro to writing security considerations = session at the last Montreal IETF, one of the main points was that IETF = can=E2=80=99t really control what implementers do. That said, I do think it is the job of the IETF to create protocols that = can make use of TEE=E2=80=99s and the like. As I=E2=80=99ve mentioned before, I think UCCS should have a very = minimal discussion on security in-the-absence-of-CWT/COSE because it=E2=80= =99s not really possible to cover it well. There=E2=80=99s too many = implementation environment and use case specific issues. Jessica=E2=80=99s= comment is an illustration of that. LL > On Aug 7, 2020, at 7:01 AM, Jessica Fitzgerald-McKay = wrote: >=20 > Hi, UCCS authors, >=20 > Mike Jenkins and I reviewed the UCCS draft. Our comments are below. = Happy to talk through any of them with the group. >=20 > Thanks, > Jess >=20 > The intent of this draft is similar to the key concept of EST - use = the authentication of the secure session connection. Most schemes build = on this concept leave a lot of banana peels laying around, some of which = we describe here. In general, this does not seem appropriate to the = scope of RATS. We feel that COSE might be a more appropriate work group = to think these issues through. >=20 > - If you're using a static symmetric key for authentication (as one = might with highly-constrained devices), you can only authenticate a net, = not an entity. The receiver cannot differentiate between authenticating = the sender and authenticating itself. >=20 > - The authentication happens at the secure channel termination, not in = the channel-contents-using application. It's important how the = termination process vouches the authentication to the application. (In = EST, this question is how the EST server vouches the requestor's = identity to the CA server.) >=20 > - A TEE only helps if the TEE application can punch through the REE = and set up the secure channel completely on its own. If the TEE relies = on the REE to set up the secure channel, you might as well just operate = in the REE. >=20 > - There is a comment at the end of the introduction (!) about = transitioning back and forth between self-protected and = channel-protected CWT, "in a well-defined scope". Define the security = characteristics of that scope or get rid of the comment. You're handing = someone an awful lot of rope there. >=20 > - The claims set should be treated as ephemeral by the recipient. It = shouldn't be stored, and can't be forwarded except as data originated by = the recipient. As soon as it emerges from the secure channel, it's no = more valid or meaningful than any other piece of unprotected data in the = application environment. > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats --Apple-Mail=_C298B9C9-3922-4EE1-B726-86EEE8BFABBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Seems to me that one of these is also characteristic of = CWT/COSE (character of symmetric keys) and the rest are potentially true = of CWT/COSE.

Personally, I don=E2=80=99= t think it is the IETF=E2=80=99s job to explain to implementers how to = correctly use a TEE, SE, HSM or other restricted operating environments. = That=E2=80=99s not a job that can be completed in a protocol document. = Most implementers working with TEEs and similar already have the rope = and we can=E2=80=99t really take it away from them. When I went to intro = to writing security considerations session at the last Montreal IETF, = one of the main points was that IETF can=E2=80=99t really control what = implementers do.

That said, I do = think it is the job of the IETF to create protocols that can make use of = TEE=E2=80=99s and the like.

As = I=E2=80=99ve mentioned before, I think UCCS should have a very minimal = discussion on security in-the-absence-of-CWT/COSE because it=E2=80=99s = not really possible to cover it well. There=E2=80=99s too many = implementation environment and use case specific issues. Jessica=E2=80=99s= comment is an illustration of that.

LL


On Aug = 7, 2020, at 7:01 AM, Jessica Fitzgerald-McKay <jmfmckay@gmail.com> = wrote:

Hi, UCCS = authors,

Mike Jenkins = and I reviewed the UCCS draft. Our comments are below. Happy to talk = through any of them with the group.

Thanks,
Jess

The intent of this draft is = similar to the key concept of EST - use the authentication of the secure = session connection. Most schemes build on this concept leave a lot of = banana peels laying around, some of which we describe here. In general, = this does not seem appropriate to the scope of RATS. We feel that COSE = might be a more appropriate work group to think these issues = through.

- If you're using a static = symmetric key for authentication (as one might with highly-constrained = devices), you can only authenticate a net, not an entity. The = receiver cannot differentiate between authenticating the sender and = authenticating itself.

- The authentication happens at = the secure channel termination, not in the channel-contents-using = application. It's important how the termination process vouches the = authentication to the application. (In EST, this question is how the EST = server vouches the requestor's identity to the CA server.)

- A TEE only = helps if the TEE application can punch through the REE and set up the = secure channel completely on its own. If the TEE relies on the REE to = set up the secure channel, you might as well just operate in the = REE.

- There is a comment at the end = of the introduction (!) about transitioning back and forth between = self-protected and channel-protected CWT, "in a well-defined scope". = Define the security characteristics of that scope or get rid of the = comment. You're handing someone an awful lot of rope there.

- The claims = set should be treated as ephemeral by the recipient. It shouldn't be = stored, and can't be forwarded except as data originated by the = recipient. As soon as it emerges from the secure channel, it's no more = valid or meaningful than any other piece of unprotected data in the = application environment.
_______________________________________________
RATS = mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

= --Apple-Mail=_C298B9C9-3922-4EE1-B726-86EEE8BFABBA-- From nobody Mon Aug 10 12:14:52 2020 Return-Path: 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 49DAE3A0B2B for ; Mon, 10 Aug 2020 12:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 7XdaDibK7G2r for ; Mon, 10 Aug 2020 12:14:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27843A0B41 for ; Mon, 10 Aug 2020 12:14:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EC963389D5 for ; Mon, 10 Aug 2020 14:54:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JFNCXbPd1-TE for ; Mon, 10 Aug 2020 14:54:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 20F18389A2 for ; Mon, 10 Aug 2020 14:54:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C431910DF for ; Mon, 10 Aug 2020 15:14:44 -0400 (EDT) From: Michael Richardson cc: rats@ietf.org In-Reply-To: <27710.1596484782@localhost> References: <27710.1596484782@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 10 Aug 2020 15:14:44 -0400 Message-ID: <5105.1597086884@localhost> Archived-At: Subject: Re: [Rats] Architecture Design Team meetings X-BeenThere: rats@ietf.org 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, 10 Aug 2020 19:14:50 -0000 Michael Richardson wrote: > I'd like a week off, many of you probably do too. > Let's resume weekly August 11. I have received a number of messages saying that people are on vacation this week. So we will actually start August 18. > That doesn't mean you can't edit pull requests. Just to repeat this :-) From nobody Tue Aug 11 15:51:55 2020 Return-Path: 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 CAD523A0D88 for ; Tue, 11 Aug 2020 15:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=fdio4K6g; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=d3o65Rzf 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 SfK-umWjfg1w for ; Tue, 11 Aug 2020 15:51:51 -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 476323A0D89 for ; Tue, 11 Aug 2020 15:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15437; q=dns/txt; s=iport; t=1597186311; x=1598395911; h=from:to:subject:date:message-id:mime-version; bh=vb1qz5n06RkgJBMC9pkafxQQwW02gNuFOgkGph+AmNo=; b=fdio4K6gxS7yi2nm1P45lQ4QYZDCVHX8O+BBoCekc+eacHNi0cBZrEl6 bpeCbMQ8AS+hI6svIJNVMqQRtwUHwxY2YCfOpimt5HMtq3juznRVj1S7c yrrdVTO6KZBPUwDSKl5Zgoo46f3douRDE560sABBC6jJL4ausyUKQQcAJ o=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3Awo1dNBc1FO0b6J2bE7td/DlRlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5CgADIDNf/4UNJK1XCYEJgm0vUQd?= =?us-ascii?q?vKy0vLAqHcgOLD4oijByCBoJnglMDVQQHAQEBCQMBASUIAgQBAYRMAoIzAiQ?= =?us-ascii?q?4EwIDAQELAQEFAQEBAgEGBG2FXAELhXYUGxMBATgRAVAwJgEEGwYUgwU4gUZ?= =?us-ascii?q?NAx8PAQ6nXAKBOYhhdIE0gwEBAQWBMwEDAgJKA4MNGIIHBwMGgTiBU4Eeih8?= =?us-ascii?q?agUE/gRFDhQRBIgIBgTIuK4Mdgi2bH5sNCoJihDiCXIFPkVeCfp0Xki+BbIh?= =?us-ascii?q?RlHcCBAIEBQIOAQEFgWojgVdwFTuCaVAXAg2OKxeDToUUhUJ0EgIjAgYIAQE?= =?us-ascii?q?DCXyPFgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,302,1592870400"; d="p7s'?scan'208,217";a="541123195" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2020 22:51:50 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07BMpo33001951 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Aug 2020 22:51:50 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 17:51:49 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 18:51:49 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 11 Aug 2020 17:51:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WitpoXqCC64GxWMAoEpLv0dLc/Cw6azdn6+fb72qvBHeK6owb6esZMF6LKvQasMmppTZMU9Pf3jOPIIpbr0o/VQCa4vABHkJMkgDn0sH1GjNx4/eV0aR53B6F6l/7LPlY/tppMTBOkNxBZneaF216b8oZiVkdyQ8mQS3bV601KhUnkp7ubVch8x4ZYjK5lstF+Y29I/Wy9ndhPrAF/it41VQEcYZhfjaINaASpuNef200JOpJ5AcEylDDmFvAmQeF0msCkWJ3MyORAeaZFn9jXpAcweI1yWMi3pcjyJyZkbCJ78pS/9TFW9R0WV7iSR/fS3ok43C/wMZlA83Bh0Q9Q== 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=pEZTj7uGy43Gvlu4lQWCk1eN6DDDMa5qnpjLELLIdFI=; b=h6fCi7MNrC/dE2TjqLKY6H1qeSrcMo8udnl3hx1y6IfbJHfmFtos1ui3JTY3nNZRfNamRcL1zI8AK7pA5ayzcjcHDPOxNKoH5gnt2zHih+YgxCoadQ49AZCEOGjI43+des/M1/eIdMJWaiOfvMgvWijIkcyNmpequdUNq765t/khxjm2WXZG/W/5IVhchO6O/pEs1FfVKgMgGDWg2BN0f2VU8UHOYUzzQbOUmj/6yaDT09qVnxB7KcdW2Q3k+rKrAwGHAkFoVgQmtWt2ZjvGi7c0rwqOE3grURkj6XAlu2d0dNP6kqVKdYnV7IirEESKXxGP8TeI9qnOazyvOVTMTg== 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=pEZTj7uGy43Gvlu4lQWCk1eN6DDDMa5qnpjLELLIdFI=; b=d3o65RzfhLyZ5yRhAD0Txqtoc/gnc6+fCz811LF6y7ShWr48QcPx2C1C55N6n8sAiY4lUaHcr246M5GSncX3JEZWv7NTmXU3ps1U+pf1LN+IglALy02g/aaejpYlHrI5FaEmIYgBfYOQGN4MHGklacqsLRhCpfmy5HjKZm2tuRc= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4079.namprd11.prod.outlook.com (2603:10b6:208:153::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Tue, 11 Aug 2020 22:51:47 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 22:51:47 +0000 From: "Eric Voit (evoit)" To: "rats@ietf.org" Thread-Topic: Which Asymmetric algorithms for Charra? Thread-Index: AdZwFfR0sMtRnzzORw2twimiOLxijg== Date: Tue, 11 Aug 2020 22:51:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 483b6e3a-ff11-4353-32e7-08d83e49209a x-ms-traffictypediagnostic: MN2PR11MB4079: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ce5TcTsXFjzQ8N9q56NVmqPa3hHGjmgxMKUTrL/4//qUDJOCaSrmhtML9IHHaNh9B/hhqoPMg0vgktJVo4QJy36YKuPmL33KqicAG7UPV/iRd/Itnav/7srJc7Fg+hKOkdIeMaf0sVSWY8idgXWjWUIizEGeZgePzjZFUkPAhM4LU+SJ2xKG+PtTvtMre+c+VemhMWqdauhQV1xMjiXr8OzQLWtgR+A7Cfn/F8O/JBfqpRs0ClgooX3NsTsMGvxi1xf0uE4T2Du1JxMPpvGE5NUk93X5ghhRDeKM8WC0iqWTBkfqtRwjhhz4WMJ4jQvSesbfNcZBMInsN9KwSsDFFxjlUr/0J07PoW6MZd4uLSFSc4+H75TRRCIj9224u+nQ4kb1deIxITE9+MTj8889pPeuGnd1pi+t4FRX0bT8Ot7WqeLu7Raur7cjB9vgPbWiIY4hxAfbKv4au3wnpqlZLA== 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; SFTY:; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(366004)(2906002)(52536014)(33656002)(83380400001)(86362001)(6916009)(8676002)(8936002)(316002)(5660300002)(166002)(66476007)(66556008)(966005)(99936003)(71200400001)(478600001)(6506007)(66616009)(186003)(55016002)(9686003)(76116006)(66446008)(26005)(66946007)(7696005)(64756008)(15398625002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2bQNg9ivjXoLu9HRynf5qdL+254IRWHq9drdK/jfJNpOnETMR7xCIOhBLwuE2t3XMKFwn4MWI7EZf3SRMEI47A52CyMiZMJoxm7j64vqWKWLeMy1YN8GCHGvWYpFm95LGtQQO16b2dADgH3lOxLP0bwQVA83XqwSUSUeoBZfvSco06k5iEc03FzPCdykw+QFmlvHaCFRzq5xjXurVDTPa2Is/qD6sgGhh4+Bhj0d6TukN7brg1bglkYqspvyLjb4f4ipuQKsah6f8EFhcSFGvnGF9iPQBq936Pynp+w4/laV04xhFIRijpH41lUmw8T3jQJT/zVUWKtAv5cM2ahi9/y+W3XRGDt+i3UebEKBzwAs92oalcYlyRGpUDNEnLENjjxgQfQ23ICpEyVfZBJkb5yivbVXLtjeP43UFsTHV3XoNVAAhhy7RdhxK29UzAPW2k67wezaLfTDU2zwOn+jq5zANy96rFx0uLp446B2OdCJ1ddewsl38hYdwxPaBHI8PZ/KWLXZ6hnbNi20Xo8LAmngcqXOwO0NtIZdtajlMl2vj88fmysUqBkD5DseQm8Ng38B5zR3VNncxyYAtnkuuv17MrwyYECVZ2q30ZTA76Cf7bn741Hd0Gz7HKY5iVNJAUMh+FRaCIgID4uvxhHpEA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006C_01D67010.729F79D0" 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: 483b6e3a-ff11-4353-32e7-08d83e49209a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 22:51:47.1467 (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: mtq5rOtImmgr/Bb+L6Md/mUwEGBep860Lw3GOXrpVT+H0PjvbWRy6uP+8Lx4xwxr X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4079 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: [Rats] Which Asymmetric algorithms for Charra? X-BeenThere: rats@ietf.org 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: Tue, 11 Aug 2020 22:51:54 -0000 ------=_NextPart_000_006C_01D67010.729F79D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006D_01D67010.729F79D0" ------=_NextPart_001_006D_01D67010.729F79D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-upd ate-00, 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 https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry _r1p32_pub.pdf 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: https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit: patch-4 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 Eric Voit Principal Engineer .:|:.:|:. Cisco Systems, Inc. ------=_NextPart_001_006D_01D67010.729F79D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 https://www.ietf.org/proceedings/108/slides/slides-108= -rats-sessb-charra-update-00, 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 https://trustedcomputinggroup.org/wp-content/u= ploads/TCG-_Algorithm_Registry_r1p32_pub.pdf 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:

https://github.com/ietf-rats-wg/basic-yang-module/com= pare/master...ericvoit:patch-4

 

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

 

Eric Voit =

Principal Engineer

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

 

------=_NextPart_001_006D_01D67010.729F79D0-- ------=_NextPart_000_006C_01D67010.729F79D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODExMjI1MTM5WjAjBgkqhkiG 9w0BCQQxFgQUKBGculKxpNd1WGF+xDzbk/N5tO4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBcHFs9hZVaTepstZvOaGtGPoiD/VSXv80NW/kDPmuc3NtFHHYZdu3JfyPdKjQa+yHu eHYeflrcK5ba43cDU0Gsgw6xKqYNW2CT5twuOF5Moem7PmgsPch3sAsLikRH0YxvYXE3vV0kl/ds FhbeMx6CL6YwNnOo8j/ch+AtbwPGSOp5DwImSn3Ntwu/mZs/9CMpsdhXdy+K+XnN7Hjqq0HzL7CJ qRuVXxHqdRreeIN2UaE3LPF8XqKoCN3GXTsVNjv2G3Cy0jnqe3YWG6DP3fOVoBJa/lfNuQ4gBiwJ uBoL7LRk29i7oDKSMnpF3QB4+amVY9ltlD9BG+ygHPt7TPntAAAAAAAA ------=_NextPart_000_006C_01D67010.729F79D0-- From nobody Tue Aug 11 16:27:00 2020 Return-Path: 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 3F82A3A0DCD for ; Tue, 11 Aug 2020 16:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 heJdoWI5knGW for ; Tue, 11 Aug 2020 16:26:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90B13A0DBE for ; Tue, 11 Aug 2020 16:26:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9AEAD389B1; Tue, 11 Aug 2020 19:06:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5d54IU_s-u8Q; Tue, 11 Aug 2020 19:06:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D1CDE389B0; Tue, 11 Aug 2020 19:06:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 977D5B3; Tue, 11 Aug 2020 19:26:53 -0400 (EDT) From: Michael Richardson To: "Eric Voit \(evoit\)" cc: "rats\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Rats] Which Asymmetric algorithms for Charra? X-BeenThere: rats@ietf.org 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: Tue, 11 Aug 2020 23:26:58 -0000 --=-=-= Content-Type: text/plain Eric Voit \(evoit\) wrote: > 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?" You are asking about *asymmetric* algoritms. I'd like to see EdDSA in the list, and I suspect that they aren't in the TPM spec. > This is reflected seen in > https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-upd > ate-00, Slide 7. And that slide shows them missing. > 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. You also write: 2. Identities instead of strings for TCG and IETF crypto algorithm types. Strings allow lots of errors to be introduced. (Question #1) the otherside if you don't use strings is you use an enum, which is not an IANA registry. So you need an integer with an IANA registry. > * 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) Good. > Are there any objections/questions/comments on this proposal? I have a > strawman YANG file posted at: > https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit: > patch-4 I think you need determine if this is a *TCG TPM* yang module, or if it is intended to accomodate other technologies. They might be essentially proprietary, but for this interface, makes them interoperate. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8zKT0ACgkQgItw+93Q 3WUAGwf/Z+iEpFWUHsYKH/D8SUd6b5mbPk9PyTrqdYBlPa3zxLQRVotZt0R5gy9J pvOwN/iP/booypZI3b//mSVTP+N5U8vnyJKqkYLJhpNWu8gy1+pN5pVx8qX9a8xR cCx4WpW+zF2QN/wmuiQ07LyLmJps6Km9gpCYgLiuWrZCElCff6a5VAbLWnSFV2DV iV5joszzhtrQkn0kUDoBBA9zETaSuF3FnDmzBtSx0X+1dv+6W2EXf4/vFZfcIBf2 CGb5mO5/RasJfxP/1J+YYvO3mlYCqTMM976fb5CPDKePNv0qwxIoXB2qksUWaAyi nXxI0H7b8Uv1hjeB+yZ5u9PurI79Hw== =yt9T -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 17:17:42 2020 Return-Path: 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 7780A3A0DE7 for ; Tue, 11 Aug 2020 17:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=FCAArnZ5; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=mulZ57oO 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 sbSLaB_tNGJM for ; Tue, 11 Aug 2020 17:17:38 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E863A0DDF for ; Tue, 11 Aug 2020 17:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8930; q=dns/txt; s=iport; t=1597191458; x=1598401058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wrUvm9qB0VDji8k8ADSU9EHAdA++tSOZb7ageGCaBQM=; b=FCAArnZ5XUEUrzs7UdVGCBMwqxU3WpOu3IWLJO91Uzdw1jfE8HxH/PmB XAIhJUsX2erAHF6E9F6181RKE4z7OMWTMKAlQBIY/exi/PoZ+OFW96hUy YtaE5z/XzOHrlfn+mNA829A4yjdpDcjuzAxHzXqmnapAIa2FPb5XEss0D o=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3Asq/F7RzmvXGKSkPXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaHt+5kilPEWYDS7bRPgrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtOEcDyalnXq3v05jdBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBQDxMzNf/5pdJa1XCRwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgVIjLgdvKy0vLAqHcgONU5hmglMDVQQHAQEBCQMBASU?= =?us-ascii?q?IAgQBAYFWgnYCgjMCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwESLgE?= =?us-ascii?q?BNwEECwIBCBUDLgIwJQEBBA4FCAYMCIMFgX5NAw4RDwEOp0gCgTmIYXSBNIM?= =?us-ascii?q?BAQEFgTMBAwSDWBiCBwcDBoE4gVOBHohcgUMagUE/gRFDgh8uPoJcAgKBMS6?= =?us-ascii?q?DSIItj2CLP5sNCoJihDiCXIFPkVegFZxslHcCBAIEBQIOAQEFgWojgVdwFTu?= =?us-ascii?q?CaVAXAg2OHwwXg06FFIVCdAI1AgYIAQEDCXyPFgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,302,1592870400"; d="p7s'?scan'208";a="525298048" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 00:17:37 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07C0Hbrt031895 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 00:17:37 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 19:17:37 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 19:17:36 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 11 Aug 2020 19:17:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hNqhLcBWoZoi1uhQJwLuueyvYrxNNUbKlfcQvg6slvv2TlRqhe5UTGfwAoWYxWoB1r9YtHaQ+1UvHP9ej/eO1rzaJkKSZSPt6bS6vLj10N8KAAPQino6X6CiqvCp3sLOczFvs3kjc7qF8Ex06tj8l3gJiRBsRci1lVqjaJX6JLWmJIduq72oRWPPT1dx1l7LQcNyG1LEGqDzJc/DRTDSNi4fNXnXb/zLrddoKQ/QW9Nhmpm7RWhrzXYkbd33GpIIRjPjbfiFLXZLngPBUi+o5fssCLx5WUqwPU1i4CGhJA6B5uRbNSBj6KNGWwnHKbkZTF4/nahdd8s/N2nO4b7OfA== 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=PpM6P5ZNphy7O6nxDpA8abTCIhj7JNNZIgfllM6xreY=; b=Ir5SXMclZdTg2G1sSJqtB3srwHmgL8ofowIVwsJNWhsGMmbKzjnk1EAi86oCo2U52bD8TNu/qgGT7wCx9dm7c29DJQualeNYCrmwUU+f7BlWd8ZcrAxDTKrRKMq0cdE44GYk1sxkTQLw/Ez4cgwqNJUe4iassGgWDwV3wBQOkOlazjQpjtBw4qdQUee8jtoH/gWvat/IMj1Pw/MEouEVehzRnRFUzXON9CtD61h3ss33RUx3aQhDiGagjpZqTgid5Z/cofn2B5JhiQR/AOMj4CSyn/T5cjd+BgPRbpURDcvAlTxiCV+5h4KcHJYdmjsXJ0P+mC6jE4TJO2NpjFPXWQ== 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=PpM6P5ZNphy7O6nxDpA8abTCIhj7JNNZIgfllM6xreY=; b=mulZ57oOlFvIk+59/+hVjNI4WiR16spk/Y9UjNDl2Xwe/MLkOqcpB/RyS9OPoYnFrwitNoltP9XJAX821fBT990uTWIrjuhy1C0ohXJfQfVdKxGx7qL6eev4Lwf+zhwQ0XJqqm4+YeMxT5N3B7VKtLMZ/kWDi/fft8YYMONTX8I= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3220.namprd11.prod.outlook.com (2603:10b6:208:2f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Wed, 12 Aug 2020 00:17:35 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3261.025; Wed, 12 Aug 2020 00:17:35 +0000 From: "Eric Voit (evoit)" To: Michael Richardson CC: "rats@ietf.org" Thread-Topic: [Rats] Which Asymmetric algorithms for Charra? Thread-Index: AdZwFfR0sMtRnzzORw2twimiOLxijgAIPDCAAAFHS/A= Date: Wed, 12 Aug 2020 00:17:35 +0000 Message-ID: References: <9899.1597188413@localhost> In-Reply-To: <9899.1597188413@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45ca42cd-6088-448b-fb22-08d83e551d3d x-ms-traffictypediagnostic: BL0PR11MB3220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5IMdLnsAZTKTDuAWozDXq3ecUl2JaKYjot+D+u9lWOAxSUH5lovoiNQKGjn/e/YXxsSc/kUe7DxAljacSJAv/8xZW4pg6NjPKiocd/uxZa+gHuxub1T30LD/Qyzi44+ad9KLZazT6TakLLdsJqcetAYus9FzYbkHQKl3FNK+aB7M0jt2dXy934BjVWCHrLfG+XT5rnNz9BOAOTxnEUZG3oEnAAATNbyk29yjKZAD9Mqy4eqBgoLK/qk5nhEB3i5svnwbzr91GGxDvXhpxPdkoOVYiK9xRigCcTe12sjcyDJkf5C4BcKl1IkhpCsBvP7FQMwCFT0YvjgV+MXU8nAFiVtqIU+Io3/8wR5+MdSkNFjHElG9RPQuFMbfovyM6BynRMYBRsd4g/hHsj3k/8tgYA== 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; SFTY:; SFS:(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(2906002)(5660300002)(9686003)(8676002)(8936002)(4326008)(86362001)(52536014)(55016002)(316002)(478600001)(64756008)(66946007)(33656002)(66446008)(76116006)(966005)(99936003)(7696005)(186003)(26005)(66476007)(71200400001)(6506007)(66616009)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mgptWeId98tBxXz/UYZJhNbpSAjznhpIaUomO77zKJGbYhAWflxIcYTm0Z0Q7ZsLNQQGbm64tKn/+B9qlw0o62QPQH3/6NEs+yMcnc3CzdxAzuIWiHTRIR/tQ3AvfbwVqjtlggcxUgkBqYwZ100XO0IdwyKqpnAGjpRtpsJrpZdK1jBmF1m2Fwhe8fO5Q5mbQnWGIqqWvOnFQi6/Hh9hU+7IR/Ku+DMqWv8PINxDBSCk1/o41Gm8qLQ9nQFNkA608R4gB/YYEh/0JIVmjhFn8ZZex+7DcKXad6Ci+kx4FZYPTt0VVYaG9gZVoa1l6Y27bJWuUYe2KuGEbDdCkPJjlqNs0Nfw+hs7KF39RpQaZpomA1Pqq9DmMKmRmL+Gmos1mbf6XJxy5a2HUEx6/WL7Ths58PutbTESVKz1ISv7Dq9TSFuFy4SyyrMqr0H/l0c9k1LvDgbgyAOnklg6Nvo/nm0b3pd1aZLPQmWlv9c1+ONn8tQZYX21I399C9wTVbA4K2T9pBtxs/fRziAyDgD/6RknWTeVwjbO/KxqOpbAK1V1hmD6q7XE1kXOJ7jBP0tYeyPeSAJ+1rxdq0M5Qb44owYhluG3uo0kSNnQUpMjh63TNrHvG5NbxzSOeTwPOZAXKT9ojFJzbABJwCAPq8tP3A== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008F_01D6701C.71FC3E80" 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: 45ca42cd-6088-448b-fb22-08d83e551d3d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 00:17:35.4439 (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: me2IER4o+kq4AMjiCI2SWf+s5WNSpirVSAVIL4MhcsHaj4Db9VLOhQymdjlrdebt X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3220 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Rats] Which Asymmetric algorithms for Charra? X-BeenThere: rats@ietf.org 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 00:17:41 -0000 ------=_NextPart_000_008F_01D6701C.71FC3E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Michael, > From: Michael Richardson, August 11, 2020 7:27 PM > > Eric Voit \(evoit\) wrote: > > 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?" > > You are asking about *asymmetric* algoritms. > I'd like to see EdDSA in the list, and I suspect that they aren't in the TPM spec. The intent of charra is to be TPM specific. So for charra it seems to make sense to only include only asymmetric algorithms which can be served from TPM chips. I.e., Non TCG algorithms don't seem standardizable for this role. The good news is that the proposed model has been structured to allow the addition of new algorithms by TCG or other non-standard entities who wish to take on new algorithms. This can be done by simply defining a new algorithm which imports and extends the YANG identity set currently defined. > > This is reflected seen in > > https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra- > upd > > ate-00, Slide 7. > > And that slide shows them missing. > > > 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. > > You also write: > 2. Identities instead of strings for TCG and IETF crypto algorithm types. > Strings allow lots of errors to be introduced. (Question #1) > > the otherside if you don't use strings is you use an enum, which is not an IANA > registry. So you need an integer with an IANA registry. I initially had used ENUMs. But ENUMs in YANG are hard to extend with new values, this is why I moved to YANG identities. Otherwise than that identities should effectively give the same result as YANG models are registered with IANA. > > * 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) > > Good. > > > Are there any objections/questions/comments on this proposal? I have a > > strawman YANG file posted at: > > > https://github.com/ietf-rats-wg/basic-yang- > module/compare/master...ericvoit: > > patch-4 > > I think you need determine if this is a *TCG TPM* yang module, or if it is > intended to accomodate other technologies. They might be essentially > proprietary, but for this interface, makes them interoperate. Exactly. During IETF 108, the file integrated TCG and IETF values. Since TPMs can't really handle IETF values, I rescoped and renamed to be only TCG algs (i.e., "ietf-tcg-algs.yang") in this proposal. Eric > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- ------=_NextPart_000_008F_01D6701C.71FC3E80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEyMDAxNzMyWjAjBgkqhkiG 9w0BCQQxFgQUHcxCQmsS/LuLGaJc4uAP5SvHtdowSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQB4JmChcV42KEj2ldWYxLrWm0bmRGdT4dXczKMtzPq2NXUjmWTSiK0CLi7hRFskMT3N P5nwMXC4x1HWCu7PYFclWFA3U5XPo0OzLiAR694Q2Im4HWYLn7/okcMJNqTkzFa17KVWG2h8TuKc cSwbP9bWGUtA2wC/Q5yQEk//ChPq27aNSGzd8fCxwnfzgGftlAhXxPiAl3/S5QKxmbKZdUTy4SF6 189bSY/kig83Le48gejSQigTxs5jKyzizk2fc73pEi1BshFMjlGYzwPdC2X9gwW3L0p1an6pms1G ftk+oEiArIo+m+c6icpuk2jhcou90F1PEaC7EKbf6wUNQj1SAAAAAAAA ------=_NextPart_000_008F_01D6701C.71FC3E80-- From nobody Wed Aug 12 00:58:51 2020 Return-Path: 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 A9F533A0D91 for ; Wed, 12 Aug 2020 00:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ4omO94SyBO for ; Wed, 12 Aug 2020 00:58:49 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26673A0D90 for ; Wed, 12 Aug 2020 00:58:48 -0700 (PDT) Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7902969B22A60E750FA7 for ; Wed, 12 Aug 2020 08:58:46 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml728-chm.china.huawei.com (10.201.108.79) 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 nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) 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 nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 12 Aug 2020 15:58:43 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" 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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] 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-BeenThere: rats@ietf.org 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 --_000_d323dbd7a24c46f0bb5074f7aad4903dhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 na= med with key length as a suffix, it also defines the ID values for the diff= erent curves used for elliptic curve cryptography. But it seems like that t= he TCG_Algorithm_Registry_r1p32_pub doesn't specify the key length of the R= SA algorithm. So do we need to define fine-granular RSA algorithms in the Y= ANG module? Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, August 12, 2020 6:52 AM To: rats@ietf.org Subject: [Rats] Which Asymmetric algorithms for Charra? During the charra presentation at IETF 108, we said we were going to ask th= e following question to the list: "Should the algorithm set defined in YANG= be reduced to just those asymmetric algorithms currently exposed in the cu= rrent TPM 1.2 and 2 specifications?" This is reflected seen in https://www.ietf.org/proceedings/108/slides/slide= s-108-rats-sessb-charra-update-00, Slide 7. The proposal I would like to make is as follows: * The TCG tracked algorithms supportable by a TPM should be the only on= es 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 https://trustedcomp= utinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf con= tains the algorithms we should encode. * There are other types of information within this table, and we mig= ht as well encode the full table within a YANG model. That way we can exp= licitly make the scope of a "ietf-tcg-algs.yang" model the contents this TC= G table encoded in YANG. * The YANG model will indicate what TCG algorithms are deprecated by th= e IETF. However identities for these deprecated algorithms from the TCG ta= ble will be assigned. (e.g., SHA-1) Are there any objections/questions/comments on this proposal? I have a s= trawman YANG file posted at: https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit= :patch-4 Henk also is thinking of encoding this same Table information within CDDL. = That could be inserted as an additional informational element of the docum= ent for where people prefer CDDL. Eric Eric Voit Principal Engineer .:|:.:|:. Cisco Systems, Inc. --_000_d323dbd7a24c46f0bb5074f7aad4903dhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Generally, I’m fine with your propos= al. I have only one question below.

 

The TCG_Algorithm_Registry_r1p32_pub defin= es a variety of SHA algorithms named with key length as a suffix, it also d= efines 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 algorith= m. So do we need to define fine-granular RSA algorithms in the YANG module?=

 

Regards & T= hanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
To: rats@ietf.org
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 lis= t: "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 https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-up= date-00, Slide 7.

 

The proposal I would like to ma= ke 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.
--_000_d323dbd7a24c46f0bb5074f7aad4903dhuaweicom_-- From nobody Wed Aug 12 12:20:38 2020 Return-Path: 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 CE19A3A07F9 for ; Wed, 12 Aug 2020 12:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, 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=fjMWCwkx; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=v9fsyROM 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 mN-VWElpdGOZ for ; Wed, 12 Aug 2020 12:20:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24013A07F5 for ; Wed, 12 Aug 2020 12:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34622; q=dns/txt; s=iport; t=1597260034; x=1598469634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kWpoZcijlqGlkLtm+t8lQSBy0J6Fvk12traXOuDPhAE=; b=fjMWCwkxh7oi3D2K6IH+S/YIvNCibxJX+0UJShwqetcXlwo3bduBbRzb HjcYd+5OFnxG4ekyikp1bipBZsbJBL6opXvtrffn92k/T3gO8pf2DtEFD O9mCIDPnKSTRtic3sLIcfIFyftSK6MndPAy+yr7Qo3FOe8IZXgJPargjT M=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AlK4gJh0wgjJ4kNFusmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9CACcPzRf/49dJa1WCR0BAQEBCQE?= =?us-ascii?q?SAQUFAUCBSoEjL1EHbystLywKh3IDixCCRYddjiKCZ4JTA1UEBwEBAQkDAQE?= =?us-ascii?q?lCAIEAQGETAKCNgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQECAhIbEwE?= =?us-ascii?q?BNwEPAgEIEQQBASEBBgcCMBQJCAEBBA4FCAYUgwU4gUZNAx8PAQ6nOgKBOYh?= =?us-ascii?q?hdIE0gwEBAQWBMwEDAgJKA4MSGIIHBwMGgTiBU4Eeih8agUE/gRFDgk0+gXl?= =?us-ascii?q?BIgIBgTIuKwmDFIItmgaBGZsNCoJihDiCXIFPkVeCfp0XlBuIUZR3AgQCBAU?= =?us-ascii?q?CDgEBBYFqI4FXcBU7gmlQFwINjh8MF4NOhRSFQnQSAiMCBggBAQMJfI5cAYE?= =?us-ascii?q?QAQE?= X-IronPort-AV: E=Sophos;i="5.76,305,1592870400"; d="p7s'?scan'208,217";a="792558057" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 19:20:32 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07CJKVY7030388 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 19:20:31 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 14:20:31 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 14:20:30 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 12 Aug 2020 15:20:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ibVZwAOxddyxWc/RqZmUIyV5OgXuSAshXQs4KRpOdMyOLUE4yrp4+lKA8eYpC+JvN/VQYP6syArahmuXy6blGc0g2UkPs0L4063qcH+BdSni45FUL23BdMN4SHSDN7d20h+x/6FgOUoueBXmtC8yHdFL/P4Bv2/KeZUiaA8f+/O+PzpmdsevS/GBuhRWOqIeAIYJBQV98dYAcSAtrEYupdG+yORaTGG53RvvAbvsCQvcToX0Tc35SzAzfE52hJzU08iCgP98oXuBT6aLE9Z2Yv8koe5pNyWi+0pLeyplF2zUN5n56d1e2Hmz95IRNWwrd2tK1zs3vSKQHiw01PpGSQ== 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=PQn++2j17nAWzxBCKrsumvu1ZwlmLtdYpdnOE5zq4G4=; b=dkLGCdvvBO+3WPFpNVaAmPEYXMjCM6nKj1BeBUcg9h3dyEiCo2hMPBcBSXHo+8+7KD8bPOCwE0lEk0X/1sMs0R/b0cDRFSxkMn4cGNXzUwe5T0ZYL+xHa1Q4sMbpHvDc7h/eaeDv/UCCaTqtdC6P5TozTyDk7j0pLdJcI+073X5wCSq5nCy60FrzciEd4DvgB9Y/6SUJBThtbss3Y8EAWO2XtKHidTXQcWcgjyhsdzEYM/kLaHkLA+32cn/6CtjjKAS09px8PcCI19KLtKbNjOMcjb7au853gO8BKql0BngAdqwKZmSzJIeC7ehmX2Y2HL3sGZqE8oTPcuSS8pQTsQ== 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=PQn++2j17nAWzxBCKrsumvu1ZwlmLtdYpdnOE5zq4G4=; b=v9fsyROM2l5SNuoR8aqWcegb+9DfVuqWn8azc04f+Nack9w2MieRdHMqw3u1/nUnfdSJXsR8tW4Gj3PMDW9CcdJsiEKdcNDZ5bUqnUlp5BCljrsbsE2A0uRMIeDG8fYdtedDAXXk7TndcgmTwSxKEqFRj7vA9YCmvM0XA57kHVk= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4174.namprd11.prod.outlook.com (2603:10b6:208:154::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Wed, 12 Aug 2020 19:20:28 +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; Wed, 12 Aug 2020 19:20:28 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" CC: "rats@ietf.org" Thread-Topic: Which Asymmetric algorithms for Charra? Thread-Index: AdZwFfR0sMtRnzzORw2twimiOLxijgAX+PawABmh0rA= Date: Wed, 12 Aug 2020 19:20:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 406ccc19-6a10-40e4-a021-08d83ef4c5f1 x-ms-traffictypediagnostic: MN2PR11MB4174: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WsVZ2w+yInp7anTgDOxrJu8EvcbUx3A54tJIjpEHawzoSZgIP/cfIWd0gIfIRHWPwxUsuyL6Xs4ZUa6fQg9kqJh2M8oXrtOAimB4IYv3A+EPjBUGxFCbHxD+rwXxGdL8EQ3q8cegHwMOlxRAsuKj99gMlI2g/ik4Ut2zVa7pqec0tTqDmd53o1oE3dy+r7a+uxAtssnA2+z4K27VUVewVgADyL1hUwfPRsr+D86wlogKY/BH2RglOrN/O7rA1/2iC85r8sU+XfZU1Qcj2nlHk82nwsNah+ydii6u7+3+6Nk/X9zMn4atZE2HI9pGPKZtoj5/3q56qs127cSpviABVrsSEKBx15+biDWAt2d2nr+btH+AGngEEQAjwqnF0ocb4W2BHS4UmSC6iZhz1FF3NPf7ibq/crc1T9vQmkTo1i1/OfcumoCpFqN12atuvT73w+MqSw/K6/xGsQreGhSY6g== 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; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(136003)(396003)(376002)(478600001)(33656002)(966005)(4326008)(86362001)(6506007)(316002)(26005)(2906002)(53546011)(8676002)(7696005)(6916009)(55016002)(9686003)(186003)(83380400001)(5660300002)(66446008)(66476007)(66616009)(76116006)(71200400001)(99936003)(64756008)(66556008)(166002)(8936002)(52536014)(66946007)(15398625002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JFIEpugX/iDRp4cR3F1D2ZClCa7TiQwU7L1U+uSEnwGj2ABjbzSHiMsmkjaLVwk7ff8GwGs7yDkZ7QzdlIArc/fFyPkXVvgEgp0R8QUvF8qYIx7Mrpt/Joj4oryE34n2dpofdQnvcy9jIZ3lHdd8Nrs25HxgVn9G4DNbgyPjBr5j1eh9CZjBUOLvtfxyOUhOPv3LCZE/G9BgWA8p9C3QnB8HK2qWy2TPkJfFit/6bcI1EnGf3QLyvPzP3XghF9KwZzcbVDJwjJE1ip4QBGBuyEdxB0YQaCX65J2Oizk9nQzJnX9BzGOWGS4S2+IlWnWVHwwwE0SYWLpV6Zuu16FbmFmLKblgPSG0pnQmKfIuzfYqxpmCOtby0AdjpFaqktXIiSltVYoDajp5T1mHBFhewHvCjJYCKHLEsmD3hr0mySziigqhoL5MJtMIbP4xTc5U5aA8VvXgVAS5x85QabSk6L3V8oCtTzBelGUkrhwhbqE51mF8Ls7kqAR9oh1yjjuY06cavd9128/6HuakNHKXW0czluqShYk0OwEstxftAtOcPGOAMiPlji4gb56KN5+/y0S0q+RCR49dS6vP3uTccPN+BS1KQviY5nTatc6mDFPoDb3aT3rZh1XjCXOUqM4U8OpcMV7O/dSUBFVwABDvEA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0169_01D670BC.18F28D80" 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: 406ccc19-6a10-40e4-a021-08d83ef4c5f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 19:20:28.6115 (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: TMsPWxV1bG9F+1YEU3VTCB+iA2E6aC8yBOzcTtWFcYty4/ONVOeQt0bAwuQWoSaf X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4174 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Rats] Which Asymmetric algorithms for Charra? X-BeenThere: rats@ietf.org 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 19:20:37 -0000 ------=_NextPart_000_0169_01D670BC.18F28D80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_016A_01D670BC.18F28D80" ------=_NextPart_001_016A_01D670BC.18F28D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, I don't think we need to define a key length for RSA. * None of our RPCs are involved with generating a new key. And we can always discover the length of the key by referencing the information from the keystore using known information (e.g., the certificate-name). * Looking at the various SHA algorithms, they are actually different algorithms (since they produce different digest sizes). * If we just match to what is in the TCG spec, we don't have to define/defend a different scoping than they have already made. Thanks, Eric From: RATS On Behalf Of Panwei (William) Sent: Wednesday, August 12, 2020 3:59 AM To: Eric Voit (evoit) Cc: rats@ietf.org Subject: Re: [Rats] Which Asymmetric algorithms for Charra? 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 [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, August 12, 2020 6:52 AM To: rats@ietf.org 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 https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-upd ate-00, 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 https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry _r1p32_pub.pdf 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: https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit: patch-4 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 Eric Voit Principal Engineer .:|:.:|:. Cisco Systems, Inc. ------=_NextPart_001_016A_01D670BC.18F28D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wei Pan,

 

I don't = think we need to define a key length for RSA. 

  • None of our RPCs are = involved with generating a new key.  And we can always discover the = length of the key by referencing the information from the keystore using = known information (e.g., the certificate-name).
  • Looking at the various SHA algorithms, they are actually different = algorithms (since they produce different digest = sizes).
  • If we just match to = what is in the TCG spec, we don't have to define/defend a different = scoping than they have already made.

 

Thanks,

Eric

 

From: RATS = <rats-bounces@ietf.org> On Behalf Of Panwei = (William)
Sent: Wednesday, August 12, 2020 3:59 = AM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: = rats@ietf.org
Subject: Re: [Rats] Which Asymmetric algorithms = for Charra?

 

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 [mailto:rats-bounces@ietf.org] = On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August = 12, 2020 6:52 AM
To: rats@ietf.org
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 https://www.ietf.org/proceedings/108/slides/slides-108= -rats-sessb-charra-update-00, 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.
    • 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:

https://github.com/ietf-rats-wg/basic-yang-module/co= mpare/master...ericvoit:patch-4

 

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

 

Eric Voit =

Principal = Engineer

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

 

------=_NextPart_001_016A_01D670BC.18F28D80-- ------=_NextPart_000_0169_01D670BC.18F28D80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEyMTkyMDIyWjAjBgkqhkiG 9w0BCQQxFgQU7mtxetSEIWGqtyUIxnAoyiGeUaYwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBgLOIGVp90gd/jnbMakzFivPPykMDPHzozUFB/iNyZDDWCHWriorOmiEFMwOPriFlr 3F4MTu6bOo9w3B58xto7qMXBRMAQSy0X8AFyCpFac0BZGKsagXC7OeNptJYx2qgktimUTA1cfNqr Q/MT1GZdtHB2rihrlIhq8QTsxjz3bKlXTBjmoPrDP+L6kgQEoUfWqfooUK/Tko8VZleu1sLE1H0o 5mUDcI0lZ6x73aou5zv+G5ahVgR13vdfiOb18GmSRGyYyScTq/r2/x6590DwymG4Rp+ykA5d0UaL GmiDHQzseMBTpiQ4/7Cctd8wOcyaixe4I44jXGUBDadtv+ezAAAAAAAA ------=_NextPart_000_0169_01D670BC.18F28D80-- From nobody Wed Aug 12 12:57:24 2020 Return-Path: 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 5040E3A0863 for ; Wed, 12 Aug 2020 12:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JJeG9B5j; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=eQjg4OT7 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 N3_IzvkwMFqS for ; Wed, 12 Aug 2020 12:57:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374113A0593 for ; Wed, 12 Aug 2020 12:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13518; q=dns/txt; s=iport; t=1597262240; x=1598471840; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=I5AefPN5pgYoC9QfGJvdRnpEosCLF0g3JtbiR0t2MEA=; b=JJeG9B5jo5PYWPv+AQc0L4ZQcLvaDlr+8pm2yKBJiET26xNmJUbrmjYo mHjPAnS+ZCFQzi4QrgroXe4ljDf8oe6x9ur5q73fOm0sSWduA5LToR/MG 4cG+nQVB4Vg+Encmq4Kf+lsF5cOmUmK+hqISfYn4L/QP2aZgAoqC2zv0m c=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3ArE3wCB9cLAc51P9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN5PNxgVuPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC9LUVRXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAACqSDRf/5xdJa1fGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCoFSKSgHbystLywKhCyDRgONV5h?= =?us-ascii?q?mglMDVQQHAQEBCQMBARgNCAIEAQGBbYJfAoI2AiQ4EwIDAQELAQEFAQEBAgE?= =?us-ascii?q?GBG2FXAyFcQEBAQMBAQEQER0BASwLAQQHBAIBBgIRBAEBAQwBHQICAiULHQg?= =?us-ascii?q?BAQQBDQUIBhSCOUYEAoF+TQMOEQ8BDpZLkGgCgTmIYXaBMoMBAQEFhSMDFYI?= =?us-ascii?q?HBwmBOAGBUoEehhqDdg8agUE/gRFDgk0+glwBAQIBFoFIFSeCWTOCLY9zihO?= =?us-ascii?q?bHoEICoJihDiCXIFPkVeCfoEjiDaTPoVXjFifNAIEAgQFAg4BAQWBaiMNgUp?= =?us-ascii?q?wFRohgmkJRxcCDY4fg3GFFIVCdAIBATMCBgEHAQEDCXyOXAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,305,1592870400"; d="p7s'?scan'208";a="525762150" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 19:57:19 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 07CJvIlh013635 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 19:57:19 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 14:57:18 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 15:57:17 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 12 Aug 2020 15:57:17 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D1Z6qT61jaNjaoIfgVQEwo5CgDYZheP890Zsbf+M+/03aDXVS9+li4p9wgFF7BADHRsa6ZoVEZ/0qqx4GoYvx6Avo+2p+oex/UuaHxGOdQPPJIKjVY5xdsVZ9O6JtrozptR74Bjgtz5RbokT0E55cFY0Cz5MGsgtUrgotcAn/tfgUxrWcoMDz/96t5dppRSM69KYXUgeK2Yc34hOYKYicxaKaTKY7o1HJVhbkfIwOswY+QBmQMUOlKSOYTMGrF91ew+XoMXgmnMe6dQh52ai4j/mxhgqlS8FcH4dBx6yXQ6Y0Dd9MzgNFF3a5JdvzeUqwktCVAjkFVx6DVZR+wMZyw== 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=/m0TnyEjPwy4ii5AE81d7qgdBOYyBBDsATo6ncohyjg=; b=OSGG/6Fb3hm8lD6T1GBPnQU4niHN6FvtYZhx1FuiRrBk7vAj8s0GKbZhv/GnzTgamXAf9xdfeYUuAbd4KhWVshpnKdTQrnPr8BdBb3e0OicUCQa5BE5IAjthMub/8rQW3sOmzs4JkraK1FNhQywsxhYJs3nzYaSUBObFVQVKLmHzs9txIkIhmui8sPR+4bM5K0ILmV3Ynw7wH1tH1c8y8mDqFnBpoCj7AdcQLMogfdprsyvQYyV2ljrZ1Q+bHJS00K4V1IXUEh3MBPemaqWa7nxInsxpL2SQqu4sZczSwBEhNQbFY5snGh+HcE9ciWNapKy6tZmU3b1ZUMKVYob3nA== 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=/m0TnyEjPwy4ii5AE81d7qgdBOYyBBDsATo6ncohyjg=; b=eQjg4OT7qhV+XHD+OLpkkSEEJD8vPxPaFJqQ3iyKk1oz+PQiY7SjzD/+SuNEh40g4xEzmmhKtlMiYxoLPWxB4kxI6k1GsSVInErSyD/dq/j+d4RQ+L5ocp5gXJKEr2T8YlZORQdpbh4tM1MfXp3oAlKAJ5QY7vkKeq8SDBst3c8= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3218.namprd11.prod.outlook.com (2603:10b6:208:60::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Wed, 12 Aug 2020 19:57:16 +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; Wed, 12 Aug 2020 19:57:16 +0000 From: "Eric Voit (evoit)" To: "Smith, Ned" , Henk Birkholz , Dave Thaler , "Eric Voit (evoit)" , "rats@ietf.org" CC: Wei Pan Thread-Topic: [Rats] draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gao8ZEPAAE4nYACybsMUA== Date: Wed, 12 Aug 2020 19:57:16 +0000 Message-ID: References: <0428729f-5754-8b19-6bbf-378aa123c799@sit.fraunhofer.de> <140611B6-9060-47A8-957F-3D4E8E7BFACD@intel.com> In-Reply-To: <140611B6-9060-47A8-957F-3D4E8E7BFACD@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b981e6c4-1bba-4ad3-6678-08d83ef9ea11 x-ms-traffictypediagnostic: BL0PR11MB3218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4+LLazHIkqQGeAscULrU7pXKcCO3fR8wcdlz0dhbvvpZZpB6WaXLvyaUUQk3q/RQByhqGp71YKpXfJKRKNR8xdyyYX07AbRSjYVU5wrrOyNPAYsArLpqqjnNdy9vVCk7bxJuQsNlAdRGeMOo/i/tAvjDaqwWiiXtn4domtBepNaOKte9OuHArF+CG5245ZS32b1C8vTlZAfVPE5prnNXm0TkuXg1rdG9R5yOxcuvtO1LSNuNRuUhpICHiRCGx4S6MtUlYc4bue/IICwN7llJDo1fee+snZCR69TIY8DRm1QCloG9LEQixHCbFhs5fGIFtkXhukxKx+wlHYi2KL+QzGg7swlcpvO5rF5sU/zKe4jjQLo/bvipOgGf1uPI2hvKgDIjrDAfMj3ikDKlnM3Fag== 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; SFTY:; SFS:(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(966005)(5660300002)(110136005)(99936003)(186003)(86362001)(76116006)(71200400001)(66946007)(66616009)(33656002)(26005)(83380400001)(478600001)(9686003)(316002)(66556008)(45080400002)(8936002)(55016002)(7696005)(66446008)(4326008)(64756008)(2906002)(52536014)(83080400001)(53546011)(6506007)(66476007)(66574015)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +PQaG+WPzUxi6dLocc1FV+SGpYQxZ9CYi9O7DZVUaXxSLOECq/fu+L7cIkt3Ltip/xj4vRkcvhbm0Apo3ohzYqdvllWkGilI6BMyUFZ4aEG+ihWyrGcJT2mGnwXf5Ej24G7f+m0+Qk1I9iMGSzcz27YUJzi63MaJHh9nfKuYY/nfmjCybZU2dEqpIHa+ikypodWonwFdak8mk8m8d9JHByKuf/T3p3gpd4REqSKjPmnsA+fE2GXSE25ZRp+vA8EPagCfk1jPgx1jb+f8gEWTvdv7CNENRTe5QPw3H0LcGj5neyLTMNnIhxa86Rx3USjlFQZB4qR7HgrBZgLYWmJgpzcky+yPaZtFmwQ9RDfACUbV/XvILk0/30hlZmDco79Wo4eHJiJFmbE7rJ5BiypX8sw2fGZ3q4hfuKs8Xud/rRpESEqly0Zxr+YjdsR7YRxwaEaf473Eur6Sj1UZVqg7hDEQXyucC+bKG8RfGmmnuv1Q6EQ71xu/X0jNlYYeCR3GahZK2n6M4SwWsj50/oekvRcid5F1yjJ1584B423+D3xWjGYR5z5vEk13fyafsrF8Bg72qmVHJEdsdy3G1gJA2it03Y+iVItkWdFvGOPEidnfCwfzojGxcKohtDvm9gfR9PFGF8/gUz4zN2CVyTWlYw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0171_01D670C1.3EB35EF0" 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: b981e6c4-1bba-4ad3-6678-08d83ef9ea11 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 19:57:16.6879 (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: MDZk0rv053DxvX+6qD+KUKylrtmzIlVbXhCDuLUpqYkAwfy29XutYjaSNf+GWTOm X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3218 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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 19:57:23 -0000 ------=_NextPart_000_0171_01D670C1.3EB35EF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ned, > From: Smith, Ned, July 28, 2020 10:54 AM >=20 > Subscription models could be topic based rather than entity based. The = use case > below suggests that a Verifier is interested in system booting events. = A topic- > based approach might allow Verifiers to subscribe to "boot image X" as = the > topic. All entities that collect a Claim for "image X" would publish = the Claim to > the field of subscribers. >=20 > Is the use of YANG to describe pub/sub limiting the ability to do = topic-based > pub/sub? There shouldn't be any limitations inherent in doing topic-based = pub/sub. In fact, the current draft does allow for a number of = pre-packaged topics as part of the event stream, as long as they are PCR = based. For example, - a Verifier can subscribe to all 'extend' and 'quote' operations for a = set of PCRs (such as PCRs 0-8). As pre-defined set of PCRs could be = considered a micro-topic. - based on the subscription parameters requested, the Attester can = filter out information for PCRs which you don't care about. =20 One thing that isn't currently supported are stateful filters. I.e., if = from one event you glean that you are not running "boot image X" then = throw away all subsequent events. It is not the YANG model which = prevents this, it is that a stateful event filtering language would need = to be defined. Alternatively, you could always define a new stream called "boot image = X" and let people subscribe to that. RFC8639 encourages the definition = of new event streams for purposes like this. Eric > -Ned >=20 > =EF=BB=BFOn 7/28/20, 7:19 AM, "RATS on behalf of Henk Birkholz" bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote: >=20 > Hi Dave, >=20 > a clarifying question: >=20 > What exactly do you mean by the "who" in "a subscriber knows who = to > subscribe to"? >=20 > The I-D does not come with its own join/rendezvous/discovery = capability. > That either comes related with YANG Push ("call home"). That would = be a > "who" on the entity level. >=20 > Another possibility is that you mean a YANG RPC with the "who"? = That > would be a "who" on the management interface level. >=20 > Or you could mean one of the Attesting Environment of a composite > Attester. Tha would be a "who" on the Attester level. And that is = done > via the included data store. >=20 > Or do you mean something I am missing here? >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 > On 28.07.20 16:10, Dave Thaler wrote: > > I asked in the meeting how a subscriber knows who to subscribe = to, and I > believe the answer was > > that CHARRA answers that. Well I looked in = draft-ietf-rats-yang-tpm- > charra-02 and it does not > > contain any mention of the subject. I think one or the other of = the two > drafts needs to address > > this issue. My preference is that it be in = draft-birkholz-rats-network-device- > subscription since > > that's the draft that talks about limitations like > >> Evidence is not streamed to an interested Verifier as soon as = it is > generated. > > Which certainly still applies, it's just another case... you = didn't know to > subscribe to it until > > after the evidence was generated when it booted. > > > > Dave > > > > -----Original Message----- > > From: RATS On Behalf Of Eric Voit = (evoit) > > Sent: Wednesday, June 24, 2020 9:41 AM > > To: rats@ietf.org > > Cc: Wei Pan ; Birkholz, Henk > > > Subject: [Rats] = draft-birkholz-rats-network-device-subscription-00 > > > > Hi All, > > > > This draft defines how to subscribe to a stream of attestation = related > Evidence on TPM-based network devices. When subscribed, a Telemetry > stream of verifiably fresh YANG notifications (which are generated = when TPM > PCRs are > > extended) are pushed to the subscriber. > > > > This draft integrates: > > * Section 5 of draft-voit-rats-trusted-path-routing-01 > > * Elements of draft-xia-rats-pubsub-model > > > > Thanks! > > > > Eric, Henk, and Wei > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org > > Sent: Wednesday, June 24, 2020 12:19 PM > > To: Eric Voit (evoit) ; Wei Pan > ; Henk Birkholz > > > Subject: New Version Notification for > > draft-birkholz-rats-network-device-subscription-00.txt > > > > > > A new version of I-D, = draft-birkholz-rats-network-device-subscription- > 00.txt > > has been successfully submitted by Eric Voit and posted to the = IETF > repository. > > > > Name: draft-birkholz-rats-network-device-subscription > > Revision: 00 > > Title: Attestation Event Stream Subscription > > Document date: 2020-06-24 > > Group: Individual Submission > > Pages: 20 > > URL: > > > = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= > = etf.org%2Finternet-drafts%2Fdraft-birkholz-rats-network-device-subscripti= on- > 00.txt&data=3D02%7C01%7Cdthaler%40microsoft.com%7C25825e2a3783 > 449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C > 0%7C637286137029115135&sdata=3DMnEJ5ZwAh4BlTNs09fk0Vr1H39j5N > %2BJdyBQHNJp7BdY%3D&reserved=3D0 > > Status: > > > = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= r > acker.ietf.org%2Fdoc%2Fdraft-birkholz-rats-network-device- > subscription%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7C2582 > 5e2a3783449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47 > %7C1%7C0%7C637286137029115135&sdata=3DqukLQaq17P4ts20nW1L% > 2B2dB9zIM9XB9SRcscFWcOeLw%3D&reserved=3D0 > > Htmlized: > > > = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .i > etf.org%2Fhtml%2Fdraft-birkholz-rats-network-device-subscription- > 00&data=3D02%7C01%7Cdthaler%40microsoft.com%7C25825e2a3783449 > 230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637286137029125095&sdata=3DQ0TfFjrfHZU%2FKFOT3li4JG0QoBa3Vo > %2FkHTp00T6GbZY%3D&reserved=3D0 > > Htmlized: > > > = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= r > acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-birkholz-rats-network-device- > subscription&data=3D02%7C01%7Cdthaler%40microsoft.com%7C25825e2 > a3783449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7 > C1%7C0%7C637286137029125095&sdata=3DRLSvdRTcWX4Gew50X2DL7t > 2pE7N%2FA%2BKWrAVz0NhsbiA%3D&reserved=3D0 > > > > > > Abstract: > > This document defines how to subscribe to a stream of = attestation > > related Evidence on TPM-based network devices. > > > > > > > > > > Please note that it may take a couple of minutes from the time = of > submission until the htmlized version and diff are available at = tools.ietf.org. > > > > The IETF Secretariat > > > > >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats ------=_NextPart_000_0171_01D670C1.3EB35EF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEyMTk1NzEzWjAjBgkqhkiG 9w0BCQQxFgQUhg6ZVJAIsqM6zPFHswyC+HlUKLcwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQA4AG3ksFpFKGek4waKUkvl/qYYVF1qn4DO8U2AIy0f+1KNJ0756W3QeRCYW4e6yiDO c8B8RYGn7i//1UlHfqgsak27KRweNJdPQjVG6aljdQstfGHkxVGgYF1kuFaPZYaAeuyUsdxHphdI Y4f/4geISypKj84mpeb2Sh3B0jslvNISNv5/E0C1NeDirGSbLW5be9ufys6UFNeM1M7k64Xs1wB2 UdPYjLiZKW40OZB1s18Es7UepcIgUHPz37ULV40UU2Ffd7y1kTFoRilluNuD/Lo7vrJtXN2/bAro SxAdMN7Co8dfE6DWCEJnby/X7UzYX0MzMPbrn4RIXKYPjYNkAAAAAAAA ------=_NextPart_000_0171_01D670C1.3EB35EF0-- From nobody Wed Aug 12 13:25:37 2020 Return-Path: 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 3E5C23A0B44 for ; Wed, 12 Aug 2020 13:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=Rpx0Bqwz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FqsqaPfa 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 zB4WW6jgrrzZ for ; Wed, 12 Aug 2020 13:25:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4A63A0B35 for ; Wed, 12 Aug 2020 13:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9397; q=dns/txt; s=iport; t=1597263934; x=1598473534; h=from:to:subject:date:message-id:mime-version; bh=dgB22sKBF4nsl2DLnMylvZBRhc2L0JtXMGjDGOMFWTE=; b=Rpx0BqwzAOTboZPQzfuPMYMttqI05lHMVb/dysig36b1c6gwVoewcp6J wGZv9ZxlUJIvENqr0Hdn7Uq68ILWjBQUQepAI/3o/867ALsi/IESf1gXX 8cYG6nAFDEW+7yXPFbmxqAiZTIsECZTekQqXmcegPNtUabxFvU5YW7pPK w=; IronPort-PHdr: =?us-ascii?q?9a23=3AN4ZHqRzodJguAaHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhCQA8TzRf/49dJa1fg3YvUQdvWC8?= =?us-ascii?q?sCoEjgwmDRgOSe45UhG2BQoERA1ULAQEBDAEBJQgCBAEBD4Q9GYIfAiQ4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBG2FXAELhgoLBh0BATgRAUoCBDAnBDWDBAGBfk0DLgE?= =?us-ascii?q?Opz4CgTmIYXaBMoMBAQEFgUdBQoJcGIIOAwaBOIJxglJLQoZAGoIAgTgchWc?= =?us-ascii?q?CAwGBJgERAgFNgmozgi2Sf4ZhnEwKgmIEiF+RNgMegn6JWZM+kS0Mdoo9kFK?= =?us-ascii?q?EJQIEAgQFAg4BAQWBaiNncHAVOyoBgj5QFwINkhCFFIVCdDcCBgEHAQEDCXy?= =?us-ascii?q?OXAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,305,1592870400"; d="scan'208,217";a="811020064" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 20:25:33 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07CKPXbs027804 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Aug 2020 20:25:33 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 15:25:33 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 16:25:32 -0400 Received: from NAM11-CO1-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; Wed, 12 Aug 2020 16:25:31 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aeazYocAjVQGQpcHykA5cLpQ5FYBSXvKIOOPYZjINRu69d68n75w9SSHp6hEg5rhY+2IY0p2p3Vo/6YWgwq83c7Xva42Nnu4OeBIVA5d8fEDq9YF7WBX/2tAMMCAV2fFbozFq6LUraWIhVPbJj8WG7wTivPgPOFi+iEz9PjiK+PJOXYY2BKVnYqtUttKHTRdYcbVZpcUu2s2Me0Z9RHG4TLNxL+YEuKq0e+zEyvnr6AdZrd3FnJdl3O1j9TmI7VSkJZsi3ksHU93xKdYQ3B9cmVFIhKB8rdydxX8W5HiVm49MNYmolNtJ7GrWiKWGrPiDMcG7I8FwgkY8LU+Voaw7A== 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=dgB22sKBF4nsl2DLnMylvZBRhc2L0JtXMGjDGOMFWTE=; b=ILTD3xh/Yjg0ReanmLGp0T952aHKWRfA5z7xc/bJfQ1TvhfTLNpmchHSXV/3VIQsVte/368+D1yBFtECqJkGT3C/NBvdPVF8s/bI/7wSO8pmB4WSfX5VBP5WMHaimzozTDdjCI1MqsBWqLhkVYXnhYZSvrrGDggWAMT/3xnd0mZXQCcwhT+sfG12kNeg4DRUu+QowsvveJh0+Mt/enk/6ScHZo9ral7eEhXrFl/kiDKNusog2399RN+kaP5l3Gh3CHOy1sqDi4Ntfl7r06U2Y8HKwseiCDVDppPR5ZJeTa60jyGSEIEoVCWjmxjZWJ1lyFX98up3Tms75xlPnmUpFg== 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=dgB22sKBF4nsl2DLnMylvZBRhc2L0JtXMGjDGOMFWTE=; b=FqsqaPfar4WGnZqQN6Sxl/wJ2DpLw50DcmuIasODGa88q0MRA5VbxGzNKica/stIKLo4ARAXomOLxme2kjL/Hx8psJGf6UgxQNDZtzhA5TjkY7juSnzNEpXKhig0+f/k+sbcCKuqkIRyuhlQBzOyjOQ9krquFOn3uLCFOe1ZTrw= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BYAPR11MB3574.namprd11.prod.outlook.com (2603:10b6:a03:b1::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Wed, 12 Aug 2020 20:25:30 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3261.025; Wed, 12 Aug 2020 20:25:30 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "rats@ietf.org" Thread-Topic: Call for adoption of draft-birkholz-rats-reference-interaction-model Thread-Index: AQHWcOa5ocl00PiKFEWQHfz6I5Hx9g== Date: Wed, 12 Aug 2020 20:25:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c0704c5-968f-47ea-3894-08d83efddbd1 x-ms-traffictypediagnostic: BYAPR11MB3574: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q8lm9WyrrW628uVGOOrfvsXQkbffHy8/DyOsy4Tm7U+b391MYF+0NQw+PiDuAGZzMZmtXSth2n7nyroOVHG0iXX/EbSPZq+9tY7McQg94oaFdXXEpeLoH7k262cIHmbpdIwIGeZqaJszBGCr3hHvghQ4GcP0AS0jyrgjpocBd0F3tWcR5zLDgGqxPKrdV+XvRuJJk3B2cNyqsTBVpfmIiffYC28ZY8r/Ghue/nQPXDqwc85gYEIdjTroNceVuD7HUFJ7Z4EA7LhdbffOFTQWSXsqb/JaYJ9fSZEZNdure9o5leFoQ0gKquNFuuu4uIXQgju/tVigfTaZFE2NIHzzcYv6FKHEcmeRYPiNNhFb3lvpHLiIL0KVCUF/tdBnlNrK5+s2V7/VpU1uXBUgwlOAIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(76116006)(6506007)(6486002)(66446008)(64756008)(316002)(66556008)(66946007)(66476007)(966005)(33656002)(83380400001)(6916009)(478600001)(8676002)(8936002)(86362001)(6512007)(36756003)(71200400001)(2616005)(186003)(4743002)(166002)(2906002)(26005)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: go5kuUpQ6l6kaO6uSIrv0bbWDt1pg/arbPacQPWHAAo0sBGKB5HDH8+VIILtVv4xKuw2jxbUrT+IZrQl2WuaGwQ6zp3jywQP0YJ6dEQm8nJ5ysUuL6p5IBxONvaqNkiZzuA1Nk/WNushEDE0SQLQQ+ZUlhZSqtBp61Nuxqh6q0B634wkqEYMBSuOykw84LeSqI1fIdDnr47j13imuaUTkW22dAVs9z1g8EcWoyLmeACLAPtSABNa2KU8YFSGvkkJSn9Y4WFEncjXznZmWk15lwR9LK6F/KJfNvmwOXJO4iHiqbhyetGCeUIoIsIjPtQAx6b2a6fH1c8e7N6MWl4rVjjGxQad6zVr/KRy2HM2LMsdD6pHqtQ0xujD+l+AHRGfS0JODa/NICwGGCDJKB4LgDR6t9cK+4sYxG8o06WLHpDS4mCAfuG5Tie/x8C9Md+7INuKW4Rw81Hjdh4baFfcE3hM3wnxxcVSguSYCG6h9xnunnoK3NGX8wXkFATj2cYnicNVLd9C9i02bfhTzM0+8akgLtdQM5DchSdiB7AlXWEe8FrlbO7ET/LJYOfluiA1KzXG9Ptgc0g7QUUaEu3yKddkXFi3r0xr7OfKZJcOfMQrbDZzeN5I+vc6j7wlouIi037H+AJGrXNj+VHviwvbTw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBDAA23E74BC45C7AA87C303963131CEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c0704c5-968f-47ea-3894-08d83efddbd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 20:25:30.6995 (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: y6UScFDlhN/W1+vpitpCmi9X/zJpo5XzlY8bHUQGFKTIlM7tyJnHVu62WuM1uuxWfSNdMi3VrYRJ+2ZFfO3y7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3574 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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 20:25:36 -0000 --_000_DBDAA23E74BC45C7AA87C303963131CEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUkFUcyBtZW1iZXJzLA0KQXQgb3VyIElFVEYgMTA4IHNlc3Npb24gd2UgZGlzY3Vzc2Vk IHRoZSBkcmFmdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmto b2x6LXJhdHMtcmVmZXJlbmNlLWludGVyYWN0aW9uLW1vZGVsLw0KDQpUaGVyZSB3YXMgaW50ZXJl c3QgaW4gdGhlIGRpc2N1c3Npb24gb24gdGhlIGFkb3B0aW9uIG9mIHRoZSB0b3BpYywgYnV0IHJh biBvdXQgb2YgdGltZSB0byBnZXQgY29uc2Vuc3VzIG9uIOKAnHdoZXJl4oCdIHRoZXNlIGludGVy YWN0aW9uIG1vZGVscyBzaG91bGQgYmUgZG9jdW1lbnRlZC4gIEZ1cnRoZXIsIEhlbmsgc3RhcnRl ZCBhbiBlbWFpbCB0aHJlYWQgcHJpb3IgdG8gb3VyIHNlc3Npb24gdG8gZ2V0IGEgc2Vuc2Ugb2Yg aW50ZXJlc3QgYW5kIHdoZXJlIHRoZXNlIG1vZGVscyB3b3VsZCBiZXN0IGJlIGRlc2NyaWJlZC4N CkdpdmVuIHRob3NlIHJlc3VsdHMsIHRoZXJlIHNlZW1lZCB0byBiZSBhIHByZWZlcmVuY2UgdG8g a2VlcCB0aGUgZG9jdW1lbnQgYXMgYSBzdGFuZGFsb25lIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGFs bCBtb2RlbHMuDQoNClRodXMsIHRoaXMgaXMgYSBDYWxsIGZvciBBZG9wdGlvbiBvZiB0aGUgZHJh ZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwgdG8gc2VydmUgYXMg dGhlIHN0YXJ0aW5nIHBvaW50IGZvciBhIHN0YW5kYWxvbmUgZHJhZnQgdGhhdCBkZXNjcmliZXMg YWxsIG1vZGVscy4gIElmIHlvdSBoYXZlIHJlc2VydmF0aW9ucyBmb3IgZG9jdW1lbnRpbmcgaW50 ZXJhY3Rpb24gbW9kZWxzLCBvciBmb3Igc3VjaCBhIGRvY3VtZW50IHRvIGJlIGEgc3RhbmRhbG9u ZSBkcmFmdCB0byBkZXNjcmliZSBhbGwgb2YgdGhlbSBwbGVhc2UgcmVzcG9uZCB0byB0aGUgbWFp bCBsaXN0IGFuZCBwcm92aWRlIHJhdGlvbmFsZSBmb3IgeW91ciBjb25jZXJucy4NCg0KVGhlIGNh bGwgZm9yIGFkb3B0aW9uIHdpbGwgZW5kIG9uIEF1ZyAyOC4NCg0KQmVzdCwgTmFuY3kgKG9uIGJl aGFsZiBvZiB0aGUgUkFUcyBjaGFpcnMpDQoNCg== --_000_DBDAA23E74BC45C7AA87C303963131CEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9CF46202B8C62149A94FC30E992AF398@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+SGVsbG8gUkFUcyBtZW1iZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BdCBv dXIgSUVURiAxMDggc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgdGhlIGRyYWZ0OiAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwvIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwvPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlRoZXJlIHdhcyBpbnRlcmVzdCBpbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgYWRv cHRpb24gb2YgdGhlIHRvcGljLCBidXQgcmFuIG91dCBvZiB0aW1lIHRvIGdldCBjb25zZW5zdXMg b24g4oCcd2hlcmXigJ0gdGhlc2UgaW50ZXJhY3Rpb24gbW9kZWxzIHNob3VsZCBiZSBkb2N1bWVu dGVkLiZuYnNwOyBGdXJ0aGVyLCBIZW5rIHN0YXJ0ZWQgYW4gZW1haWwgdGhyZWFkIHByaW9yIHRv IG91ciBzZXNzaW9uIHRvIGdldCBhDQogc2Vuc2Ugb2YgaW50ZXJlc3QgYW5kIHdoZXJlIHRoZXNl IG1vZGVscyB3b3VsZCBiZXN0IGJlIGRlc2NyaWJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+R2l2ZW4gdGhvc2UgcmVzdWx0cywgdGhlcmUgc2VlbWVkIHRvIGJlIGEgcHJlZmVyZW5jZSB0 byBrZWVwIHRoZSBkb2N1bWVudCBhcyBhIHN0YW5kYWxvbmUgZHJhZnQgdGhhdCBkZXNjcmliZXMg YWxsIG1vZGVscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRodXMsIHRoaXMgaXMgYSBDYWxsIGZvciBBZG9wdGlvbiBvZiB0aGUg ZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwgdG8gc2VydmUg YXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciBhIHN0YW5kYWxvbmUgZHJhZnQgdGhhdCBkZXNjcmli ZXMgYWxsIG1vZGVscy4mbmJzcDsgSWYgeW91IGhhdmUgcmVzZXJ2YXRpb25zIGZvciBkb2N1bWVu dGluZyBpbnRlcmFjdGlvbiBtb2RlbHMsDQogb3IgZm9yIHN1Y2ggYSBkb2N1bWVudCB0byBiZSBh IHN0YW5kYWxvbmUgZHJhZnQgdG8gZGVzY3JpYmUgYWxsIG9mIHRoZW0gcGxlYXNlIHJlc3BvbmQg dG8gdGhlIG1haWwgbGlzdCBhbmQgcHJvdmlkZSByYXRpb25hbGUgZm9yIHlvdXIgY29uY2VybnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2Zv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp ZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBlbmQgb24gQXVnIDI4LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QmVzdCwg TmFuY3kgKG9uIGJlaGFsZiBvZiB0aGUgUkFUcyBjaGFpcnMpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBDAA23E74BC45C7AA87C303963131CEciscocom_-- From nobody Wed Aug 12 13:34:37 2020 Return-Path: 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 818933A0B59 for ; Wed, 12 Aug 2020 13:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mg5JOvw72rs8 for ; Wed, 12 Aug 2020 13:34:35 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB303A080E for ; Wed, 12 Aug 2020 13:34:35 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id 186so800340vkx.4 for ; Wed, 12 Aug 2020 13:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BL+3R2WObP9CalArQBKBk4BEYWt12z7rho7uxOYBVQo=; b=HY4PwywYZUwUQDmTgxykCCRxPbCI/GLoZrWQG/0OwvwwB2+kC2EmJqWSf8PYrJWlmQ OAmDWmYA9MmRokj33Vsruu7lHk5QBQjmRWmEqr37GLCE0pmqh8BHLfpSLefQZkABavLo GaySaGydam0WgxTA3g8zQP4sgDvM3f9jZbNe7wgDyCxFT8WteJFoNMrghzKLue14wDpx zUpNV8+3EQCtmzOhx65yN+PH7hVv3qUbBXoHXlhwokzTRJIECuO948xWs4BqP+eUyBKj gsVJpqHhuL3kmalxXPNT/H0DT2OfMwTVSusM9flrgeXo1HkdM2l8o9IL0quAsLJJgEot 4QJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BL+3R2WObP9CalArQBKBk4BEYWt12z7rho7uxOYBVQo=; b=qc5NsnConuH7BUKyAA5Ws8/YitRTJlqhZF1dIArj6+plgdka7l1Q5SGYehNHqc7862 uIhUPr31eO2o7AvtmshydCCftJAlYMnFa9c1Jaa9tAAeMmZURDWWUTGtlu88f1qh6JEF k2+MWN4R6CubGjPCv1vjVgF0FZIpL/5/LHmMWGtjQCIEK8VL9w8oAoaCwA9tTrP7IszH NnJTXzcST7eNpS6acUiv8fxpQ9N2ufAGmEGy3gMFJGAFJO33x5XZmuT37OWss5V6ggS7 C4skE3tv3dfCsvBoKwaDHQqw+6reXaXtt2F4uL2fP1xt/tEY6Hpl2uH0XIpyGxFoVLnB dFdA== X-Gm-Message-State: AOAM53017WIISGrpjPtS6lINSyyhd12oQHyPvnmt/QGmpSzKa3cCWfem QIXyyjTursg9HiBY6zFAaLNr0Ss97N9lGZu+HBQ= X-Google-Smtp-Source: ABdhPJxjv+s01Xg7Wn3Eij4TdMexpHi0kFj/XN9ox9SAk0lgXw0JMkYy8h+ISDsHWSnTdinLz/7pamExv2bt3bJBl2U= X-Received: by 2002:ac5:c889:: with SMTP id n9mr1078569vkl.3.1597264474136; Wed, 12 Aug 2020 13:34:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ira McDonald Date: Wed, 12 Aug 2020 16:34:22 -0400 Message-ID: To: "Nancy Cam-Winget (ncamwing)" , Ira McDonald Cc: "rats@ietf.org" Content-Type: multipart/alternative; boundary="00000000000097e4bd05acb41de9" Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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 20:34:37 -0000 --00000000000097e4bd05acb41de9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, +1 for adoption as a stand-alone document. Cheers, - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/hi= ghnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Wed, Aug 12, 2020 at 4:25 PM Nancy Cam-Winget (ncamwing) wrote: > Hello RATs members, > > At our IETF 108 session we discussed the draft: > > > https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interactio= n-model/ > > > > There was interest in the discussion on the adoption of the topic, but ra= n > out of time to get consensus on =E2=80=9Cwhere=E2=80=9D these interaction= models should be > documented. Further, Henk started an email thread prior to our session t= o > get a sense of interest and where these models would best be described. > > Given those results, there seemed to be a preference to keep the document > as a standalone draft that describes all models. > > > > Thus, this is a Call for Adoption of the > draft-birkholz-rats-reference-interaction-model to serve as the starting > point for a standalone draft that describes all models. If you have > reservations for documenting interaction models, or for such a document t= o > be a standalone draft to describe all of them please respond to the mail > list and provide rationale for your concerns. > > > > The call for adoption will end on Aug 28. > > > > Best, Nancy (on behalf of the RATs chairs) > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --00000000000097e4bd05acb41de9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

+1 for adoption as a sta= nd-alone document.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TC= G Trusted Mobility Solutions WG
Co= -Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secreta= ry - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet P= rinting Protocol WG
IETF Designated Expert - IPP & Printer MIB
Bl= ue Roof Music / High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent= ) PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434
<= /div>


On Wed, Aug 12, 2020 at 4:25 P= M Nancy Cam-Winget (ncamwing) <ncamwing=3D40cisco.com@dmarc.ietf.org> wrote:

Hello RATs members,

At our IETF 108 session we discussed the draft:= =C2=A0

https://datatracker.ietf.org/doc/draft-birkholz= -rats-reference-interaction-model/

=C2=A0

There was interest in the discussion on the ado= ption of the topic, but ran out of time to get consensus on =E2=80=9Cwhere= =E2=80=9D these interaction models should be documented.=C2=A0 Further, Hen= k started an email thread prior to our session to get a sense of interest and where these models would best be described.

Given those results, there seemed to be a prefe= rence to keep the document as a standalone draft that describes all models.=

=C2=A0

Thus, this is a Call for Adoption of the draft-= birkholz-rats-reference-interaction-model to serve as the starting point fo= r a standalone draft that describes all models.=C2=A0 If you have reservati= ons for documenting interaction models, or for such a document to be a standalone draft to describe all of them pl= ease respond to the mail list and provide rationale for your concerns.

=C2=A0

The call for adoption will end on Aug 28.

=C2=A0

Best, Nancy (on behalf of the RATs chairs)

=C2=A0<= /span>

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--00000000000097e4bd05acb41de9-- From nobody Wed Aug 12 13:41:26 2020 Return-Path: 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 E4F283A0B69 for ; Wed, 12 Aug 2020 13:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=jkp74/rt; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=x6gAH7qI 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 Hv50e1frmjZX for ; Wed, 12 Aug 2020 13:41:24 -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 309083A0B5F for ; Wed, 12 Aug 2020 13:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14669; q=dns/txt; s=iport; t=1597264884; x=1598474484; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iZEV/zzyJ/Dfc44pt3YL57q3iFubyZNBbuTvEjK+U3U=; b=jkp74/rtUeEig7YRQxIcZ591CNkgk54ed0+x1Np+38vFmRXyDfbdqBWK RRlwBzi4EYIEaz33LRMbleLczqV3kpIcPlU6KdNzkCR3yUnq5v+mE3WsZ xk7NGsoooFCvqWpHSFEuF7P3oaKwSaleymed1/ZyjtSc3neBMW7UaVd2g E=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AEGwobhRUtWFqOQrNWGA8COcC1tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APCAB6UzRf/5tdJa1fHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy9RB28rLS8sCoEjgwmDRgONV4UljlSEbYFCgREDVQQHAQEBCQM?= =?us-ascii?q?BASUIAgQBAQ+EPQKCNgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEEEgs?= =?us-ascii?q?GChMBATgPAgEIEQQBASsCAgIwHQgCBAESCAYUgwWBfk0DHw8BDqgBAoE5iGF?= =?us-ascii?q?2gTKDAQEBBYFHQYMVGIIHBwMGgTiBU4EeglJLhwIagUE/gRFDgk0+glwCAwG?= =?us-ascii?q?BJgERAgEiK4JqM4IttiwKgmKEOIJcgU+RV4J+iVmTPpEtDHaKPZBShCUCBAI?= =?us-ascii?q?EBQIOAQEFgWojZ3BwFTuCaVAXAg2OH4NxhRSFQnQ3AgYBBwEBAwl8jlwBgRA?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.76,305,1592870400"; d="p7s'?scan'208,217";a="541607656" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 20:41:23 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07CKfM3D015719 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 20:41:22 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 15:41:22 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 15:41:21 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 12 Aug 2020 15:41:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=apLkOgJ6v0zWKiVa606U8+2bKt7EzeGVhPpjVy2imVtP8Cd1IH0z6DhXZI5P3KXsdKvL1zCMXrQUCCRnHyS3YepSYg2H2n9c6WPhxwZPJNi5ry9UOluPHFJSecunOweJ8EOMrvrushsmPyrmjLK7d69Nq6LaDuPmaxS9u88atZfnkZYlG3eekWzeszsDGO9mhQFTAFlxJXTHE6BRVbP1jqIaXJZbg0Nas2VASCIB0okoJulpyNV2Ny/hHLZkzsKIsTUqoUK8WkUKU8XJGc1hNS46zGjlZGVQ+dgxJjtxyKYAhbMvWjGUzlxdxZrk9jqqBKMcX/bfni+GTXtDSTBrHg== 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=eI37f9e5Z6wRghvrVMJxin8mqoLmbBU1WiDW47cagJQ=; b=hBwKQS4bQ23HF19Daoi8nW9RscYZrZjuhDuMgkpP81lyvMRN3hfsLPtyXVk10DW3REkIPssn9FwJ9f4btSzIf3q061JO3f7SrBIfJLcjYNiy6nc3JhcpuzMU9ORI7Lq/1BS1TRwU9QLWjg0G9pcG+Vdcw5pkTm7vWwe8ZvTIA9SZLTISNiroPWGNi/foaqZKbxj1DCfjKXG6J15CnOfDd6xRiDVY+2qGnz/f2YngGRPAy3+9Qil9YA6oTZ6EYv9gosxQWBqMtHp6ZSBEVLofTG1x8a72UIV2/RxG8MJ1U62RNycp+hic5+IBOaAzQQA+L00ZsIovQi4yvAbwoXC/2A== 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=eI37f9e5Z6wRghvrVMJxin8mqoLmbBU1WiDW47cagJQ=; b=x6gAH7qIhqMcXap0JurqT/Bw0Gi0mjlPUAOPsF6mnFHsLwnHGGHnf4TnXgyConGCs0e66HJJXv2+JYoYc0yND10g+yt64fWAJyb0IUN+tngqqTUnwGvMbjKg44DYStR/0d9fcS0oSyuNcPF1u94uGX6it69eOLy0/YmwGoSrqFA= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3235.namprd11.prod.outlook.com (2603:10b6:208:6b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Wed, 12 Aug 2020 20:41:20 +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; Wed, 12 Aug 2020 20:41:20 +0000 From: "Eric Voit (evoit)" To: "Nancy Cam-Winget (ncamwing)" , "rats@ietf.org" Thread-Topic: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model Thread-Index: AQHWcOa5ocl00PiKFEWQHfz6I5Hx9qk078Bw Date: Wed, 12 Aug 2020 20:41:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: 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: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eebefd10-2911-463d-6648-08d83f0011a9 x-ms-traffictypediagnostic: BL0PR11MB3235: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OJpRB0ioonpHUNQCzEIQTDmzf4nolPLQtzlJ4tQiNwbFPGXAd7+FVAodQOlZ91Y1ILUIwCLYkQG5K6lljYoBqg2Sejk7Kxs2fQ0d8SZKVUyN/XfPiJAEZFc7hZIUykn8I12vsKQmhHLTL40m/EcA7eSb3udGQpMgmTbHrdW6XkwAxh6xvAwmmncE0DVX617C0Rn4pbzxVAODpcSjw2BbZZ3a/YbkByieHeM7ZBjgEqdQOTGXf3u3pAnaemGGtIlYoStLMze4ixybkZ4MrsunsT9+2JPtpgowUSxfk3w1bY/VY4A6msHIGmfh0B4HrqZF1cARQJfbfXjLYrT8YBDGmg2EfjdHzm/rV/p+Qc8PgKt6NPce2HvkuZSHpbOFfPIOSqb0kM4/WbzcI72zzzXeCg== 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; SFTY:; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(66556008)(64756008)(66946007)(66616009)(66476007)(66446008)(76116006)(71200400001)(53546011)(86362001)(33656002)(8676002)(83380400001)(8936002)(6506007)(186003)(166002)(55016002)(478600001)(966005)(110136005)(5660300002)(99936003)(9686003)(316002)(26005)(7696005)(2906002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pG8gPYC3LiOyTEG+12zbpIpLi1clO1RuKHPVlGB/hbVIme3v83e1x1bJMGuY20qP5LEVFxXxbAiNuJDXCC301DHriejNjbxqAz6alU0V1CkXBOENO/4ARPzG6yy6mSWQ6tBRzTzocnyS2JOf6dnBmQ+iJWgJoDYaRUv103uoeojyihCgWiczutIyD7j8Kpf7GRA19/DnrvqbO8+iSyWGOqUkIaDqK+4rGQMKvHK0lPnPPovzFDmRgOuc9FPo2gfWcSwdYgcMTsIyo7gJp0j1GsdokVJMhIONmH78NyXIE5KsrJvr6qyMGlFDps1HQIFmIIDn7Ef0i6+tAh6vx1nPpID61J7ciGeY3KoBJoJFAh2lMbPusnkjSSq/2oIxlH58SzVBMujTx+hWhPliZ/LIVxOUOk+vduwbqoWNdoNCMZd5XO9+bXG3KwMFpBMFj1NAi10grpHpl6nFJeCo8u4AuoWdJxQVNlvO2FIVkBBRWGACphSFLB64B9uBcAK9DTJD6v9fLOelc7yloE8cxy4YcPXrAvK5oWSgEGaqPj7PtatKuazNqgGDrnwDxcCEX0Bil4fc/XzSMx9fg9dtwkn0WBt9WG7rf5JDkWHsGJIBzPaT4nQLVIqTmHqGpIOATXu59eI8ZRBzt27O3HB3kMuKOQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01F7_01D670C7.660191B0" 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: eebefd10-2911-463d-6648-08d83f0011a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 20:41:20.0846 (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: lrTIWJZzRTKDQInamnp1BTha2I+EU87j6t+a8Zz7KvRmSQHOPniFKe37wza4qAi2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3235 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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 20:41:26 -0000 ------=_NextPart_000_01F7_01D670C7.660191B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01F8_01D670C7.660191B0" ------=_NextPart_001_01F8_01D670C7.660191B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this should be adopted. If we want interaction model = commonality across the WG, this is needed. =20 Eric =20 From: RATS On Behalf Of Nancy Cam-Winget = (ncamwing) Sent: Wednesday, August 12, 2020 4:26 PM To: rats@ietf.org Subject: [Rats] Call for adoption of = draft-birkholz-rats-reference-interaction-model =20 Hello RATs members, At our IETF 108 session we discussed the draft: =20 = = https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interactio= n-model/ =20 There was interest in the discussion on the adoption of the topic, but = ran out of time to get consensus on =E2=80=9Cwhere=E2=80=9D these = interaction models should be documented. Further, Henk started an email = thread prior to our session to get a sense of interest and where these = models would best be described. Given those results, there seemed to be a preference to keep the = document as a standalone draft that describes all models. =20 Thus, this is a Call for Adoption of the = draft-birkholz-rats-reference-interaction-model to serve as the starting = point for a standalone draft that describes all models. If you have = reservations for documenting interaction models, or for such a document = to be a standalone draft to describe all of them please respond to the = mail list and provide rationale for your concerns. =20 The call for adoption will end on Aug 28. =20 Best, Nancy (on behalf of the RATs chairs) =20 ------=_NextPart_001_01F8_01D670C7.660191B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think this should = be adopted.=C2=A0=C2=A0 If we want interaction model commonality across = the WG, this is needed.

 

Eric

 

From: RATS <rats-bounces@ietf.org> On = Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Wednesday, = August 12, 2020 4:26 PM
To: rats@ietf.org
Subject: = [Rats] Call for adoption of = draft-birkholz-rats-reference-interaction-model

 

Hello RATs = members,

At our IETF 108 session we discussed the draft: =  

https://datatracker.ietf.org/doc/draft-birkholz-r= ats-reference-interaction-model/

 

There was interest in the discussion on the = adoption of the topic, but ran out of time to get consensus on = =E2=80=9Cwhere=E2=80=9D these interaction models should be = documented.  Further, Henk started an email thread prior to our = session to get a sense of interest and where these models would best be = described.

Given those results, there seemed to be a = preference to keep the document as a standalone draft that describes all = models.

 

Thus, this is a Call for Adoption of the = draft-birkholz-rats-reference-interaction-model to serve as the starting = point for a standalone draft that describes all models.  If you = have reservations for documenting interaction models, or for such a = document to be a standalone draft to describe all of them please respond = to the mail list and provide rationale for your = concerns.

 

The call for adoption will end on Aug = 28.

 

Best, Nancy (on behalf of the RATs = chairs)

 

------=_NextPart_001_01F8_01D670C7.660191B0-- ------=_NextPart_000_01F7_01D670C7.660191B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEyMjA0MTE2WjAjBgkqhkiG 9w0BCQQxFgQUKXAtD7mx7y6D72mHajfKSan8AWgwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBX2z+XFL1XD8qTLUA6nwgS3CHxZRDAM2R0KmaLWJWK4aE0toQFlPoFsRUKi6/VMieA DY2wYGNUwRk/GmOVXAGfiIcdOeaSl9+ynVhYAU9MmYhbvhQ0Pym/BrQxGBV1fRCIrlYq+pKmQQnu 0DfsS+HN53NelYM+1bf1lSFImr24LpB/NfT+utWbeUxQzHISKfzbaPwCws/8SoVpUiWp+pnK0bxr l6t52MdTnak77cRo1KsAN6AIYU93eFkWX0zNw4qjtAY9rZfbGSHlR0oOM+eBmJJUC5xnHpxtNbIm ayBS0SswNgZOjK/SQSjKN0kc2fcd9ShuO5u8mCoJJmiES687AAAAAAAA ------=_NextPart_000_01F7_01D670C7.660191B0-- From nobody Wed Aug 12 14:42:47 2020 Return-Path: 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 ECDB93A0B47 for ; Wed, 12 Aug 2020 14:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 8TFqAx8kNCOX for ; Wed, 12 Aug 2020 14:42:44 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2128.outbound.protection.outlook.com [40.107.237.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58DA3A0BEB for ; Wed, 12 Aug 2020 14:42:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RBNeOAhzRPcPwqWlcSpkIuPgNSXdo91Waq7xaskiKpiUD++nfHI8I2A8ZJPg/LauUUfXF9ASZS3kmLmhym/NE4NinF6Cuw59OvvdjMbQtOxeSCffJU2R3UiXEslTqRodOm1cV4GB6c5KkpetJGy6tLwoaTT64Ro0ApeRnhtwjP2r0hlxfWYSOu2xnpNckf5K5APex0KjOjW9aKo84/2hb1wY5APUn3zsr1pxIeWyvXaGDPMhWyaMmlgooWjOxIE1/Scn0436QJ+J7W4Q4gJfEF1WlNvIrwiPyfE1rpqAisXtCCqJO7ScUma5tSQ5UpB3xRtyYhI581BxGjgiyfZt1A== 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=11g8mDQjDWBbVDtdwWkxld5p2Xnz6+dXQ28BO466cxI=; b=jW0JzMHnf5vS+czrU2VTVV9IF/siHJ+E5Xgkmbwew+wASgmTRfjS+Jvy1XaG064zzQtJht+Zv196KdREH0Xu3WLLwEub2oNUELh7iXDnmJtvSwl+s+6Yazt4zXTRrHCRmJm+PGBHSlCz6njfwaRU3tTzMw4nI95Xs3360TGzVC0wwBtZ8aLsUz/pA+pLyIR8OD1TsqpVtDMIspOzbHVM8LG5pruWG/ggxacIYN+Vzz35DJezKCpEmUCq7V4FFVOlifTA7x8RXNaafx5izoGXJE/8cpjsb07rzYskL7EBTOSsrHYEqs5PB2ZiB6LH08J2lDvecVR+ixgD4GwqZkgO4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11g8mDQjDWBbVDtdwWkxld5p2Xnz6+dXQ28BO466cxI=; b=PSqxZ4+v/iESWn5KsSaUaxZa/m1HAmlTRTN7F6TcqRg/hdLIUmIj4tsU9FaG8iIoWA9GuRKhnbkyqCC1lm4dxhUIhvItABuySOyGtCHc4CBwyEDlCaCagY2LglbqKAZy6J1L2+iQciL0RWOKU/2m8tnv4mTSIEnEGi6RVXni/oA= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1123.namprd21.prod.outlook.com (2603:10b6:207:30::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.3; Wed, 12 Aug 2020 21:42:43 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::41c0:a400:b7aa:e3b8]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::41c0:a400:b7aa:e3b8%5]) with mapi id 15.20.3283.014; Wed, 12 Aug 2020 21:42:43 +0000 From: Dave Thaler To: "Eric Voit (evoit)" , Dave Thaler , "rats@ietf.org" CC: Wei Pan , "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQA== Date: Wed, 12 Aug 2020 21:42:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-28T14:10:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=418b9af6-b4d5-4eb1-9d7d-e75014a19a02; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:9780:16f0:3029:9ddd:28d2:bcfd] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 78827127-9046-4c16-a6b1-08d83f08a4d4 x-ms-traffictypediagnostic: BL0PR2101MB1123: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oaUiud5XaHmr1QVRLvuwn4111V/QSF9E2Dpg5D+LtbgArqXGSPqkMwEGuJ0fnKnRoYzMH2g/tBguCH+G8qkWPdRN9hV/PvqsbNYY5vkttO+qroqJCn4iOXSFQXe7NEt5dRgnPl4C3d3MXiW1E33Xobcwwoyow/1CIY6WF+bH1WfZoicuthxbk/dOy4ocdBaNn/eNspPrZQTlrHXFqQX46orRLA+YMvOrz5AEz3AL4e9YA+CbxGvIrfFhzT/khdaxcE8Xo2+ep7DnIodI08qtZdFhiZWDsZCgfN/E6WiKDxu+avkhTAsC3OST8w/z6ovZjaiAiwe6wlWvA25KYDKwZg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(66446008)(66556008)(64756008)(66946007)(66476007)(71200400001)(82960400001)(82950400001)(186003)(6506007)(76116006)(7696005)(52536014)(9686003)(55016002)(5660300002)(316002)(110136005)(2906002)(8676002)(86362001)(4326008)(54906003)(8936002)(10290500003)(83380400001)(8990500004)(33656002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: z5Gi4m20cTlBea1F+mXsSfeeglSw/UjUs7lqr701AzWZBdjBbvTEdx2p5t5vVYzT09/88J+gLOthqmz1oWnofRM+aVLnAnSabSJULjye+BIDx8/0S2cb1ojfV9Q1RTM3NgM2+xekOXjjsjMUhegPay/ufflcClakgc0JhEqhnW7Yyv6EE/oXBUHDyAb5m3wfdr2OksLkFdQ/QzLoO1QdtC4kI+qkTKfSK9XB3WpbCeEhlrdRW6b4/y5+H/rtulTfJGanff83XcaUah8mwU3nWYioqw3RIuRE3msnrKc1hZbSpufsEdnwMe2F4wczniqKjbpC62nmIKFPPo8FMrFcX81LjTQwl7q5ztAjLjsRiJ2fHwBPtAILj5VFLUwdDD6tvo+nY9oOPXypVB7cuIKrAkz3FjJJN6cAXpkexoBMdNd8vBpC/5AczG56uUUbkfEWpxj4AzhJeQFhlbATunCFVG0Nj12Gsnbv8/TqoeivOSaXdB/H3fWOg3plBDNaxg+F29YXt1zU1cWQW1189viGTgzTKRmz9jG2XZf5uMibQQ8hx56yeiLJg3ISVTeOQY9L6oMwnLmiJZPN/plost/S6orW9+9BbzpUhHCinqTuXvbcfWbI6GCRhVU3Tqn7I269oZGSB81uVEsUskRZaahpI5kuvM4BBZ44ZdLB85Ugd1J9Ah66J3vnwrrFJ/0NQ68mVdV9ChZAmmvfMAizJj8HKQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78827127-9046-4c16-a6b1-08d83f08a4d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 21:42:42.9893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 36uGPSfPRRPxTxL2qUYnomLXtRuiXi4xa5Fkf0Hj7rDddcGl9ius2dvxe3bzdvlJpVPWzHxgdFx47/IvHT+J3DOPyN/vcTaKE5GbxvWo8RI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1123 Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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 21:42:46 -0000 Eric Voit wrote:=20 > > I asked in the meeting how a subscriber knows who to subscribe to, and= =20 > > I believe the answer was that CHARRA answers that. >=20 > The answer I gave was that the problem was the same as Charra. I believe= I also said the > problem itself is generic to any YANG based network element (I don't reme= mber if that came out). > Generalizing more from there, Network Operators have diverse set embedded= management systems > which include discovery, addressability, inventory, etc. of the network d= evices they manage. > > Moving back to YANG, these network management systems don't include all Y= ANG info about a device. > So once you have found that a device exists, the device capabilities it s= upports can be acquired via a variety > of mechanisms like:=20 > - NETCONF RFC 6241, Section 7 (and RFC6470) > - YANG Library RFC 8525 > > > Well I looked in draft- > > ietf-rats-yang-tpm-charra-02 and it does not contain any mention of=20 > > the subject. I think one or the other of the two drafts needs to=20 > > address this issue. > > This topic has not been within the scope of the many other YANG drafts/RF= C > which exist. This is reasonable as there is a huge breadth of topology > discovery protocols available and in-use for routers and switches. The topic being discussed here is about *timing* (and windows of how long t= hings can be out of date for, etc.) I expect that most other YANG drafts/RFCs do not cover that topic, = whereas Figure 1 of draft-birkholz-rats-network-device-subscription specifically *does*. That'= s what brings it in scope and why I believe it must be mentioned, even if it's by reference to another do= cument where the topic is covered. Dave From nobody Wed Aug 12 15:50:46 2020 Return-Path: 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 9BE7E3A0C84 for ; Wed, 12 Aug 2020 15:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com 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 W7vOW_STIk4a for ; Wed, 12 Aug 2020 15:50:42 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50115.outbound.protection.outlook.com [40.107.5.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77FE3A0C75 for ; Wed, 12 Aug 2020 15:50:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wkq1LeTsSukY2R7OcYuvBUQrVcA5Sc4Do8D1059UfEyFF5syPHoDS70E55ORhPk94fyZyJcuR31f1FqHxnsksiMzXkrNO+qhHyder752gSc2lPjR0XmnZ3d7OFStxEzQZkHp0JeKpNT6lsVq9h7Nffj3n49i4j5Vemn6CHBaKbZAsMYlYmU0YRPq4Hzf8w+Lp3H73nRnr3TXqRmG43k9nT4+xX5ysn6SEHSCpBYVOZfH19fTwvbJPfdajxUQux5RCvw6SlrRPQ1LY20l6C0s87B1JzszX29VU6OSvxhkG59wbWWy6c5TPc892s3eDrzuycAScnN67888gTi3usO+DQ== 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=MVnu7wSEwam3oaNHD1aKr9VpzIdbtxDYPJkayy4j8E0=; b=en0rkqkiCpt+ZyZ/BkPYlfww7MmtlVbkX8NAgXDxjZxlAsFCfyKyvCLEoTught5olC4Ve79he9XnbYfVAiPHAm7RrfRYRCIK2A8ctKo9JALx9sfi5Wz+ra6UFHhu9g+ydSVLGu1fj5rlSpX1okOQABoNKk6pOxQ2UPwoRGlBWrKeRE/wMWgXpRzqIAskcdyJAN9gtzPdqBZZySlcEjMisWl0Rr/sxPqdLvGxNDgXoiRzUxaljlLGSdbc0QKo1dEiKA1A5b37G0bGwaYSn1I4AmTRWbBa7Ozf6jK5+swv0DZiHFdmcL4gj0qmGP2w07CZ7XbwBf+pP5euh69JRnfFug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MVnu7wSEwam3oaNHD1aKr9VpzIdbtxDYPJkayy4j8E0=; b=AyIAzEQ9g/2V3jtwjL+KWp8bkV1FU0+IkXYIxrY7Ni26frQzWIO15fLi316MxXCdV4/+FPP/QVEIZdMSOj6JiIPa3Gos4vZUSRuuT0y1xcr6e6Cwp59ohiVDNNFEZY921Uvw8LZstjOYGrZw5WggB88MdxK+HbFkctqSuwiGMmU= Received: from VI1PR06MB6446.eurprd06.prod.outlook.com (2603:10a6:800:12d::16) by VE1PR06MB6205.eurprd06.prod.outlook.com (2603:10a6:803:127::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Wed, 12 Aug 2020 22:50:34 +0000 Received: from VI1PR06MB6446.eurprd06.prod.outlook.com ([fe80::b0c6:b385:ca79:dcd4]) by VI1PR06MB6446.eurprd06.prod.outlook.com ([fe80::b0c6:b385:ca79:dcd4%9]) with mapi id 15.20.3283.015; Wed, 12 Aug 2020 22:50:34 +0000 From: "Diego R. Lopez" To: "Eric Voit (evoit)" , "Nancy Cam-Winget (ncamwing)" , "rats@ietf.org" Thread-Topic: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model Thread-Index: AQHWcOa5ocl00PiKFEWQHfz6I5Hx9qk078BwgABF8AA= Date: Wed, 12 Aug 2020 22:50:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20073000 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [79.148.131.204] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4c203fef-f4f5-44c5-9968-08d83f121fa1 x-ms-traffictypediagnostic: VE1PR06MB6205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: brxuYmkW/qKkw9pwbpu0Sjuhe1v2KJ93EAq9qYpDE/RCr1iorIbMY0EoeBIhWQo5x3pITPaz2kZ2qV7AL2UJSCfUnoTNkRkKK74jKNbartjKG2bZ27c+fOlamfDCm0l89qauQIZ4G/k/oapU3Y2B+lMTSEnwJD3hhPo9/NzZjsH/hn5HxnlYdjNQKn8YJyjYic6yE8355FvUqzJI434FJQFSe9qDB9SZuk9yDMsc+jVy8CU0eSw4/haU4BDuKIrgXMdqANS3TFqAGQPrQQDsf+db0V4x/nleBrL78iBH9/rcFfHcqXb36ySgE2FFhNaW3S9H4f/BdcjIq77viBPB0ubNccNigXPzbwo+cEoHJiacwlCHgFU1ie7Wb37lQVmWM1vdI8WKY+Sz120lWJFhEg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR06MB6446.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(110136005)(8936002)(966005)(186003)(66574015)(316002)(33656002)(2616005)(2906002)(36756003)(83380400001)(478600001)(166002)(786003)(6512007)(8676002)(6506007)(86362001)(5660300002)(53546011)(6486002)(45080400002)(66446008)(26005)(64756008)(66556008)(66476007)(91956017)(66946007)(76116006)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: LlX+We41KmKNloCni56LFVwzJeYNlI/fQ5MnvS0mOecsRpCk8XpootxY92DRLLJSXtgvyfvNdFEy99wiN8Gp9JqsqcKkcJZ8++11oE66BEJnwfURkkXfqwgpav7MFbfJp64uKwjXiW7MzHFZUW3JBmrw9UdjiNYc5rkXMK/JxVq7Q9G9+9vaZmbwoelSdgdG80pkSam9ran27L02CvoZQx9A7YuuiX0/QKFA65g++iY2NMAbUueCfMXd1s/hcqs0uxo2qdRQ1eSk/Pn7ZQkzt15wXYeHrvYt97H+HISOR52QN3GFIkkJAtA/RkK3bZ8WxuLLhvSvJpfXLDPsXBDi+/HLN54mP9AV9MomOZohXRFsrHixYUQlBiJZ5gT4Dp2LHeApQUlfqSUlbnEkBdW+kO+efvTeiIK6TXd6zym0yL8pvLSNqMdCGY9JYxy0cZKDJSycv/o9oH7htZdHbY9Och0nU5TUCkYb2/aO8J2OH6uxGPeRo7zq3UntRabqp/+8ZwrnqkhMXrJGU4Rm9ro/NiIypv9y+d9y4/Spj56FroyPJrdJzM6bJ2sixbphNTHt9fdEs9lmi/XDaPYk5/3A4Ta1RFzXDmKaXyQ45OOc4sTjodEaTsW7xWvZcn9otAtGS5sgxR0NZulKpmC7aQF6JA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CF320C3C291E43C4B7F8586C082DE317telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR06MB6446.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c203fef-f4f5-44c5-9968-08d83f121fa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 22:50:34.4296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FUJDrDRgjj2jHYwYvIIZcMS5a6Fee38gv/yUi4kHv7Cb7j6siN4+hDSxNxyqQhyjQ7O2VrWIUdNBuQJB4U6lX8uy2zBmq6NztRaf08rEiY4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR06MB6205 Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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 22:50:44 -0000 --_000_CF320C3C291E43C4B7F8586C082DE317telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLiBJIHN1cHBvcnQgYWRvcHRpb27igKYNCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0K VGVsZWZvbmljYSBJK0QNCmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Blei8NCg0K ZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPG1haWx0bzpkaWVnby5yLmxvcGV6 QHRlbGVmb25pY2EuY29tPg0KVGVsOiAgICAgICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiAg KzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9u IDEyLzA4LzIwMjAsIDIyOjQxLCAiUkFUUyBvbiBiZWhhbGYgb2YgRXJpYyBWb2l0IChldm9pdCki IDxyYXRzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJhdHMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIGV2b2l0PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpldm9pdD00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJIHRoaW5rIHRoaXMgc2hvdWxk IGJlIGFkb3B0ZWQuICAgSWYgd2Ugd2FudCBpbnRlcmFjdGlvbiBtb2RlbCBjb21tb25hbGl0eSBh Y3Jvc3MgdGhlIFdHLCB0aGlzIGlzIG5lZWRlZC4NCg0KRXJpYw0KDQpGcm9tOiBSQVRTIDxyYXRz LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBOYW5jeSBDYW0tV2luZ2V0IChuY2Ftd2lu ZykNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEyLCAyMDIwIDQ6MjYgUE0NClRvOiByYXRzQGll dGYub3JnDQpTdWJqZWN0OiBbUmF0c10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtYmlya2hv bHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwNCg0KSGVsbG8gUkFUcyBtZW1iZXJz LA0KQXQgb3VyIElFVEYgMTA4IHNlc3Npb24gd2UgZGlzY3Vzc2VkIHRoZSBkcmFmdDoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJlbmNl LWludGVyYWN0aW9uLW1vZGVsLw0KDQpUaGVyZSB3YXMgaW50ZXJlc3QgaW4gdGhlIGRpc2N1c3Np b24gb24gdGhlIGFkb3B0aW9uIG9mIHRoZSB0b3BpYywgYnV0IHJhbiBvdXQgb2YgdGltZSB0byBn ZXQgY29uc2Vuc3VzIG9uIOKAnHdoZXJl4oCdIHRoZXNlIGludGVyYWN0aW9uIG1vZGVscyBzaG91 bGQgYmUgZG9jdW1lbnRlZC4gIEZ1cnRoZXIsIEhlbmsgc3RhcnRlZCBhbiBlbWFpbCB0aHJlYWQg cHJpb3IgdG8gb3VyIHNlc3Npb24gdG8gZ2V0IGEgc2Vuc2Ugb2YgaW50ZXJlc3QgYW5kIHdoZXJl IHRoZXNlIG1vZGVscyB3b3VsZCBiZXN0IGJlIGRlc2NyaWJlZC4NCkdpdmVuIHRob3NlIHJlc3Vs dHMsIHRoZXJlIHNlZW1lZCB0byBiZSBhIHByZWZlcmVuY2UgdG8ga2VlcCB0aGUgZG9jdW1lbnQg YXMgYSBzdGFuZGFsb25lIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGFsbCBtb2RlbHMuDQoNClRodXMs IHRoaXMgaXMgYSBDYWxsIGZvciBBZG9wdGlvbiBvZiB0aGUgZHJhZnQtYmlya2hvbHotcmF0cy1y ZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwgdG8gc2VydmUgYXMgdGhlIHN0YXJ0aW5nIHBvaW50 IGZvciBhIHN0YW5kYWxvbmUgZHJhZnQgdGhhdCBkZXNjcmliZXMgYWxsIG1vZGVscy4gIElmIHlv dSBoYXZlIHJlc2VydmF0aW9ucyBmb3IgZG9jdW1lbnRpbmcgaW50ZXJhY3Rpb24gbW9kZWxzLCBv ciBmb3Igc3VjaCBhIGRvY3VtZW50IHRvIGJlIGEgc3RhbmRhbG9uZSBkcmFmdCB0byBkZXNjcmli ZSBhbGwgb2YgdGhlbSBwbGVhc2UgcmVzcG9uZCB0byB0aGUgbWFpbCBsaXN0IGFuZCBwcm92aWRl IHJhdGlvbmFsZSBmb3IgeW91ciBjb25jZXJucy4NCg0KVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdp bGwgZW5kIG9uIEF1ZyAyOC4NCg0KQmVzdCwgTmFuY3kgKG9uIGJlaGFsZiBvZiB0aGUgUkFUcyBj aGFpcnMpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5z YWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRl bmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEg bm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24g eS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0 dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2Fq ZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVu dGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4g UGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpF c3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBz ZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBv dSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlk YWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlv IGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6Nv LCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBw cm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVz dGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Oj bw0K --_000_CF320C3C291E43C4B7F8586C082DE317telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F2A51F88B821342ADDAA699B20B9BDC@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1FUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5BZ3JlZWQuIEkgc3VwcG9ydCBhZG9wdGlvbuKApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZSBnb29kZSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZxdW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5E ciBEaWVnbyBSLiBMb3BlejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGVsZWZvbmljYSBJK0Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGlu LmNvbS9pbi9kcjJsb3Blei8iPmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Blei88 L2E+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPmUtbWFpbDombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJt YWlsdG86ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbSI+PHNwYW4gbGFuZz0iRVMiPmRpZWdv LnIubG9wZXpAdGVsZWZvbmljYS5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGVs OiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKzM0IDkxMyAxMjkg MDQxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Nb2JpbGU6ICZuYnNwOyszNCA2ODIgMDUxIDA5MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAx Mi8wOC8yMDIwLCAyMjo0MSwgJnF1b3Q7UkFUUyBvbiBiZWhhbGYgb2YgRXJpYyBWb2l0IChldm9p dCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyYXRzLWJvdW5jZXNAaWV0Zi5vcmciPnJhdHMt Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86ZXZvaXQ9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPmV2b2l0PTQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDsgd3JvdGU6PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFkb3B0ZWQu Jm5ic3A7Jm5ic3A7IElmIHdlIHdhbnQgaW50ZXJhY3Rpb24gbW9kZWwgY29tbW9uYWxpdHkgYWNy b3NzIHRoZSBXRywgdGhpcyBpcyBuZWVkZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5FcmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IFJBVFMg Jmx0O3JhdHMtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmFuY3kg Q2FtLVdpbmdldCAobmNhbXdpbmcpPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0 IDEyLCAyMDIwIDQ6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IHJhdHNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW1JhdHNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWJpcmtob2x6LXJh dHMtcmVmZXJlbmNlLWludGVyYWN0aW9uLW1vZGVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZWxsbyBSQVRzIG1l bWJlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BdCBv dXIgSUVURiAxMDggc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgdGhlIGRyYWZ0OiAmbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJlbmNlLWlu dGVyYWN0aW9uLW1vZGVsLyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJlbmNlLWludGVy YWN0aW9uLW1vZGVsLzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlRoZXJlIHdhcyBpbnRlcmVzdCBpbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgYWRv cHRpb24gb2YgdGhlIHRvcGljLCBidXQgcmFuIG91dCBvZiB0aW1lIHRvIGdldCBjb25zZW5zdXMg b24g4oCcd2hlcmXigJ0gdGhlc2UgaW50ZXJhY3Rpb24gbW9kZWxzIHNob3VsZCBiZSBkb2N1bWVu dGVkLiZuYnNwOyBGdXJ0aGVyLCBIZW5rIHN0YXJ0ZWQgYW4gZW1haWwgdGhyZWFkIHByaW9yIHRv IG91ciBzZXNzaW9uIHRvIGdldCBhDQogc2Vuc2Ugb2YgaW50ZXJlc3QgYW5kIHdoZXJlIHRoZXNl IG1vZGVscyB3b3VsZCBiZXN0IGJlIGRlc2NyaWJlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2NhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkdpdmVuIHRob3NlIHJlc3VsdHMsIHRoZXJlIHNlZW1lZCB0 byBiZSBhIHByZWZlcmVuY2UgdG8ga2VlcCB0aGUgZG9jdW1lbnQgYXMgYSBzdGFuZGFsb25lIGRy YWZ0IHRoYXQgZGVzY3JpYmVzIGFsbCBtb2RlbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2NhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRodXMsIHRoaXMgaXMgYSBDYWxsIGZvciBBZG9wdGlvbiBvZiB0aGUg ZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwgdG8gc2VydmUg YXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciBhIHN0YW5kYWxvbmUgZHJhZnQgdGhhdCBkZXNjcmli ZXMgYWxsIG1vZGVscy4mbmJzcDsgSWYgeW91IGhhdmUgcmVzZXJ2YXRpb25zIGZvciBkb2N1bWVu dGluZyBpbnRlcmFjdGlvbiBtb2RlbHMsDQogb3IgZm9yIHN1Y2ggYSBkb2N1bWVudCB0byBiZSBh IHN0YW5kYWxvbmUgZHJhZnQgdG8gZGVzY3JpYmUgYWxsIG9mIHRoZW0gcGxlYXNlIHJlc3BvbmQg dG8gdGhlIG1haWwgbGlzdCBhbmQgcHJvdmlkZSByYXRpb25hbGUgZm9yIHlvdXIgY29uY2VybnMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBjYWxsIGZvciBh ZG9wdGlvbiB3aWxsIGVuZCBvbiBBdWcgMjguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2NhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkJlc3QsIE5hbmN5IChvbiBiZWhhbGYgb2YgdGhlIFJBVHMgY2hhaXJzKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0i QXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRq dW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUg Y29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBh cmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBu byBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRl IHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBz aW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxl Z2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9y LCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3Rh IG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLjxicj4NCjxicj4NClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRo aXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0cmlidXRpb24gb3IgY29weWlu ZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQ bGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuPGJyPg0K PGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVu dGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxl Z2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBv dSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGlu YXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRp bGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9k ZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSBy ZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211 bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRl c3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CF320C3C291E43C4B7F8586C082DE317telefonicacom_-- From nobody Wed Aug 12 15:58:19 2020 Return-Path: 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 B64233A0C96 for ; Wed, 12 Aug 2020 15:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=SPyR/d7c; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=vlpw3RVN 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 vpiMITgnn7M6 for ; Wed, 12 Aug 2020 15:58:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3CC3A0C75 for ; Wed, 12 Aug 2020 15:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9103; q=dns/txt; s=iport; t=1597273094; x=1598482694; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZaN8oXC0zzAN2hBy0Tr7LWALBlGQSMeB8a9Infd3Img=; b=SPyR/d7cLngaDlHsSVAaYpKyAegEYxfHVz3fLQND3RXariv9UHxyen8D BbfSigXfbJFz1NMbL2R63qDpkisNRfDSoC36Y15qDpBIIf1TmmP7Qm1rw OKM83yvgxG+UBGH18S194KZhh4ZX41bVqqiqf/BDWXlDQIUX0bb/wUoaX Q=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AwjWBSxEpFxWV/71Yl1TqDJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAABgczRf/5tdJa1fGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgVIpKAdvKy0vLAqHcgONV5hmglMDVQQ?= =?us-ascii?q?HAQEBCQMBASUIAgQBAYRMAoI2AiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQE?= =?us-ascii?q?BAQMBEi4BATcBBAsCAQgVAwwBIQIwJQEBBAENDQYUgjlMgX5NAw4RDwEOp2Y?= =?us-ascii?q?CgTmIYXSBNIMBAQEFgUdBgyAYggcHAwaBOIFTgR6KHxqBQT+BVIJNPoJcAgI?= =?us-ascii?q?BAYFdg0iCLZsfmw0KgmKEOIJcgU+Feotdgn6dF4VXjFiBbIhRlHcCBAIEBQI?= =?us-ascii?q?OAQEFgWojgVdwFYMkUBcCDY4fDBeDToUUhUJ0NwIGCAEBAwl8jkkBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,305,1592870400"; d="p7s'?scan'208";a="800743846" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 22:58:13 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07CMwDUe032012 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 22:58:13 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 17:58:13 -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; Wed, 12 Aug 2020 17:58:13 -0500 Received: from NAM10-MW2-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; Wed, 12 Aug 2020 18:58:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BkEyRfuNoW5YmuN0VQJF8XzZgw9i2+YTllofogw9XCcIlelI7eGopuOTJerZHT2DXsfREKCZerMRcC+38Ggewo2qd5sDnRQaLwaBpI2+GnbzfCEahAPGahcte0W/73uY8RY/SnmFyO9jAythoMXeyBeFwyK8PB5eZ4cjBG549mAGXXfOd335qVNgAG6C+Z51tJfpMGfgUZloo8HfZ/zEs5xm6hpFONU2k5D/5DUjCUbS/gscEShfVqoEd8oN3zA315CCb53QZiuCtmYbMXxCJ190Xvb39wRrwYDE/92/DvLYBeVhPloFQqkb9rS7y1CMizoexIkQe9WblgdvhErl7g== 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=KMsZIR2v+ujRf2VK1KOhaKlXSZ+3XbkjlvGG+fte/SE=; b=AEsG9VhSgIjPChapheFwsDzn9gqcWwvQ/wzMYMMKNyffGiZFhiWK4jyzqYRGu1PePLxM0vgX+3nKBYHVuqBeLECWIaYMiHgdMCk5hECRSwaQHzag9oUxCQO7vyRQrVWWBQulTCvOS6XpCosEqLLYtp1rr19kpAhPk+bkvjT5YngNRcUzriZf7wBOUaakVR3fcVxZvh+FCleVjaeMAEnVjvTxAVmGxRYExC43djDuv3Ej+Wi7StdSDOeQZr2xl9/JbnHRH8hLHZC98/dRN7a/aKL3B5PQ3joP4oyQqJqHXHJE3+hhznwUoeMPoOlCJVSS6kziYnK+AQcfwdDU6HpeQA== 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=KMsZIR2v+ujRf2VK1KOhaKlXSZ+3XbkjlvGG+fte/SE=; b=vlpw3RVNzeKXhl9pb6J+2fyHuzuO+mMlBbmvKi+NREhS6VrArbFV4IIEpRVwXWOvKLEK6hgUh3i+MeV2eo/IORvZ9AlqwLnc/j8upf9MxKJfmFeCiSjVOQrMHifw/FfX1zr0gHo09QNreZ9SY28B2BsLQ4JlaWRIj9zOoLukStQ= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4584.namprd11.prod.outlook.com (2603:10b6:208:264::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 12 Aug 2020 22:58:11 +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; Wed, 12 Aug 2020 22:58:11 +0000 From: "Eric Voit (evoit)" To: Dave Thaler , Dave Thaler , "rats@ietf.org" CC: Wei Pan , "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6g Date: Wed, 12 Aug 2020 22:58:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-28T14:10:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=418b9af6-b4d5-4eb1-9d7d-e75014a19a02; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 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: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2cbb634f-ee54-44d3-2d92-08d83f133005 x-ms-traffictypediagnostic: MN2PR11MB4584: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PNQn6yiVQHISQlXP/NHln749n66tljlODAkkCvybXBIvD+kotTDeYMD0p9eEVqWvAzvLtjS3QBSKZ5amGKm0FQVcbrcuE6EfVlHxz6mpa2wTYW6tWp9QobM6G3zEsRPuh5RuxEfhYqaD3b/BSYkkSSNfSkAiRz3dzJM6gMCdfZtcXkTZePdQWBQ8rsgU//ql42bkk7kToExX1xN4M7riFFkG4977Zp10XhdvVuRHjGZkarOVR3Tktte8oQ41RF+oqVZxrSnyJsxE3xxMFL2sGp3yYOdScuNqfVwJpO3mXVVHaNdEKBQ8u+pi2JF2AuyK3fd7X6fL8GZWQpsqbq7ka824j1CJNbXLlBcufe6TT+XpMIsh7K7Uva3GJvgJoN5B3QKHBVRrMgrEr5J2Qol3Ug== 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; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(86362001)(66446008)(2906002)(110136005)(66616009)(54906003)(76116006)(66556008)(478600001)(71200400001)(316002)(5660300002)(966005)(83380400001)(4326008)(66476007)(26005)(66946007)(186003)(64756008)(9686003)(55016002)(99936003)(7696005)(8676002)(6506007)(52536014)(8936002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UQA6pBc48XVHxjJHSZnNkq0pZJei5mEEElKA7o2dxiY6vtZnBJgH7kEiOPFpM8sr0VjV4xWf+KZ4np64I4WWx9KXKwIrOj2+i69fGC/kk9y7yTkHJrK8ntfZ3shhQ4WLoQUV7sDYIW6ASATWBYBttYLrvMXBFNny0x3CesGgg3xlbekTy6LS8gqXjbUIocCU9IkTE+XbqIrqMUDlXTYfaPPd+nSTye/r+MkTZyHtmEhKKy69oJZ7rkjYeOpK77YA2GgS6HT99VZN2SwkQ006z4I9Ks2TQGMbctLYu7YnBsyQODg7/tHRr0PTXdbdv3kFRtEnvbJHOIq7C0mlhIRhowlQ/IHHqCj3kGFpKMsqnIyyC2xOcY5kxEma+eccTver6kvHFBZ4QYU6BCXW6Lk6bk66pJVK7vgogLnC6cYv6m24sducvemK+Wzr9wNgaCUoh7+GU7VlfCaaohdPzn1+kRiSsrWI9Xs0AOrYGc1GC3X7mX7wWzFVM48Ww41Ildcf0SQG+0aP8n2D5Iugyb0V9SgFTJePo53aggQk8xWbo2hi1+v4p2r3CXyItcbEiZ05e0MRoaK8kdl4sJ5cxB8agRkdvT3oQZly86B9yNP7DKfcbejNXu4UqWE5UBJb5lqAPJUl4XPk6nYiAeqqqpKVLg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0253_01D670D9.05FFE980" 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: 2cbb634f-ee54-44d3-2d92-08d83f133005 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 22:58:11.3927 (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: 5yLbFfglHD8lw67tE2M4PzAekW1/6mEwkLfJDlQPaRD7Zk6O2TZoC1GJRDxV2PoN X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4584 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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 22:58:17 -0000 ------=_NextPart_000_0253_01D670D9.05FFE980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dave, > From: Dave Thaler, August 12, 2020 5:43 PM > > Eric Voit wrote: > > > I asked in the meeting how a subscriber knows who to subscribe to, > > > and I believe the answer was that CHARRA answers that. > > > > The answer I gave was that the problem was the same as Charra. I > > believe I also said the problem itself is generic to any YANG based network > element (I don't remember if that came out). > > Generalizing more from there, Network Operators have diverse set > > embedded management systems which include discovery, addressability, > inventory, etc. of the network devices they manage. > > > > Moving back to YANG, these network management systems don't include all > YANG info about a device. > > So once you have found that a device exists, the device capabilities > > it supports can be acquired via a variety of mechanisms like: > > - NETCONF RFC 6241, Section 7 (and RFC6470) > > - YANG Library RFC 8525 > > > > > Well I looked in draft- > > > ietf-rats-yang-tpm-charra-02 and it does not contain any mention of > > > the subject. I think one or the other of the two drafts needs to > > > address this issue. > > > > This topic has not been within the scope of the many other YANG drafts/RFC > > which exist. This is reasonable as there is a huge breadth of topology > > discovery protocols available and in-use for routers and switches. > > The topic being discussed here is about *timing* (and windows of how long > things can be out of date for, > etc.) I expect that most other YANG drafts/RFCs do not cover that topic, > whereas Figure 1 of > draft-birkholz-rats-network-device-subscription specifically *does*. That's > what brings it in scope and why I believe it must be mentioned, even if it's by > reference to another document where the topic is covered. There are a YANG nodes relevant to such timings. For YANG datastores the best place to start is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilitie s/ and look through definitions like: +--ro subscription-capabilities +--ro max-nodes-per-update? uint32 +--ro periodic-notifications-supported? notification-support +--ro (update-period)? | +--:(minimum-update-period) | | +--ro minimum-update-period? uint32 | +--:(supported-update-period) | +--ro supported-update-period* uint32 +--ro on-change-supported? notification-support | {yp:on-change}? +--ro minimum-dampening-period? uint32 | {yp:on-change}? +--ro supported-excluded-change-type* union {yp:on-change}? However it is important to note that these capabilities above are for reporting on changes YANG datastore nodes. This is not the same thing as the placement of YANG notifications into event streams. Therefore for this event subscription draft, look to the definition of the "marshalling-period" leaf. This leaf attempts to define the problem from the perspective of the maximum amount of time from when an event extends a PCR to when the notification leaves the Attester. Eric > Dave ------=_NextPart_000_0253_01D670D9.05FFE980 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEyMjI0NzI2WjAjBgkqhkiG 9w0BCQQxFgQUwdkmJbmxl1rWVhKZzxp0ydntwREwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAO2kejmNr+BB7ScR4MZsoh1FE6uM4toT0Lh33dq4QMZTkKZbTDxPIHiAsO/7vibhHx N8/AeOeYylaoRaHWpjeA8fH7RExfepLV/vz3HtTTgjOeXBgrjB9xdHRwThAg7pqPSTudV0IBjOc6 GPX7FbWvPpdqkpJriQAmrHd5+8ox1yZ4WzGa82djkcSuU3oJUJVmqPYCigRrpXxkKeaA/GCDdKsd WzkaHui0m33JKo6H4LJ/cGmnO0Jk/SLAPI4MQheRrENPeMA7T8aOIchtPIagnN+s3l2ltKEN7DaK 1m9KbTilYnHGGZaaUNzdasVP5eDg6K5Hp934mWLDXHkY9JsdAAAAAAAA ------=_NextPart_000_0253_01D670D9.05FFE980-- From nobody Wed Aug 12 16:21:27 2020 Return-Path: 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 B73163A0D4C for ; Wed, 12 Aug 2020 16:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 CXHb7Boaik-4 for ; Wed, 12 Aug 2020 16:21:24 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2132.outbound.protection.outlook.com [40.107.236.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958A53A0CE0 for ; Wed, 12 Aug 2020 16:21:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FuKa3oF5eqmGBsRQs0ZrlMzG7HN9Et9oQRmyqJdmGH1fX0v8S8s+r6RcKAHTnXZm3jgzyCCfmbgZqKKIWkg6S3OFjy73VY6hPUmLvIEoJmqg+hI/B2FYwPba4zhEnx7HmzO/h+A976A3MZauTdh939oI5uiPAtqEkaSyYOr6GRvegpEwvRUjkrMpGt5ctwFYzpcANeF9NSlqpZIYIGBc2GHZuJeLXNqUc6CFqrAX0X4lXpVkDfAddtN3LNQXD6fY7nf34XYya84U7h6ie1rd1b5LgCeCC/TpMlSqFWlwbxy/XHdn7g8Fdq3OpI5GNdrZEarpfFKXjQwD5a/SFavhMw== 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=1yTKQ0NY5YYiCN8DVPMRPoCaRf7TO7kFzOw4T2uoefQ=; b=K/6MO5s4j1NLCNp5bZHdYDieFJ0WsssUFkbEoBEg0VxqlrfIxnEjpCz7BBJtwN//aja43lD9pk2EUw4fjTl+h5NlY0yPJza4+20/wFK0EBpyRURuWkma5Z49zQHUZ6lsTa+JvZc63yFL52c5TqHfcJaCuTQdtZODgckqki75QjdnBG/5RiQ6ZJK2X9BPMoUq8mbnqq5duQRbsmeBw0yWa0idk/VNTRrg2n/dgZB62wDVuwOSj7Uwkm56djWzmxB4JIdDfQ4YRq+QS9wD6dqVG2hIJbmU+NEYtT+c8ZN5RgbCjOZKhR7PU+6CbfzzXvmPvrrr1Om3+6FxQeiWizoBdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1yTKQ0NY5YYiCN8DVPMRPoCaRf7TO7kFzOw4T2uoefQ=; b=KB3nE3RpeIQXlNM+NKSElJYALVosulEzwiwcarpVG+Zco0FbAZVBfc3dSr8Mop75COnmBFu0jlHW7iFDjpetoA102fmIWRwJ1psVwRx6qrdoJSrkUciWHtjh/XVIGYjyG1ZSqFBn04sL0W9W39ULubiuIPNMaX1w/Azif9glOQw= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1842.namprd21.prod.outlook.com (2603:10b6:207:1a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.1; Wed, 12 Aug 2020 23:21:16 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::41c0:a400:b7aa:e3b8]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::41c0:a400:b7aa:e3b8%5]) with mapi id 15.20.3283.014; Wed, 12 Aug 2020 23:21:16 +0000 From: Dave Thaler To: "Eric Voit (evoit)" , Dave Thaler , "rats@ietf.org" CC: Wei Pan , "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6gAAHIi0A= Date: Wed, 12 Aug 2020 23:21:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-28T14:10:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=418b9af6-b4d5-4eb1-9d7d-e75014a19a02; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:9780:16f0:3029:9ddd:28d2:bcfd] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3ede1709-b0ef-4b77-f718-08d83f166994 x-ms-traffictypediagnostic: BL0PR2101MB1842: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P51G+XdABeprk4SKnAQtViso+yOOK1jRl05Xti6r7+uG3dAYb2MbvEJy2lk5gT8up5advhYY4VGrdg8iB1tPNX0pW6+DsM5/9371CL0euiPZ849Izml2fbfVaMetGgyaAAA2v9TkMq1ukb1tXDqYNlhtsy48M2fwIIyRqYSLLSTcHxdiaFJtX2WBvsuTgUi/pB27905l0StqU3wPFBGem/DzJtOu4aJrJrHqFY6aFH67UNDPkj1/lPiBlHs7LUPdna+HtWKT5uVI16yr9rF0Wdu2W1pHN/zrBAlMVDC9GH7el4Pp+feugPXXLdbc53wdjNv3c+7kD+aUzPsp8EaDJir6itDuxFwCs53CTTzEDe3Q7DNOfnupxFUyPvHSeou4dupL66oR72qNC4RMFRkwzQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(82950400001)(82960400001)(54906003)(110136005)(4326008)(8676002)(8990500004)(316002)(186003)(10290500003)(52536014)(83380400001)(7696005)(8936002)(6506007)(9686003)(5660300002)(33656002)(478600001)(66556008)(966005)(66476007)(64756008)(86362001)(71200400001)(66446008)(66946007)(4744005)(76116006)(55016002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ARm6iHgmT7F3ki84ilN0poayP5VT6aiQaPUqW8CYtITYzdyw4vllhXuOlRIErBIoVWFi93o0h6W2cItZR6146GTNRlh/hj2pJqfhnwmCxmd2y3f49dZp14ryMmdQjyDpAuLgBiK2XmAIx7OhdLG0pKmdVkTOSkFbUlZTkL0LvHI+rP/K4YdsthfFYXnmNQMnX8fDj1nOjFTnPhQee7kG6WzhepLGDshlF4rUQaiaQeWf8lootUothzVwB1soSFl4vExvZISYJfcBjNKx+oR9CtvxZuTd2E6rAzTtvAY3iR99y9F33oTKdgyc/V0v7nTbOiAqUQsu9u8W5YVv556fUKai3etvMWq2CR6A1GDVPFOey+9YHOeYL9FyFf18EuRoIP/8WZzXWAhh3w0Gx9oRMpNBMIMdAyFxV0SQk8QXdao2r6TFDvy/Gv68Zf9z4YZYsmYl3oKcnIZKqn927PL9pkbXLtUu1E+1auJr3jMWTHcqDxiaPfDf2ipVq4aOxV3yKGp2bRseLv9/Anp2YdfEui7JS3wOGSjM115QUNy5wHyy3khi3NVCWou2Sxt9vmjgP5/+HXhnMRHvUNXrikrLCU0pPV4JzR9/TjHZFZmY3KZaJGd3aED9IdILsAfwrtQTPyddDcr/AaMX7MZSbAmcIlpegCyA7RoiMJji4LJIWM4XTAjdQ7Q8XGOEo6BQMByE8ahn3RSDTgM+gABsKkY6Jg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ede1709-b0ef-4b77-f718-08d83f166994 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 23:21:16.4456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nSbFf4pKUJa1bLM/oD1c1VPEuEwmDz+OmuCYkszVPUq8NXheBrDckFa/JBJM5nMfNlTZwZHLDVBq4vKQx4XTHXnPN1LdtN/CCxb7DK6R1FY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1842 Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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 23:21:26 -0000 Eric Voit wrote: [...] > There are a YANG nodes relevant to such timings. For YANG datastores the > best place to start is:=20 > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/=20 > and look through definitions like: [...] Sounds like you're saying yes there is a referencable document. I'm sayin= g the answer should be in the doc not (just) in an email message in the list archive, si= nce the doc talks about timing in the section with Figure 1. Dave From nobody Wed Aug 12 18:19:07 2020 Return-Path: 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 1CAE53A155F for ; Wed, 12 Aug 2020 18:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D90HJPD9gpIl for ; Wed, 12 Aug 2020 18:19:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE6F3A0E3B for ; Wed, 12 Aug 2020 18:19:04 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BC80C2E41F38B990DC42 for ; Thu, 13 Aug 2020 02:19:01 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 02:19:01 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 09:18:58 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 13 Aug 2020 09:18:58 +0800 From: "Panwei (William)" To: "Nancy Cam-Winget (ncamwing)" , "rats@ietf.org" Thread-Topic: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model Thread-Index: AQHWcOa5ocl00PiKFEWQHfz6I5Hx9qk1PUcg Date: Thu, 13 Aug 2020 01:18:58 +0000 Message-ID: <7353086993874b3285c845a3efb66f53@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_7353086993874b3285c845a3efb66f53huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 01:19:06 -0000 --_000_7353086993874b3285c845a3efb66f53huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpSZWdhcmRzICYgVGhh bmtzIQ0KV2VpIFBhbg0KDQpGcm9tOiBSQVRTIFttYWlsdG86cmF0cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTmFuY3kgQ2FtLVdpbmdldCAobmNhbXdpbmcpDQpTZW50OiBUaHVyc2Rh eSwgQXVndXN0IDEzLCAyMDIwIDQ6MjYgQU0NClRvOiByYXRzQGlldGYub3JnDQpTdWJqZWN0OiBb UmF0c10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2Ut aW50ZXJhY3Rpb24tbW9kZWwNCg0KSGVsbG8gUkFUcyBtZW1iZXJzLA0KQXQgb3VyIElFVEYgMTA4 IHNlc3Npb24gd2UgZGlzY3Vzc2VkIHRoZSBkcmFmdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJlbmNlLWludGVyYWN0aW9uLW1vZGVs Lw0KDQpUaGVyZSB3YXMgaW50ZXJlc3QgaW4gdGhlIGRpc2N1c3Npb24gb24gdGhlIGFkb3B0aW9u IG9mIHRoZSB0b3BpYywgYnV0IHJhbiBvdXQgb2YgdGltZSB0byBnZXQgY29uc2Vuc3VzIG9uIOKA nHdoZXJl4oCdIHRoZXNlIGludGVyYWN0aW9uIG1vZGVscyBzaG91bGQgYmUgZG9jdW1lbnRlZC4g IEZ1cnRoZXIsIEhlbmsgc3RhcnRlZCBhbiBlbWFpbCB0aHJlYWQgcHJpb3IgdG8gb3VyIHNlc3Np b24gdG8gZ2V0IGEgc2Vuc2Ugb2YgaW50ZXJlc3QgYW5kIHdoZXJlIHRoZXNlIG1vZGVscyB3b3Vs ZCBiZXN0IGJlIGRlc2NyaWJlZC4NCkdpdmVuIHRob3NlIHJlc3VsdHMsIHRoZXJlIHNlZW1lZCB0 byBiZSBhIHByZWZlcmVuY2UgdG8ga2VlcCB0aGUgZG9jdW1lbnQgYXMgYSBzdGFuZGFsb25lIGRy YWZ0IHRoYXQgZGVzY3JpYmVzIGFsbCBtb2RlbHMuDQoNClRodXMsIHRoaXMgaXMgYSBDYWxsIGZv ciBBZG9wdGlvbiBvZiB0aGUgZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rp b24tbW9kZWwgdG8gc2VydmUgYXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciBhIHN0YW5kYWxvbmUg ZHJhZnQgdGhhdCBkZXNjcmliZXMgYWxsIG1vZGVscy4gIElmIHlvdSBoYXZlIHJlc2VydmF0aW9u cyBmb3IgZG9jdW1lbnRpbmcgaW50ZXJhY3Rpb24gbW9kZWxzLCBvciBmb3Igc3VjaCBhIGRvY3Vt ZW50IHRvIGJlIGEgc3RhbmRhbG9uZSBkcmFmdCB0byBkZXNjcmliZSBhbGwgb2YgdGhlbSBwbGVh c2UgcmVzcG9uZCB0byB0aGUgbWFpbCBsaXN0IGFuZCBwcm92aWRlIHJhdGlvbmFsZSBmb3IgeW91 ciBjb25jZXJucy4NCg0KVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgZW5kIG9uIEF1ZyAyOC4N Cg0KQmVzdCwgTmFuY3kgKG9uIGJlaGFsZiBvZiB0aGUgUkFUcyBjaGFpcnMpDQoNCg== --_000_7353086993874b3285c845a3efb66f53huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTsNCglwYW5vc2UtMToyIDEgNiAwIDQgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2Ut MToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkdhZHVnaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBzdXBwb3J0IGFkb3B0aW9u IG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjExMCUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDts aW5lLWhlaWdodDoxMTAlO2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5SZWdhcmRzICZhbXA7IFRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEwJSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0OjExMCU7Zm9udC1m YW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldlaSBQYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtH YWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBSQVRTIFttYWlsdG86cmF0cy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5OYW5jeSBDYW0tV2luZ2V0IChuY2Ftd2luZyk8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMywgMjAyMCA0OjI2IEFNPGJyPg0KPGI+ VG86PC9iPiByYXRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtSYXRzXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiBkcmFmdC1iaXJraG9sei1yYXRzLXJlZmVyZW5jZS1pbnRlcmFjdGlvbi1t b2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+SGVsbG8gUkFUcyBtZW1iZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzst d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+QXQgb3VyIElFVEYgMTA4IHNlc3Npb24gd2UgZGlzY3Vzc2VkIHRoZSBkcmFmdDogJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLXJlZmVyZW5j ZS1pbnRlcmFjdGlvbi1tb2RlbC8iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLXJlZmVyZW5jZS1p bnRlcmFjdGlvbi1tb2RlbC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5UaGVyZSB3YXMgaW50ZXJlc3QgaW4gdGhlIGRpc2N1c3Npb24gb24gdGhlIGFkb3B0aW9uIG9m IHRoZSB0b3BpYywgYnV0IHJhbiBvdXQgb2YgdGltZSB0byBnZXQgY29uc2Vuc3VzIG9uIOKAnHdo ZXJl4oCdIHRoZXNlIGludGVyYWN0aW9uIG1vZGVscyBzaG91bGQgYmUgZG9jdW1lbnRlZC4mbmJz cDsgRnVydGhlciwgSGVuayBzdGFydGVkIGFuIGVtYWlsIHRocmVhZCBwcmlvciB0byBvdXIgc2Vz c2lvbg0KIHRvIGdldCBhIHNlbnNlIG9mIGludGVyZXN0IGFuZCB3aGVyZSB0aGVzZSBtb2RlbHMg d291bGQgYmVzdCBiZSBkZXNjcmliZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRv Oy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5HaXZlbiB0aG9zZSByZXN1bHRzLCB0aGVyZSBzZWVtZWQgdG8gYmUgYSBwcmVmZXJl bmNlIHRvIGtlZXAgdGhlIGRvY3VtZW50IGFzIGEgc3RhbmRhbG9uZSBkcmFmdCB0aGF0IGRlc2Ny aWJlcyBhbGwgbW9kZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaHVzLCB0aGlz IGlzIGEgQ2FsbCBmb3IgQWRvcHRpb24gb2YgdGhlIGRyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJl bmNlLWludGVyYWN0aW9uLW1vZGVsIHRvIHNlcnZlIGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3Ig YSBzdGFuZGFsb25lIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGFsbCBtb2RlbHMuJm5ic3A7IElmIHlv dSBoYXZlIHJlc2VydmF0aW9ucyBmb3IgZG9jdW1lbnRpbmcgaW50ZXJhY3Rpb24NCiBtb2RlbHMs IG9yIGZvciBzdWNoIGEgZG9jdW1lbnQgdG8gYmUgYSBzdGFuZGFsb25lIGRyYWZ0IHRvIGRlc2Ny aWJlIGFsbCBvZiB0aGVtIHBsZWFzZSByZXNwb25kIHRvIHRoZSBtYWlsIGxpc3QgYW5kIHByb3Zp ZGUgcmF0aW9uYWxlIGZvciB5b3VyIGNvbmNlcm5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBlbmQgb24gQXVnIDI4LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5CZXN0LCBOYW5jeSAob24gYmVoYWxmIG9mIHRoZSBSQVRzIGNo YWlycyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7353086993874b3285c845a3efb66f53huaweicom_-- From nobody Wed Aug 12 20:52:30 2020 Return-Path: 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 D55FC3A1635 for ; Wed, 12 Aug 2020 20:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uP6oStRj0stI for ; Wed, 12 Aug 2020 20:52:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADED3A1634 for ; Wed, 12 Aug 2020 20:52:25 -0700 (PDT) Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 85C5D1F259BDE4C9F53D; Thu, 13 Aug 2020 04:52:22 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 13 Aug 2020 04:52:21 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 11:52:19 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 13 Aug 2020 11:52:19 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" , Dave Thaler , Dave Thaler , "rats@ietf.org" CC: "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6gAAcrZWA= Date: Thu, 13 Aug 2020 03:52:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 03:52:28 -0000 Hi Eric, Hi Dave, I think Dave's question is that how the YANG module reflects the different = time points in Figure 1, e.g., time(VG), time(EG), time(NS), and time(RG, R= A). My feeling is that time(VG), time(EG), and time(NS) don't need to be reflec= ted. For the routers and switches, the time(VG) is usually when the devices= boot, and it can be much earlier than the Evidence generation and appraisa= l, so usually the Verifier doesn't care about it. When the Verifier wants t= o establish the subscription, it generates a nonce and sends the subscripti= on request to the Attester at the time(NS). The Attester doesn't need to kn= ow the time(NS), it just generates the Evidence according to the 'values' a= nd nonce, and theoretically it should send back the Evidence to the Verifie= r immediately after generation. The Verifier can appraise the Evidence's fr= eshness based on the nonce and the time interval between sending the subscr= iption and receiving the Evidence, so there is usually no need for the Veri= fier to know the exact time(EG). The time(RG, RA) may need to be reflected in the Attestation Result, but ne= ither CHARRA nor this subscription draft includes this scope. I think draft= -voit-rats-trustworthy-path-routing should consider this because it defines= the Attestation Result YANG module. After subscription, when a new event happens (e.g., the PCRs extends with a= new value), the Attester will generate a new Evidence and send it to the V= erifier. Usually the time(VG'), time(EG') and time(RG') are very close. But= the "marshalling-period" leaf defined in this draft do give the Attester a= n opportunity to fold multiple 'values' into one Evidence to reduce the amo= unt of notifications when multiple events happen in short succession. It re= flects the max time interval between the first time(VG') and the time(EG') = to the Verifier. So for now, I think current CHARRA and RATS subscription YANG modules don't= need to explicitly reflect the exact time of these time points. Regards & Thanks! Wei Pan > From: Eric Voit (evoit) Thursday, August 13, 2020 6:58 AM > > > The topic being discussed here is about *timing* (and windows of how > long > > things can be out of date for, > > etc.) I expect that most other YANG drafts/RFCs do not cover that top= ic, > > whereas Figure 1 of > > draft-birkholz-rats-network-device-subscription specifically *does*. > That's > > what brings it in scope and why I believe it must be mentioned, even if > it's by > > reference to another document where the topic is covered. >=20 > There are a YANG nodes relevant to such timings. For YANG datastores the > best place to start is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= tie > s/ > and look through definitions like: >=20 > +--ro subscription-capabilities > +--ro max-nodes-per-update? uint32 > +--ro periodic-notifications-supported? notification-support > +--ro (update-period)? > | +--:(minimum-update-period) > | | +--ro minimum-update-period? uint32 > | +--:(supported-update-period) > | +--ro supported-update-period* uint32 > +--ro on-change-supported? > notification-support > | {yp:on-change}? > +--ro minimum-dampening-period? uint32 > | {yp:on-change}? > +--ro supported-excluded-change-type* union > {yp:on-change}? >=20 > However it is important to note that these capabilities above are for > reporting on changes YANG datastore nodes. This is not the same thing as > the placement of YANG notifications into event streams. Therefore for th= is > event subscription draft, look to the definition of the "marshalling-peri= od" > leaf. This leaf attempts to define the problem from the perspective of = the > maximum amount of time from when an event extends a PCR to when the > notification leaves the Attester. >=20 > Eric >=20 >=20 > > Dave From nobody Thu Aug 13 02:24:09 2020 Return-Path: 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 0A0C33A0A4D; Thu, 13 Aug 2020 02:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mN1FevsvknSQ; Thu, 13 Aug 2020 02:24:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FEE3A0A49; Thu, 13 Aug 2020 02:24:06 -0700 (PDT) Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 72FD12FD4BA59B436D21; Thu, 13 Aug 2020 10:24:02 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 10:24:01 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 17:23:59 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 13 Aug 2020 17:23:59 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Comments on the changes of CHARRA YANG module Thread-Index: AdZWpd3aUHkm/3I1RKafnNj2CppmIwAHwgsgAAAIMzAAAASPEASf77EQABwSseAAG9AKEAHLrgSg Date: Thu, 13 Aug 2020 09:23:59 +0000 Message-ID: <3182ad9e4a1045f499d8c4bfcfb2b55c@huawei.com> References: <4e2e0b53d2be47009b1958758620914c@huawei.com> <3cac223f282f47f882f6da0507b0b841@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Comments on the changes of CHARRA YANG module X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 09:24:08 -0000 Hi Eric, authors, > > This is not a problem, the question is then do we make this a case > > statement, or use XPATH. Either one works. Do you want to propose > the > > YANG model change? >=20 > Sure, I can propose a change in the github. I've submit a PR (https://github.com/ietf-rats-wg/basic-yang-module/pull/11= ), please have a check. Regards & Thanks! Wei Pan From nobody Thu Aug 13 05:28:51 2020 Return-Path: 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 DCD2D3A0BDF; Thu, 13 Aug 2020 05:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2kqkqxG2AqeI; Thu, 13 Aug 2020 05:28:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89A53A0BE9; Thu, 13 Aug 2020 05:28:46 -0700 (PDT) Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C6C3F58051951C0DB629; Thu, 13 Aug 2020 13:28:44 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 13:28:44 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 20:28:41 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 13 Aug 2020 20:28:41 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Some new comments for CHARRA YANG module Thread-Index: AdZxbUUfWQ8kKtvDQNubGicd9eCWvQ== Date: Thu, 13 Aug 2020 12:28:41 +0000 Message-ID: <300450dd9780421aa1b9f5afa88261fc@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_300450dd9780421aa1b9f5afa88261fchuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Rats] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 12:28:49 -0000 --_000_300450dd9780421aa1b9f5afa88261fchuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, In modifying the YANG module, I have some new comments about the module. 1. Do we still need the basic-trust-establishment now? It provides the func= tion of retrieving the certificates of TPM2.0. But I think now the certific= ates can be get from the rats-support-structure and ietf-keystore. 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-obj= ects is a list. So you can challenge for different pcr-lists of different T= PMs 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 | | +---w add-version? boolean | | +---w tpm-name* string In the TPM1.2 challenge input, if you want to challenge for different pcr-i= ndexs of different TPMs, you need to construct multiple challenge inputs wi= th different nonce values. I think it's better to change the style of TPM1.2 to the same one of TPM2.0= . 3. In the log-retrieval part, the input uses tpm-name as the identifier, bu= t the output uses certificate-name. The certificate-name isn't used in the = log-result, should we also use tpm-name as the identifier of output? Regards & Thanks! Wei Pan --_000_300450dd9780421aa1b9f5afa88261fchuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

In modifying the YANG module, I have some new comments about the = module.

1. Do we still need the basic-trust-establishment now? It provide= s the function of retrieving the certificates of TPM2.0. But I think now the certificates can be get from the rats-support-structur= e and ietf-keystore.

2. The styles of challenge input for TPM1.2 and TPM2.0 are differ= ent.

 =      +---x tpm20-challenge-response-attestation {TP= M20}?

 =      |  +---w input

 =      |  |  +---w tpm20-attestation-cha= llenge

 =      |  |     +---w nonce-value        &n= bsp; binary

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

 =      |  |       = ; +---w pcr-list* [TPM2_Algo]

 =      |  |       = ; |  +---w TPM2_Algo        ide= ntityref

 =      |  |       = ; |  +---w pcr-index*       tpm:pcr<= o:p>

 =      |  |       = ; +---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 cha= llenge-objects is a list. So you can challenge for different pcr-lists of different TPMs in one challenge input.

 =      +---x tpm12-challenge-response-attestation {TP= M12}?

 =      |  +---w input

 =      |  |  +---w tpm1-attestation-chal= lenge

 =      |  |     +---w pcr-in= dex*            = ;  pcr

 =      |  |     +---w nonce-value         &= nbsp;   binary

 =      |  |     +---w TPM12_= Algo?           &nbs= p; identityref

 =      |  |     +---w (key-i= dentifier)?

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

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

 =      |  |     |  +--:= (TSS_UUID)

 =      |  |     |  &nb= sp;  +---w TSS_UUID-value

 =      |  |     |  &nb= sp;     +---w ulTimeLow?    &nb= sp;  uint32

 =      |  |     |  &nb= sp;     +---w usTimeMid?    &nb= sp;  uint16

 =      |  |     |  &nb= sp;     +---w usTimeHigh?     &= nbsp;uint16

 =      |  |     |  &nb= sp;     +---w bClockSeqHigh?   uint8=

 =      |  |     |  &nb= sp;     +---w bClockSeqLow?    uint8=

 =      |  |     |  &nb= sp;     +---w rgbNode*     = ;    uint8

 =      |  |     +---w add-ve= rsion?            bo= olean

 =      |  |     +---w tpm-na= me*             = ;  string

In the TPM1.2 challenge input, if you want to challenge for diffe= rent pcr-indexs of different TPMs, you need to construct multiple challenge inputs with different nonce values.

I think it’s better to change the style of TPM1.2 to the sa= me one of TPM2.0.

3. In the log-retrieval part, the input uses tpm-name as the iden= tifier, but the output uses certificate-name. The certificate-name isn’t used in the log-result, should we also use tp= m-name as the identifier of output?

 

Regards & Thanks!

Wei Pan

--_000_300450dd9780421aa1b9f5afa88261fchuaweicom_-- From nobody Thu Aug 13 05:42:12 2020 Return-Path: X-Original-To: rats@ietf.org Delivered-To: rats@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0B3A0C0B; Thu, 13 Aug 2020 05:42:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rats@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rats@ietf.org Message-ID: <159732252134.29471.2012606737744895787@ietfa.amsl.com> Date: Thu, 13 Aug 2020 05:42:01 -0700 Archived-At: Subject: [Rats] I-D Action: draft-ietf-rats-tpm-based-network-device-attest-03.txt X-BeenThere: rats@ietf.org X-Mailman-Version: 2.1.29 List-Id: Remote ATtestation procedureS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 12:42:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote ATtestation ProcedureS WG of the IETF. Title : TPM-based Network Device Remote Integrity Verification Authors : Guy Fedorkow Eric Voit Jessica Fitzgerald-McKay Filename : draft-ietf-rats-tpm-based-network-device-attest-03.txt Pages : 38 Date : 2020-08-13 Abstract: This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-device-attest/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rats-tpm-based-network-device-attest-03 https://datatracker.ietf.org/doc/html/draft-ietf-rats-tpm-based-network-device-attest-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-tpm-based-network-device-attest-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 13 06:02:37 2020 Return-Path: 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 9FAB53A0C0B for ; Thu, 13 Aug 2020 06:02:32 -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_H4=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=Ci0tjLJN; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=zth3h/Tt 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 yRWk1qFc_TXp for ; Thu, 13 Aug 2020 06:02:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3659D3A0C04 for ; Thu, 13 Aug 2020 06:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14870; q=dns/txt; s=iport; t=1597323750; x=1598533350; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MeD0uzo+b5IJ6hOTPIat8t0e85zRBok6k6eWYtiQCuc=; b=Ci0tjLJNDJC0CO+9GFNJYVr3BOqvoJM6WwYkOont5jK+DmwCxRBcJDMN DTMSevtZioI/dFBITzUtprDjzHkcUcP0tWg4IRMS8a/QzzvZJPaCKMYf5 UMtSkN0P2jzSzLOLtwp5t9z4AgCmBzd3YBUWoln8DPxxUnsIi/nUYo8Lr Y=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AzMiFVR2ieMvqNHZSsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFv6dojVTTWp7c5e4CgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8P/bEfVuXq88XgZHR?= =?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?A0BjAQDYODVf/5NdJa1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYEiLykoB3ArLS8sCodyA41Xh16MHIRtgUKBEQN?= =?us-ascii?q?VBAcBAQEJAwEBIwoCBAEBhEwCgkACJDcGDgIDAQELAQEFAQEBAgEGBG2FXAy?= =?us-ascii?q?FcQEBAQMBEhsTAQE3AQQLAgEIDgcQIQIwJQIEAQ0NBhSCOUyBfk0DDhEPAQ6?= =?us-ascii?q?mUQKBOYhhdIE0gwEBAQWBR0GDIBiCBwcDBoE4AYFSgR6KEA8agUE/gVSCTT6?= =?us-ascii?q?CXAICAQGBJgESASMrgx2CLY9hiz6bDQqCYoQ4glyBT4JCjxigFYVajFmKP5R?= =?us-ascii?q?3AgQCBAUCDgEBBYFpJGdwcBU7gmlQFwINjh+DcYUUhUJ0NwIGCgEBAwl8jnA?= =?us-ascii?q?BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="p7s'?scan'208,217";a="811343533" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 13:02:28 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DD2SaN021320 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 13:02:28 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:02:28 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 09:02:27 -0400 Received: from NAM11-BN8-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; Thu, 13 Aug 2020 08:02:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NiYceXobbnYSfGnfUq/MQD7DPI7ySAkH4WUTvcaklxtg07jpxnmOx62fexmXYQQ1nWFRyYxmFokZllPMtwRXzzJ64sBbfUkybhk/vNUAR7eXwJnu6vFnnoJCkiAuF9Z95OqMxYCdHPw2KtNre8zQrCRPRHR8vod15UWADqHLL6MCKhIu9JZHnpvYsz1JUEg1gG3yoDmRVZBcAj7+Rmzp09UmXYaW8qqK0+ceaYd+67yleW35+8izCfJFeDWQaoWkqej74yl2y1OeMzAiWasn1VFA5zCvOswZQGsqYXKUkCXfNUKrBYNu5ikm9heODGvyjhezvEjiE5DCvGj/8HTT/w== 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=UxoJ3Bg86cm75Zqi9hHYzalmYbOCin4R6SwuwWoZ8o0=; b=lLd5z8GOWECm+xJO1I+bx1mBPvKOz3ve+pq+vAtJCkrHYErGP1J/PS0+1YchGKC/FD03xZb3QY1UsMzi5eq3APqzktuP+CRJrYnrfzarq0ozBUfQ58YX9en4XqlDiHSWjm7exfN8mDnmjfot9pgdxMtmgkOccpuH4ii3y5ue0ObF+lY3ttJsUbJjRwAs99XBV4brAPo6bj3s91Rf5QIDFkhoq6Cuu3/cW/6mp3Cw9WY4/tjLR7R0jiwkvSiBJnr8Oz/Z4y5b1fDrm3KY3no5c3p3V3E8vZmX/iEWLf6R/AaxW0d8SIi0ggsCqxJnONnj2syQJK3zE+dCzFm8IAwubA== 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=UxoJ3Bg86cm75Zqi9hHYzalmYbOCin4R6SwuwWoZ8o0=; b=zth3h/TtPa/DXFjyFVlsjJS4U6bnN3KYAsCH4+Xvux3kVNAXsrGMIaO1qRCzO08X9KjeCszbzRbNkHn/bccxbSDkGSkMK2SJhReyUs2l4c4Kdt3j306QHadBWKwafddlx2mj7GHrOvdWUTWPNgF6G0tBgg4zSgwMZr09yuxuhsk= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4080.namprd11.prod.outlook.com (2603:10b6:208:137::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Thu, 13 Aug 2020 13:02:26 +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; Thu, 13 Aug 2020 13:02:26 +0000 From: "Eric Voit (evoit)" To: Dave Thaler , Dave Thaler , "rats@ietf.org" CC: Wei Pan , "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6gAAHIi0AAGrLvgA== Date: Thu, 13 Aug 2020 13:02:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-28T14:10:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=418b9af6-b4d5-4eb1-9d7d-e75014a19a02; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3becbc8e-6472-4967-dc57-08d83f89208d x-ms-traffictypediagnostic: MN2PR11MB4080: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IhQR2QUP+EDWd7MfKZnA49KSUHR179FKyRK2FZh4MLyhertC9NMIrnKv7uIBtuuMNr/NDQyom34FD3v3IfsRnhuLZAqus/+DXS7uK33B6E/GEaZe5HCEW3OO6O+NUG8V8I7PL3u6AfxqZiAOAZSQ36AJoe/TLhXuaHts30OINbOWiuS8oHA/Qlmy1y16oNsW8xVJgSwIzVhgZ9YIfKYcTq5jdOHomam5O1E40tQdtK8RQ6rzrYoIlrne9maiV8x3o2CHrO8T0kRUyQSCVGXH+0eKSN1Dp3FfitF0GR3JCEPrJgP/5CdcteA8SjEXofHzthmUFwPiFmeLZFqLP4zS3xleTdCyvGf3IUtr70yyg7hHgI4ucl2gEoo9L3734Vid7KxcbR0/PRdjVVNVG/dj6A== 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)(39860400002)(346002)(366004)(376002)(136003)(396003)(99936003)(86362001)(33656002)(76116006)(71200400001)(7696005)(9686003)(66616009)(316002)(26005)(66446008)(64756008)(66556008)(66476007)(66946007)(186003)(166002)(966005)(478600001)(5660300002)(8936002)(110136005)(83380400001)(4326008)(54906003)(6506007)(8676002)(55016002)(2906002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KKM/DsVC75LD20lzSD8WtvvnXPHhFiwpbfBUw9ZGYkI/Aj7jwL698/nAxGdppLFe0aReZ8NEjCu6adG1uScsnbB/fzF3RCsz2sJWzYzOnK+H0/DcVNR+c0FpaGTU8SvbrFU+8gcElqKrIAQEnNKZp4Olm1Vsb8Y5Pf0azNe+0GeEiq9MQ2QjbNDK4OPzYOigq1X212pItc1/LLLHMaalA4h0UbUZLebz9UO5RJq7Y3BgPnukeLdb106eBDHufpz6IJoy+jNBScvwBaX4rNfWHUL5ZUbUPbl4fMr0I0jiDhacKpqy/PpdRxy3uE5DbGPX17u0hVxclM4n7uHvUCXPkvXto/H43gq1R+/WY1sTCbzVJyRJAH4LqiX47IdT1XC0S/7l4hN1ajgm+zc2WWZ3N0WnFI9V1w2j+B4Uqh8fXCN5mdNEgSqIAknecvTg4VewF4T+ONJN+Lm4+dB6yRIU5+yCtkZVyHdmVozXB01+Y26ixB0VpOa2J77hh1vKqjQy9nakYOEynz3qPNDyKrV6RKBoSpltzhA3m4uB0L5eOHKot1xbOqO2Ztu5GHO9uUclbW2INDNNhEn5uWHTuHP5j5/3JFHk6GPq1jsMZ8Pj0FALbe/YphY2CaZi5G49MkMbGVH2+wsuMOiwPLUWRc3FYw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02A1_01D6714E.161F5BF0" 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: 3becbc8e-6472-4967-dc57-08d83f89208d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:02:26.0490 (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: 0Om2SY+0jBjDexT9sWGlFxncUVenUFHR2lqKudA8gX4t0y9GG+Fybcph75JX2KYR X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4080 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 13:02:34 -0000 ------=_NextPart_000_02A1_01D6714E.161F5BF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02A2_01D6714E.161F5BF0" ------=_NextPart_001_02A2_01D6714E.161F5BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Dave Thaler, August 12, 2020 7:21 PM > > Eric Voit wrote: > [...] > > There are a YANG nodes relevant to such timings. For YANG datastores > > the best place to start is: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capab > > ilities/ > > and look through definitions like: > [...] > > Sounds like you're saying yes there is a referencable document. I'm saying the > answer > should be in the doc not (just) in an email message in the list archive, since the > doc talks about timing in the section with Figure 1. The answer is in the document. Section 4.3.1 talks about a which is associated with the of Figure 1. The was also described within yesterday's thread. Here is its YANG definition: leaf marshalling-period { config true; type uint8; default 5; description "The maximum number of seconds between the time an event extends a PCR, and the 'tpm-extend' notification which reports it to a subscribed Verifier. This period allows multiple extend operations bundled together and handled as a group."; } I have highlighted this information under Figure 1 so that readers of that section do not have to search it out. o time(eg) - Directly subsequent to the request, an initial response of Evidence is returned to the Verifier. This includes: ... o time(vg',eg') - This occurs when a PCR is extended subsequent to time(eg). Within a configurable marshalling period after the extension (see Section 4.3.1), the following information needs to be pushed to the Verifier: ... Eric > Dave ------=_NextPart_001_02A2_01D6714E.161F5BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> From: Dave Thaler, August 12, 2020 7:21 = PM

>

> Eric = Voit wrote:

> [...]

> > There are a YANG nodes relevant to such = timings.  For YANG datastores

> > = the best place to start is:

> > https://datatracker.ietf.= org/doc/draft-ietf-netconf-notification-capab

> > ilities/

> = > and look through definitions like:

> = [...]

>

> = Sounds like you're saying yes there is a referencable = document.   I'm saying the

> = answer

> should be in the doc not (just) = in an email message in the list archive, since the

> doc talks about timing in the section with = Figure 1.

 

The answer is in the document.  Section 4.3.1 = talks about a <marshalling-period> which is associated with the = <tpm-extend> of Figure 1.   The = <marshalling-period> was also described within yesterday's = thread.  Here is its YANG definition:

 

    leaf marshalling-period = {

      config = true;

      type = uint8;

      default = 5;

      = description

        = "The maximum number of seconds between the time an event extends a = PCR,

        and = the 'tpm-extend' notification which reports it to a = subscribed

        = Verifier.  This period allows multiple extend operations = bundled

        = together and handled as a group.";

    = }

 

I have highlighted this information under Figure 1 = so that readers of that section do not have to search it = out.

 

 

   o  time(eg) - Directly = subsequent to the <establish-subscription>

      request, an = initial response of Evidence is returned to the

      Verifier.  = This includes:

 

...

 

   o  = time(vg',eg') - This occurs when a PCR is extended subsequent = to

      time(eg).  = Within a configurable marshalling period after = the

      extension (see = Section 4.3.1), the following information needs = to

      be pushed to the = Verifier:

 

...

 

Eric

 

> = Dave

------=_NextPart_001_02A2_01D6714E.161F5BF0-- ------=_NextPart_000_02A1_01D6714E.161F5BF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTI0NTI0WjAjBgkqhkiG 9w0BCQQxFgQU6pSrVlUyuCaB6gIIgG3X+RTful4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBh5l7YZVWj1+vImerf9r0ZYKQEY6QVRwzWnQPWQbqDjxjqjYgcsSt/t5ydBl5OaLK3 pRk597cKz+J2EKwtrB4Iju/wY1O5o7cAUNAwNKMVC0qj/yagmtjr7S05DhqFLWi2laRMKSxroCXM m4tl4qzgEjQ+J4kDGYEihsHh1QZURzshkr7SE7Vf4Na7PA5tfndn4Oc6Rxz4QsIvonNGPa4K2W4r YkGlbQzVrR56aih8QnxzwHXnZGrmdLnWdb/tMKUT0CdPrsiWYgWayF9byXMyOWRHtsxNNY1qJR2M LLzqNcGABWjWi1zgP+IBriUQ54kF3wV8SvQdHGVFude7PG8tAAAAAAAA ------=_NextPart_000_02A1_01D6714E.161F5BF0-- From nobody Thu Aug 13 06:04:17 2020 Return-Path: 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 697873A0C04 for ; Thu, 13 Aug 2020 06:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=iX0Uyfr6; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=OVbptB3F 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 K2nHtSuwt2go for ; Thu, 13 Aug 2020 06:04:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D981A3A0C03 for ; Thu, 13 Aug 2020 06:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10821; q=dns/txt; s=iport; t=1597323854; x=1598533454; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jAN0ksF+mkHFpidrKb2x33Q4KOCxb6hbuVdHPcCVQH0=; b=iX0Uyfr64WjJernmc1xgWsxo5IntB4pb/z4n7V5eehIXRzXmlEXsHbxV lFpQ/y8pJ8sR694xVyb4nOqDRa2cghefyR5+jGz3AaTbNQesvW/00UorD Fg5ZlJyrpFQlQW29YWbeEMnbBQabM/UEoirk6YbkFDDZcyjib0aKpKLMO s=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AC//fDxE+rFftof8g+nOhCJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbXZjS9P9FzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX+elTNr3z05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9BQC7OTVf/4gNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUikoB3ArLS8sCodyA41XgQKXZYJTA1UEBwEBAQkDAQE?= =?us-ascii?q?jCgIEAQGETAKCQAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEDARIuAQE?= =?us-ascii?q?3AQQLAgEIFRAhAjAlAgQBDQ0GFII5TIF+TQMOEQ8BDqZJAoE5iGF0gTSDAQE?= =?us-ascii?q?BBYFHQYMgGIIHBwMGgTiBU4EeihAPGoFBP4ERQ4IYNT6CXAICAQGBXRWDM4I?= =?us-ascii?q?tmx+KHZBwCoJihDiCXIFPhXqLYIJ+nReFWoxZgWyIU5R3AgQCBAUCDgEBBYF?= =?us-ascii?q?qI4FXcBWDJFAXAg2OH4ElAQKCSYUUhUJ0NwIGCgEBAwl8jnABgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="p7s'?scan'208";a="800990266" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 13:04:13 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DD4DHn020915 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 13:04:13 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:04:13 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:04:12 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 09:04:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X5BW+/PSJ98jb0oc9KvgdK2fhBf8fAPbVYcMZ0jcbbcMRc6z4kcRkEHAj22VhMxA2DsvDnAHtO+qlQlEIxq34IQQKf0hWYm7sQsFcspbWqvhCqN6BMeF/6mrjdlrZOF/kOLrHaa5+QiEalZ74Lw8W2aJ4FwDBwqZ23PpK6E9kp60qT1hZljRmlf5FSyXf3SqMcr/WSkKLIWyd3bV37ln6spFlSbhECQgnst0QUsDf3NZPMRh/2QIYX/HbV5Oyv8hzCrINJXtOzDptDMUpGV5pvDH1WqdKzsY4BqNCbqXSjcvAZ8yllJX/xmFyDhHDLjTdhH6wFNNBqXihG1xwqvgfw== 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=Vuw7dKtahcIgGOD2PU6jr389/q0MG2YkjtxACT9cuws=; b=SeL7mBOWvSLSvcmDz4U6FOpEmvxvYyhTAiuXN7Tu8iBQnPtXZc+UVjxJpDFZ/8rOATc5rEtXlGI12M1aMNbfu9lRlLDTcsEhymOcQn0KxtcjZYNmY8tvnlFHDt5aRvX6GZOeBoN+IGc2LX6UZMsimFJxVUYS6CfIBJj+lFKrSMdUu2IA9b5XQ0o96NVZPPpgZJZCGiGMEqq0Bj288PPGjrRAkqHUJ0wnxHmR82U9Q+Nr0m/3oaD/0McaQKjHi/5Wc3CUxDHG2T+Ftgic2oy65cBTNa5O5LmZPBx7rBeJ04qEp3g1QE97onN5pNj5Syr2FAB8ad1JS6wZjybS7hpE7g== 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=Vuw7dKtahcIgGOD2PU6jr389/q0MG2YkjtxACT9cuws=; b=OVbptB3F4NTaay0AD2yw1i5u1+9kTg65peLhTcGvGOIOvN85q7RXc/pP+35cAuaa+jdeJk1q57IuNFlIoyomccAB/QWcWmK8MhUaYuWUJ22DauBYYlmb1S5rPTl+E7QP/cWtFkm1BPnb5p5Az3FV6+WnplX9xAbXorEqP7VAJKk= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4080.namprd11.prod.outlook.com (2603:10b6:208:137::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Thu, 13 Aug 2020 13:04:11 +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; Thu, 13 Aug 2020 13:04:11 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" , Dave Thaler , Dave Thaler , "rats@ietf.org" CC: "Birkholz, Henk" Thread-Topic: draft-birkholz-rats-network-device-subscription-00 Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6gAAcrZWAAFvHBwA== Date: Thu, 13 Aug 2020 13:04:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f971b891-92be-41ac-0919-08d83f895f74 x-ms-traffictypediagnostic: MN2PR11MB4080: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: p2z9wIlKaMv0k4Qyje3JOUe2bw1IxLHWxSt/2z9yAvVLIukb2LiyGHL0Fb2zWwsSOzOMWdhdT/uvuJrppYI/jTISl5iCRbfXnUw1vtQudwIZxzU51y43Vh19WUvYt+8W6Tq1iG9IXxQOddUkRTYdVtrylFk767GI6I8sor4yzJtBEE4QBXEwBoWz1YiQAWMcGfT5fFoHa6Ku3w+VtpBtKl7tqy+B16Wo7bdhqrEWHLxuJAqHZdqT2u9sbvqdEHM38NILBGKUB/krRmSDT51ZNdRLjBs4m+4CQwWZLiqDq1tuePohoK1kAQcg6MTq97WNQgFWyI4DnJglv95JemlSh6O9tZHUeXFvfqbLPiiiRhrSROGtI0LnX9C7vtS5CmaaxPLGagrRYNBLaFUmWBXY3Q== 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)(376002)(136003)(366004)(346002)(39860400002)(110136005)(5660300002)(8936002)(83380400001)(4326008)(478600001)(966005)(2906002)(52536014)(6506007)(55016002)(8676002)(71200400001)(7696005)(9686003)(99936003)(76116006)(86362001)(33656002)(66446008)(64756008)(66556008)(66476007)(66946007)(186003)(26005)(66616009)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6nOBJmcY6VFXGy3gVyQr3QBm8OXnZHdEl19tpBtwzm/lp4LrhSHk/EY7cenTxSMAoUzEBm5P3gQFs1WHiG2ogHuDRbH29GRnc1NPvu/eI4mzoDwp5dM6gFOd47g/oRbFaE8kzmgoxWJVoYeRVggHNdRSJLiveeE8RJ1bvsQXQbdFTnF966iuOZz06RYep2aRKe14Df5bjkcrqGAXSWhlEj1FJPYiiCAH3TRRJRHCo0fhl/rIViOQJobKnaap6urtXhgJTl+m2n3X4QTw5JM+gCzPp9RGSSKDEZMDmu6QYkMeAel+yD+AP7+oVN3BxcSX26jVeVMMgM4Nci9N7JqTUcBTJod5xSjXztcfwlPdxWNo/5BqhcyDGq3Wt/LLCQOBY/fgncrBmiwtBIVI/9u/4rOIraZ7t94dCJ4wgoliMaQnEtcKfP2sWhBowGk7tQiHmC23+ET21yBxuUsE/Am0b0QV6BFGFWIfvahPxaZiOB6W/o9+eL3A7qBI+NmXZUdviJ+SZm8+ibTNvcknMtMi7u6Rj6c45by4XYZXQGt/ZTLXjcpqZKnvKIyzrxUXC/f0RRHqCPoDgxwDD+rR5v82AmmwfoKVOhVovtF7iGleM3KMQXZSokhNJPmWuo3fXs7pNenpP0z9cbheYJtNXfzK6Q== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02CC_01D67150.B13C4DD0" 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: f971b891-92be-41ac-0919-08d83f895f74 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:04:11.5398 (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: R/JwEKci7qapZWOTvKNDJnV6ezoZY9cGDMai3dxU0xHVKMeA/5AiO5/pDTUWhVey X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4080 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00 X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 13:04:16 -0000 ------=_NextPart_000_02CC_01D67150.B13C4DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, > From: Panwei (William), August 12, 2020 11:52 PM > > Hi Eric, > Hi Dave, > > I think Dave's question is that how the YANG module reflects the different time > points in Figure 1, e.g., time(VG), time(EG), time(NS), and time(RG, RA). My answer tried to differentiate YANG data presented as system generation event stream of YANG notifications, versus subscribing to changes to a YANG datastore. These differences are significant, and are covered in RFC-8639 vs RFC-8641. I think Dave's response was that he simply wanted a reference in the document, and I have now included this. > My feeling is that time(VG), time(EG), and time(NS) don't need to be reflected. > For the routers and switches, the time(VG) is usually when the devices boot, > and it can be much earlier than the Evidence generation and appraisal, so > usually the Verifier doesn't care about it. When the Verifier wants to establish > the subscription, it generates a nonce and sends the subscription request to the > Attester at the time(NS). The Attester doesn't need to know the time(NS), it just > generates the Evidence according to the 'values' and nonce, and theoretically it > should send back the Evidence to the Verifier immediately after generation. The > Verifier can appraise the Evidence's freshness based on the nonce and the time > interval between sending the subscription and receiving the Evidence, so there > is usually no need for the Verifier to know the exact time(EG). > The time(RG, RA) may need to be reflected in the Attestation Result, but neither > CHARRA nor this subscription draft includes this scope. I think draft-voit-rats- > trustworthy-path-routing should consider this because it defines the Attestation > Result YANG module. In general I agree with all of this. For certain attacks a Verifier might care to investigate time(VG), time(EG), and time(NS). But this is nothing we need to focus upon here. > After subscription, when a new event happens (e.g., the PCRs extends with a > new value), the Attester will generate a new Evidence and send it to the > Verifier. Usually the time(VG'), time(EG') and time(RG') are very close. But the > "marshalling-period" leaf defined in this draft do give the Attester an > opportunity to fold multiple 'values' into one Evidence to reduce the amount of > notifications when multiple events happen in short succession. It reflects the > max time interval between the first time(VG') and the time(EG') to the Verifier. Exactly. > So for now, I think current CHARRA and RATS subscription YANG modules don't > need to explicitly reflect the exact time of these time points. Based on Dave's request, I inserted some text under Figure 1 as he suggests this might improve overall readability. Eric > Regards & Thanks! > Wei Pan > > > From: Eric Voit (evoit) Thursday, August 13, 2020 6:58 AM > > > > > The topic being discussed here is about *timing* (and windows of how > > long > > > things can be out of date for, > > > etc.) I expect that most other YANG drafts/RFCs do not cover that topic, > > > whereas Figure 1 of > > > draft-birkholz-rats-network-device-subscription specifically *does*. > > That's > > > what brings it in scope and why I believe it must be mentioned, even > > > if > > it's by > > > reference to another document where the topic is covered. > > > > There are a YANG nodes relevant to such timings. For YANG datastores > > the best place to start is: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capab > > ilitie > > s/ > > and look through definitions like: > > > > +--ro subscription-capabilities > > +--ro max-nodes-per-update? uint32 > > +--ro periodic-notifications-supported? notification-support > > +--ro (update-period)? > > | +--:(minimum-update-period) > > | | +--ro minimum-update-period? uint32 > > | +--:(supported-update-period) > > | +--ro supported-update-period* uint32 > > +--ro on-change-supported? > > notification-support > > | {yp:on-change}? > > +--ro minimum-dampening-period? uint32 > > | {yp:on-change}? > > +--ro supported-excluded-change-type* union > > {yp:on-change}? > > > > However it is important to note that these capabilities above are for > > reporting on changes YANG datastore nodes. This is not the same thing > > as the placement of YANG notifications into event streams. Therefore > > for this event subscription draft, look to the definition of the "marshalling- > period" > > leaf. This leaf attempts to define the problem from the perspective of the > > maximum amount of time from when an event extends a PCR to when the > > notification leaves the Attester. > > > > Eric > > > > > > > Dave ------=_NextPart_000_02CC_01D67150.B13C4DD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTMwNDAzWjAjBgkqhkiG 9w0BCQQxFgQU4+UH9a+2o9VWVEQXT2T3uPzHuaMwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBqZ9RoSc6ws60zqz8wQSJXa5a0WYb+VxY1ICxXITjieiFnRy9yvuxBNCcujEQTCSXE +4vrLOr0wV5VkpD6LxHkIbPCCx+XKZHR5JKzeEyG3LPfwgzuMeFpqyztXDvAUJaqSF2BiOQJEqSe me0t7U2nyu4+RxwQI8uf9r/PgJk1WSiTXScqumfVXu5hPlW9UY/Fj8iiQWu4uIVJDot/YxIqzpxB M1xz+1gbbJkFzazFPvZTwjzYh1Jbh8t8uliGJXPRDxHKaaqR1qMyA1Ji6MFoO1ESqP6a33BqI4sg YfSOR9x0LGUmg1uqmBoKqhN15MxOOn5WYVuzOwckb5cqyxdgAAAAAAAA ------=_NextPart_000_02CC_01D67150.B13C4DD0-- From nobody Thu Aug 13 06:52:59 2020 Return-Path: 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 C0B793A0C48; Thu, 13 Aug 2020 06:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=OCalBlo2; dkim=pass (1024-bit key) header.d=juniper.net header.b=hOkB1/Zh 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 8Bx5jbg-V3Pm; Thu, 13 Aug 2020 06:52:55 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CEB3A0C47; Thu, 13 Aug 2020 06:52:54 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07DDqsZd000378; Thu, 13 Aug 2020 06:52:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=wX7g7rI2A8eayk08kEKaH5wQgCCH+lLea80WuaWzSpc=; b=OCalBlo2g7zTigt9tcl4qtfVVyPz5tjAIlcpOgbtD2k86I8JXIKnaqWIynVyip98AZhC IOaefNYngzVh+JuVCgCMB2xfN4WXNaZ6Y5V2n+IRqmYMu18vbqfyYwUhGmmK7B5Y4Voe OpEM2NIwg/DdVhy9cI54fQHfe7flgHx4rvTrc8uVsL0h54JwMHt/zoR+NbBUZy8pdRFg Fa7ip3l1kRXdN8vRsRmWA0PQ1wbujNDlblFtOlLUqf9mNDVSuxATswApLdKXRh3hJIva gLvkDjem+mlEwZSsQfGGI8I0IsCvsiL/Zk0m4x2WH+KFO8GRLXYKznSERUJGGXYji16Y Ww== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by mx0b-00273201.pphosted.com with ESMTP id 32vrr115j8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 06:52:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZmBJ/xGyzqobWGjYxCo0doY2OHDCkFuLjYd9nmsHMCJ8l+vsmPY6pOM1hP/1HqrTC6O5qTQ2Kb4JjZ8ouQXlIi6A7zJPl0p2yFgygqXO+ng3jTUBvYB20jDFv4DcyYb2s01UY3ec/W3RC8kDjZL2eaIIDkYI2f6EbxfkYlfs4ia2xaE9q/wFoTnvnjt9ttTgTihlE8D514odkW5wxst3y6yUCOPRZCL4gJnor3w6aQfYtAS4aBzH47LMpmQV8zVzdXbJV/Xfb5Sa4mSEEUwLFBBJeQsY9DDR77cPN/TE7y4KyEqJF4Kb2NNxmY594NQlZ8RCLeF7oOXJwhNN35JHdg== 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=wX7g7rI2A8eayk08kEKaH5wQgCCH+lLea80WuaWzSpc=; b=kdf00XNfj6SKeojFl3+cj5TxF3JtnL/8kPzDKlwthriVgHhPlvjRxcz7BjQ6zJsfyU3PFFOAzjFJPln4GCOwjpDPsv7Rm83sYpN+sdeiiqNIJfU0B3gcpqC1lYMVGaul+8Oa8ZWmzxKpmlEzw1gPoEFnOqpaGYNXRUHhXmcJfUrX9CsdyQOkPezFasgmSwm8mmsD0azWVKbGRLFEoyuMkplL/FUIT31SttCQVcgnoGkkfm75t3ukZMdPWwJLrHQDDFjKFffKqOUyd9JijDqbqD0lMDk74F5yGuITOKkMKDiEclD3TOL7H6lHexTgFQ+vHl5mxPRF9zUbpw2Kr8h3hg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wX7g7rI2A8eayk08kEKaH5wQgCCH+lLea80WuaWzSpc=; b=hOkB1/ZhODI3Vy0nvqCCzPjkpY/IUKNSYSwO0+B13u86WB9mA3pOXbHNe9+jhCc9wJ3dcoCrxxj3v+v2aLJzbnylnhHO4DxHFrlJgUJC7oP+kF6hTbmO170cHZrxja6qqn0Dza9WA9QaJeQXAwOLPVKfoaqw3oTIabgaJEncVrE= Received: from DM6PR05MB6889.namprd05.prod.outlook.com (2603:10b6:5:204::22) by DM6PR05MB7050.namprd05.prod.outlook.com (2603:10b6:5:1dc::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.13; Thu, 13 Aug 2020 13:52:51 +0000 Received: from DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::f5ae:e4dc:9e61:d5f5]) by DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::f5ae:e4dc:9e61:d5f5%5]) with mapi id 15.20.3283.015; Thu, 13 Aug 2020 13:52:51 +0000 From: Guy Fedorkow To: "Nancy Cam-Winget (ncamwing)" , "rats@ietf.org" Thread-Topic: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model Thread-Index: AQHWcOa5ocl00PiKFEWQHfz6I5Hx9qk2ECYw Date: Thu, 13 Aug 2020 13:52:51 +0000 Message-ID: References: In-Reply-To: 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-08-13T13:52:49Z; 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=744347ad-9490-4791-bd26-16f0a524ad1b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7af8dda5-5dec-4a59-ae0c-08d83f902bfa x-ms-traffictypediagnostic: DM6PR05MB7050: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sBrJ8PqN81hHFdguwbAMqbdn/dwoqp56aT93+lmtf7hL+YoEB2WhPL1soq4uZDOgECUui/wB4xweobLuM3pocMbt0/kZ+Wd7LwygcILNx6ypaRxF5WspdSWMLs83PtwDBGuO7s0n41TQVVjQTKShY9advS68mFnV7CvKBwkOlkZKKk9090IUwhasdVw9dqyCgRU0YJUnEx8zhSi8XjQhylXsQN0hjpIh5PwbHb7h9/mX2hFGpHWRSGDKr+Nc/0fHVePUsBA0oq7jx8K9be85EFGJ5PTfmGRz5n7dUo+ddZ+v8ebsV3rzmOLpggXuibY9XfYgqVQ/exe4/EgfhDgLowBY2CNwtl6wLmCkxCqcxHvE5aP9Wkm0znTJ292lr+EhJu/mjAB2Pe7prjEUYFjf2Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6889.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(136003)(39860400002)(396003)(55016002)(966005)(86362001)(9686003)(478600001)(8936002)(71200400001)(76116006)(7696005)(66946007)(52536014)(66446008)(64756008)(66556008)(66476007)(66616009)(5660300002)(8676002)(33656002)(110136005)(316002)(186003)(2906002)(6506007)(99936003)(26005)(53546011)(83380400001)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xlRhUL5CzrLeVuTSZJI65CdprSk1We/ICnJ5es4fasIGuuCZ0x8LhybGv6Z/6YR3aUkjIXwYFOeLi8R/Zx7tmSMzBL/r/MVzJdYTtXy4ZA0VRNFmMDWcWSF8VEpGfygLy2x4O16gTzC1xKueGBYUwtTFGk/As8bR7rMsoMMcOFURyJmqm1nsT/R9nFcCbdVqJuufpztY76/nOs5wlBz3y+r7Ey15nPx9KQBn3em/SOFiZ9QREQ0TGJu/5rVgWMOQePDSrJCnfPWF9xh/5lYYqFnn0HquW4UVNMCVllz1F9wjMvurtWHOGVQ4AnGVdQ2gd5LgSuIamFuG73QbByjTC8qY9noE9QxtnV60e4zZgv26shvTg94rlPsSR3tOJeUxwmFUzddpWJ9Ay62YCsk3lGmdOoZVG7laPBvdrcWY3eo7j9lqBARVQEk9ce+RCxFC5/Qwikg/dQi6phBTVVF8dudq+vGbR+MgEescyflVcCcrGUVeTP3n5UnCqBbW1aEuqr23VpEqKMgApz0NP5pdfW0g+5K+CW6clZmm+btzZbQabnJW+3AzYEt4Ltp/AP6qYakWXUvFPpm3CVSj4nldCNytdrJ9V6SanDedQIp4eF+z+r9V4MZWyCG/e+nup46ngHvSjyyTWxHIsFTaSR16PA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_07F7_01D67157.8125F450" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6889.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7af8dda5-5dec-4a59-ae0c-08d83f902bfa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:52:51.7725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vvX5kD33SOFi4202hECClDm9TYGdqFbxvy9WikEpiDPqdJyfwFdujEV/PUdwIhE8N6gIff5DoWgV/pVEGmH5CA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB7050 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-13_11:2020-08-13, 2020-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008130104 Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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: Thu, 13 Aug 2020 13:52:57 -0000 ------=_NextPart_000_07F7_01D67157.8125F450 Content-Type: multipart/alternative; boundary="----=_NextPart_001_07F8_01D67157.8125F450" ------=_NextPart_001_07F8_01D67157.8125F450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support adoption as a standalone doc /guy Juniper Business Use Only From: RATS On Behalf Of Nancy Cam-Winget (ncamwing) Sent: Wednesday, August 12, 2020 4:26 PM To: rats@ietf.org Subject: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model [External Email. Be cautious of content] Hello RATs members, At our IETF 108 session we discussed the draft: https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-m odel/ There was interest in the discussion on the adoption of the topic, but ran out of time to get consensus on "where" these interaction models should be documented. Further, Henk started an email thread prior to our session to get a sense of interest and where these models would best be described. Given those results, there seemed to be a preference to keep the document as a standalone draft that describes all models. Thus, this is a Call for Adoption of the draft-birkholz-rats-reference-interaction-model to serve as the starting point for a standalone draft that describes all models. If you have reservations for documenting interaction models, or for such a document to be a standalone draft to describe all of them please respond to the mail list and provide rationale for your concerns. The call for adoption will end on Aug 28. Best, Nancy (on behalf of the RATs chairs) ------=_NextPart_001_07F8_01D67157.8125F450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption as = a standalone doc

/guy

 

 

 

Juniper Business Use = Only

From: RATS <rats-bounces@ietf.org> On = Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Wednesday, = August 12, 2020 4:26 PM
To: rats@ietf.org
Subject: = [Rats] Call for adoption of = draft-birkholz-rats-reference-interaction-model

 

[Ext= ernal Email. Be cautious of content]

 

Hello RATs = members,

At our IETF 108 session we discussed the draft: =  

https://datatracker.ietf.org/doc/draft-birkholz-r= ats-reference-interaction-model/

 

There was interest in the discussion on the = adoption of the topic, but ran out of time to get consensus on = “where” these interaction models should be documented.  = Further, Henk started an email thread prior to our session to get a = sense of interest and where these models would best be = described.

Given those results, there seemed to be a = preference to keep the document as a standalone draft that describes all = models.

 

Thus, this is a Call for Adoption of the = draft-birkholz-rats-reference-interaction-model to serve as the starting = point for a standalone draft that describes all models.  If you = have reservations for documenting interaction models, or for such a = document to be a standalone draft to describe all of them please respond = to the mail list and provide rationale for your = concerns.

 

The call for adoption will end on Aug = 28.

 

Best, Nancy (on behalf of the RATs = chairs)

 

------=_NextPart_001_07F8_01D67157.8125F450-- ------=_NextPart_000_07F7_01D67157.8125F450 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISJTCCBd4w ggPGoAMCAQICEAH9bTD8o8pRqBu8ZA41Ay0wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTEwMDIwMTAwMDAwMFoXDTM4MDExODIzNTk1OVowgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw12 7c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NCtnby qTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQfjtTkUcYRZ0YIUcuG FFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy2 9lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnH a4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQN wZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sF qV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMnsQybQ v0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV 4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaNCMEAwHQYDVR0O BBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MA0GCSqGSIb3DQEBDAUAA4ICAQBc1HwNz/cBfUGZZQxzxVKfy/jPmQZ/G9pDFZ+eAlVXlhTxUjwn h5Qo7R86ATeidvxTUMCEm8ZrTrqMIU+ijlVikfNpFdi8iOPEqgv976jpS1UqBiBtVXgpGe5fMFxL JBFV/ySabl4qK+4LTZ9/9wE4lBSVQwcJ+2Cp7hyrEoygml6nmGpZbYs/CPvI0UWvGBVkkBIPcygu xeIkTvxY7PD0Rf4is+svjtLZRWEFwZdvqHZyj4uMNq+/DQXOcY3mpm8fbKZxYsXY0INyDPFnEYkM nBNMcjTfvNVx36px3eG5bIw8El1l2r1XErZDa//l3k1mEVHPma7sF7bocZGM3kn+3TVxohUnlBzP YeMmu2+jZyUhXebdHQsuaBs7gq/sg2eF1JhRdLG5mYCJ/394GVx5SmAukkCuTDcqLMnHYsgOXfc2 W8rgJSUBtN0aB5x3AD/Q3NXsPdT6uz/MhdZvf6kt37kC9/WXmrU12sNnsIdKqSieI47/XCdr4bBP 8wfuAC7UWYfLUkGV6vRH1+5kQVV8jVkCld1incK57loodISlm7eQxwwH3/WJNnQy1ijBsLAL4JxM wxzW/ONptUdGgS+igqvTY0RwxI3/LTO6rY97tXCIrj4Zz0Ao2PzIkLtdmSL1UuZYxR+IMUPuiB3X xo48Q2odpxjefT0W8WL5ypCo/TCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJKoZI hvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VS VHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMwMTIz MTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGln byBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkqKtLN nFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfbM3wc caNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+LbnTe ef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmHfpsE kzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMBAAGj ggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy/Ava lNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBHMEWg Q6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVzZXJ0 cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiMAN0X 13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vhNn9d NqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHitcPr 5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDpVRH9 9lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7T2ww C+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI9oKS ChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RIZllX 4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDonM8V/ 2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQz3lC NObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMIIGKzCCBROgAwIBAgIRAPuElTZ4 EhaY10ByhNJltnIwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTkwODI0MDAwMDAwWhcNMjIwODIzMjM1OTU5WjCCATcxCzAJBgNVBAYTAlVT MQ4wDAYDVQQREwU5NDA4OTELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTEcMBoGA1UE CRMTMTEzMyBJbm5vdmF0aW9uIFdheTEeMBwGA1UEChMVSnVuaXBlciBOZXR3b3JrcywgSW5jMR4w HAYDVQQLExVTb2Z0d2FyZSBFbmdpbmVlciBMYWIxOzA5BgNVBAsTMklzc3VlZCB0aHJvdWdoIEp1 bmlwZXIgTmV0d29ya3MsIEluYyBFLVBLSSBNYW5hZ2VyMR8wHQYDVQQLExZDb3Jwb3JhdGUgU2Vj dXJlIEVtYWlsMRUwEwYDVQQDEwxHdXkgRmVkb3Jrb3cxJDAiBgkqhkiG9w0BCQEWFWdmZWRvcmtv d0BqdW5pcGVyLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Fewgz3OFG1Go3 cuoLYIbLNRTSEFgN+GLUaqB6g5VuCf0UTvgARSlxgDmsvE5qwTtb8JOtJ64OylVNvz28uslsfvg4 WCc0InZUo1B6JkgNamxa3HI31h63s5wVm/wZgglg5Dv7WH7gmAPrgeoWpBC2GN1sxWHfcJOi2fzg M5LWst0Iwz4M7vqFsZ77AOkUFDNm5p19Fu8HRjVlsE0fNGieZB5GEiL2CN2YoxyOKrJdqWHNMkK8 Q5owvlDnSR0tb8oJgHDX8EESSo5TDA5zqnva48zFfFWCrOdobNgf1To4uBskX6B+QEmrSNLuSdpK JOHw9IdrPofgpjZCmFwvtS8CAwEAAaOCAc4wggHKMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZ Qs/J4K0AMB0GA1UdDgQWBBQPfL+xFDoZAlQisKraMq/Y34eQGjAOBgNVHQ8BAf8EBAMCBaAwDAYD VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1Bgwr BgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAg BgNVHREEGTAXgRVnZmVkb3Jrb3dAanVuaXBlci5uZXQwDQYJKoZIhvcNAQELBQADggEBALilLU71 sn7XVNFoUU4MqcHXXFiFiOjCQmq1nqijMa6L4fKm/VX9LZtrsQs3CZTUiHuW2pyLapLVIEXdubNX L877oIVJmeAoSWz1+AYelK6CIpuGUUcGSsXKd4Xl9yOTrmLb7PTjrRpXsWSHJi//jrXTrR/X6M+U TterfzhR5gYPFyvX65Zie9M7k7V2yB3YJJPzT8EtfrJc+eDzYAgiWK8X/ToMZOG7noa/Er8FEARn joL7pKHVOkHTOM9UNaublWlhiUEzzXx9kYPKjgqjAetRo4zh1KBFm9MBlXeigAVBx+BQpP0OdmHb 5vcX3pUR4lkRpnVeLKFR++q6z+bViYAxggRnMIIEYwIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAPuElTZ4EhaY10ByhNJltnIwCQYFKw4DAhoFAKCCAo8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTM1MjQ5WjAjBgkq hkiG9w0BCQQxFgQU+O++zU+Q/HDo5pmzJYbk/FNhbpEwga0GCSqGSIb3DQEJDzGBnzCBnDALBgkq hkiG9w0BAQcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCSqGSIb3DQEBCjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBvQYJKwYBBAGCNxAEMYGvMIGs MIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA+4SVNngSFpjXQHKE0mW2 cjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+ MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD7hJU2eBIWmNdAcoTSZbZyMA0GCSqGSIb3DQEBAQUABIIBAJsDG3Ely315GJdaCfHC CElGElEAA1GgTwjcWcpusOzleQHDC3nw/C8nbzFFoAY7IO3F+GTqR2evmIU0+3OlZEseX3mYwexv txtnnC9rMjT7MosqEWM1aAkbQDl0uFgFEE6fA7js6ZDH/tV3g8pBq8SMR+L0prLtZ7AjihbxitfX +1Ih6Bydg9QVBMVTUSvryDtK8PWLV6Lh8OHJz9ih9NlxesdTCvhllTcVhNVLsWSMASS5F5iPLen0 BeK3E/xzgocU0dsBjfistNcfA/tNmGLACdJyHggbsX2nzypa2ZDdRGR/p9Os9jgDHPTXCOXSYF7+ Z+d9xlLhvyV54acuEH4AAAAAAAA= ------=_NextPart_000_07F7_01D67157.8125F450-- From nobody Thu Aug 13 07:32:34 2020 Return-Path: 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 D19AC3A0C7E; Thu, 13 Aug 2020 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=iQYE2V2S; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=m0cBD9gh 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 nPlN88fRTALO; Thu, 13 Aug 2020 07:32:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6328A3A0C7B; Thu, 13 Aug 2020 07:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30986; q=dns/txt; s=iport; t=1597329150; x=1598538750; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Kde4f2KtaFNjvxeWkvOEwUgpRZmuqFUtfZpkpdWq9IU=; b=iQYE2V2SeVr8ojrsFoclXXB9S75i8pS1Er1/cNTsRwU3iS+E7rZW4hUP E8bfvyxCf7ny/Ys9jHYc8rK0rASNODBPoWAZKNDMJw4WPWs4Xgrc2xJ+g LISjkiFRn24lQxTkF4QbWnG0zFl0p4uxhbJwLvVXdK12cwlU0u3dtnzEv c=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3Aso9r0x0AtNjtL/wLsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAADRTTVf/5FdJa1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTgFAQELAYEiL1EHcCstLywKh3IDjVmHXpEJgS6BJQNVBAc?= =?us-ascii?q?BAQEJAwEBLQIEAQGBNYMXAoJAAiQ2Bw4CAwEBCwEBBQEBAQIBBgRthVwMhXE?= =?us-ascii?q?BAQEEEhsTAQE3AQ8CAQgVIw4CMCUBAQQBDQ0GFIMFgX5NAx8PAacOAoE5iGF?= =?us-ascii?q?0gTSDAQEBBYUdGIIHBwmBOAGBUoEeiiAagUE/gVSCHy4+hBUqg0iCLY9gNYl?= =?us-ascii?q?xgRmbDQqCYoQ4glyTKaAVkjSbDIQqAgQCBAUCDgEBBYFaBS6BV3AVO4JpUBc?= =?us-ascii?q?CDY4fDBeDTopWdDcCBgoBAQMJfI1ngTQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="p7s'?scan'208,217";a="811381303" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 14:32:28 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DEWSu7002158 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 14:32:28 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 09:32:28 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 09:32:28 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 10:32:27 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QBh0cCjXoYFQBepIXbxlmOld/NRoKz1FNlWA7a/jrjXmJmWsvmTyK6L1DuRGhR6Zso3V6FmJ+tS+m4V5EDHcTg2SqmL9YM2UwpInTPGMf0f0hxsMC1EGyT/tdyle1tUH5troQTF8MJQoONe6hWgnk69q6tSp+GNY0kwxaYkIIDsBOK2ZJK1covQY5tfu1m5iN6aVgv4Lr3HEJAUGNqutUKslnmtz3yzZRAa4zCu/og6Gx0igYUGncSiFUVpTdIxRHSFPFycSQzTXqxCDnCzWIQhKXmoSx5BMlExwUmD3hXiTTrKRKlYTocX23ZFyMhE0Eu/ZGswcHnrot1Fp2LGxVw== 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=AqPi3b0XZkoGHnXze/cYLbP984b0p6QwGcbtgN/+zOI=; b=mKFNXNyF3CWbu8eU2iLHQEACnbOS3tB561GoKr675M8ueXwOvW+RKTZ2B0h0txdu8Nc6bXeT0CD/H0r8sYICglbsT4dYoCyVHjilo773eOzqwMKi9rsshCW/rnV7nGdcmRDd7kAJMHBEh1meS0vhQ4t5aP+7WrBehVF0+BdJNv39IQbln+f2EdGbgXxV3O5g94WX3DNMEXCo9NeOfAuB5WQhW0I0X1PVt5AqYtvDKw3BjBOt7HxDu4g31xNrL0KhFQUwFR2nQcu/JjOYjOBzvKazRTnCG502LrFEzn6FfQCX8oWFXQpPf4jGRrrdVzLDc/+2+9v8kOFgyM+MrUVHNw== 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=AqPi3b0XZkoGHnXze/cYLbP984b0p6QwGcbtgN/+zOI=; b=m0cBD9ghMw/rZk0A89CUDLu2EMmZduBfuaQFkZQnba75o2zhFFVHpuGhOXDUJLSBxBP+X3JsiAmiKV4VGwlCCApwfg3Cme0lCsN8QM+lElLGxJr5bJWivRMPRyzpDTxrzIx4L0YKb7oiFiE3vhhmhP/OBz8DZ5TagcLas9iWxXM= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3316.namprd11.prod.outlook.com (2603:10b6:208:68::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Thu, 13 Aug 2020 14:32:27 +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; Thu, 13 Aug 2020 14:32:27 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" , "Shwetha Bhandari (shwethab)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Some new comments for CHARRA YANG module Thread-Index: AdZxbUUfWQ8kKtvDQNubGicd9eCWvQABoeIQ Date: Thu, 13 Aug 2020 14:32:26 +0000 Message-ID: References: <300450dd9780421aa1b9f5afa88261fc@huawei.com> In-Reply-To: <300450dd9780421aa1b9f5afa88261fc@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad795ae2-706a-4ab8-def2-08d83f95b3c8 x-ms-traffictypediagnostic: BL0PR11MB3316: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eXs/gR9kTGDe/zCfLPqq+XPpxyObKl5XqAD9H0iYPlrjQjmfh8dl9ODgN0lrAfM5aaQOpR0pDD0lihz3hZaNoEbrCXj4QSYzikykokPNEPYBTgvJhKlVTmKOR4jBkXwQIJtYiJ8r6fgEfR+OSaDNIBkOty30NoDfAiMQRpPSvAdIllR/kFHfgpiN9wA/WnalrQH4uf+kWiJe4Rw/UiZGp6komiQMaFQBszQSao7LEV+P2vLsxgm7cCRFwurdWZwBgn1lpeUdLr37QJpHegB1KR4YNN32MJz3Dw+iOZSlEgRH9PJBaNiXUqwBDJHfUJ7m/C0L4Tu/CyBsgZ50v8boeg== 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)(346002)(39860400002)(366004)(376002)(396003)(136003)(86362001)(33656002)(99936003)(76116006)(7696005)(9686003)(71200400001)(6636002)(316002)(26005)(66616009)(66446008)(64756008)(66556008)(66476007)(66946007)(186003)(478600001)(83380400001)(5660300002)(8936002)(110136005)(4326008)(54906003)(6506007)(8676002)(55016002)(2906002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: gdcoAA4/UXMoOpJASNFqM7C0rli3lWrRij2dQtW4BDbof/WzRUqdUQwGNBoV0nvVNxFp7cmrQ0jAGFLay9WieeR7P2Lo9tBFj7Nw3DW1LF5atEKPoAW1MLRtwqFM2l/saR9JIkkJnu7J6tRNu89dkU8yg+UBGOuHM01Jpgyj1mJ2GC2D+Gf9EEIPI4p8dlU+hUxSA3BTmmKxBwiEUFu3n1EpSE/2byr4B/rJp8DBnuQHy9ljCF8PaOOFtFcfBmsX7/xk1OG9iT3MUk+LCGRs4KemMJ2gqEg1Y3AKsOtbcCHx2pxSn9Wal3aHCghKDfBaCI7mjnYP53Am+vAEWBFQ5iLeUS4NWo5etL4j/W2jOp4Xkp/kyMzDMOQ+aIF35iJx7Fz1A9GF47o5diq0yLcMahNTF0rLu6R31+W4m2/N7OCGC5xfhNo4+5n8c6mowa67zoPwAY0hQvfZUWU0xuGzbdfsH2/yagfACSQhJLwY1FP6IbtZT9Qu4vMmCoPmrSvZy/mkCg9VuLN0N2cEMUPw2zob7kfyknhf4Z9R0tdDHo6aTDMtb1ULc7TZ6ns5IzfLGUlV//6rF/hkcckRb7CejCY9iF9owaLCu3QTYYZdac9K1qIpkOuNp1jBBtsRy3GLwR0hEi/wkA/jPZ2kI953HQ== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0316_01D6715B.BAFDDBD0" 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: ad795ae2-706a-4ab8-def2-08d83f95b3c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 14:32:26.9936 (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: MhfO5Pd/pFFoJQYDdik4JbBamBWxxQFko0weq5JFlA/36hAl+YawRyzBwbXTMqOK X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3316 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Rats] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 14:32:33 -0000 ------=_NextPart_000_0316_01D6715B.BAFDDBD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0317_01D6715B.BAFDDBD0" ------=_NextPart_001_0317_01D6715B.BAFDDBD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Wei Pan, From: Panwei (William), August 13, 2020 8:29 AM Hi Eric, In modifying the YANG module, I have some new comments about the module. 1. Do we still need the basic-trust-establishment now? It provides the function of retrieving the certificates of TPM2.0. But I think now the certificates can be get from the rats-support-structure and ietf-keystore. I can go either way on this. This RPC could provide some simplifications for TPMs. Adding Shwetha to the thread to see if there is sufficient differentiation from draft-ietf-netconf-keystore-17 (and its extended family of documents) to justify this RFC. 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 | | +---w add-version? boolean | | +---w tpm-name* string In the TPM1.2 challenge input, if you want to challenge for different pcr-indexs of different TPMs, you need to construct multiple challenge inputs with different nonce values. This is true. The question I have is for multiple TPM1.2 line cards, whether you ever would really need to have a single query which hits different PCRs. If yes, then we need the flexibility you are asking. If no, the restrictions will simplify the code needed to handle the RPC. (Note that for TPM2.0 we already need the extra complexity as groups of PCRs are hashed together.) I think it's better to change the style of TPM1.2 to the same one of TPM2.0. If you or others have a business need to have a single query which targets different PCRs from different line cards, I would agree. Do you really have this? If yes (or even no), are you willing to create some more XPATH statements which can limit the options so that the exposure of this flexibility doesn't drive code developers to supporting unneeded variants? 3. In the log-retrieval part, the input uses tpm-name as the identifier, but the output uses certificate-name. The certificate-name isn't used in the log-result, should we also use tpm-name as the identifier of output? My initial thinking was that perhaps a certificate upgrade has occurred between the last log-retrieval and the current one. As the existing RPC would notify with the new certificate-name, this could save a step. However the logs are not really tied to a certificate name, so I will make the change to . Eric Regards & Thanks! Wei Pan ------=_NextPart_001_0317_01D6715B.BAFDDBD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wei = Pan,

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.0pt'>

From: Panwei (William), August 13, 2020 8:29 = AM

Hi Eric,

 

In modifying the YANG module, I have some = new comments about the module.

1. Do we still need the = basic-trust-establishment now? It provides the function of retrieving = the certificates of TPM2.0. But I think now the certificates can be get = from the rats-support-structure and = ietf-keystore.

 

<= p class=3DMsoNormal style=3D'margin-bottom:.05in'><eric> I can go either way on this.   This = RPC could provide some simplifications for TPMs.  Adding Shwetha to = the thread to see if there is sufficient differentiation from = draft-ietf-netconf-keystore-17 (and its extended family of documents) to = justify this RFC.

 

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*          &nb= sp;   pcr

      |  |     = +---w nonce-value     =         binary<= /span>

      |  |     +---w = TPM12_Algo?          &n= bsp;  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

      |  |     +---w = add-version?          &= nbsp; boolean

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

In the TPM1.2 challenge input, if you want = to challenge for different pcr-indexs of different TPMs, you need to = construct multiple challenge inputs with different nonce = values.

 

<eric>  This is true.  The question I have = is for multiple TPM1.2 line cards, whether you ever would really need to = have a single query which hits different PCRs.  If yes, then we = need the flexibility you are asking.  If no, the restrictions will = simplify the code needed to handle the RPC.  (Note that for TPM2.0 = we already need the extra complexity as groups of PCRs are hashed = together.)

 

I think it’s better to change the = style of TPM1.2 to the same one of TPM2.0.

 

<eric>  If you or others have a business need to = have a single query which targets different PCRs from different line = cards, I would agree.  Do you really have this?  If yes (or = even no), are you willing to create some more XPATH statements which can = limit the options so that the exposure of this flexibility doesn't drive = code developers to supporting unneeded variants?

 

3. In the log-retrieval part, the input = uses tpm-name as the identifier, but the output uses certificate-name. = The certificate-name isn’t used in the log-result, should we also = use tpm-name as the identifier of output?

 

<eric> My initial thinking was that perhaps a = certificate upgrade has occurred between the last log-retrieval and the = current one.  As the existing RPC would notify with the new = certificate-name, this could save a step.  However the logs are not = really tied to a certificate name, so I will make the change to = <tpm-name>.

 

Eric

 

<= p class=3DMsoNormal align=3Dleft = style=3D'margin-bottom:.05in;text-align:left;line-height:110%'>Regards & = Thanks!

Wei = Pan

------=_NextPart_001_0317_01D6715B.BAFDDBD0-- ------=_NextPart_000_0316_01D6715B.BAFDDBD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTQyMzA0WjAjBgkqhkiG 9w0BCQQxFgQUT7ZQQjMaKHEiByvQlQxNfdozotwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBjQ5OognzKbene6DBukZlhUjgUlCF4gFNU5UMPlGTMjhVU+qec4G8C+D6U7GfwWpNZ /t3p7h5lQ4TyMIvTE8wV4QYGsQfs0+c6P8Inos/D3IIbcmzBCI6GoBbUmD7jLDUWfRHlbsJ8GM2P s8QffuYh6wxIzZkKNvj/WFp3VW53yS9anp9iX3NWyphaMPaPLpGO1+Gq9stIRA6qL4xUZ/XkjgTl vXhhKn3VMPPcUK89+R5sRXZz7mRhAlmi8DiaCB5SyucESLjpn4zJvwFd2n24f5KsHxzHTJC/MYhi zXRN0ccG9JkGNwqq0k1Kovm4zraBCbvvAFfENsHDf1h61DfyAAAAAAAA ------=_NextPart_000_0316_01D6715B.BAFDDBD0-- From nobody Fri Aug 14 03:01:37 2020 Return-Path: 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 1CC9F3A0AE5; Fri, 14 Aug 2020 03:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-Nf7uLWheF4; Fri, 14 Aug 2020 03:01:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8803A0ADA; Fri, 14 Aug 2020 03:01:32 -0700 (PDT) Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9AB6A98E83494F25F606; Fri, 14 Aug 2020 11:01:30 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 14 Aug 2020 11:01:29 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 14 Aug 2020 18:01:27 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Fri, 14 Aug 2020 18:01:27 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" , "Shwetha Bhandari (shwethab)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Some new comments for CHARRA YANG module Thread-Index: AdZxbUUfWQ8kKtvDQNubGicd9eCWvQABoeIQACqR4uA= Date: Fri, 14 Aug 2020 10:01:27 +0000 Message-ID: <0be97c3566f642348a123a8f9c4c6f4a@huawei.com> References: <300450dd9780421aa1b9f5afa88261fc@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_0be97c3566f642348a123a8f9c4c6f4ahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 10:01:35 -0000 --_000_0be97c3566f642348a123a8f9c4c6f4ahuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for your reply, please see inline. Regards & Thanks! Wei Pan From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, August 13, 2020 10:32 PM To: Panwei (William) ; Shwetha Bhandari (shwetha= b) Cc: rats@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, In modifying the YANG module, I have some new comments about the module. 1. Do we still need the basic-trust-establishment now? It provides the func= tion of retrieving the certificates of TPM2.0. But I think now the certific= ates can be get from the rats-support-structure and ietf-keystore. I can go either way on this. This RPC could provide some simplific= ations for TPMs. Adding Shwetha to the thread to see if there is sufficien= t differentiation from draft-ietf-netconf-keystore-17 (and its extended fam= ily of documents) to justify this RFC. [Wei] OK. Let's wait for Shwetha's opinions. 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-obj= ects is a list. So you can challenge for different pcr-lists of different T= PMs 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 | | +---w add-version? boolean | | +---w tpm-name* string In the TPM1.2 challenge input, if you want to challenge for different pcr-i= ndexs of different TPMs, you need to construct multiple challenge inputs wi= th different nonce values. This is true. The question I have is for multiple TPM1.2 line card= s, whether you ever would really need to have a single query which hits dif= ferent PCRs. If yes, then we need the flexibility you are asking. If no, = the restrictions will simplify the code needed to handle the RPC. (Note th= at for TPM2.0 we already need the extra complexity as groups of PCRs are ha= shed together.) I think it's better to change the style of TPM1.2 to the same one of TPM2.0= . If you or others have a business need to have a single query which = targets different PCRs from different line cards, I would agree. Do you re= ally have this? If yes (or even no), are you willing to create some more X= PATH statements which can limit the options so that the exposure of this fl= exibility doesn't drive code developers to supporting unneeded variants? [Wei] Actually I have no actual use case for a single query which hits diff= erent PCRs. I don't know whether others have. I just raised my point from t= he perspective of style consistency. But I agree with you that if there is = no actual use case the flexibility is useless and a burden. We can keep it = the way it is and wait if others have the actual requirement. 3. In the log-retrieval part, the input uses tpm-name as the identifier, bu= t the output uses certificate-name. The certificate-name isn't used in the = log-result, should we also use tpm-name as the identifier of output? My initial thinking was that perhaps a certificate upgrade has occur= red between the last log-retrieval and the current one. As the existing RP= C would notify with the new certificate-name, this could save a step. Howe= ver the logs are not really tied to a certificate name, so I will make the = change to . [Wei] Thanks. Eric Regards & Thanks! Wei Pan --_000_0be97c3566f642348a123a8f9c4c6f4ahuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,=

&nb= sp;

Thanks f= or your reply, please see inline.

&nb= sp;

Regards & Thanks!

Wei Pan=

&nb= sp;

From:= Eric Voit (evoit) [mailto:= evoit@cisco.com]
Sent: Thursday, August 13, 2020 10:32 PM
To: Panwei (William) <william.panwei@huawei.com>; Shwetha Bhan= dari (shwethab) <shwethab@cisco.com>
Cc: rats@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,<= /span>

 

In modifying the YAN= G module, I have some new comments about the module.

1. Do we still need = the basic-trust-establishment now? It provides the function of retrieving t= he certificates of TPM2.0. But I think now the certificates can be get from the rats-support-structure and ietf-keystore.

&= nbsp;

<eric> I can go either way on this. &= nbsp; This RPC could provide some simplifications for TPMs.  Adding Sh= wetha to the thread to see if there is sufficient differentiation from draft-ietf-netconf-keystore-17 (and its extended family of documents)= to justify this RFC.

[Wei] OK. Let’= s wait for Shwetha’s opinions.

&nb= sp;

2. The styles of cha= llenge 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]

     &nbs= p;|  |        |  +---w TPM= 2_Algo        identityref

     = ; |  |        |  +---w pcr= -index*       tpm:pcr

     = ; |  |        +---w TPM2_Algo?&= nbsp;         identityref

     = ; |  |        +---w (key-identi= fier)?

     = ; |  |        |  +--:(publ= ic-key)

     = ; |  |        |  |  += ---w pub-key-id?   binary

     = ; |  |        |  +--:(uuid= )

     = ; |  |        |   &n= bsp; +---w uuid-value?   binary

 =      |  |       = ; +---w tpm-name*         =   string

In the TPM2.0 challe= nge input, the nonce is put aside and the challenge-objects is a list. So y= ou 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*   &= nbsp;          pcr<= /span>

     = ; |  |     +---w nonce-value        &nbs= p;    binary

     = ; |  |     +---w TPM12_Algo?   =           identityref

     = ; |  |     +---w (key-identifier)?<= /span>

     = ; |  |     |  +--:(public-key)=

     = ; |  |     |  |  +---w pub-key-id?&n= bsp;      binary

     = ; |  |     |  +--:(TSS_UUID)

     = ; |  |     |     +---w TSS= _UUID-value

     = ; |  |     |      &n= bsp; +---w ulTimeLow?       uint32

     = ; |  |     |      &n= bsp; +---w usTimeMid?       uint16

     = ; |  |     |      &n= bsp; +---w usTimeHigh?      uint16<= /span>

     = ; |  |     |      &n= bsp; +---w bClockSeqHigh?   uint8

     = ; |  |     |      &n= bsp; +---w bClockSeqLow?    uint8

     = ; |  |     |      &n= bsp; +---w rgbNode*         uin= t8

     = ; |  |     +---w add-version?   = ;         boolean=

 =      |  |     +---w tpm-na= me*             = ;  string

In the TPM1.2 challe= nge input, if you want to challenge for different pcr-indexs of different T= PMs, you need to construct multiple challenge inputs with different nonce values.

 

<eric>  This is true.  The quest= ion I have is for multiple TPM1.2 line cards, whether you ever would really= need to have a single query which hits different PCRs.  If yes, then we need the flexibility you are asking.  If no, the rest= rictions will simplify the code needed to handle the RPC.  (Note that = for TPM2.0 we already need the extra complexity as groups of PCRs are hashe= d together.)

 

I think it’s b= etter to change the style of TPM1.2 to the same one of TPM2.0.

 

<eric>  If you or others have a busin= ess need to have a single query which targets different PCRs from different= line cards, I would agree.  Do you really have this?  If yes (or even no), are you willing to create some more XPATH statements = which can limit the options so that the exposure of this flexibility doesn'= t drive code developers to supporting unneeded variants?<= /p>

[Wei] Ac= tually I have no actual use case for a single query which hits different PC= Rs. I don’t know whether others have. I just raised my point from the perspective of style consistency. But I agree with you t= hat if there is no actual use case the flexibility is useless and a burden.= We can keep it the way it is and wait if others have the actual requiremen= t.

 

3. In the log-retrie= val part, the input uses tpm-name as the identifier, but the output uses ce= rtificate-name. The certificate-name isn’t used in the log-result, should we also use tpm-name as the identifier of output= ?

 

<eric> My initial thinking was that perhap= s a certificate upgrade has occurred between the last log-retrieval and the= current one.  As the existing RPC would notify with the new certificate-name, this could save a step.  However the l= ogs are not really tied to a certificate name, so I will make the change to= <tpm-name>.

[Wei] Th= anks.

&nb= sp;

Eric

&= nbsp;

Regards & Thanks!

Wei Pan=

--_000_0be97c3566f642348a123a8f9c4c6f4ahuaweicom_-- From nobody Fri Aug 14 11:32:54 2020 Return-Path: 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 462323A11C4 for ; Fri, 14 Aug 2020 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JBEDTsQPlkOm for ; Fri, 14 Aug 2020 11:32:51 -0700 (PDT) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F176D3A0FE7 for ; Fri, 14 Aug 2020 11:32:50 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 6eVVkA3nN8B0s6eVWk9My8; Fri, 14 Aug 2020 11:32:50 -0700 X-CMAE-Analysis: v=2.3 cv=B97HL9lM c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=Lyj-tKl4kf5N2EBW_WUA:9 a=C4eKisNKb83Rdvdn:21 a=Iq6MWgrJsuPEguE_:21 a=QEXdDO2ut3YA:10 a=4swtI4kOnyIL86qi:21 a=I7-ZTxpvEOLmXQop:21 a=cZfDxADVmFseAqKl:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_996278DF-C085-4454-B891-4845CC8E95DC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Aug 2020 11:32:48 -0700 In-Reply-To: Cc: "rats@ietf.org" To: "Nancy Cam-Winget (ncamwing)" References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfI/wGC6KIbPiNIvUJSB1wU8Jb659CS874VkqKdzDxFGYVNpKlN+BR5ExRvqKVoeHb3Hb0WHIbU2pZbl4EiLlLvSrkoy6Eyx2Uih1Ow/70n/sNFhXj0ky 6slL29iPTtDYfzpVee1oYUljsN9qmJAl/opmkJswo4fapZhWN2SUlYUMKaCKzb9r2pLntpd7uURWAh/9xJ/wVgDLnts0O/CbGs587OgCDB1ay8NdXTdmmO3H Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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: Fri, 14 Aug 2020 18:32:53 -0000 --Apple-Mail=_996278DF-C085-4454-B891-4845CC8E95DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Henk and others, can you comment on how this relates to FIDO, Android = Attestation, ARM PSA Token and such? It seems that a decision has to be taken as to whether this is: - THE generic interaction model for all of RATS in which case FIDO, = Android and such have to fit into it - One interaction model specific to a subset of RATS use cases I did a quick read and it seems like FIDO, Android and such could fit. = But it seems a commitment one way or the other is needed up front. If it = is THE model, then the work to make sure it is fully generic needs to be = done. People (not just me) will have to review it to see if it fits all = attestation use cases. If it doesn=E2=80=99t there will be writing to = do. Right now it seems framed as THE interaction mode (abstract, = introduction sections). Are the authors committing to this as THE Rats = interaction model? I think this needs to be clear before the document is adopted. LL > On Aug 12, 2020, at 1:25 PM, Nancy Cam-Winget (ncamwing) = wrote: >=20 > Hello RATs members, > At our IETF 108 session we discussed the draft: =20 > = https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction= -model/ = > =20 > There was interest in the discussion on the adoption of the topic, but = ran out of time to get consensus on =E2=80=9Cwhere=E2=80=9D these = interaction models should be documented. Further, Henk started an email = thread prior to our session to get a sense of interest and where these = models would best be described. > Given those results, there seemed to be a preference to keep the = document as a standalone draft that describes all models. > =20 > Thus, this is a Call for Adoption of the = draft-birkholz-rats-reference-interaction-model to serve as the starting = point for a standalone draft that describes all models. If you have = reservations for documenting interaction models, or for such a document = to be a standalone draft to describe all of them please respond to the = mail list and provide rationale for your concerns. > =20 > The call for adoption will end on Aug 28. > =20 > Best, Nancy (on behalf of the RATs chairs) > =20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats = --Apple-Mail=_996278DF-C085-4454-B891-4845CC8E95DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Henk = and others, can you comment on how this relates to FIDO, Android = Attestation, ARM PSA Token and such?

It seems that a decision has to be = taken as to whether this is:
- THE generic = interaction model for all of RATS in which case FIDO, Android and such = have to fit into it
- One interaction model = specific to a subset of RATS use cases

I did a quick read and it seems like = FIDO, Android and such could fit. But it seems a commitment one way or = the other is needed up front. If it is THE model, then the work to make = sure it is fully generic needs to be done. People (not just me) will = have to review it to see if it fits all attestation use cases. If it = doesn=E2=80=99t there will be writing to do.

Right now it seems framed as THE = interaction mode (abstract, introduction sections). Are the authors = committing to this as THE Rats interaction model?
I think this needs to be clear before = the document is adopted.

LL


On Aug = 12, 2020, at 1:25 PM, Nancy Cam-Winget (ncamwing) <ncamwing=3D40cisco.com@dmarc.ietf.org> wrote:

Hello RATs members,
At our IETF 108 session we discussed the draft: =  
https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-= interaction-model/
 
There was interest in the discussion on the = adoption of the topic, but ran out of time to get consensus on = =E2=80=9Cwhere=E2=80=9D these interaction models should be = documented.  Further, Henk started an email thread prior to our = session to get a sense of interest and where these models would best be = described.
Given those results, there seemed to be a = preference to keep the document as a standalone draft that describes all = models.
 
Thus, this is a Call for = Adoption of the draft-birkholz-rats-reference-interaction-model to serve = as the starting point for a standalone draft that describes all = models.  If you have reservations for documenting interaction = models, or for such a document to be a standalone draft to describe all = of them please respond to the mail list and provide rationale for your = concerns.
 
The call for adoption will = end on Aug 28.
 
Best, Nancy (on behalf of = the RATs chairs)
 
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

= --Apple-Mail=_996278DF-C085-4454-B891-4845CC8E95DC-- From nobody Fri Aug 14 12:25:59 2020 Return-Path: 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 CE5AA3A11F0; Fri, 14 Aug 2020 12:25: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=Aa9RbAil; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=ANSWXfwB 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 lJWHsHwuCCr5; Fri, 14 Aug 2020 12:25:54 -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 6CA933A11E5; Fri, 14 Aug 2020 12:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23693; q=dns/txt; s=iport; t=1597433154; x=1598642754; h=from:to:cc:subject:date:message-id:mime-version; bh=ZY8I+TUCoGQHyj9NkmTmpIHfDO2mmkmsDdijov4QTd8=; b=Aa9RbAilevbXyNf366SkZFc1fH6q8kbbjHk+thwRS0rmHECuw+ej/55Q 4oNbobXacOzpkgR+OFQwVi/7XOrhEKetFaT4Vi6qiM2sr141r1ALHMDOx +d8iaBmVnseNQ6H3VA7cJ6FtOzK2ibVgbom055gHFryij+ih9vH65RdKz c=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3ALn/iixPm1EmWk55j5JMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3l/UVJrW6rRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGNv3eFDT5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAACP5DZf/4UNJK1eGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgSMvUQdwKy0vLAqHcwONVodejByEbYJ?= =?us-ascii?q?TA1UEBwEBAQkDAQEtAgQBAYE1gxcCgkcCJDgTAgMBAQsBAQUBAQECAQYEbYV?= =?us-ascii?q?cDIVxAQEBAxMbEwEBNwEEDQEZBAEBKAkwFAkJAQQBDQUIBhSDBYF+TQMOEQ8?= =?us-ascii?q?BqB4CgTmIYXSBNIMBAQEFhTMYggcHCYE4gVOBHoosGoFBP4ERQ4IfbIQ/FYM?= =?us-ascii?q?zgi2QG4lvgRmbDwqCYoQ4glyTLIJ/iVuTRY1xhEefPAIEAgQFAg4BAQWBaiO?= =?us-ascii?q?BV3AVO4JpUBcCDY4fDBeDTopWdDcCBgoBAQMJfI8VAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,313,1592870400"; d="p7s'?scan'208,217";a="542676523" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 19:25:53 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EJPrNH019480 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 19:25:53 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 14:25:52 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 14:25:52 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 14:25:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PTDvFXa8U/XkTS+aXuz9Gjeo/EJqePiP13IP5SX3a+TZ8Z18OT0aNfavCmJY8Si1b7oCanjhwcHWQEu7AiAT/At+yuYunnhjgrNO9dzEeTGuDsR0I5eHqVhfTGHPZvHnS+oRN5I4ajksphfra3XPqsiJdGyir1A0UWj3h5JAsNTOBhIqgrZGOAape09DpNM7RZ+LI3nRpk29X8EDgBi4pEM6tz5sb7GU9BhHqzsL6rE3fULapCmv3nEJ+eZSr+9wLA0uwMWJWRH7kmXcaWV4A/O9it5V2a1eDjXhMqWw3bGFBoRyZpgu3P044L9StlsBL24OXfSuo3Ey1qVqbl5QhA== 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=TlB7WKwInLcJGMd69JJYfkoXcsQOEupFPi5z2RbmWpk=; b=EYJ2xESsYnE+Zm+p9M+SuRLQx4qw2suwqzAht2w8aCdpbc9Tn9hhTYmxJM2+O7LZn/cMbpXJWtD6xHthVg/qwaXr+7nYCjMC5vSIEXTS1Oe7hp8zA7qL+DXN0k0gDS4FZp26dbQM1szDZAG2Bjxvw9dzGLl0NXXjvXjrUjqI2hYivpyqMPvnXbubdW5jpodVXNSHen+Pmt+LgCdxNu+IZ1KBJRuSdrOXcZpogB4xHvRn4UBGTVsZsUcWn5QXZFV+eu1ewXCAGPJ1AEV6VjEsi1Db+/iADKZV0FZdq+8tqPlnbZsPfO+4cDOyI6WSvR2eDOtQmKv2ljRw1wmOyi1eCQ== 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=TlB7WKwInLcJGMd69JJYfkoXcsQOEupFPi5z2RbmWpk=; b=ANSWXfwBeIfaNnbrySLsj/evoicWE6SD8ra7AdosaQmMhwddCJzOv/4AUIB4EP+F3roFTQdYM5xWbXm/MpvdQFHIEmgdsOcjddkcOOKMLy+2/Bq5Bh9nw9PRADgyDkEEegebHzYL68MtZH21Hb2/K/eY+EJbnSXkM1U/dDDC4zk= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3123.namprd11.prod.outlook.com (2603:10b6:208:7b::33) 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 19:25:50 +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 19:25:50 +0000 From: "Eric Voit (evoit)" To: "Panwei (William)" , "Shwetha Bhandari (shwethab)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module) Thread-Index: AdZycLCFh7nlxgpkQEGyeEIa+yDQWg== Date: Fri, 14 Aug 2020 19:25:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.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: b61f07b7-32ec-49c7-d126-08d84087da62 x-ms-traffictypediagnostic: BL0PR11MB3123: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d3LBhO00MB1BkxdN/+gMtPIu1/iaGebBWZrlol+j4WtpLve6SQEZJZLL8x+dxA1gxREoMqVII44a0I0rR1eQSNQX96+tlr4aV00ZGg5f6nDOinHYyYt972aiZQojisFOhLCjvJhJO/vWfltIXX3Umon/FYP18ZWxUYCFqDDgVMESVUphI4VjSClWQo8kHD1ngDy5yf0OwFZnyPdNkLBFVx4BO2f4/FcayFQpLckchPfy6g6mrcEFbjsAJbHTci3vaDvrAYzPaAJo4j8FmnPyiWKB1deQd+EKkiSOZ2X2Ht0teUPce49wqUK5vNvsBS/5ZZ3AynLSvs5MlOYOckYIIg== 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)(366004)(376002)(346002)(39860400002)(136003)(396003)(9686003)(86362001)(2906002)(8676002)(71200400001)(99936003)(478600001)(6636002)(83380400001)(55016002)(110136005)(4326008)(6506007)(7696005)(26005)(186003)(5660300002)(53546011)(52536014)(66946007)(76116006)(66446008)(66616009)(66476007)(64756008)(8936002)(66556008)(54906003)(316002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: h9L1Kqcjx4v7nI0Y2tNrc7rKLgQAdmU1rme0v+6J6jQnSV6+6y2jdwBne1jeFz5Om9jOusFhN//2lfWvOI17rxXqC5f+ccd/K/k+3k1kGh04Fk16GSbayXAAciK0JOdvgVgODf/VNI4jw2SvWJgO9M7KPj/7knL+gnoP7EafqDIaHSbt+3lCEPMw3vLLoXpCLKKMXnAdXp3Yx3+neLCEYKO0BZeZUUyIt5Vi88NQol4sagpz5/OGCoSQhvn7xKXDVEv0etXkbEydMb2EdCmmCNPUW38uyVx9XWeHvtZsPUGcW63PyERvVbtCV1kPAgVDt7rw76H5KaeDrAxaUsnipx14+evUtqJJMrWqyoqvLKpKi6w13BPKBCYmcpnbCdFcWsySkzQws3MT4TqHFy6Pg11uTVictELnAdI2zstbizDf2DzvVODt2Yd+r6Sj7vcjZzt+DG4AL9hgoIxE2qKeo5czQjPAyPYaI/e2os/v9fz88hHPLAyimkrwbW/q2Pjz+QWlILNRKRBGrMYjTXwo5CPbHfJEKwwQJn8MnTNoyvmTJrMqypl8EGgX5fSkthHhh8n8a8QHP/ACVHg1fq6d/4wI+47/HCPkFQR/oxS5j6kQOKmCU2mtMOUOpSkKGzGRZT/rbiM81jQ4WXWMVuoMxw== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018C_01D6724F.2C4C2960" 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: b61f07b7-32ec-49c7-d126-08d84087da62 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 19:25:50.0449 (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: 2hI9NNEnAfj7W8fOn0dBcpP4p63DC1jfeHfMsslh5XE7Rjs9d1mnQ2OrrgrR0N5p X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3123 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:25:57 -0000 ------=_NextPart_000_018C_01D6724F.2C4C2960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_018D_01D6724F.2C4C2960" ------=_NextPart_001_018D_01D6724F.2C4C2960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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) ; Shwetha Bhandari (shwethab) > > Hi Eric, > > Thanks for your reply, please see inline. > > Regards & Thanks! > Wei Pan > > From: Eric Voit (evoit) [ mailto:evoit@cisco.com] > Sent: Thursday, August 13, 2020 10:32 PM > To: Panwei (William) < william.panwei@huawei.com>; Shwetha Bhandari > (shwethab) < shwethab@cisco.com> > Cc: rats@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 ------=_NextPart_001_018D_01D6724F.2C4C2960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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>; Shwetha Bhandari = (shwethab)

>

> Hi Eric,

> =

> Thanks for your reply, please see = inline.

>

> = Regards & Thanks!

> Wei Pan

>

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

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

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

> = (shwethab) <shwethab@cisco.com= >

> Cc: rats@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          &n= bsp;  binary

> =       |  |     = +---w = TPM12_Algo?          &n= bsp;  identityref

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

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

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

> =       |  |     = |  +--:(TSS_UUID)

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

> =       |  |     = |        +---w ulTimeLow?  &n= bsp;    uint32

> =       |  |     = |        +---w usTimeMid?  &n= bsp;    uint16

> =       |  |     = |        +---w usTimeHigh?  &= nbsp;   uint16

> =       |  |     = |        +---w bClockSeqHigh? &nbs= p; uint8

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

>       |  = |     |        = +---w rgbNode*  &nbs= p;      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?          &= nbsp; boolean

> =       |  |     = +---w = tpm-name*          &nbs= p;    string

 

 

------=_NextPart_001_018D_01D6724F.2C4C2960-- ------=_NextPart_000_018C_01D6724F.2C4C2960 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE0MTkyNTQyWjAjBgkqhkiG 9w0BCQQxFgQU2tGspyh7WnfB6cX4nnVo7kJl0G4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAlybfSiUlV1DR/rhoUaliiKJskrYbkYeTvGoLSFhoQBP2fyaEut66jHLi3SWhKr9aM mU+qhu+66If5H/A+EVnOdsSIgGdM9Yl751c3qv/8tyzhr/Ao4MEYA5peiTwV65XRxA3aRIoq54yB WFEIE/0pJ/Hs8bntaG6jfOEbEDe6w5gEyUGqa7aKTkH3rmu+RbUikYg6gb473bPX2D6FEaM4+mjX 7tVRmFPyyxmxPa/OAcqn2/m2QO9/3YlYxhm/Ays5DfSFPIE9qiGn6Kxtvb5tkXXaKcS/kYz7bmBl B8Rcm7KS6krOLu+LRZQtAGHAJvqgBK9FYU8M/7PNq9nwBvfwAAAAAAAA ------=_NextPart_000_018C_01D6724F.2C4C2960-- From nobody Fri Aug 14 13:26:58 2020 Return-Path: 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)" To: "Shwetha Bhandari (shwethab)" , "Panwei (William)" , "draft-ietf-rats-yang-tpm-charra@ietf.org" CC: "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: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 20:26:57 -0000 ------=_NextPart_000_01EC_01D67257.467062E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01ED_01D67257.467062E0" ------=_NextPart_001_01ED_01D67257.467062E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Shwetha, Panwei, and other Charra authors, On another parallel but related question, should we use rather than 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 you directly know the TPM. With some , 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 (binary) to (string). With 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 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) ; Shwetha Bhandari (shwethab) 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) >; Shwetha Bhandari (shwethab) > > Hi Eric, > > Thanks for your reply, please see inline. > > Regards & Thanks! > Wei Pan > > From: Eric Voit (evoit) [ mailto:evoit@cisco.com] > Sent: Thursday, August 13, 2020 10:32 PM > To: Panwei (William) < william.panwei@huawei.com>; Shwetha Bhandari > (shwethab) < shwethab@cisco.com> > Cc: rats@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 ------=_NextPart_001_01ED_01D67257.467062E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

         &= nbsp;   +--rw certificate* = [certificate-name]

         &= nbsp;      +--rw certificate-name = ;   string

         &= nbsp;      +--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   = ;            =             &= nbsp;        = string

         &= nbsp;    +--rw = public-key          &nb= sp;           &nbs= p;       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>; 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>; Shwetha = Bhandari (shwethab)

> =

> Hi Eric,

>

> = Thanks for your reply, please see inline.

>

> = Regards & Thanks!

> Wei = Pan

>

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

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

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

> (shwethab) <shwethab@cisco.com= >

> Cc: rats@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          &n= bsp;  binary

> =       |  |     = +---w = TPM12_Algo?          &n= bsp;  identityref

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

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

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

>       |  = |     |  +--:(TSS_UUID)

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

> =       |  |     = |        +---w ulTimeLow?  &n= bsp;    uint32

> =       |  |     = |        +---w usTimeMid?  &n= bsp;    uint16

> =       |  |     = |        +---w usTimeHigh?  &= nbsp;   uint16

> =       |  |     = |        +---w bClockSeqHigh? &nbs= p; uint8

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

>       |  = |     |        = +---w rgbNode*  &nbs= p;      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?          &= nbsp; boolean

> =       |  |     = +---w = tpm-name*          &nbs= p;    string

 

 

------=_NextPart_001_01ED_01D67257.467062E0-- ------=_NextPart_000_01EC_01D67257.467062E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE0MjAyMzQyWjAjBgkqhkiG 9w0BCQQxFgQUWmOeydpyfWHxTqIox8dDQ0vKROkwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBOW1hQFg4mDxzPh7fYq+pkeNKZB51Yqg74cT0cVa/iG4rNTI9F01BLFtCv/jsmC+YI vdk3GwEhfLB/2I+ZOeRA6Qe0Tqai3ExpOcq4vJB6NKSE9/G3paJZlBE1vWmaX4Kn5mzZ7NeyPKXz Olq94OEuztZVju9+uyKNrDI7IQ0CSWYR9ZyQT86Tl/fKhKg+oOAS7/VF+dtf9+3lopu1j2+SDpHS oH6RRxvAIWuElPkukiotScSN/zp9ChMZ+OHW8u+cSk49bFnFydS5DOtD0M6FbVDxW+dRisJWdKO2 NlJp1ct7V0K5mXYcgOyax8I0mHVZa5B0+HFfFOX5/4W4z68HAAAAAAAA ------=_NextPart_000_01EC_01D67257.467062E0-- From nobody Fri Aug 14 13:40:24 2020 Return-Path: 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 3FF513A0828 for ; Fri, 14 Aug 2020 13:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 6nTq-Hu6KfcS for ; Fri, 14 Aug 2020 13:40:21 -0700 (PDT) Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBE13A0829 for ; Fri, 14 Aug 2020 13:40:21 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 6gUukGkdl0z4J6gUukofDd; Fri, 14 Aug 2020 13:40:20 -0700 X-CMAE-Analysis: v=2.3 cv=EP14LGRC c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=HLvPDLHGFjgA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=i0EeH86SAAAA:8 a=xmUNafhd6lKAHtGaHIgA:9 a=jfNWjsY6Fqv2vH6u:21 a=6oluxLdc4AcZMxH5:21 a=CjuIK1q_8ugA:10 a=-RoEEKskQ1sA:10 a=T3wz0T-rhxfyFPLmYl0A:9 a=GDVG_9hhRVaeYIu-:21 a=gx20X-eYy1KLarAA:21 a=PLh_Fdiy6M89ooQr:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_56E047AC-F617-4E22-B475-F17B6D0A7421" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Aug 2020 13:40:18 -0700 In-Reply-To: Cc: "Panwei (William)" , "Shwetha Bhandari (shwethab)" , "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" To: "Eric Voit (evoit)" References: X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfF96k2xUaMhMfm015XQFbnECtabaADaqW5ANy1m2WCq4r03xC/OBsZ97JtihAh/2xccBr1fqpH22tsnykd9teDkuF/Af0uVVzlE76HgB8WT2bmXR3ZJQ t2k9X3LbKEtCnKrx2AwD3uqttTgF+DU0c7y48zSTz0tBS0bqJhRYvZQH/fca5YdKaG0sm5Aqt82H0x2vBeocwoXAl3w0BL6pu6808dsztwp7VynmwQgWEvhe DsshLReK2p9r4uZiUPPieKoIl4jv4Cp7F6le7tmZ5pgcpRmI2IIfwwD6pbw6aHd2RFGGh+XxGRMI4W0CJ4gCFUj0q3mqbo8Awl2i+Drqw9M= Archived-At: Subject: Re: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 20:40:23 -0000 --Apple-Mail=_56E047AC-F617-4E22-B475-F17B6D0A7421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would suggest avoiding UUIDs if possible. Nowadays good RNGs are = available and you can just use them to generate a nonce or such. Good = RNGs were not available commonly in CPUs when UUIDs were invented, but = they are now. If you just want a nonce, then the internal structure of = a UUID is of no value and just adds complexity and confusion. LL > On Aug 14, 2020, at 12:25 PM, Eric Voit (evoit) = wrote: >=20 > Hi Wei Pan, > =20 > Just slightly related to the question you asked previously, I have a = question on the model/tree you sent back (in-line...) > =20 > > From: Panwei, August 14, 2020 6:01 AM > > To: Eric Voit (evoit) >; = Shwetha Bhandari (shwethab) > > > > Hi Eric, > > > > Thanks for your reply, please see inline. > > > > Regards & Thanks! > > Wei Pan > > > > From: Eric Voit (evoit) [mailto:evoit@cisco.com = ] > > Sent: Thursday, August 13, 2020 10:32 PM > > To: Panwei (William) >; Shwetha Bhandari > > (shwethab) > > > Cc: rats@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 > =20 > 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: > =20 > (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? > =20 > (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? > =20 > (3) Assuming you really want UUIDs, you need to propose how a UUID = might relate to keys within the IETF ecosystem of YANG models. =20 > =20 > BTW: If you don't need UUIDs, we could always drop them from the = model. (Leaving them to vendor specific augmentations if necessary.) > =20 > Thanks, > Eric > =20 > > | | +---w add-version? boolean > > | | +---w tpm-name* string > =20 > =20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats = --Apple-Mail=_56E047AC-F617-4E22-B475-F17B6D0A7421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = would suggest avoiding UUIDs if possible. Nowadays good RNGs are = available and you can just use them to generate a nonce or such. Good = RNGs were not available commonly in CPUs when UUIDs were invented, but = they are now.  If you just want a nonce, then the internal = structure of a UUID is of no value and just adds complexity and = confusion.

LL

On Aug 14, 2020, at 12:25 PM, Eric Voit (evoit) <evoit=3D40cisco.com@dmarc.ietf.org> wrote:

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>; = Shwetha Bhandari (shwethab)
>
> Hi = Eric,
>
> Thanks for your reply, please see = inline.
>
> Regards & Thanks!
> Wei Pan
>
> From: Eric Voit = (evoit) [mailto:evoit@cisco.com]
> Sent: Thursday, August 13, 2020 10:32 PM
> To: Panwei (William) <william.panwei@huawei.com>; Shwetha = Bhandari
> (shwethab) <shwethab@cisco.com>
> 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          &nb= sp;  binary
> =       |  |     = +---w = TPM12_Algo?          &nb= sp;  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?          &n= bsp; boolean
> =       |  |     = +---w = tpm-name*           = ;    string
 
 
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

= --Apple-Mail=_56E047AC-F617-4E22-B475-F17B6D0A7421-- From nobody Fri Aug 14 14:01:12 2020 Return-Path: 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 A8C4B3A0913; Fri, 14 Aug 2020 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 aWqvaUMPJMxd; Fri, 14 Aug 2020 14:01:07 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753213A08E9; Fri, 14 Aug 2020 14:01:02 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07EKtCtB031206; Fri, 14 Aug 2020 22:00:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OsmYBju9WO34xxbDgXthV525pNbIRgCz2mVdxIYgyGg=; b=GorVhgTVyTpPEdo619j+JQOXfAZTG+jICqVnV2HW+//nlgWu/xqTujVNmgM8l7felSCZ ZBPbvPjDhPHRGp+RnArQSpx+KOH30PRO3UTz9FWXYSovYWqCtWrZuaGwgTdNZEg7Ovzq FzN7sXTIiDtRn6h36qm1etxqXCJGcPO05xJ72EtRuEdZWOHAFqsJ8en4WMePh5PCo8Zg whwTVmmxWBEOWQVWNG3UPaNzqbsAv+v/qdfuoI4yAztbe9CTChQToun0g199kEmahObW sPFQKwB4mwvRdDLfGNxk2odRl5+KSTFBl4qMqtIeO/ayviw8zGBp2N0zfCpb2Wg6LwFD VA== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 32sm80hw2g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 22:00:57 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07EKZ0RU020482; Fri, 14 Aug 2020 17:00:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint4.akamai.com with ESMTP id 32sqcyehnn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 17:00:56 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 16:00:55 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Fri, 14 Aug 2020 16:00:55 -0500 From: "Salz, Rich" To: Laurence Lundblade , "Eric Voit (evoit)" CC: "rats@ietf.org" , "Panwei (William)" , "Shwetha Bhandari (shwethab)" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module) Thread-Index: AdZycLCFh7nlxgpkQEGyeEIa+yDQWgANFdEA///CswA= Date: Fri, 14 Aug 2020 21:00:54 +0000 Message-ID: <2251DEFB-F6A2-4AC9-82D4-B67D22175821@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.150] Content-Type: multipart/alternative; boundary="_000_2251DEFBF6A24AC982D4B67D22175821akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-14_13:2020-08-14, 2020-08-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=684 adultscore=0 mlxscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008140151 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-14_16:2020-08-14, 2020-08-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 clxscore=1011 malwarescore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 suspectscore=0 mlxlogscore=631 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008140154 Archived-At: Subject: Re: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 21:01:09 -0000 --_000_2251DEFBF6A24AC982D4B67D22175821akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3b3VsZCBzdWdnZXN0IGF2b2lkaW5nIFVVSURzIGlmIHBvc3NpYmxlLiBOb3dhZGF5 cyBnb29kIFJOR3MgYXJlIGF2YWlsYWJsZSBhbmQgeW91IGNhbiBqdXN0IHVzZSB0aGVtIHRvIGdl bmVyYXRlIGEgbm9uY2Ugb3Igc3VjaC4gR29vZCBSTkdzIHdlcmUgbm90IGF2YWlsYWJsZSBjb21t b25seSBpbiBDUFVzIHdoZW4gVVVJRHMgd2VyZSBpbnZlbnRlZCwgYnV0IHRoZXkgYXJlIG5vdy4g IElmIHlvdSBqdXN0IHdhbnQgYSBub25jZSwgdGhlbiB0aGUgaW50ZXJuYWwgc3RydWN0dXJlIG9m IGEgVVVJRCBpcyBvZiBubyB2YWx1ZSBhbmQganVzdCBhZGRzIGNvbXBsZXhpdHkgYW5kIGNvbmZ1 c2lvbi4NCg0KQXMgdGhlIGxlYWQgYXV0aG9yIG9mIHRoZSBVVUlEIFJGQzogSSBhZ3JlZS4NCg0K --_000_2251DEFBF6A24AC982D4B67D22175821akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEzMjM4NDcxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTE3Mjc3NjMyNiAtODI5Mjc3NDE0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+SSB3b3VsZCBzdWdnZXN0IGF2b2lkaW5nIFVVSURzIGlmIHBvc3NpYmxlLiBO b3dhZGF5cyBnb29kIFJOR3MgYXJlIGF2YWlsYWJsZSBhbmQgeW91IGNhbiBqdXN0IHVzZSB0aGVt IHRvIGdlbmVyYXRlIGEgbm9uY2Ugb3Igc3VjaC4gR29vZCBSTkdzIHdlcmUgbm90IGF2YWlsYWJs ZSBjb21tb25seSBpbiBDUFVzIHdoZW4NCiBVVUlEcyB3ZXJlIGludmVudGVkLCBidXQgdGhleSBh cmUgbm93LiAmbmJzcDtJZiB5b3UganVzdCB3YW50IGEgbm9uY2UsIHRoZW4gdGhlIGludGVybmFs IHN0cnVjdHVyZSBvZiBhIFVVSUQgaXMgb2Ygbm8gdmFsdWUgYW5kIGp1c3QgYWRkcyBjb21wbGV4 aXR5IGFuZCBjb25mdXNpb24uDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIHRoZSBsZWFkIGF1dGhvciBvZiB0aGUgVVVJRCBSRkM6IEkgYWdyZWUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2251DEFBF6A24AC982D4B67D22175821akamaicom_-- From nobody Sat Aug 15 18:10:57 2020 Return-Path: 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 A272A3A0B6A for ; Sat, 15 Aug 2020 18:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LE_KlzqIZ2xC for ; Sat, 15 Aug 2020 18:10:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30EA3A0B69 for ; Sat, 15 Aug 2020 18:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A242389DA; Sat, 15 Aug 2020 20:50:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 35BePpx402nx; Sat, 15 Aug 2020 20:50:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 00DFF389D9; Sat, 15 Aug 2020 20:50:02 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6B6A4136; Sat, 15 Aug 2020 21:10:51 -0400 (EDT) From: Michael Richardson To: Laurence Lundblade , rats@ietf.org In-Reply-To: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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, 16 Aug 2020 01:10:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Laurence Lundblade wrote: > Service providers (e.g., web sites) use whatever HW and SW they want = to > use. As a user of the service we don=E2=80=99t care what HW and SW th= ey > select. We trust the service provider to pick good HW and SW and to > configure and operate it correctly. They might change the HW and the = SW > and as a user we won=E2=80=99t know. For example we trust Bank of Xx= x to > operate their banking web site correctly with little concern for their > HW. This is why attestation of the HW and SW is not so useful to the > user of a service. The only reason that I do not demand knowledge (attestation) about how my Bank operates is because I don't (individually) have the economic clout to = demand it, and the users suffer from a Collective Action Problem https://www.britannica.com/topic/collective-action-problem-1917157 https://en.wikipedia.org/wiki/Collective_action_problem In Canada (at least), as a shareholder of a publically trade company, I'm apparently forbidden from communicating with other shareholders, except via= the company. So I don't think that the difference has anything to do with what we want, but rather what has been possible up to now. My bank regularly makes very poor technology choices. They also seem very reluctant to publically document their processes. Unfortunately, I can't vote with my wallet, because the other ones are as b= ad or worse. > Users of mobile phones and IoT devices are not trustworthy to pick > secure HW and SW. They are not professionals like the people running > web sites. There is little accountability against them if they pick b= ad > SW and HW. Therefor we want attestation for these usage scenarios. Th= is > is why EAT, FIDO and Android Attestation exist. This does not ring correct at all to me. Large media giants want assurances from manufacturers of phones that the end user does not have control over the video output systems, and the large suppliers have demanded (again, through massive differences in economic clout) assurances. It has nothing to do with the abilities of the owners. In fact, what is desired is assurance that the owners have in fact been forced not to pick their own SW. Carsten Bormann wrote: > if you are talking about HTTPS, there is exactly one claim: The > service is speaking for a specific name (e.g., facebook.com). All > other claims are funneled through this one very special one. Of > course, the TLS handshake could be leveraged to do more than this one > claim, but that is not what happens in HTTPS. The CA system could also review the Bank's systems on a regular basis. Claims could be embedded in the HTTPS server certificate, and this is alrea= dy in the architecture, in the spider diagram. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl84h5sACgkQgItw+93Q 3WVruQf/c7+nyKkPfb5cvrtFyBassrCR6ExrevdhHsv4Y3IE2bluDptu0TITkjdL 2YVR0g1+UeUm3iNn4uZ+fq5zzj77GRAJMWy7Yc8D/1hozTK2UVC5UPM9Sm7saabB PW3eAh9lwrwBCjWARaI5WxNx5Ja/06OR74Q5eeggp6RqPHPNT60Hfap2mvSGCQzk DbV9F2e/Wk28SLvnjorJqUv7aqQkD33BTPjYsZsk2kwKZ3IWj4jGgGYQZUsR3IAM beAwiIhww/EovbF2WxctwZCSA76tCkLH+1a21vUi8tjf95qJ7ipo18nJ82WLnlpO 2duop3s0F+o2VTV1W3MWdKEn2Z2cTw== =lDIQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 03:28:35 2020 Return-Path: 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 800443A0B2B for ; Mon, 10 Aug 2020 12:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=pNgSkgTS; dkim=pass (2048-bit key) header.d=gmail.com header.b=CO2okpPR 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 9un7_vCJICMA for ; Mon, 10 Aug 2020 12:15:34 -0700 (PDT) Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C1D3A0B76 for ; Mon, 10 Aug 2020 12:15:34 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id r1so14067569ybg.4 for ; Mon, 10 Aug 2020 12:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=qmR39YQgd2QWXTq7yq1IPn3uUjBR3x3qnq9Mw80gFO0=; b=pNgSkgTSmrYIYfGToFXYHyd6Equ0LU3Jj8BCwAA16fMdRBBoIn7q4R3TKWOMldOakT IPvjl+hkE3ETmcKeRqRq8feeSbD8mHLg/mZAO+kcn+7xZFC5qIKm2Mlk2ML+BNgY3C/k cgh4+9Kzji/rfiRnU2/fikeTN460TCL69LHBA22cLEzWUimHE6EHBwZ8C1LyCt82DAEh Jj1UI+uwGt+FHWfWP6d4aK9YdfveIPCOARENi0l4SaoI+HZXRrLY7Kly8ji4e2BuRJWf XTGC/W2Mfh32W3G7d8tY5f4RlX+cM8HMsI7Mm9xu/BuRy136jHnFqf2lgdlaeVvRnHdX A5iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=qmR39YQgd2QWXTq7yq1IPn3uUjBR3x3qnq9Mw80gFO0=; b=CO2okpPRsM4waLh7yBaVJEv0ntA8X3bGpPfQdipRiQqjGz8M5Q7jR0uqeM4v7+J5Yv OVE8rWj7JX7WQGiPn8hu2s+E82n4Sqgj7py3w47poyZ/JDmndTQr3CBrmgTw8L9XJETb tdYytOyjETCP8IvEahPv0DVFpJqr+pB9FZd9u3K1gHW5S9AHdTHm1KZ8CUsB/e0bMah9 GbZohmJu+EG/pcWlmhKo8B2bB6yR/zkMedzyo0IcZ2IB/ijAALa3I7EcXfLkEdOwXwTa kdrpal+8XEvKZXArqgsYlIDWrh2eqtWAWRt80j/fheKiqZ3c7cxA/ODyAcozn13wUPbL bVfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=qmR39YQgd2QWXTq7yq1IPn3uUjBR3x3qnq9Mw80gFO0=; b=LH60sHZcKZ5auzfsw+qsSZTh/PX06mh3hXKd2znJKDdnf+Tgwv7cjXbxv+bh2/WmR3 JrsnF5w+AcrrHw4ho5TxC/ilfYx5IF/xz3NAcOQWF7NX7tbTDCQXdcy1cux/sF0JRaVm OyrIBNVACuzfYlp4wfvSGXxKw17oVUocKNJO62Mf5b4UlM6uSSlozd8JnISIqSjsdWt8 omNLhq3iO0Vi/4hdCveYEVGkNla5Dwgd2W9bYevPIH7bBvTvndkbUWoQfvv4JTEpQK9N r36yB2GLoCPFnQq3e7I6WQsCJDJlvNGDQO33cPDIIO5q1zT/czyOo55K+mqNSn2qH+yr v71Q== X-Gm-Message-State: AOAM531PIuLFMOFBM6BIZeK0SyfnJQCZrof/wVnZu+8o1PbeSXUuc+v1 J9glVMnSFff6QeemKqSaF92jXqb7LZBo5UjkczQ= X-Google-Smtp-Source: ABdhPJzRoOdsTeVE2N4kmdXMSlrrgCFpzeBViFGjQq5/6M80/Hz6geVMOv2MtNJPT2d62GNLXDYwRtyyntjLsLVncckQ MIME-Version: 1.0 X-Received: by 2002:a25:ce04:: with SMTP id x4mr39009426ybe.360.1597086932981; Mon, 10 Aug 2020 12:15:32 -0700 (PDT) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <00000000000050dfa205ac8ac766@google.com> Date: Mon, 10 Aug 2020 19:15:32 +0000 From: mcharlesr@gmail.com To: rats@ietf.org, prowe@mitre.org, ncamwing@cisco.com, Nicolae Paladi , lgl@island-resort.com, xinxin@iotex.io, blueroofmusic@gmail.com, Thomas Fossati , mathias.brossard@arm.com, Ned Smith , Henk Birkholz , dthaler@microsoft.com, Peter Loscocco , "Zhu, Bing" , "Helble, Sarah C." , elear@cisco.com, mdb@juniper.net, jodonogh@qti.qualcomm.com, Thomas Hardjono , "Joe Malcolm (jomalcol)" , Pete Loscocco , Thomas Fossati , "Guinn, Andrew L." , shwethab@cisco.com Content-Type: multipart/mixed; boundary="00000000000050df3e05ac8ac765" Archived-At: X-Mailman-Approved-At: Mon, 17 Aug 2020 03:28:34 -0700 Subject: [Rats] Invitation: RATS Architecture Design Team weekly meeting time @ Weekly from 10:00 to 11:00 on Tuesday, Friday 8 times (EDT) (rats@ietf.org) X-BeenThere: rats@ietf.org 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, 10 Aug 2020 19:15:37 -0000 --00000000000050df3e05ac8ac765 Content-Type: multipart/alternative; boundary="00000000000050df3b05ac8ac763" --00000000000050df3b05ac8ac763 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes You have been invited to the following event. Title: RATS Architecture Design Team weekly meeting time Meeting link:https://ietf.webex.com/ietf/j.php?MTID=m4c3d7395a15dad1ed8c0f95452794c25Meeting number:610 366 750Password:4vY2aS6X8DFHost key:820822More ways to join When: Weekly from 10:00 to 11:00 on Tuesday, Friday 8 times Eastern Time - Toronto Where: https://ietf.webex.com/ietf/j.php?MTID=m4c3d7395a15dad1ed8c0f95452794c25 Joining info: Join with Google Meet https://meet.google.com/iki-tpac-hdh Calendar: rats@ietf.org Who: * mcharlesr@gmail.com - organizer * prowe@mitre.org * ncamwing@cisco.com * Nicolae Paladi * lgl@island-resort.com * xinxin@iotex.io * blueroofmusic@gmail.com * Thomas Fossati * mathias.brossard@arm.com * Ned Smith * Henk Birkholz * dthaler@microsoft.com * Peter Loscocco * Zhu, Bing * Helble, Sarah C. * elear@cisco.com * mdb@juniper.net * rats@ietf.org * jodonogh@qti.qualcomm.com * Thomas Hardjono * Joe Malcolm (jomalcol) * Pete Loscocco * Thomas Fossati * Guinn, Andrew L. * shwethab@cisco.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NmJldGE2NjFhdTI2bGh0c3NkdHM2bGdqbGggcmF0c0BpZXRmLm9yZw&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbWQ2Yzg4MjMwMDdhYzFmNmMyNWQzOGMwZTU0NzZlNmJjMTY2MmM4ZTA&ctz=America%2FToronto&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account rats@ietf.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding --00000000000050df3b05ac8ac763 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

You have been invited to the follo= wing event.

RATS Architecture Design Team weekl= y meeting time

<= td style=3D"padding-bottom:4px;font-family:Arial,Sans-serif;font-size:13px;= color:#222" valign=3D"top">
Join with Google= Meet
=
When
W= eekly from 10:00 to 11:00 on Tuesday, Friday 8 times Eastern Time - Toronto
= Where
https://ietf.webex.com/= ietf/j.php?MTID=3Dm4c3d7395a15dad1ed8c0f95452794c25 (map)=
Joining info
Calendar
r= ats@ietf.org
Who
•
= = = =
mcharlesr@gmail.com - organ= izer
&= #x2022;
=
prowe@mitre.org
ncamwing@cisco.com
•
Nicolae Paladi
•
lgl@island-resort.com
•
xinxin@iotex.io
•
=
blueroofmusic@gmail.com
•
Thomas Fossat= i
•<= /div>
mathias.b= rossard@arm.com
•
Ned Smith
<= div style=3D"text-indent:-1px">•
Henk Birkholz
•
dthaler@microsoft.com
•
Peter Loscocco
<= span style=3D"font-family:Courier New,monospace">•
Zhu, Bing
<= span style=3D"font-family:Courier New,monospace">•
Helble, Sarah C.
•
elear@c= isco.com
•
mdb@= juniper.net
•=
rats@ietf.org
•= ;
jodonogh@qti.qualcomm.com
•
Thomas Hardjono
•
Joe Malcolm (jomalcol)
•
= Pete Loscocco
<= span style=3D"font-family:Courier New,monospace">•
Thomas Fossati
•
Guinn, And= rew L.=
&#x= 2022;
shwethab@cisco.com
more details »
Meeting link:
https://ietf.webex.com/i= etf/j.php?MTID=3Dm4c3d7395a15dad1ed8c0f95452794c25
Meeting numb= er:
610 366 750
Password:
4vY2aS6X8DF
Host = key:
820822


More ways to join
=

Goi= ng (rats@ietf.org)?   All events in this series:=    Yes - Maybe - No=     more options &r= aquo;

= Invitation from Google Calendar

You are receiving this courtesy em= ail at the account rats@ietf.org because you are an attendee of this event.=

To stop receiving future updates for this event, decline this event.= Alternatively you can sign up for a Google account at https://www.google.c= om/calendar/ and control your notification settings for your entire calenda= r.

Forwarding this invitation could allow any recipient to send a res= ponse to the organizer and be added to the guest list, or invite others reg= ardless of their own invitation status, or to modify your RSVP. Learn More= .

 --00000000000050df3b05ac8ac763 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20200818T100000 DTEND;TZID=America/Toronto:20200818T110000 RRULE:FREQ=WEEKLY;WKST=MO;COUNT=8;BYDAY=FR,TU DTSTAMP:20200810T191532Z ORGANIZER;CN=mcharlesr@gmail.com:mailto:mcharlesr@gmail.com UID:6beta661au26lhtssdts6lgjlh@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=prowe@mitre.org;X-NUM-GUESTS=0:mailto:prowe@mitre.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=ncamwing@cisco.com;X-NUM-GUESTS=0:mailto:ncamwing@cisco.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Nicolae Paladi;X-NUM-GUESTS=0:mailto:nicolae.paladi@ri.se ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=lgl@island-resort.com;X-NUM-GUESTS=0:mailto:lgl@island-resort.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=xinxin@iotex.io;X-NUM-GUESTS=0:mailto:xinxin@iotex.io ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=blueroofmusic@gmail.com;X-NUM-GUESTS=0:mailto:blueroofmusic@gmail.c om ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Thomas Fossati;X-NUM-GUESTS=0:mailto:tho@koanlogic.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=mathias.brossard@arm.com;X-NUM-GUESTS=0:mailto:mathias.brossard@arm .com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Ned Smith;X-NUM-GUESTS=0:mailto:ned.smith@intel.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Henk Birkholz;X-NUM-GUESTS=0:mailto:henk.birkholz@sit.fraunhofer.de ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=dthaler@microsoft.com;X-NUM-GUESTS=0:mailto:dthaler@microsoft.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Peter Loscocco;X-NUM-GUESTS=0:mailto:palosco@tycho.nsa.gov ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN="Zhu, Bing";X-NUM-GUESTS=0:mailto:bing.zhu@intel.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN="Helble, Sarah C.";X-NUM-GUESTS=0:mailto:sarah.helble@jhuapl.edu ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=mcharlesr@gmail.com;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=elear@cisco.com;X-NUM-GUESTS=0:mailto:elear@cisco.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=mdb@juniper.net;X-NUM-GUESTS=0:mailto:mdb@juniper.net ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=rats@ietf.org;X-NUM-GUESTS=0:mailto:rats@ietf.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=jodonogh@qti.qualcomm.com;X-NUM-GUESTS=0:mailto:jodonogh@qti.qualco mm.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Thomas Hardjono;X-NUM-GUESTS=0:mailto:ietf-rats@hardjono.net ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Joe Malcolm (jomalcol);X-NUM-GUESTS=0:mailto:jomalcol@cisco.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Pete Loscocco;X-NUM-GUESTS=0:mailto:pete.loscocco@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Thomas Fossati;X-NUM-GUESTS=0:mailto:thomas.fossati@arm.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN="Guinn, Andrew L.";X-NUM-GUESTS=0:mailto:andrew.guinn@jhuapl.edu ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=shwethab@cisco.com;X-NUM-GUESTS=0:mailto:shwethab@cisco.com X-MICROSOFT-CDO-OWNERAPPTID:-940844781 CREATED:20200810T191531Z DESCRIPTION:
Meeting link:
h ttps://ietf.webex.com/ietf/j.php?MTID=m4c3d7395a15dad1ed8c0f95452794c25
Meeting number:
610 366 750
Password:
4vY2 aS6X8DF
Host key:
820822


More ways to join
\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the desc ription.\n\nThis event has a video call.\nJoin: https://meet.google.com/iki -tpac-hdh\n\nView your event at https://www.google.com/calendar/event?actio n=VIEW&eid=NmJldGE2NjFhdTI2bGh0c3NkdHM2bGdqbGggcmF0c0BpZXRmLm9yZw&tok=MTkjb WNoYXJsZXNyQGdtYWlsLmNvbWQ2Yzg4MjMwMDdhYzFmNmMyNWQzOGMwZTU0NzZlNmJjMTY2MmM4 ZTA&ctz=America%2FToronto&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20200810T191531Z LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m4c3d7395a15dad1ed8c0f95452 794c25 SEQUENCE:0 STATUS:CONFIRMED SUMMARY:RATS Architecture Design Team weekly meeting time TRANSP:OPAQUE END:VEVENT END:VCALENDAR --00000000000050df3b05ac8ac763-- --00000000000050df3e05ac8ac765 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkFtZXJpY2EvVG9yb250bw0KWC1MSUMtTE9DQVRJT046 QW1lcmljYS9Ub3JvbnRvDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9G RlNFVFRPOi0wNDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6 RlJFUT1ZRUFSTFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFO REFSRA0KVFpPRkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpE VFNUQVJUOjE5NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURB WT0xU1UNCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQVJU O1RaSUQ9QW1lcmljYS9Ub3JvbnRvOjIwMjAwODE4VDEwMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNh L1Rvcm9udG86MjAyMDA4MThUMTEwMDAwDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NUPU1PO0NPVU5U PTg7QllEQVk9RlIsVFUNCkRUU1RBTVA6MjAyMDA4MTBUMTkxNTMyWg0KT1JHQU5JWkVSO0NOPW1j aGFybGVzckBnbWFpbC5jb206bWFpbHRvOm1jaGFybGVzckBnbWFpbC5jb20NClVJRDo2YmV0YTY2 MWF1MjZsaHRzc2R0czZsZ2psaEBnb29nbGUuY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVB TDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVF O0NOPXByb3dlQG1pdHJlLm9yZztYLU5VTS1HVUVTVFM9MDptYWlsdG86cHJvd2VAbWl0cmUub3Jn DQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RB VD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPW5jYW13aW5nQGNpc2NvLmNvbTtYLU5VTS1H VUVTVFM9MDptYWlsdG86bmNhbXdpbmdAY2lzY28uY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJ RFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBU UlVFO0NOPU5pY29sYWUgUGFsYWRpO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpuaWNvbGFlLnBhbGFk aUByaS5zZQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1sZ2xAaXNsYW5kLXJlc29ydC5j b207WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmxnbEBpc2xhbmQtcmVzb3J0LmNvbQ0KQVRURU5ERUU7 Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNU SU9OO1JTVlA9DQogVFJVRTtDTj14aW54aW5AaW90ZXguaW87WC1OVU0tR1VFU1RTPTA6bWFpbHRv OnhpbnhpbkBpb3RleC5pbw0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFS VElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1ibHVlcm9vZm11 c2ljQGdtYWlsLmNvbTtYLU5VTS1HVUVTVFM9MDptYWlsdG86Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5j DQogb20NCkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BB UlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049VGhvbWFzIEZvc3NhdGk7WC1OVU0t R1VFU1RTPTA6bWFpbHRvOnRob0Brb2FubG9naWMuY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJ RFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBU UlVFO0NOPW1hdGhpYXMuYnJvc3NhcmRAYXJtLmNvbTtYLU5VTS1HVUVTVFM9MDptYWlsdG86bWF0 aGlhcy5icm9zc2FyZEBhcm0NCiAuY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xF PVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPU5l ZCBTbWl0aDtYLU5VTS1HVUVTVFM9MDptYWlsdG86bmVkLnNtaXRoQGludGVsLmNvbQ0KQVRURU5E RUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMt QUNUSU9OO1JTVlA9DQogVFJVRTtDTj1IZW5rIEJpcmtob2x6O1gtTlVNLUdVRVNUUz0wOm1haWx0 bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJ RFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBU UlVFO0NOPWR0aGFsZXJAbWljcm9zb2Z0LmNvbTtYLU5VTS1HVUVTVFM9MDptYWlsdG86ZHRoYWxl ckBtaWNyb3NvZnQuY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPVBldGVyIExvc2Nv Y2NvO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpwYWxvc2NvQHR5Y2hvLm5zYS5nb3YNCkFUVEVOREVF O0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFD VElPTjtSU1ZQPQ0KIFRSVUU7Q049IlpodSwgQmluZyI7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmJp bmcuemh1QGludGVsLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFS VElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj0iSGVsYmxlLCBT YXJhaCBDLiI7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOnNhcmFoLmhlbGJsZUBqaHVhcGwuZWR1DQpB VFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1B Q0NFUFRFRDtSU1ZQPVRSVUUNCiA7Q049bWNoYXJsZXNyQGdtYWlsLmNvbTtYLU5VTS1HVUVTVFM9 MDptYWlsdG86bWNoYXJsZXNyQGdtYWlsLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtD Tj1lbGVhckBjaXNjby5jb207WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmVsZWFyQGNpc2NvLmNvbQ0K QVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9 TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1tZGJAanVuaXBlci5uZXQ7WC1OVU0tR1VFU1RT PTA6bWFpbHRvOm1kYkBqdW5pcGVyLm5ldA0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9M RT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1y YXRzQGlldGYub3JnO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpyYXRzQGlldGYub3JnDQpBVFRFTkRF RTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1B Q1RJT047UlNWUD0NCiBUUlVFO0NOPWpvZG9ub2doQHF0aS5xdWFsY29tbS5jb207WC1OVU0tR1VF U1RTPTA6bWFpbHRvOmpvZG9ub2doQHF0aS5xdWFsY28NCiBtbS5jb20NCkFUVEVOREVFO0NVVFlQ RT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPQ0KIFRSVUU7Q049VGhvbWFzIEhhcmRqb25vO1gtTlVNLUdVRVNUUz0wOm1haWx0bzppZXRm LXJhdHNAaGFyZGpvbm8ubmV0DQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1Q QVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPUpvZSBNYWxj b2xtIChqb21hbGNvbCk7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmpvbWFsY29sQGNpc2NvLmNvbQ0K QVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9 TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1QZXRlIExvc2NvY2NvO1gtTlVNLUdVRVNUUz0w Om1haWx0bzpwZXRlLmxvc2NvY2NvQGdtYWlsLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURV QUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJV RTtDTj1UaG9tYXMgRm9zc2F0aTtYLU5VTS1HVUVTVFM9MDptYWlsdG86dGhvbWFzLmZvc3NhdGlA YXJtLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7 UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj0iR3Vpbm4sIEFuZHJldyBMLiI7 WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmFuZHJldy5ndWlubkBqaHVhcGwuZWR1DQpBVFRFTkRFRTtD VVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD0NCiBUUlVFO0NOPXNod2V0aGFiQGNpc2NvLmNvbTtYLU5VTS1HVUVTVFM9MDptYWls dG86c2h3ZXRoYWJAY2lzY28uY29tDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6LTk0MDg0 NDc4MQ0KQ1JFQVRFRDoyMDIwMDgxMFQxOTE1MzFaDQpERVNDUklQVElPTjo8ZGQ+TWVldGluZyBs aW5rOjxicj48L2RkPjxkZD48ZGw+PGRkPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWINCiBleC5j b20vaWV0Zi9qLnBocD9NVElEPW00YzNkNzM5NWExNWRhZDFlZDhjMGY5NTQ1Mjc5NGMyNSIgdGFy Z2V0PSJfYmxhbmsiPmgNCiB0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00 YzNkNzM5NWExNWRhZDFlZDhjMGY5NTQ1Mjc5NGMyNTwvYT4NCiA8L2RkPjxkdD5NZWV0aW5nIG51 bWJlcjo8L2R0PjxkZD42MTAgMzY2IDc1MDwvZGQ+PGR0PlBhc3N3b3JkOjwvZHQ+PGRkPjR2WTIN CiBhUzZYOERGPC9kZD48ZHQ+SG9zdCBrZXk6PC9kdD48ZGQ+ODIwODIyPC9kZD48L2RsPjxicj48 YnI+PGg1Pk1vcmUgd2F5cyB0byANCiBqb2luPC9oNT48L2RkPlxuXG4tOjp+On46On46fjp+On46 fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On4NCiA6fjp+On46fjp+On46 fjp+On46fjp+Ojp+On46Oi1cblBsZWFzZSBkbyBub3QgZWRpdCB0aGlzIHNlY3Rpb24gb2YgdGhl IGRlc2MNCiByaXB0aW9uLlxuXG5UaGlzIGV2ZW50IGhhcyBhIHZpZGVvIGNhbGwuXG5Kb2luOiBo dHRwczovL21lZXQuZ29vZ2xlLmNvbS9pa2kNCiAtdHBhYy1oZGhcblxuVmlldyB5b3VyIGV2ZW50 IGF0IGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvZXZlbnQ/YWN0aW8NCiBuPVZJRVcm ZWlkPU5tSmxkR0UyTmpGaGRUSTJiR2gwYzNOa2RITTJiR2RxYkdnZ2NtRjBjMEJwWlhSbUxtOXla dyZ0b2s9TVRramINCiBXTm9ZWEpzWlhOeVFHZHRZV2xzTG1OdmJXUTJZemc0TWpNd01EZGhZekZt Tm1NeU5XUXpPR013WlRVME56WmxObUpqTVRZMk1tTTQNCiBaVEEmY3R6PUFtZXJpY2ElMkZUb3Jv bnRvJmhsPWVuJmVzPTEuXG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+On46fjoNCiB+ On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+Ojp+On46Oi0NCkxBU1Qt TU9ESUZJRUQ6MjAyMDA4MTBUMTkxNTMxWg0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTRjM2Q3Mzk1YTE1ZGFkMWVkOGMwZjk1NDUyDQogNzk0YzI1DQpT RVFVRU5DRTowDQpTVEFUVVM6Q09ORklSTUVEDQpTVU1NQVJZOlJBVFMgQXJjaGl0ZWN0dXJlIERl c2lnbiBUZWFtIHdlZWtseSBtZWV0aW5nIHRpbWUNClRSQU5TUDpPUEFRVUUNCkVORDpWRVZFTlQN CkVORDpWQ0FMRU5EQVINCg== --00000000000050df3e05ac8ac765-- From nobody Mon Aug 17 03:39:08 2020 Return-Path: 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 B6B9B3A0A9D for ; Mon, 17 Aug 2020 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uCkXnMv7rfaV for ; Mon, 17 Aug 2020 03:39:03 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35773A0AA8 for ; Mon, 17 Aug 2020 03:39:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FMCQDuXDpf/xwBYJlfHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFMgxiBMwqELZEjnAkLCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgk0?= =?us-ascii?q?BJDgTAhABAQYBAQEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARY?= =?us-ascii?q?CQ1USAR8BAQEDAQEhDwEFNhsJAhACBgICJgICJyACDgYBDAYCAQGDIgGCewU?= =?us-ascii?q?LkzSbeoEyhVKDS4E6BoEOKgGGUIZMD4FNP4ERJw+CWj6CXAEBhHaCYASSf5I?= =?us-ascii?q?+kEgqB4FbgQqBCQQLmHwFCh6DAIlcBYR/Bo47kjmfPwIEAgkCFYFqgXtNJE+?= =?us-ascii?q?CaVAXAg2XJIVEcjcCBgEJAQEDCXyNbi2BBgGBEAEB?= X-IPAS-Result: =?us-ascii?q?A2FMCQDuXDpf/xwBYJlfHQEBPAEFBQECAQkBFYFMgxiBM?= =?us-ascii?q?wqELZEjnAkLCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgk0BJDgTAhABAQYBA?= =?us-ascii?q?QEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQEDA?= =?us-ascii?q?QEhDwEFNhsJAhACBgICJgICJyACDgYBDAYCAQGDIgGCewULkzSbeoEyhVKDS?= =?us-ascii?q?4E6BoEOKgGGUIZMD4FNP4ERJw+CWj6CXAEBhHaCYASSf5I+kEgqB4FbgQqBC?= =?us-ascii?q?QQLmHwFCh6DAIlcBYR/Bo47kjmfPwIEAgkCFYFqgXtNJE+CaVAXAg2XJIVEc?= =?us-ascii?q?jcCBgEJAQEDCXyNbi2BBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="19689332" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:38:58 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKBgBzXTpf/1lIDI1fgQmDdHADVDA?= =?us-ascii?q?sCoQtkSOcFAsBAwEBAQEBBgEBGAsKAgQBAYRMAoJLAiQ4EwIQAQEFAQEBAgE?= =?us-ascii?q?GBG2FXAyFcgEBBAEBIQ8BBTYbCQIQAgYCAiYCAicgAg4GAQwGAgEBgyIBgwA?= =?us-ascii?q?LkyGbeoEyhVKDQIE6BoEOKoZRhkwPgU0/gREnD4JaPoJcAQGEdoJgBJJ/kj6?= =?us-ascii?q?QSCoHgVuBCoEJBAuYfAUKHoMAiVwFhH8GjjuSOZ8/AgQCCQIVgWojgVdNJE+?= =?us-ascii?q?CaVAXAg2XJIVEQTE3AgYBCQEBAwl8jW4tgQYBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="32887733" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:38:55 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07HAcsDc006961 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 17 Aug 2020 12:38:55 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 17 Aug 2020 12:38:49 +0200 To: Russ Housley , "rats@ietf.org" References: <27435.1575305487@localhost> <19794.1575378270@localhost> <6a18b426-b11f-82e5-8758-93f79360b2a4@sit.fraunhofer.de> <40A05013-D12A-4D16-9FE9-2E97D5D8EF90@intel.com> <27974.1575407275@localhost> From: Henk Birkholz Message-ID: Date: Mon, 17 Aug 2020 12:38:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] Review of draft-birkholz-rats-uccs-01 X-BeenThere: rats@ietf.org 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, 17 Aug 2020 10:39:07 -0000 Thank Russ! we will discuss all feedback as soon as we find a time for an author's meeting. Sorry for for the latency, I was out-of-office for a while. Viele Grüße, Henk On 30.07.20 22:45, Russ Housley wrote: > # Major Concerns > > In Section 3.1, the re are two MUST requirements, but they are not presented clearly. The are: > > 1) The secure channel MUST authenticate the Verifier to the Attester. > > 2) The secure channel MUST protect the integrity of the communications from the Verifier to the Attester. > > The way it is written also requires integrity protection in both directions. Is that really needed? > > In Section 3.1, says: > > Further, the provider of the UCCS SHOULD be > authenticated by the reciever to ensure the channel is truly secured > and the sender is validated. > > I do not understand what this is trying to say beyond the MUST requirement above. Maybe part of the problem is the mixing of the discussion about authentication and integrity. > > In Section 3, when talking about confidentiality, I think that it would be better to say: > > If confidentiality is also required, the secure channel SHOULD mutually authenticate Verifier and the Attester. > > > # Minor concerns > > In section 1, the phrase "Secure Channel provides the correct properties" is a bit troublesome. The properties are not difficult to explain in a sentence or two, so they should just be stated here. Also, the sentences that follow can be omitted if you simply include in the summary of the "correct properties" that the party sending the UCCS is authenticated. > > In Section 1.1, please add Verifier and Attester the the terms that are defined. > > > # Nits > > General: Why are Claim and Secure Chanel capitalized? > > In section 1.1, please add a reference for the CWT Claims Registry. > > In section 2, please add a reference for a device's trusted execution environment (probably the TEEP architecture draft). > > > Russ > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > From nobody Mon Aug 17 03:49:04 2020 Return-Path: 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 7407E3A0ABB; Mon, 17 Aug 2020 03:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 b-s0MDuaXz6F; Mon, 17 Aug 2020 03:49:00 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6713A0AA8; Mon, 17 Aug 2020 03:48:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EeAwBkpYde/xoHYZldCRsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgXuCKWwDVS8qCoQRkF0tmz0KCgEBAQEBAQEBAQYBARg?= =?us-ascii?q?LCgIEAQGERAKCRyQ4EwIQAQEGAQEBAQEFBAICaYVWDIZGAQEBAwEBIQ8BBTY?= =?us-ascii?q?LBQsJAhgCAiYCAicgEAYBDAEFAgEBgyIBgnsFC5M/m3mBMoVLg2eBOAaBDiq?= =?us-ascii?q?MMQ+BTD+BEScPglo+gmcBAYE5FIMqgl4EjWGDHpA1j14HgUl3fASLf4ogI4J?= =?us-ascii?q?MiDiEMQWMRo8ynB0CBAIJAhWBaSOBV00kT4JpUBgNjikXiGSFQ3KBKY0ZAYE?= =?us-ascii?q?PAQE?= X-IPAS-Result: =?us-ascii?q?A2EeAwBkpYde/xoHYZldCRsBAQEBAQEBBQEBAREBAQMDA?= =?us-ascii?q?QEBgXuCKWwDVS8qCoQRkF0tmz0KCgEBAQEBAQEBAQYBARgLCgIEAQGERAKCR?= =?us-ascii?q?yQ4EwIQAQEGAQEBAQEFBAICaYVWDIZGAQEBAwEBIQ8BBTYLBQsJAhgCAiYCA?= =?us-ascii?q?icgEAYBDAEFAgEBgyIBgnsFC5M/m3mBMoVLg2eBOAaBDiqMMQ+BTD+BEScPg?= =?us-ascii?q?lo+gmcBAYE5FIMqgl4EjWGDHpA1j14HgUl3fASLf4ogI4JMiDiEMQWMRo8yn?= =?us-ascii?q?B0CBAIJAhWBaSOBV00kT4JpUBgNjikXiGSFQ3KBKY0ZAYEPAQE?= X-URL-LookUp-ScanningError: 1 X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="33649345" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:48:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAwAEYDpf/1lIDI1WCRwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgipwA1QwLAqELZEknBQLAQMBAQEBAQYBARgLCgIEAQG?= =?us-ascii?q?ETAKCSwIkOBMCEAEBBQEBAQIBBgRthVwMhXIBAQEDAQEhDwEFNgsFCwkCGAI?= =?us-ascii?q?CJgICJyAQBgEMAQUCAQGDIgGDAAuTFpt6gTKFUoNKgToGgQ4qhlGGTA+BTT+?= =?us-ascii?q?BEScPglo+glwBAYEzFIMvgmAEjz2DQpI+kEgqB4FbgQqBCQQLjUeLNQUKHoM?= =?us-ascii?q?AiVyFBAaOO5I5nz8CBAIJAhWBaiOBV00kT4JpUBcCDY4rF4hihURBMTcCBgE?= =?us-ascii?q?JAQEDCXyPGwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="119747710" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:48:54 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07HAmrDr007176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 17 Aug 2020 12:48:53 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 17 Aug 2020 12:48:48 +0200 To: Jessica Fitzgerald-McKay , CC: Jessica Fitzgerald-McKay , Jim Schaad , "draft-birkholz-rats-uccs@ietf.org" References: From: Henk Birkholz Message-ID: <7e0d32a9-46d2-c9db-ac54-c241d5209b22@sit.fraunhofer.de> Date: Mon, 17 Aug 2020 12:48:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] comments on draft-birkholz-rats-uccs X-BeenThere: rats@ietf.org 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, 17 Aug 2020 10:49:04 -0000 Thanks Jess! the discussion on where this is incubated was deliberately scoped down to provide: * a finite and still useful set of Security/Privacy considerations, and * relatively specific guidance and context on how prerequisites for usage look like. The concept of an UCCS tag goes beyond RATS, of course. The usage of an UCCS tag alas requires some application-specific "rules". That said, we will discuss this topic specifically asap. Also, Jim is now in CC (Hi Jim) and maybe he can weigh in on this topic? With respect to your technical comments, please give us some time to come back with well-formed answers. I do not want to barge ahead with half-baked replies :-) Viele Grüße, Henk On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote: > Hi, UCCS authors, > > Mike Jenkins and I reviewed the UCCS draft. Our comments are below. > Happy to talk through any of them with the group. > > Thanks, > Jess > > The intent of this draft is similar to the key concept of EST - use the > authentication of the secure session connection. Most schemes build on > this concept leave a lot of banana peels laying around, some of which we > describe here. In general, this does not seem appropriate to the scope > of RATS. We feel that COSE might be a more appropriate work group to > think these issues through. > > - If you're using a static symmetric key for authentication (as one > might with highly-constrained devices), you can only authenticate a net, > not an entity. The receiver cannot differentiate between authenticating > the sender and authenticating itself. > > - The authentication happens at the secure channel termination, not in > the channel-contents-using application. It's important how the > termination process vouches the authentication to the application. (In > EST, this question is how the EST server vouches the requestor's > identity to the CA server.) > > - A TEE only helps if the TEE application can punch through the REE and > set up the secure channel completely on its own. If the TEE relies on > the REE to set up the secure channel, you might as well just operate in > the REE. > > - There is a comment at the end of the introduction (!) about > transitioning back and forth between self-protected and > channel-protected CWT, "in a well-defined scope". Define the security > characteristics of that scope or get rid of the comment. You're handing > someone an awful lot of rope there. > > - The claims set should be treated as ephemeral by the recipient. It > shouldn't be stored, and can't be forwarded except as data originated by > the recipient. As soon as it emerges from the secure channel, it's no > more valid or meaningful than any other piece of unprotected data in the > application environment. > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > From nobody Mon Aug 17 09:40:16 2020 Return-Path: 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 2B90F3A11FE; Mon, 17 Aug 2020 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=coy4ydQ+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=NKODb7Vr 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 QXpYfkUL-_Bo; Mon, 17 Aug 2020 09:40:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2513A0D47; Mon, 17 Aug 2020 09:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14623; q=dns/txt; s=iport; t=1597682409; x=1598892009; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gd34RXOnY4gVoqZADbEHsFNwAAHjslJ/p4yKYqKDmyk=; b=coy4ydQ+LxbvCwLXKRyaGX6UWBFJdSUQXYh3zfD86T2Q+hJ00OZZvUjO 20Hzb8UrQWexLt4zqUDPQ2MT4BuCUJnSa9gyx+5DtinVvTrp8vYMisj0L Ucua+bEZaCCdAGcumpQWZOHBgAVGaR4uglw4mEufCQ3WpF31SIBo9FUSq E=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3A57TKSBCBjTNk0GDaZ8qxUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw30A3FWIzB4LRFhvbY9af6Vj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7ep3So5ngTFw?= =?us-ascii?q?nxcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQD/sTpf/4wNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBeQQBAQsBgSIvUQdwKy0vLAqELYNGA41bh16MHoRtglMDVQQ?= =?us-ascii?q?HAQEBCQMBAS0CBAEBhEwCgk0CJDcGDgIDAQELAQEFAQEBAgEGBG2FXAyFcQE?= =?us-ascii?q?BAQQSEQoTAQE3AQ8CAQgRBAEBKwICAjAdCAIEAQ0FCAYUgwWBfk0DHw8BpRk?= =?us-ascii?q?CgTmIYXaBMoMBAQEFhTYYggcHCYE4AYFSgR6GHoQOG4FBP4ERQ4JNPoJcBIF?= =?us-ascii?q?fgxUzgi2bI5sQCoJihDiCXJMtoCGNcoRHnz8CBAIEBQIOAQEFgWkkgVdwFYM?= =?us-ascii?q?kUBcCDY4fDBeDTopWdAI1AgYBCQEBAwl8jyABgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,324,1592870400"; d="p7s'?scan'208,217";a="546109798" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Aug 2020 16:40:08 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07HGe8Hl032289 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2020 16:40:08 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 11:40:08 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 12:40:07 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 17 Aug 2020 11:40:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a27ttPIP6gWiG2Yym31kILwalh8xcUWDCOupXTqgbx3Hda1qn8+3x1MWeLLoTyrL9clqiFMnFIbUCMhQ7UdGzSQuYyzMELPSpQr/GhyFV/dg1no0ySoviQvMa3AA640SQSCsrP2vVbs1dx8XA5rATTDU0UN/Qlfrsan9jkUjhzrCuEBP7dG9sBGEYR6w79whXcbKoQHHeNIHgWYCwa2ofGYosdWX3O9LyQn/GCgHzgpb7P04LiIgTFQDEJ0PjgAlziNscdz91gj4SWRmZeDxbmeQDzJED8uEEywM35hcGw7V9WHoMsUOTci6en2rMUObGRr3Z9SwA3eaURYsQrjpRg== 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=1FtfS+VZmBFG9cAS1OzZUeLEYD0wD1VG9RvaikICBZc=; b=Tgt5Lv9flZlPdbL7g5aI/mjZrd4zOa5djeZwESmoPZ6HO8Rl83ItTXjcKyA3QcdRRKgfpz4Jzvm4XRlW6fFJialR+Akh/d3KY6E0uS12d95zx5bZ0iNd1UT2OHpBJiKLp3XNMWdaW3FBfxfcpKxYYWRnY/0dPz3+T2zn0jajixljkwPoT+1NMeg760XvP4587CgatdMLVgkmb51GZTeYkK9gYOHjAbLrr/dDKKreSGFPBIrppri8799TK0AX0sShqmILI3sUVxsXuMGqXRKesQ/GNgftYqVGVrPta1W8fSM5UXRAHNWLBzQ0n6NIga1ziUWJryl6KfzcxiiVGb++oA== 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=1FtfS+VZmBFG9cAS1OzZUeLEYD0wD1VG9RvaikICBZc=; b=NKODb7VrlT0UZQdMitGkJwGQy/BLDSJg4H4nqeTfpB6K6CsafK+fBUBy7f2IxBp+BZced3gFqtzFd5BAqyHWdQ2/DmMSfvg1r+X2rpWQ9RUGnG1FlgZqv5OsD0erhrNoEn3jrIiIZRVdvtSDaZuJP26sjzlbj+4Z6g9wWRs08YY= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4599.namprd11.prod.outlook.com (2603:10b6:208:26d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Mon, 17 Aug 2020 16:40:06 +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.027; Mon, 17 Aug 2020 16:40:06 +0000 From: "Eric Voit (evoit)" To: "Salz, Rich" , Laurence Lundblade , "Eric Voit (evoit)" , "Panwei (William)" CC: "rats@ietf.org" , "Shwetha Bhandari (shwethab)" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module) Thread-Index: AQHWdLUPHfaViP6ulUuzKuAfkv64+Q== Date: Mon, 17 Aug 2020 16:40:05 +0000 Message-ID: References: <2251DEFB-F6A2-4AC9-82D4-B67D22175821@akamai.com> In-Reply-To: <2251DEFB-F6A2-4AC9-82D4-B67D22175821@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: 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: [173.38.117.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a905e271-5243-4f50-7cab-08d842cc327a x-ms-traffictypediagnostic: MN2PR11MB4599: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qhaxA+SPyGWMu0jC75PYWNwD6hC1IgdYJcNxv/crZsauCoEMTtnRKTID8uD452V+B5AVdOanflt6KDHgtF2+POWX421YmrAM2h5F8rGvhlj61AilXHixc/WKkSj26EdS3VgucAceyeEfuz8YwZN55WbLBRXYtI7dCAewJEWK74B3xUbvx7+8aJ9dtRyGAtCjrxyzg1f92qsMkkB4TVFSLeUbP3jAlQ2yWeM0HfNKM/JZmJAIcTF5GU0c6t2pyZi/K3P0oCR6poVKSfWLkhKPY8boqlk4ItG6oN+75O7R6VQ14dbSl+UmcY/Gmb2LZR9hqDmZNAgdOMyvjwacAmUeDw== 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)(136003)(366004)(396003)(346002)(376002)(39860400002)(4326008)(7696005)(8936002)(53546011)(26005)(6506007)(9686003)(64756008)(71200400001)(4744005)(2906002)(66446008)(110136005)(55016002)(54906003)(478600001)(76116006)(66616009)(66556008)(66476007)(66946007)(83380400001)(316002)(52536014)(86362001)(8676002)(99936003)(33656002)(186003)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: OpGCyeps0UxoLFu3YrCr8+D3WpLx8Jj0L54PFhgua+TUoz4y5mw1nvvR16k9VXR7kFtqJCWcy4mj+1g7k/aBuMHE2/vBcb2QIfvRfKlkUvFozhxVGeuLbTXqQg4HbbRT3XVUY4Q4KAwO3NwOVYHeFWAvGkwOd/TYUkxtAiHpu1CKjbkPSfhbB9/Ri2lbk93yuJiIbtXoRh7kYQ4jjQJ7Nfxl18keOShpWPdSyQggkNSaPB4PWw56nE64cHbOkknILIYGk6FElH25tTQbzBjxG9Hbzuitjd2uvAbWmiqH7yYCT6hF7e23lmzts8xVJvYTMPo85JpfmpDtBY7r325nO4uUTsdf1A3z1YoIk8X9Ngs04Ks1oOszg17PwTZUtjken2wxS+F9q2dfMiwnntwn9jqlpySTBwj7fmVq85FyGqTOjcNmYKz2lhfe737UBKhQbdohEPtxX7Um8UtakOnzl49WChE+TCSnO+pvNqiy0JtZ1vVa6bwEJQ/qdmnjRE3dgdjq12OBy0KdrHyo7h4S9zZObu3uqX2JlRislkRFrdnA3rup5dXAPDKcE1Hr4v+mB4x7goJ2cPB25t4se/Z0bclvcJTX7yEOOglAYLpV/AZtX4PtylGLHUIisCwGu4YKBZpb0/VNMH0mrbATkGSIZw== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009B_01D67493.8712F770" 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: a905e271-5243-4f50-7cab-08d842cc327a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 16:40:05.8838 (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: MkJBtQ8mWYU95bpHcgHrKh5WhfWM2mE5OmRNrgqeLrl/rfAA0SjuYfsz3LEUxren X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4599 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 16:40:12 -0000 ------=_NextPart_000_009B_01D67493.8712F770 Content-Type: multipart/alternative; boundary="----=_NextPart_001_009C_01D67493.8712F770" ------=_NextPart_001_009C_01D67493.8712F770 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I am happy to get rid of it. I am just making sure that there are no objections from the requesting source(s). Eric From: RATS On Behalf Of Salz, Rich Sent: Friday, August 14, 2020 5:01 PM To: Laurence Lundblade ; Eric Voit (evoit) Cc: rats@ietf.org; Panwei (William) ; Shwetha Bhandari (shwethab) ; draft-ietf-rats-yang-tpm-charra@ietf.org Subject: Re: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module) * I would suggest avoiding UUIDs if possible. Nowadays good RNGs are available and you can just use them to generate a nonce or such. Good RNGs were not available commonly in CPUs when UUIDs were invented, but they are now. If you just want a nonce, then the internal structure of a UUID is of no value and just adds complexity and confusion. As the lead author of the UUID RFC: I agree. ------=_NextPart_001_009C_01D67493.8712F770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am happy = to get rid of it.=C2=A0=C2=A0=C2=A0 I am just making sure that there are = no objections from the requesting source(s).


Eric

 

From: RATS = <rats-bounces@ietf.org> On Behalf Of Salz, = Rich
Sent: Friday, August 14, 2020 5:01 PM
To: = Laurence Lundblade <lgl@island-resort.com>; Eric Voit (evoit) = <evoit=3D40cisco.com@dmarc.ietf.org>
Cc: rats@ietf.org; = Panwei (William) <william.panwei@huawei.com>; Shwetha Bhandari = (shwethab) <shwethab@cisco.com>; = draft-ietf-rats-yang-tpm-charra@ietf.org
Subject: Re: [Rats] = Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG = module)

 

  • I would suggest = avoiding UUIDs if possible. Nowadays good RNGs are available and you can = just use them to generate a nonce or such. Good RNGs were not available = commonly in CPUs when UUIDs were invented, but they are now.  If = you just want a nonce, then the internal structure of a UUID is of no = value and just adds complexity and confusion. =

 

As the lead author of the UUID RFC: I = agree.

 

------=_NextPart_001_009C_01D67493.8712F770-- ------=_NextPart_000_009B_01D67493.8712F770 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE3MTY0MDAyWjAjBgkqhkiG 9w0BCQQxFgQUkZZTloXypFP6YAATHPVEowEKMUAwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBsX53Xzhwl0AZQwJlAXwQVxFqhRSYNKqNj63FdFP56pxRhWHNO6vURajGWwf8Y7os1 m2nfHgP/xFSFlhw9i/010tY6esbPpffHkrHbVCy99PcQVA+hnfXQvIqUs9gKxA2d3k85xGcEJz8I mUdUItF086jNDsPaLbmR4mM8scup9mqySChUtzgoaNJ+N4zboGpahwKW8BgvoD22AlT3NM59Lv3p nZTf57dsVa+bK6YyxVOgc7AcejnNheTQONZqx+Y3o5mVUmRz4rTnloxo5QcZSrUcLAcm3o7Rg2Fq dBLfO1c+xioE1sd5IuivXYqmwE1+R3ZAsH9L3MF5KDBOc7eVAAAAAAAA ------=_NextPart_000_009B_01D67493.8712F770-- From nobody Mon Aug 17 13:14:03 2020 Return-Path: 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 788EF3A1055; Mon, 17 Aug 2020 13:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 m-EF7wI7GrzH; Mon, 17 Aug 2020 13:13:58 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BFC3A0EDD; Mon, 17 Aug 2020 13:13:58 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 13:13:52 -0700 From: Jim Schaad To: 'Henk Birkholz' , 'Jessica Fitzgerald-McKay' , CC: 'Jessica Fitzgerald-McKay' , References: <7e0d32a9-46d2-c9db-ac54-c241d5209b22@sit.fraunhofer.de> In-Reply-To: <7e0d32a9-46d2-c9db-ac54-c241d5209b22@sit.fraunhofer.de> Date: Mon, 17 Aug 2020 13:13:50 -0700 Message-ID: <016a01d674d2$edf35630$c9da0290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKSrUcr9Gm0Xi9nn2sIf7/6XuQYBAG8bGQep7ZPCIA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Rats] comments on draft-birkholz-rats-uccs X-BeenThere: rats@ietf.org 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, 17 Aug 2020 20:14:01 -0000 -----Original Message----- From: Henk Birkholz =20 Sent: Monday, August 17, 2020 3:49 AM To: Jessica Fitzgerald-McKay ; rats@ietf.org Cc: Jessica Fitzgerald-McKay ; Jim Schaad = ; draft-birkholz-rats-uccs@ietf.org Subject: Re: [Rats] comments on draft-birkholz-rats-uccs Thanks Jess! the discussion on where this is incubated was deliberately scoped down = to provide: * a finite and still useful set of Security/Privacy considerations, and * relatively specific guidance and context on how prerequisites for = usage look like. The concept of an UCCS tag goes beyond RATS, of course. The usage of an = UCCS tag alas requires some application-specific "rules". That said, we will discuss this topic specifically asap. Also, Jim is = now in CC (Hi Jim) and maybe he can weigh in on this topic? With respect to your technical comments, please give us some time to = come back with well-formed answers. I do not want to barge ahead with = half-baked replies :-) Viele Gr=C3=BC=C3=9Fe, Henk On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote: > Hi, UCCS authors, >=20 > Mike Jenkins and I reviewed the UCCS draft. Our comments are below.=20 > Happy to talk through any of them with the group. >=20 > Thanks, > Jess >=20 > The intent of this draft is similar to the key concept of EST - use=20 > the authentication of the secure session connection. Most schemes=20 > build on this concept leave a lot of banana peels laying around, some=20 > of which we describe here. In general, this does not seem appropriate=20 > to the scope of RATS. We feel that COSE might be a more appropriate=20 > work group to think these issues through. [JLS] To me COSE is exactly the wrong place to do this. If it is not = done in RATS then ACE would be the appropriate location. Doing it in = COSE would be something along the lines of "If you don't use the core = technology of this group then you should?" >=20 > - If you're using a static symmetric key for authentication (as one=20 > might with highly-constrained devices), you can only authenticate a=20 > net, not an entity. The receiver cannot differentiate between=20 > authenticating the sender and authenticating itself. [JLS] I don't see this as being interesting for this document The exact = same set of problems exist if you use HMAC or symmetric encryption with = COSE where a static symmetric key is used. The thing that might be = interesting would be to talk about correspondences of the secure channel = security and the equivalent COSE objects. =20 >=20 > - The authentication happens at the secure channel termination, not in = > the channel-contents-using application. It's important how the=20 > termination process vouches the authentication to the application. (In = > EST, this question is how the EST server vouches the requestor's=20 > identity to the CA server.) >=20 > - A TEE only helps if the TEE application can punch through the REE=20 > and set up the secure channel completely on its own. If the TEE relies = > on the REE to set up the secure channel, you might as well just=20 > operate in the REE. >=20 > - There is a comment at the end of the introduction (!) about=20 > transitioning back and forth between self-protected and=20 > channel-protected CWT, "in a well-defined scope". Define the security=20 > characteristics of that scope or get rid of the comment. You're=20 > handing someone an awful lot of rope there. >=20 > - The claims set should be treated as ephemeral by the recipient. It=20 > shouldn't be stored, and can't be forwarded except as data originated=20 > by the recipient. As soon as it emerges from the secure channel, it's=20 > no more valid or meaningful than any other piece of unprotected data=20 > in the application environment. >=20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats >=20 From nobody Mon Aug 17 15:22:55 2020 Return-Path: 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 05FA03A12BB; Mon, 17 Aug 2020 15:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a3FgOo8gClDy; Mon, 17 Aug 2020 15:22:52 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8DF3A12AF; Mon, 17 Aug 2020 15:22:51 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id k1so3882728vkb.7; Mon, 17 Aug 2020 15:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8gscst13IKBJENQzm+eZYRsdBRWct5Y+Or7d23CP8aw=; b=l7jJ+094O/zzLkoLJ3JDJzGTBwtJCLgdD97D3ou1bcS+iA8pxLQ4Whi9bVDb5zKAEw BEoxdAB5Vf98Sjy3JMP+VY38S4fHpW8bJYfTPk7KuWBAe/Caqrn4KV0pVVtEUGFEtBa5 3YkXMqP50zfkB70caynvpp1Q2omEb1+lr78MBEebtvazvTLC0QpJCrsl6fEw+0F24yY4 GmAS3apidE+CeLX/3m4Y70d6x1/RJx8vy6o9d5Wgfc/KPc2T6eFRyOZQQX8b4pETYfte 9PHECOvWHe7zKQqvpoRjBjaQ9anXh6taDesE7/ApK5RsvZAeJxr4UcnhI0YOaVW7HVZc rfFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8gscst13IKBJENQzm+eZYRsdBRWct5Y+Or7d23CP8aw=; b=HFvDVUwfKzeLuVMR/JtjzjiauoF8wYybc1i9KK85V62CBk81+5btxSzqJtsM7LRZzR q0Ui6gK80Fr6aEaWcFPGhsLtHPSBj59sa9ht4t4dMTkFJwLwCtdb7fHf/Z1RzfO3c2IG EL+ot+e5fWcpAkVFfzPWzW3mqQ6pffSLn2Y1+xsKvaCVyTU0f9gtaKoCmxtVjoS7d378 h75UompMnPpRQ77kbPbfNqzxDzlLiV2HTsh9oH3fYZBrICNkN6ebwUIctSL9FqYMhM5x t8cD/CZZPDIw8FYVWEsN/2yqRbiBD2h5HXiYKiK7JmgpS5zoXM7c4JHoRFhJvjX4mlZe qXYg== X-Gm-Message-State: AOAM533npmxBsXSoViFsD28UWn8b4bakx+bTjIR9YWHNasavS4mKd86N sFONCb6kohmMth2VwciwThV6+dGcYmZA79iekho= X-Google-Smtp-Source: ABdhPJzIIzCiNFsesYCgb2fz2KO85YM4OeJuNDY6lz6MscTA/bZmf1Flvi7gAuFr7aqbXO4rb9Vm0sdLq2p2eNMfz3Y= X-Received: by 2002:a1f:9b8f:: with SMTP id d137mr9609194vke.97.1597702970849; Mon, 17 Aug 2020 15:22:50 -0700 (PDT) MIME-Version: 1.0 References: <7e0d32a9-46d2-c9db-ac54-c241d5209b22@sit.fraunhofer.de> <016a01d674d2$edf35630$c9da0290$@augustcellars.com> In-Reply-To: <016a01d674d2$edf35630$c9da0290$@augustcellars.com> From: Ira McDonald Date: Mon, 17 Aug 2020 18:22:37 -0400 Message-ID: To: Jim Schaad , Ira McDonald Cc: Henk Birkholz , Jessica Fitzgerald-McKay , rats@ietf.org, Jessica Fitzgerald-McKay , draft-birkholz-rats-uccs@ietf.org Content-Type: multipart/alternative; boundary="00000000000008c06205ad1a3656" Archived-At: Subject: Re: [Rats] comments on draft-birkholz-rats-uccs X-BeenThere: rats@ietf.org 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, 17 Aug 2020 22:22:54 -0000 --00000000000008c06205ad1a3656 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Of course Jim knows where work should be in IETF. I also concur that ACE, but *not* COSE, could be a reasonable alternate home for UCCS. Cheers. - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/hi= ghnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Mon, Aug 17, 2020 at 4:14 PM Jim Schaad wrote: > > > -----Original Message----- > From: Henk Birkholz > Sent: Monday, August 17, 2020 3:49 AM > To: Jessica Fitzgerald-McKay ; rats@ietf.org > Cc: Jessica Fitzgerald-McKay ; Jim Schaad < > ietf@augustcellars.com>; draft-birkholz-rats-uccs@ietf.org > Subject: Re: [Rats] comments on draft-birkholz-rats-uccs > > Thanks Jess! > > the discussion on where this is incubated was deliberately scoped down to > provide: > > * a finite and still useful set of Security/Privacy considerations, and > * relatively specific guidance and context on how prerequisites for usage > look like. > > The concept of an UCCS tag goes beyond RATS, of course. The usage of an > UCCS tag alas requires some application-specific "rules". > > That said, we will discuss this topic specifically asap. Also, Jim is now > in CC (Hi Jim) and maybe he can weigh in on this topic? > > With respect to your technical comments, please give us some time to come > back with well-formed answers. I do not want to barge ahead with half-bak= ed > replies :-) > > Viele Gr=C3=BC=C3=9Fe, > > Henk > > On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote: > > Hi, UCCS authors, > > > > Mike Jenkins and I reviewed the UCCS draft. Our comments are below. > > Happy to talk through any of them with the group. > > > > Thanks, > > Jess > > > > The intent of this draft is similar to the key concept of EST - use > > the authentication of the secure session connection. Most schemes > > build on this concept leave a lot of banana peels laying around, some > > of which we describe here. In general, this does not seem appropriate > > to the scope of RATS. We feel that COSE might be a more appropriate > > work group to think these issues through. > > > [JLS] To me COSE is exactly the wrong place to do this. If it is not don= e > in RATS then ACE would be the appropriate location. Doing it in COSE wou= ld > be something along the lines of "If you don't use the core technology of > this group then you should?" > > > > > - If you're using a static symmetric key for authentication (as one > > might with highly-constrained devices), you can only authenticate a > > net, not an entity. The receiver cannot differentiate between > > authenticating the sender and authenticating itself. > > [JLS] I don't see this as being interesting for this document The exact > same set of problems exist if you use HMAC or symmetric encryption with > COSE where a static symmetric key is used. The thing that might be > interesting would be to talk about correspondences of the secure channel > security and the equivalent COSE objects. > > > > > - The authentication happens at the secure channel termination, not in > > the channel-contents-using application. It's important how the > > termination process vouches the authentication to the application. (In > > EST, this question is how the EST server vouches the requestor's > > identity to the CA server.) > > > > - A TEE only helps if the TEE application can punch through the REE > > and set up the secure channel completely on its own. If the TEE relies > > on the REE to set up the secure channel, you might as well just > > operate in the REE. > > > > - There is a comment at the end of the introduction (!) about > > transitioning back and forth between self-protected and > > channel-protected CWT, "in a well-defined scope". Define the security > > characteristics of that scope or get rid of the comment. You're > > handing someone an awful lot of rope there. > > > > - The claims set should be treated as ephemeral by the recipient. It > > shouldn't be stored, and can't be forwarded except as data originated > > by the recipient. As soon as it emerges from the secure channel, it's > > no more valid or meaningful than any other piece of unprotected data > > in the application environment. > > > > _______________________________________________ > > RATS mailing list > > RATS@ietf.org > > https://www.ietf.org/mailman/listinfo/rats > > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --00000000000008c06205ad1a3656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Of course Jim knows wher= e work should be in IETF.

I also concur that ACE, = but *not* COSE, could be a reasonable
alternate home for UCCS.

Cheers.
- Ira

Ira McD= onald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility So= lutions WG
Co-Chair - TCG Metadata= Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printe= r Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High = North Inc
http://sites.google.com/site/blue= roofmusic
http://sites.google.com/site/h= ighnorthinc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221=C2=A0 Gr= and Marais, MI 49839=C2=A0 906-494-2434
<= /div>


On Mon, Aug 17, 2020 at 4:14 PM Jim Schaad <ietf@augustcellars.com> wrote:=


-----Original Message-----
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Sent: Monday, August 17, 2020 3:49 AM
To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>; rats@ietf.org
Cc: Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov>; Jim Schaad <ietf@augustcellars.com&= gt;; draft-birkholz-rats-uccs@ietf.org
Subject: Re: [Rats] comments on draft-birkholz-rats-uccs

Thanks Jess!

the discussion on where this is incubated was deliberately scoped down to p= rovide:

* a finite and still useful set of Security/Privacy considerations, and
* relatively specific guidance and context on how prerequisites for usage l= ook like.

The concept of an UCCS tag goes beyond RATS, of course. The usage of an UCC= S tag alas requires some application-specific "rules".

That said, we will discuss this topic specifically asap. Also, Jim is now i= n CC (Hi Jim) and maybe he can weigh in on this topic?

With respect to your technical comments, please give us some time to come b= ack with well-formed answers. I do not want to barge ahead with half-baked = replies :-)

Viele Gr=C3=BC=C3=9Fe,

Henk

On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote:
> Hi, UCCS authors,
>
> Mike Jenkins and I reviewed the UCCS draft. Our comments are below. > Happy to talk through any of them with the group.
>
> Thanks,
> Jess
>
> The intent of this draft is similar to the key concept of EST - use > the authentication of the secure session connection. Most schemes
> build on this concept leave a lot of banana peels laying around, some =
> of which we describe here. In general, this does not seem appropriate =
> to the scope of RATS. We feel that COSE might be a more appropriate > work group to think these issues through.


[JLS] To me COSE is exactly the wrong place to do this.=C2=A0 If it is not = done in RATS then ACE would be the appropriate location.=C2=A0 Doing it in = COSE would be something along the lines of "If you don't use the c= ore technology of this group then you should?"

>
> - If you're using a static symmetric key for authentication (as on= e
> might with highly-constrained devices), you can only authenticate a > net, not an entity. The receiver cannot differentiate between
> authenticating the sender and authenticating itself.

[JLS] I don't see this as being interesting for this document=C2=A0 The= exact same set of problems exist if you use HMAC or symmetric encryption w= ith COSE where a static symmetric key is used.=C2=A0 The thing that might b= e interesting would be to talk about correspondences of the secure channel = security and the equivalent COSE objects.

>
> - The authentication happens at the secure channel termination, not in=
> the channel-contents-using application. It's important how the > termination process vouches the authentication to the application. (In=
> EST, this question is how the EST server vouches the requestor's <= br> > identity to the CA server.)
>
> - A TEE only helps if the TEE application can punch through the REE > and set up the secure channel completely on its own. If the TEE relies=
> on the REE to set up the secure channel, you might as well just
> operate in the REE.
>
> - There is a comment at the end of the introduction (!) about
> transitioning back and forth between self-protected and
> channel-protected CWT, "in a well-defined scope". Define the= security
> characteristics of that scope or get rid of the comment. You're > handing someone an awful lot of rope there.
>
> - The claims set should be treated as ephemeral by the recipient. It <= br> > shouldn't be stored, and can't be forwarded except as data ori= ginated
> by the recipient. As soon as it emerges from the secure channel, it= 9;s
> no more valid or meaningful than any other piece of unprotected data <= br> > in the application environment.
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats
>

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--00000000000008c06205ad1a3656-- From nobody Tue Aug 18 01:35:35 2020 Return-Path: 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 DCA4D3A0770; Tue, 18 Aug 2020 01:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ABv8khxSYKq3; Tue, 18 Aug 2020 01:35:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBE33A076F; Tue, 18 Aug 2020 01:35:31 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3E2EB404BE8079E722DE; Tue, 18 Aug 2020 09:35:29 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 18 Aug 2020 09:35:28 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 18 Aug 2020 16:35:25 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 18 Aug 2020 16:35:25 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" , "Shwetha Bhandari (shwethab)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" Thread-Topic: Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module) Thread-Index: AdZycLCFh7nlxgpkQEGyeEIa+yDQWgCyQwhQ Date: Tue, 18 Aug 2020 08:35:25 +0000 Message-ID: <6d651f96f7d04f43a5cbb6d2ce8fbbc3@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.173.17] Content-Type: multipart/alternative; boundary="_000_6d651f96f7d04f43a5cbb6d2ce8fbbc3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 08:35:34 -0000 --_000_6d651f96f7d04f43a5cbb6d2ce8fbbc3huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for asking, but I'm afraid that the UUID structures weren't introduc= ed by us Huawei. And we don't use UUIDs, so we don't object to drop them fr= om the model. Regards & Thanks! Wei Pan From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Saturday, August 15, 2020 3:26 AM To: Panwei (William) ; Shwetha Bhandari (shwetha= b) Cc: rats@ietf.org; draft-ietf-rats-yang-tpm-charra@ietf.org Subject: Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG modul= e) Hi Wei Pan, Just slightly related to the question you asked previously, I have a questi= on on the model/tree you sent back (in-line...) > From: Panwei, August 14, 2020 6:01 AM > To: Eric Voit (evoit) >; Shwetha = Bhandari (shwethab) > > Hi Eric, > > Thanks for your reply, please see inline. > > Regards & Thanks! > Wei Pan > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Thursday, August 13, 2020 10:32 PM > To: Panwei (William) >; Shwetha Bhandari > (shwethab) > > Cc: rats@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-o= bjects > 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 wh= ich are mandatory where other UUID parts exist. Shwetha told me that the U= UID structures originally came from Huawei. A few questions: (1) UUID only appears in RPCs. It doesn't appear in the datanodes. Nor d= oes 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 reconc= iled 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 re= late to keys within the IETF ecosystem of YANG models. BTW: If you don't need UUIDs, we could always drop them from the model. (L= eaving them to vendor specific augmentations if necessary.) Thanks, Eric > | | +---w add-version? boolean > | | +---w tpm-name* string --_000_6d651f96f7d04f43a5cbb6d2ce8fbbc3huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Thanks for asking, but I’m afr= aid that the UUID structures weren’t introduced by us Huawei. And we = don’t use UUIDs, so we don’t object to drop them from the model= .

 

Regards & Thanks!

Wei Pan

 

 

From: = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Saturday, August 15, 2020 3:26 AM
To: Panwei (William) <william.panwei@huawei.com>; Shwetha Bhan= dari (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 YAN= G module)

 

Hi W= ei Pan,

 

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

 

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

> To: Eric Voit (evoit) &= lt;evoit@cisco.com>; Shwetha Bhan= dari (shwethab)

>

> Hi Eric,

>

> Thanks for your reply, = please see inline.

>

> Regards & Thanks!

> Wei Pan

>

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

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

> To: Panwei (William) &l= t;william.panwei@huawei.com>; Shwetha= Bhandari

> (shwethab) <shwethab@cisco.com>

> Cc: rats@ie= tf.org; draft-ietf-rats-yang-tpm-charra@ietf= .org

> Subject: RE: Some new c= omments for CHARRA YANG module

>

> Hi Wei Pan,<= /span>

>

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

>

>

> 2. The styles of challe= nge input for TPM1.2 and TPM2.0 are different.

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

>     = ;  |  +---w input

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

>     = ;  |  |     +---w nonce-value &= nbsp;        binary

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

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

>     = ;  |  |        |  &#= 43;---w TPM2_Algo        identityref

>     = ;  |  |        |  &#= 43;---w pcr-index*       tpm:pcr

>     = ;  |  |        +---w = TPM2_Algo?          identityre= f

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

>     = ;  |  |        |  &#= 43;--:(public-key)

>     = ;  |  |        |  |&= nbsp; +---w pub-key-id?   binary

>     = ;  |  |        |  &#= 43;--:(uuid)

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

>     = ;  |  |        +---w = tpm-name*           strin= g

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

> is a list. So you can c= hallenge 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* &n= bsp;            pcr<= o:p>

>     = ;  |  |     +---w nonce-value &= nbsp;           binary

>     = ;  |  |     +---w TPM12_Algo? &= nbsp;           identityr= ef

>     = ;  |  |     +---w (key-identifier)?<= o:p>

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

>     = ;  |  |     |  |  +---w pu= b-key-id?       binary

>=       |  |     |&nb= sp; +--:(TSS_UUID)

>=       |  |     |&nb= sp;    +---w TSS_UUID-value

>=       |  |     |&nb= sp;       +---w ulTimeLow? &nbs= p;     uint32

>=       |  |     |&nb= sp;       +---w usTimeMid? &nbs= p;     uint16

>=       |  |     |&nb= sp;       +---w usTimeHigh? &nb= sp;    uint16

>=       |  |     |&nb= sp;       +---w bClockSeqHigh? =   uint8

>=       |  |     |&nb= sp;       +---w bClockSeqLow? &= nbsp;  uint8

>=       |  |     |&nb= sp;       +---w rgbNode*  =        uint8

 

UUID is represented differen= tly in the TPM1.2 and TPM2 models.   In fact in the TPM1.2 modeli= ng 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. &= nbsp; Nor does UUID appear in draft-ietf-netconf-keystore.  As a resul= t 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?&nbs= p;  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.)

 

Than= ks,

Eric=

 

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

>     = ;  |  |     +---w tpm-name* &nb= sp;            = string

 

 

--_000_6d651f96f7d04f43a5cbb6d2ce8fbbc3huaweicom_-- From nobody Tue Aug 18 05:07:51 2020 Return-Path: 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 A4AD03A05A7; Tue, 18 Aug 2020 05:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5WV9h4s8MGxy; Tue, 18 Aug 2020 05:07:47 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8F3A091D; Tue, 18 Aug 2020 05:07:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FeAABGxDtf/xoBYJlVChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBSoRNCpVRnBQLAQEBAQEBAQEBBgEBLQI?= =?us-ascii?q?EAQGBNYMXAoIhASQ4EwIQAQEGAQEBAQEGBAIChlGGSgEBAQEDMgEFQRALEQQ?= =?us-ascii?q?BAQEnB0YJCAYBDAEFAgEBgyKCfAWvKHSBNIVSg1+BQIE4jR8PgU0/gREnD4I?= =?us-ascii?q?sLj6EEIYkBJAXiW+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1zhEifQAI?= =?us-ascii?q?EAgkCFYFqgXtNJE+CaVAXAg2OKxeOJnI3AgYBCQEBAwl8j0QBgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2FeAABGxDtf/xoBYJlVChoBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBSoRNCpVRnBQLAQEBAQEBAQEBBgEBLQIEAQGBNYMXAoIhA?= =?us-ascii?q?SQ4EwIQAQEGAQEBAQEGBAIChlGGSgEBAQEDMgEFQRALEQQBAQEnB0YJCAYBD?= =?us-ascii?q?AEFAgEBgyKCfAWvKHSBNIVSg1+BQIE4jR8PgU0/gREnD4IsLj6EEIYkBJAXi?= =?us-ascii?q?W+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1zhEifQAIEAgkCFYFqgXtNJ?= =?us-ascii?q?E+CaVAXAg2OKxeOJnI3AgYBCQEBAwl8j0QBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="23737671" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:07:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAABGwztf/1lIDI1VChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBQIFKgiqBRzAsCpVRnBQLAQMBAQE?= =?us-ascii?q?BAQYBAS0CBAEBgTWDFwKCHwIkOBMCEAEBBQEBAQIBBgRthWiFcQEBAQEDMgE?= =?us-ascii?q?FQRALEQQBAQEnB0YJCAYBDAEFAgEBgyKDAa8qdIE0hVKDXIFAgTgBjR4PgU0?= =?us-ascii?q?/gREnD4IsLj6EEIYkBJAXiW+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1?= =?us-ascii?q?zhEifQAIEAgkCFYFqI4FXTSRPgmlQFwINjisXjiZBMTcCBgEJAQEDCXyPRAG?= =?us-ascii?q?BEAEB?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="88716595" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:07:36 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07IC7YMm001620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 18 Aug 2020 14:07:34 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 18 Aug 2020 14:07:29 +0200 To: "Panwei (William)" , "Eric Voit (evoit)" , "Shwetha Bhandari (shwethab)" CC: "rats@ietf.org" , "draft-ietf-rats-yang-tpm-charra@ietf.org" , "Fuchs, Andreas" , Michael Eckel References: <6d651f96f7d04f43a5cbb6d2ce8fbbc3@huawei.com> From: Henk Birkholz Message-ID: <322dea6f-2f03-8cbd-5dfe-7eb88a275127@sit.fraunhofer.de> Date: Tue, 18 Aug 2020 14:07:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6d651f96f7d04f43a5cbb6d2ce8fbbc3@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] Orthogonal: UUID? (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:07:50 -0000 Hi all, the use of UUIDs originates from the early days of module design (pre individual -00 I-D), I think. The only reason this usage exists is... because that is the only uniform method to identify both a legacy TPM 1.2 and a TPM 2.0 via the TSS. That is not a very good stand-alone reason :-) To make sure, I'll add two fellow colleagues as CC - just to be on the safe side. Viele Grüße, Henk On 18.08.20 10:35, Panwei (William) wrote: > Hi Eric, > > Thanks for asking, but I’m afraid that the UUID structures weren’t > introduced by us Huawei. And we don’t use UUIDs, so we don’t object to > drop them from the model. > > Regards & Thanks! > > Wei Pan > > *From:*Eric Voit (evoit) [mailto:evoit@cisco.com] > *Sent:* Saturday, August 15, 2020 3:26 AM > *To:* Panwei (William) ; Shwetha Bhandari > (shwethab) > *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) >; Shwetha Bhandari (shwethab) > >> > >> Hi Eric, > >> > >> Thanks for your reply, please see inline. > >> > >> Regards & Thanks! > >> Wei Pan > >> > >> From: Eric Voit (evoit) [mailto:evoit@cisco.com] > >> Sent: Thursday, August 13, 2020 10:32 PM > >> To: Panwei (William) >; Shwetha > Bhandari > >> (shwethab) > > >> Cc: rats@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 > From nobody Tue Aug 18 05:40:47 2020 Return-Path: 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 A3B813A09A0 for ; Tue, 18 Aug 2020 05:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 WpydmBLRrmXo for ; Tue, 18 Aug 2020 05:40:44 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE793A098E for ; Tue, 18 Aug 2020 05:40:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FcBQBMyztf/xmnZsBfgQmDRYEfgTM?= =?us-ascii?q?KhC2RIporgWAJCwEBAQEBAQEBAQYBARgNCAIEAQEChEoCgiEBJDgTAhABAQY?= =?us-ascii?q?BAQEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQE?= =?us-ascii?q?DAQEbBg8BBTYLEAkCDgoCAiMDAgInHwEQBg0BBQIBAReDCwGCfAQLlCibeoE?= =?us-ascii?q?yhE9BQoNVgToGgQ4qhUVLQ4ZMD4FNP4ERJw+BXH4+glwBAQIBAYEmARECAYM?= =?us-ascii?q?3gmAEkn+iKF4qB4FbgQqBCgQLh0uRMQUKHoMAiVyFBAYojhWcf5BVhCcCBAI?= =?us-ascii?q?JAhWBaoELcE0kT4JpUBcCDY4rF4ECAQiHV4VEcgI1AgYBCQEBAwl8jwgBgRA?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A2FcBQBMyztf/xmnZsBfgQmDRYEfgTMKhC2RIporgWAJC?= =?us-ascii?q?wEBAQEBAQEBAQYBARgNCAIEAQEChEoCgiEBJDgTAhABAQYBAQEBAQYEAgKGR?= =?us-ascii?q?QyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQEDAQEbBg8BBTYLE?= =?us-ascii?q?AkCDgoCAiMDAgInHwEQBg0BBQIBAReDCwGCfAQLlCibeoEyhE9BQoNVgToGg?= =?us-ascii?q?Q4qhUVLQ4ZMD4FNP4ERJw+BXH4+glwBAQIBAYEmARECAYM3gmAEkn+iKF4qB?= =?us-ascii?q?4FbgQqBCgQLh0uRMQUKHoMAiVyFBAYojhWcf5BVhCcCBAIJAhWBaoELcE0kT?= =?us-ascii?q?4JpUBcCDY4rF4ECAQiHV4VEcgI1AgYBCQEBAwl8jwgBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="23738886" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:40:39 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkBgCJyztf/1lIDI1fHgEBCxIMQIN?= =?us-ascii?q?FL3ADVDAsCoQtkSOaK4FpCwEDAQEBAQEGAQEYDQgCBAEBhEwCgh8CJDgTAhA?= =?us-ascii?q?BAQUBAQECAQYEbYVcDIVyAQEEAQEbBg8BBTYLEAkCDgoCAiMDAgInHwEQBg0?= =?us-ascii?q?BBQIBAReDCwGDAAuUKZt6gTKET0FCg1WBOgaBDiqFRUtDhkwPgU0/gREnD4F?= =?us-ascii?q?cfj6CXAEBAgEBgSYBEQIBgzeCYASSf6IoXioHgVuBCoEKBAuHS5ExBQoegwC?= =?us-ascii?q?JXIUEBiiOFZx/kFWEJwIEAgkCFYFqI2dwTSRPgmlQFwINjisXgQIBCIdXhUR?= =?us-ascii?q?BMQI1AgYBCQEBAwl8jwgBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="88437754" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:40:36 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07ICeX8L003782 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 18 Aug 2020 14:40:33 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 18 Aug 2020 14:40:28 +0200 To: Laurence Lundblade , "Nancy Cam-Winget (ncamwing)" CC: "rats@ietf.org" References: From: Henk Birkholz Message-ID: <19311dcf-cfe7-a2c0-c8cb-c0ec8aeca634@sit.fraunhofer.de> Date: Tue, 18 Aug 2020 14:40:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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: Tue, 18 Aug 2020 12:40:47 -0000 Hi Laurence, there is a slight difference between 'generic' and 'reference' (at least from my PoV). Yes, 'these' are THE *reference* interaction models for all of RATS - that hopefully also accommodate all FIDOs (at least that was the intent). Meanwhile, each reference interaction model is probably always specific to a subset of RATS use cases - which is intentional. If a use case - or better: solution I-D - uses a specialization or derivate of a reference interaction model (because it describes something new) that can be easily elaborated on by using the reference models as... well a reference. More generalization or more abstraction of course makes the models fit "better" to bigger sets of use cases, but it also removes the value they add. For example, if a solution does not require an Authentication Secret ID to be conveyed, then it can now simply refer to the concept and highlight why the contribution does not need that baggage. As a result, I think I would neither call them "THE models" nor would I attempt to generalize them more. They are simply "THE reference models" that help with placing emerging solutions in the landscape of the exiting ecosystem (which is notoriously hard to do, typically). I am not sure, if my reply was helpful or not, though :-) Viele Grüße, Henk On 14.08.20 20:32, Laurence Lundblade wrote: > Henk and others, can you comment on how this relates to FIDO, Android > Attestation, ARM PSA Token and such? > > It seems that a decision has to be taken as to whether this is: > - THE generic interaction model for all of RATS in which case FIDO, > Android and such have to fit into it > - One interaction model specific to a subset of RATS use cases > > I did a quick read and it seems like FIDO, Android and such could fit. > But it seems a commitment one way or the other is needed up front. If it > is THE model, then the work to make sure it is fully generic needs to be > done. People (not just me) will have to review it to see if it fits all > attestation use cases. If it doesn’t there will be writing to do. > > Right now it seems framed as THE interaction mode (abstract, > introduction sections). Are the authors committing to this as THE Rats > interaction model? > > I think this needs to be clear before the document is adopted. > > LL > > >> On Aug 12, 2020, at 1:25 PM, Nancy Cam-Winget (ncamwing) >> > > wrote: >> >> Hello RATs members, >> At our IETF 108 session we discussed the draft: >> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/ >> There was interest in the discussion on the adoption of the topic, but >> ran out of time to get consensus on “where†these interaction models >> should be documented.  Further, Henk started an email thread prior to >> our session to get a sense of interest and where these models would >> best be described. >> Given those results, there seemed to be a preference to keep the >> document as a standalone draft that describes all models. >> Thus, this is a Call for Adoption of the >> draft-birkholz-rats-reference-interaction-model to serve as the >> starting point for a standalone draft that describes all models.  If >> you have reservations for documenting interaction models, or for such >> a document to be a standalone draft to describe all of them please >> respond to the mail list and provide rationale for your concerns. >> The call for adoption will end on Aug 28. >> Best, Nancy (on behalf of the RATs chairs) >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > From nobody Tue Aug 18 06:30:25 2020 Return-Path: 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 F28F93A09FD for ; Tue, 18 Aug 2020 06:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UGHtVRUz-jw8 for ; Tue, 18 Aug 2020 06:30:20 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D01A3A09FB for ; Tue, 18 Aug 2020 06:30:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HABgB21ztf/xoBYJlfgQmBSoMagTM?= =?us-ascii?q?KhC2QfiWaK4EsNAkLAQEBAQEBAQEBBgEBGAsKAgQBAQKESgKCIQEkNwYOAhA?= =?us-ascii?q?BAQYBAQEBAQYEAgKGRQyCcmE9RgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQENAkMDUgMPAR8BAQEDAQEhDwEFNgsQCQIOBAYCAiYCAicgAg4GDQEFAgE?= =?us-ascii?q?BgyIBgnsFC5Rsm3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJ?= =?us-ascii?q?cAQGBKgESAYM4gmAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgU?= =?us-ascii?q?KHoMAgSONPQYojhWSO4hwllACBAIJAhWBaYEMcE0kT4JpCUcXAg2SEIUUhUR?= =?us-ascii?q?yNwIGAQkBAQMJfI8IAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2HABgB21ztf/xoBYJlfgQmBSoMagTMKhC2QfiWaK4EsN?= =?us-ascii?q?AkLAQEBAQEBAQEBBgEBGAsKAgQBAQKESgKCIQEkNwYOAhABAQYBAQEBAQYEA?= =?us-ascii?q?gKGRQyCcmE9RgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQENAkMDUgMPA?= =?us-ascii?q?R8BAQEDAQEhDwEFNgsQCQIOBAYCAiYCAicgAg4GDQEFAgEBgyIBgnsFC5Rsm?= =?us-ascii?q?3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJcAQGBKgESAYM4g?= =?us-ascii?q?mAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgUKHoMAgSONPQYoj?= =?us-ascii?q?hWSO4hwllACBAIJAhWBaYEMcE0kT4JpCUcXAg2SEIUUhURyNwIGAQkBAQMJf?= =?us-ascii?q?I8IAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="19724848" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 15:30:01 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBCABL1ztf/1lIDI1fgQmBSoIqcAN?= =?us-ascii?q?UMCwKhC2QfSWaK4FpCwEDAQEBAQEGAQEYCwoCBAEBhEwCgh8CJDcGDgIQAQE?= =?us-ascii?q?FAQEBAgEGBG2FXAyFcgEBBAEBIQ8BBTYLEAkCDgQGAgImAgInIAIOBg0BBQI?= =?us-ascii?q?BAYMiAYMAC5Rsm3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJ?= =?us-ascii?q?cAQGBKgESAYM4gmAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgU?= =?us-ascii?q?KHoMAgSONPQYojhWSO4hwllACBAIJAhWBaSRncE0kT4JpCUcXAg2SEIUUhUR?= =?us-ascii?q?BMTcCBgEJAQEDCXyPCAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="88724648" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 15:29:58 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07IDTwnc004909 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 18 Aug 2020 15:29:58 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 18 Aug 2020 15:29:53 +0200 To: Laurence Lundblade , "Smith, Ned" CC: "rats@ietf.org" , Carsten Bormann References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> From: Henk Birkholz Message-ID: <7a320d3e-801b-ef1f-2483-e81d130e042d@sit.fraunhofer.de> Date: Tue, 18 Aug 2020 15:29:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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: Tue, 18 Aug 2020 13:30:24 -0000 Hi Laurence, I am fine with "no Claims exclusive for services" in the base EAT I-D. One can always start a complementary I-D that focuses on services later (e.g. facilitated by re-chartering). Viele Grüße, Henk On 06.08.20 21:09, Laurence Lundblade wrote: > Yes, the RATS architecture seems highly applicable to claims-about-services (for lack of a better term). It would be dumb to have an IETF architecture for claims-about-services that didn’t re use the RATS architecture at least partially. > > By my read of the charter, claims-about-services are not explicitly excluded, but also not quite in the spirit of it. Maybe the work done is done in RATS with a re charter? > > The bottom line for me, is that I really don’t want to put any claims about services in EAT. There is enough work to do already :-) > > LL > > > >> On Aug 6, 2020, at 11:38 AM, Smith, Ned wrote: >> >> The RATS charter refers to "system component" as the initial focus for definition; which includes claims definition. The architecture makes it clear that claims can originate elsewhere as well. It seems reasonable that claims about services could be defined elsewhere, but still be conveyed / appraised using RATS WG defined architecture and technology. Alternatively it could be defined in RATS, but possibly with some charter adjustments to allow "services" scope? >> >> -Ned >> >> On 8/5/20, 12:42 PM, "RATS on behalf of Laurence Lundblade" wrote: >> >> >> >>> On Aug 5, 2020, at 4:47 AM, Carsten Bormann wrote: >>> >>> On 2020-08-03, at 20:58, Laurence Lundblade wrote: >>>> >>>> Service Authenticity >>>> • Focus is on the provider of the service, not the HW or SW >>>> • The legal entity of interest is the service provider >>>> • There is no equivalent of claims, but if there was they would be about the business or person operating the service >>>> • Example: a web site >>>> • Example: an email provider (IMAP service) >>>> >>> >>> Hi Laurence, >>> >>> if you are talking about HTTPS, there is exactly one claim: The service is speaking for a specific name (e.g., facebook.com). All other claims are funneled through this one very special one. Of course, the TLS handshake could be leveraged to do more than this one claim, but that is not what happens in HTTPS. >> >> Yes, agreed. >> >> Any notion of trustworthiness, regulatory compliance and such for a service is implied. We make heavy use of that implication and that is mostly OK. For example, knowing that facebook.com is Facebook Inc allows us to assume lots about the service from what we know of the company. >> >> The equivalent for attestation would be just to name the manufacturer of the HW or SW. However, we are going far beyond that with all the Claims in the Evidence and Results. >> >> Maybe we should have Claims about services? For example, what regulatory statutes they meet. Where are they incorporated. A reference to their terms of service and privacy policy. >> >> That however seems like a new WG, not RATS. >> >> LL >> >> >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats >> >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > From nobody Tue Aug 18 12:25:55 2020 Return-Path: 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 DBCE13A0A97 for ; Tue, 18 Aug 2020 12:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7g2Ib2vtbKcC for ; Tue, 18 Aug 2020 12:25:52 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A5D3A0ABB for ; Tue, 18 Aug 2020 12:25:52 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 87F0k6zrIXBtn87F1kZg30; Tue, 18 Aug 2020 12:25:51 -0700 X-CMAE-Analysis: v=2.3 cv=O5ZHQy1W c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=cauk0CUAAAAA:8 a=8pif782wAAAA:8 a=QdydKHLRhsMtKogxFcwA:9 a=WKvYoJsGByY9ySTb:21 a=c2AjFEKETSxgnPYB:21 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Laurence Lundblade In-Reply-To: <7785.1597540251@localhost> Date: Tue, 18 Aug 2020 12:25:50 -0700 Cc: rats@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <7785.1597540251@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfBR8xG3fiTaRtbanltaeW7ldoI5wbm20HgiujmYyaFmTqscH471knG0MVhK/h30GOkKRkjuRI5kYfBSo5G1lN4Os0sfWBiafd3SY2OZ4pYtxwZHrEorZ 8SrSkxFmAQmgpuG2PIYJ2EgQgdT947PWlKWTsvdD0dmu1qGA5AaI2xYyGUOsfQujXqagzkxxtYWJeDytK9Wo/rfWr9hH8N9XceI= Archived-At: Subject: Re: [Rats] Attestation of implementation vs authenticity of service X-BeenThere: rats@ietf.org 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: Tue, 18 Aug 2020 19:25:54 -0000 > On Aug 15, 2020, at 6:10 PM, Michael Richardson = wrote: >=20 >=20 > Laurence Lundblade wrote: >> Service providers (e.g., web sites) use whatever HW and SW they want = to >> use. As a user of the service we don=E2=80=99t care what HW and SW = they >> select. We trust the service provider to pick good HW and SW and to >> configure and operate it correctly. They might change the HW and the = SW >> and as a user we won=E2=80=99t know. For example we trust Bank of = Xxx to >> operate their banking web site correctly with little concern for = their >> HW. This is why attestation of the HW and SW is not so useful to the >> user of a service. >=20 > The only reason that I do not demand knowledge (attestation) about how = my > Bank operates is because I don't (individually) have the economic = clout to demand it, and > the users suffer from a Collective Action Problem > https://www.britannica.com/topic/collective-action-problem-1917157 > https://en.wikipedia.org/wiki/Collective_action_problem > In Canada (at least), as a shareholder of a publically trade company, = I'm > apparently forbidden from communicating with other shareholders, = except via the > company. >=20 > So I don't think that the difference has anything to do with what we = want, > but rather what has been possible up to now. >=20 > My bank regularly makes very poor technology choices. > They also seem very reluctant to publically document their processes. > Unfortunately, I can't vote with my wallet, because the other ones are = as bad or worse. Collective action for banks exists in a big way in the form of = government regulation. For other services its usually reputational. = Facebook=E2=80=99s isn=E2=80=99t so good right now. We all seem to trust = GitHub well enough based on reputation. Most folks decide to trust services based on reputation - what we read = in the news, what we hear from friends and such. Sometimes we want to = see if they meet government regulations, have deposit insurance or such. = Sometimes we read the terms of service (which are scary for a bank), but = mostly we don=E2=80=99t.=20 I=E2=80=99m thinking about general population here, not super-smart = IETFers or lawyers that read terms of service. But I doubt even us IETFers would care if GitHub switched from Intel to = ARM CPUs or from Azure to AWS. We mostly trust Microsoft to run GitHub = well. >=20 >> Users of mobile phones and IoT devices are not trustworthy to pick >> secure HW and SW. They are not professionals like the people running >> web sites. There is little accountability against them if they pick = bad >> SW and HW. Therefor we want attestation for these usage scenarios. = This >> is why EAT, FIDO and Android Attestation exist. >=20 > This does not ring correct at all to me. > Large media giants want assurances from manufacturers of phones that = the end > user does not have control over the video output systems, and the = large > suppliers have demanded (again, through massive differences in = economic > clout) assurances. > It has nothing to do with the abilities of the owners. > In fact, what is desired is assurance that the owners have in fact = been > forced not to pick their own SW. My characterization was coarse. - End users don=E2=80=99t get to choose much about the OS on a phone, = maybe when to upgrade - Some areas of devices are particularly locked down =E2=80=94 video = playback, authentication, payments (e.g. Apple Secure Enclave). - End users do get to choose which apps they install - But only from an approved list - Some end users get to use debug modes and write their own code, but = when they do apps and services are disabled or they are fenced off. I think it does have to do with the end users. In China, the app ecosystems are a lot more wild-west than the US. There = are imposter apps trying to dupe people into using them. If I lose half the money in my bank account through a mobile app = problem, I=E2=80=99m going to blame the bank and the bank might even be = liable. The bank doesn=E2=80=99t want anyone accessing their online = banking with anything but their app (and a browser). Or consider allowing end users to write their own FIDO authenticators or = use any authenticator available for download. Maybe one is branded as = =E2=80=9Ceasy FIDO=E2=80=9D and truly is easier than most so it gets a = lot of users. But underneath it is allowing the a foreign enemy nation = to collect private info on citizens. Allowing the masses unconstrained choices of SW for to access high-value = services opens the door to fakes, frauds, getting duped and such. LL From nobody Wed Aug 19 00:29:55 2020 Return-Path: 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 7CFC23A10D9; Wed, 19 Aug 2020 00:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvQ68MDogbqN; Wed, 19 Aug 2020 00:29:48 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052483A10D3; Wed, 19 Aug 2020 00:29:48 -0700 (PDT) Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8E6DD4E50C5276B686FB; Wed, 19 Aug 2020 08:29:45 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 19 Aug 2020 08:29:44 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 19 Aug 2020 15:29:42 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 19 Aug 2020 15:29:42 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" , "draft-ietf-rats-yang-tpm-charra@ietf.org" CC: "rats@ietf.org" Thread-Topic: Multi-line card? (was RE: Charra: certificate-name vs TPM-name) Thread-Index: AdZqhEE3A+htPcigTJ6yGgEuz8Go2gLberhw Date: Wed, 19 Aug 2020 07:29:42 +0000 Message-ID: <709464e4635e46f2bce97348bdf8d167@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_709464e4635e46f2bce97348bdf8d167huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Multi-line card? (was RE: Charra: certificate-name vs TPM-name) X-BeenThere: rats@ietf.org 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, 19 Aug 2020 07:29:53 -0000 --_000_709464e4635e46f2bce97348bdf8d167huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, I agree with you, I also didn't intend to bring the topic of the relationsh= ips/roles between TPMs into CHARRA. What I've tried is to make the model ea= sy to understand and to augment in the future. I don't object to adding a constraint to limit the in the RPC ou= tput. But if you think it is tricky and it may not clear to see the potenti= al problems, then I suggest we don't need to add such constraints. The is a mandatory and key node in the datastore rats-support-st= ructure. So you can see, even for the devices with only one TPM, the TPM sh= ould be given a name. Then adding this into the RPC output isn't= an extra complicated thing. If you are very concerned about the devices with only one TPM, I think mayb= e we can just set to an optional node, this is easy to do and th= e devices with only one TPM can just omit this node. Regards & Thanks! From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, August 5, 2020 1:29 AM To: Panwei (William) ; draft-ietf-rats-yang-tpm-= charra@ietf.org Cc: rats@ietf.org Subject: [Rats] Multi-line card? (was RE: Charra: certificate-name vs TPM-n= ame) Hi Wei Pan, I didn't want to couple the general Multi-line card topic you have been adv= ocating in the architecture draft with the charra RPC response structures. = But they are related. One of the things not currently in the scope of Charra are the roles and re= lationships between redundant supervisor cards and line cards. As you have= pointed out, each of these cards might have their own TPM. As was thinkin= g about the issue below, I considered adding a constraint to the RPC output= list which would limit including in the RPC to only those times= when there were two or more instantiated in the configuration d= atastore nodes. (This should be fine as we agree need not be a = key object.) Opening up the discussion into such constraints needs to be done carefully = as they have the potential to limit future solutions to how to structure ro= les/relationships between TPMs. I don't think that this is a topic ready t= o bring into charra as we are trying to get it to WGLC. But at some point = we will need draft which defines how to securely advertise/discover the re= lationships between multiple line cards and supervisors. I.e., if a Verifi= er has a certificate for a supervisor, can information stored in that super= visor's TPM can safely expose the relationships between TPMs in that device= ? How do you refresh this view when the line cards in a device change. Th= is is a worthwhile problem to solve. Eric Hi Wei Pan, Below I cut the thread to the last bit of difference. I think we agree on = everything else. From: Panwei (William), August 4, 2020 1:18 AM Hi Eric, Thanks for your reply. After a twice thinking, I realize it's true that the= difference between our proposals is that whether to contain in = the response and whether to make unique across different= TPMs. Some thoughts please see inline. Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, August 4, 2020 12:42 AM To: Panwei (William) > Cc: rats@ietf.org Subject: Re: [Rats] Charra: certificate-name vs TPM-name Hi Wei Pan, I fully agree that multiple line cards per switch/router is necessary. The = current model does support this, as the RPC output is a list. Lists are id= entified by the "[]" in the tree diagram. So for any current list entry, = a which is unique to an individual TPM can be placed wit= hin this list. The real difference I see between our proposals is that you want = explicitly listed in the RPC response, [Wei] Indeed. and I thought a unique which doesn't require users of si= ngle TPM devices to understand is preferable. I.e., some comple= xity is hidden within the router so that a class of developers need not car= e. [Wei] But I think some new complexities for multi-TPM devices have also eme= rged. The first complexity is that the certificate name should be unique across T= PMs. Imagine this case: there are two TPMs and each one has a certificate, e.g.,= tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA cha= nges its certificate, it releases the name 'cert1' and names the new certif= icate 'cert3'. Right after that tpmB changes its certificate, and names the= new certificate 'cert1' because 'cert1' is unique right now. But you can s= ee a potential problem here, if the Verifier receives the attestation respo= nse before receiving the updates of the certificates, it will wrongly match= the record according to the certificate-name, as it doesn't know the owner= of 'cert1' is changed. Although the Verifier will fail to verify the signa= ture, but it doesn't know what's the real problem. So, the second complexity is that the certificate name should not be reused= by other TPMs. There may be other complexities that I didn't come up with. If the charra model's were populated with someth= ing like "cert1", I would absolutely agree with you. But that is not what= I am proposing. Stepping back, perhaps the conventions used for YANG object naming are caus= ing some mis-communications here. In the example below, use: * "ks" as the prefix for ietf-keystore.yang * "tpm" as the prefix for charra points to an instance of "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ks:certificates/ks:cert= ificate/ks:name" It is over in ietf-keystore.yang, you would have that be somethin= g human readable like "cert1". But we likely wouldn't want two human reada= ble names for the same certificate in different yang models. Looking back at the path from ietf-keystore.yang, you can see that there is= no TPM differentiator in that YANG datastore for asymmetric keys. In othe= r words the primary repository for asymmetric-key information does not use = anything like as part of its key. This is why I believe tha= t is best system generated, and need not be human re= adable. So what I would do in implementation for is= to populate it with the value of "/ks:asymmetric-key/ks:name" appended wit= h the value of "/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name".= This long a string isn't necessary, but it works and requires no addition= al human configuration. Other protections could be put into place as well,= such as an XPATH constraint on so that it is never = the same as "../../tpm:tpm-name/tpm:certificate-name". Again, I wouldn't be overly upset if the WG did have a preference for the n= ested key option of and . It is less = efficient, and exposes extra complexity to the receiver (nested identifiers= and the need for single TPM devices to expose a TPM-name). But it has the= benefit of being simple to understand. How about add a XPATH constraint on within the RPC= to allow the inclusion of this object when /Eric2 --_000_709464e4635e46f2bce97348bdf8d167huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

I agree with you, I also didn’t inte= nd to bring the topic of the relationships/roles between TPMs into CHARRA. = What I’ve tried is to make the model easy to understand and to augment in the future.

 

I don’t object to adding a constrain= t to limit the <tpm-name> in the RPC output. But if you think it is t= ricky and it may not clear to see the potential problems, then I suggest we don’t need to add such constraints.

The <tpm-name> is a mandatory and ke= y node in the datastore rats-support-structure. So you can see, even for th= e devices with only one TPM, the TPM should be given a name. Then adding this <tpm-name> into the RPC output isn’t an= extra complicated thing.

If you are very concerned about the device= s with only one TPM, I think maybe we can just set <tpm-name> to an o= ptional node, this is easy to do and the devices with only one TPM can just omit this node.

 

Regards & T= hanks!

 

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 5, 2020 1:29 AM
To: Panwei (William) <william.panwei@huawei.com>; draft-ietf-r= ats-yang-tpm-charra@ietf.org
Cc: rats@ietf.org
Subject: [Rats] Multi-line card? (was RE: Charra: certificate-name v= s TPM-name)

 

Hi Wei Pa= n,

&nbs= p;

I didn't = want to couple the general Multi-line card topic you have been advocating i= n the architecture draft with the charra RPC response structures.  But= they are related.

 

One of th= e things not currently in the scope of Charra are the roles and relationshi= ps between redundant supervisor cards and line cards.  As you have poi= nted out, each of these cards might have their own TPM.  As was thinking about the issue below, I considered adding = a constraint to the RPC output list which would limit including <tpm-nam= e> in the RPC to only those times when there were two or more <tpm-na= me> instantiated in the configuration datastore nodes.  (This should be fine as we agree <tpm-name> need not be= a key object.)

&nbs= p;

Opening u= p the discussion into such constraints needs to be done carefully as they h= ave the potential to limit future solutions to how to structure roles/relat= ionships between TPMs.  I don't think that this is a topic ready to bring into charra as we are trying to get it= to WGLC.  But at some point we will need draft which defines how &nbs= p;to securely advertise/discover the relationships between multiple line ca= rds and supervisors.  I.e., if a Verifier has a certificate for a supervisor, can information stored in that supervi= sor's TPM can safely expose the relationships between TPMs in that device?&= nbsp; How do you refresh this view when the line cards in a device change.&= nbsp; This is a worthwhile problem to solve.

&nbs= p;

Eric=

 

Hi Wei = Pan,

&n= bsp;

Below I= cut the thread to the last bit of difference.  I think we agree on ev= erything else.

 

From: Panwei (William), August 4, 2020 1= :18 AM

Hi Eric,

 

Thanks for your reply. After a twice think= ing, I realize it’s true that the difference between our proposals is= that whether to contain <tpm-name> in the response and whether to make <certificate-name> unique across different TPMs.

Some thoughts please see inline.

 

Regards & T= hanks!

Wei Pan

 

From: RATS [mailto:rats-boun= ces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats@ietf.org
Subject: Re: [Rats] Charra: certificate-name vs TPM-name<= /span>

 

Hi Wei = Pan,

&n= bsp;

I fully= agree that multiple line cards per switch/router is necessary. The current= model does support this, as the RPC output is a list.  Lists are iden= tified by the "[]" in the tree diagram.   So for any current list entry, a <cert= ificate-name> which is unique to an individual TPM can be placed within = this list.

&n= bsp;

The rea= l difference I see between our proposals is that you want <tpm-name> = explicitly listed in the RPC response,

 

[Wei] Indeed.

 

and I t= hought a unique <certificate-name> which doesn't require users of sin= gle TPM devices to understand <tpm-name> is preferable.  I.e., s= ome complexity is hidden within the router so that a class of developers need not care.

 

[Wei] But I think some new complexities fo= r multi-TPM devices have also emerged.

The first complexity is that the certifica= te name should be unique across TPMs.

Imagine this case: there are two TPMs and = each one has a certificate, e.g., tpmA’s certificate is cert1 and tpm= B’s certificate is cert2. When tpmA changes its certificate, it releases the name ‘cert1’ and names the new certificate = 216;cert3’. Right after that tpmB changes its certificate, and names = the new certificate ‘cert1’ because ‘cert1’ is uniq= ue right now. But you can see a potential problem here, if the Verifier rec= eives the attestation response before receiving the updates of the certificates,= it will wrongly match the record according to the certificate-name, as it = doesn’t know the owner of ‘cert1’ is changed. Although th= e Verifier will fail to verify the signature, but it doesn’t know what’s the real problem.

So, the second complexity is that the cert= ificate name should not be reused by other TPMs.

There may be other complexities that I did= n’t come up with.

 

<eri= c2> If the charra model's <certificate-name> were populated with s= omething like "cert1", I would absolutely agree with you.  &= nbsp;But that is not what I am proposing. 

&n= bsp;

Steppin= g back, perhaps the conventions used for YANG object naming are causing som= e mis-communications here. 

&n= bsp;

In the = example below, use:

  • "ks" as the prefix for ietf-keystore.yang<= /o:p>
  • "tpm" as the prefix for charra=

&n= bsp;

<tpm:certificate-ref&g=
t; points to an instance of  =

 <= /span>"/ks:keystore/ks:asymmetric-keys/ks:asymm= etric-key/ks:certificates/ks:certificate/ks:name"

 

It is o= ver in ietf-keystore.yang, you would have that <ks:name> be something= human readable like "cert1".  But we likely wouldn't want t= wo human readable names for the same certificate in different yang models.

&n= bsp;

Looking= back at the path from ietf-keystore.yang, you can see that there is no TPM= differentiator in that YANG datastore for asymmetric keys.  In other = words the primary repository for asymmetric-key information does not use anything like <tpm:tpm-name> as part of its= key.  This is why I believe that <tpm:certificate-name> is best= system generated, and need not be human readable.  So what I would do= in implementation for <tpm:certificate-name> is to populate it with the value of "/ks:asymmetric-ke= y/ks:name" appended with the value= of "/ks:asymmetric-key/ks:cert= ificates/ks:certificate/ks:name".  This long a string isn't necessary, but it works and requires no additiona= l human configuration.  Other protections could be put into place as w= ell, such as an XPATH constraint on <tpm:certificate-name> so that it= is never the same as "../../tpm:tpm-name/tpm:certificate-name= ".

&n= bsp;

Again, = I wouldn't be overly upset if the WG did have a preference for the nested k= ey option of <tpm:tpm-name> and <tpm:certificate-name>.  I= t is less efficient, and exposes extra complexity to the receiver (nested identifiers and the need for single TPM devices to expose= a TPM-name).  But it has the benefit of being simple to understand.

 

<Eric3>   How a= bout add a XPATH constraint on <tpm:tpm-name> within the RPC to allow= the inclusion of this object when

 

/Eric2<= o:p>

--_000_709464e4635e46f2bce97348bdf8d167huaweicom_-- From nobody Thu Aug 20 09:50:32 2020 Return-Path: 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 22AFD3A0B57 for ; Thu, 20 Aug 2020 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 fcvC2sPbUPSV for ; Thu, 20 Aug 2020 09:50:28 -0700 (PDT) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2E03A0B4F for ; Thu, 20 Aug 2020 09:50:28 -0700 (PDT) Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 8nljkEjgljUDF8nlkkQjpi; Thu, 20 Aug 2020 09:50:28 -0700 X-CMAE-Analysis: v=2.3 cv=G59i7Os5 c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=0n-vlVEVwLVXQyp6cCMA:9 a=JPkXZyH_pJINFWCW:21 a=nJ_IdM1qkaeSHfMx:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Laurence Lundblade In-Reply-To: <19311dcf-cfe7-a2c0-c8cb-c0ec8aeca634@sit.fraunhofer.de> Date: Thu, 20 Aug 2020 09:50:27 -0700 Cc: "Nancy Cam-Winget (ncamwing)" , "rats@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <19311dcf-cfe7-a2c0-c8cb-c0ec8aeca634@sit.fraunhofer.de> To: Henk Birkholz X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfBsf1pjL/K1qHcs429Hm0HZKT3lc5F7bhrKkdJEn1kEos52Ko5KBDd47TRerPjGvHUxk4gdri8TO8RUWL65GNpPBHyZ0iEl7kTeuIIMLcVanpyDj6pQT 43mOHXj9/5WmQLqNx1/jaCMhP7OvDzcBiUWoXc8kkcBdP+QRpqXhCYV65zfjalmXzn0IqpXtDZ9yLb8Hq76P6j2Pn8YaGxza7XV+dmBtqNHngJ8j8RjyAkNC 5i7HgHwJn9/IHVVuQHLUGpf3i9SjxeK5//Ef6umkf2E= Archived-At: Subject: Re: [Rats] Call for adoption of draft-birkholz-rats-reference-interaction-model X-BeenThere: rats@ietf.org 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: Thu, 20 Aug 2020 16:50:30 -0000 Your distinction between reference and generic makes sense. Some text = can be added explaining that. For example =E2=80=9Cthe flows in the = document are descriptive, not prescriptive; actual protocol flows may be = different as along as they achieve the same results=E2=80=9D.=20 I suspect that mobile apps using the whole Web API development paradigm = that use Android Attestation will have interesting flows that are = dictated by the app, the layers in the web/app SW libraries and stack, = how AWS/Azure/... works and so on. But they should still achieve in = effect what is laid out in the reference interaction model. I support adoption. LL > On Aug 18, 2020, at 5:40 AM, Henk Birkholz = wrote: >=20 > Hi Laurence, >=20 > there is a slight difference between 'generic' and 'reference' (at = least from my PoV). >=20 > Yes, 'these' are THE *reference* interaction models for all of RATS - = that hopefully also accommodate all FIDOs (at least that was the = intent). >=20 > Meanwhile, each reference interaction model is probably always = specific to a subset of RATS use cases - which is intentional. >=20 > If a use case - or better: solution I-D - uses a specialization or = derivate of a reference interaction model (because it describes = something new) that can be easily elaborated on by using the reference = models as... well a reference. >=20 > More generalization or more abstraction of course makes the models fit = "better" to bigger sets of use cases, but it also removes the value they = add. For example, if a solution does not require an Authentication = Secret ID to be conveyed, then it can now simply refer to the concept = and highlight why the contribution does not need that baggage. >=20 > As a result, I think I would neither call them "THE models" nor would = I attempt to generalize them more. They are simply "THE reference = models" that help with placing emerging solutions in the landscape of = the exiting ecosystem (which is notoriously hard to do, typically). >=20 > I am not sure, if my reply was helpful or not, though :-) >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 > On 14.08.20 20:32, Laurence Lundblade wrote: >> Henk and others, can you comment on how this relates to FIDO, Android = Attestation, ARM PSA Token and such? >> It seems that a decision has to be taken as to whether this is: >> - THE generic interaction model for all of RATS in which case FIDO, = Android and such have to fit into it >> - One interaction model specific to a subset of RATS use cases >> I did a quick read and it seems like FIDO, Android and such could = fit. But it seems a commitment one way or the other is needed up front. = If it is THE model, then the work to make sure it is fully generic needs = to be done. People (not just me) will have to review it to see if it = fits all attestation use cases. If it doesn=E2=80=99t there will be = writing to do. >> Right now it seems framed as THE interaction mode (abstract, = introduction sections). Are the authors committing to this as THE Rats = interaction model? >> I think this needs to be clear before the document is adopted. >> LL >>> On Aug 12, 2020, at 1:25 PM, Nancy Cam-Winget (ncamwing) = > wrote: >>>=20 >>> Hello RATs members, >>> At our IETF 108 session we discussed the draft: >>> = https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction= -model/ >>> There was interest in the discussion on the adoption of the topic, = but ran out of time to get consensus on =E2=80=9Cwhere=E2=80=9D these = interaction models should be documented. Further, Henk started an email = thread prior to our session to get a sense of interest and where these = models would best be described. >>> Given those results, there seemed to be a preference to keep the = document as a standalone draft that describes all models. >>> Thus, this is a Call for Adoption of the = draft-birkholz-rats-reference-interaction-model to serve as the starting = point for a standalone draft that describes all models. If you have = reservations for documenting interaction models, or for such a document = to be a standalone draft to describe all of them please respond to the = mail list and provide rationale for your concerns. >>> The call for adoption will end on Aug 28. >>> Best, Nancy (on behalf of the RATs chairs) >>> _______________________________________________ >>> RATS mailing list >>> RATS@ietf.org >>> https://www.ietf.org/mailman/listinfo/rats >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats From nobody Fri Aug 21 17:38:12 2020 Return-Path: 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 6B9033A012A; Fri, 21 Aug 2020 17:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=I4xCwjQJ; dkim=pass (1024-bit key) header.d=juniper.net header.b=L/KUlYDU 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 JmPKpXumv4nk; Fri, 21 Aug 2020 17:38:08 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F153A0128; Fri, 21 Aug 2020 17:38:08 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07M0Mira019356; Fri, 21 Aug 2020 17:37:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=YqBLziQ7m000oVULSLRzQes2ZRhf+Z2PmnnhfooscY0=; b=I4xCwjQJzYlo3gfL5hVc901KqX/eST8v3AlEldZtuw6/7W5i9S9kNGh7J5TMh6RgzaWg 2LiIMMPUwu61XkJrg8zRs023EBO+qZgNRk8nzMOYx196qjoEpgBV6EmRrAAkl8qHE1nj g3O2IsNqzc4HrzhpDRW6mgp9MlIdpzwzY4UldaMjZmG7nzXYTGWGP72GbVf8tzVlriTF I4kHOpIUXPAe4ZPczAKnk2TD868YPY93hBe4HzGZz6f5xsnlYBo/fAlb/UrbqUwS+8px 6dFATjl5HybxA1W4iAr4fupuIltafe/rrAZnTfFy7ULjltWVaw46Hw20cYVwzo/6Lw9k aA== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2176.outbound.protection.outlook.com [104.47.55.176]) by mx0b-00273201.pphosted.com with ESMTP id 3304mu7kt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Aug 2020 17:37:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jB/Bb49IQFdjxD1QaZz+Lcv3UUoOOfRpqBvy/Yn5HLuqF7sFXJWQlbJPhY6sd7w+bDX+8dl36s5XRxK9u00mY5kfaA28WkpNvmrGyDk5inB9ltAYyeP60xgBXWl++wkI02WeQjfjtexnNgpKfMqNzxEPZOlJYb+HusnJ73lY0cwz+crqy530RZ19qPT7wyBj6LX5trI6wxUdc29VmpjHvTipgM1LpWuMPWLj2oLXOu8YVlW+e40yVsOChknHbtOgl/T6JEa10Nm9QOM8LRN/UF2F6Cu3/nShtAGKIAHn+Z1dgc6m0WLvBCgfBX9cauBrbS9DtGmV95X8plEZtF6LYg== 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=YqBLziQ7m000oVULSLRzQes2ZRhf+Z2PmnnhfooscY0=; b=Ae+Sgibffdx/Gvwubefx7mVbOc7TEz6r0wSVchiVmc12zegBEIIlFIXvepnFeSO7mz5nxXX1G+CLEGS3RyUm4nzXf8Wmfc6O9pGwzD+kCT1xE081NO3lpHSqJMgMBXISyleee1gE8pHKhScBxxJapW+sJljSwk4vOB7hw/WYQ7wlpg/jYbHq2Nl4KLM6TRL7gaEkz7Bb5XVRn9/6vrTCx8waWYUi2OUlXzsZJyUBwJb0TV2oAFE50VxoWiJjasm2qz4MDiRWOk7xB07pN7vwQg112fDAmw+0sdj9cFfo3jrchcQkVqRObFXwQf3ZP86z5GnOmPrVpvzydoiZ9J4RSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YqBLziQ7m000oVULSLRzQes2ZRhf+Z2PmnnhfooscY0=; b=L/KUlYDUmJqK7s1SioyjNRJihk+MgMepOAU+hAxz0v4k0ypB2FpyXAlk4RPvaqngbrI+zOzi74cPx+P9nSiQ2TfxQ+QBWSTnRnNm6Fz0+1JYZ5I+A9bBmSlkSdXoKliW2R8tjQbI4WjsIj3p4QVZWdshqKHtNY1a1Y6NonR/Tz8= Received: from DM6PR05MB6889.namprd05.prod.outlook.com (2603:10b6:5:204::22) by DM5PR05MB3532.namprd05.prod.outlook.com (2603:10b6:4:45::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Sat, 22 Aug 2020 00:37:49 +0000 Received: from DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::951c:3bee:1ef0:7e1c]) by DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::951c:3bee:1ef0:7e1c%2]) with mapi id 15.20.3326.010; Sat, 22 Aug 2020 00:37:49 +0000 From: Guy Fedorkow To: "Panwei (William)" CC: "Eric Voit (evoit)" , "jessica.m.fitzgerald-mckay.civ@mail.mil" , "rats-chairs@ietf.org" , "rats@ietf.org" Thread-Topic: Review Request: TPM-based attestation Thread-Index: AdZfYrT8yrmJ2HQvTki0TiwHcLsNtwSDMOowAP1OrAAAJnrcAACHa1Hg Date: Sat, 22 Aug 2020 00:37:49 +0000 Message-ID: References: <275b5e5770fb4439bc6a453d80d78484@huawei.com> In-Reply-To: <275b5e5770fb4439bc6a453d80d78484@huawei.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-08-22T00:37:47Z; 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=ea328a91-8f77-4782-8997-87086b6cefa6; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b2e6e41c-1881-4751-d32b-08d8463398d8 x-ms-traffictypediagnostic: DM5PR05MB3532: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1388; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y16KZD2usJkIMfGAPPRxASq3Fz3ZDAfql9gTo9MZZvapehDEb4/eH1PrtF+lNnwsumvLimWb1pEL6cYANxQLSda3mzqfPf/79bO1eElUfS2dFtBJDkqkptF6WejyX/KEXqYBXRJOr3rh32+lUbaa8gBOziWJna9dS/rAnJphSAS0xzIOfrRv+qghEIonG7r7nm92IQS4mNLmp+7yY7Td5nB7xAYd55uBQB9cosnHsBV9XyezBjaE2LiPFqTKIEz07Ty8a9P1N1kIDDEEtnWPVT3fSyUCEV6ZzgiQ/fdkcXqJfd24kHwkxkSI1ZVJ8Up0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6889.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(376002)(346002)(39860400002)(83380400001)(52536014)(2906002)(54906003)(99936003)(6916009)(8676002)(4744005)(71200400001)(66946007)(6506007)(4326008)(5660300002)(7696005)(316002)(26005)(53546011)(478600001)(66556008)(33656002)(186003)(9686003)(66446008)(76116006)(86362001)(8936002)(66616009)(66476007)(64756008)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: QicloolyvhcEbW3e18s38pjcHVlTwMwXEVfq0N04IT3hZkqp5LGaLgmlekVSheXFdBReFFwZt6w2FkV5/yYiLfKXLB/QHvhKts9GHeKGH8Fprh+N3UZ6Ec8rCYh2QTb39QBE6tS0uqoKiSWk7LrsYbVER59ZsoC2wq7mUIiyVBOjdr9RUBvkdNO8dUqoz7cJC4M3NwQrdAB3diO5buyNVV7rnNDSAto1GK5kSuhaZ2Atypsp1EL6CXY7SGjpI8to+8tzVquB4ZqBW4JQ1KKQCV0BIOIvvZFKQf+ykORW9BiHnDlnWjxcv3icwnBfpWzBN+OEvqx8Ha1w3YGihzb0uuePtsNVTVg1RXkk6JKCyOaUa1lBlEpsbbhZ/vQ9d9mj7lqb7VoJ2hR9hxAUQiox6OiLJ66J2jOO1EEuyLNPnBlLwld2Y6bzTRGik6W9iG6DEKBgKO9D3ZOEqopIebeYJtPaRgXih6fwmad7Dq3ApileOa7P46mzyNTI+ztakHqIVQl+QjtC54DH274YcAmC8hsI+YIAZxrmhw6jsxUDbAG81PZIIKM08sHURMHF83ITEx8u08kGywKoHySnkS2OyGJIWyXAZXsDeJ8Yusg0Vxw8YQ1L1gFslBGrUeKjuvru7OexR5CpWnEpvYQ7DgftsQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013F_01D677FA.EE3AF960" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6889.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2e6e41c-1881-4751-d32b-08d8463398d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2020 00:37:49.2369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1uZG4cyYQB1a4irX/RTQIEiuThbtsrgAiGyDyjLuDAhh+76UKzfGEGre0MKXPpwgBX6JKcVYc6TTrsBD1G8WyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3532 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_10:2020-08-21, 2020-08-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 clxscore=1015 malwarescore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008220000 Archived-At: Subject: Re: [Rats] Review Request: TPM-based attestation X-BeenThere: rats@ietf.org 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: Sat, 22 Aug 2020 00:38:10 -0000 ------=_NextPart_000_013F_01D677FA.EE3AF960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wei Pan, thanks very much! /guy Juniper Business Use Only -----Original Message----- From: Panwei (William) Sent: Wednesday, August 19, 2020 3:59 AM To: Henk Birkholz ; Guy Fedorkow ; Smith, Ned ; Dave Thaler ; Laffey, Tom (HPE Aruba) ; Wiseman, Monty (GE Research, US) ; Ira McDonald Cc: Eric Voit (evoit) ; jessica.m.fitzgerald-mckay.civ@mail.mil; rats-chairs@ietf.org; Michael Richardson Subject: RE: Review Request: TPM-based attestation [External Email. Be cautious of content] +1 support for WGLC, I'll have one more round detailed review soon. Regards & Thanks! Wei Pan ------=_NextPart_000_013F_01D677FA.EE3AF960 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISJTCCBd4w ggPGoAMCAQICEAH9bTD8o8pRqBu8ZA41Ay0wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTEwMDIwMTAwMDAwMFoXDTM4MDExODIzNTk1OVowgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw12 7c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NCtnby qTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQfjtTkUcYRZ0YIUcuG FFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy2 9lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnH a4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQN wZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sF qV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMnsQybQ v0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV 4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaNCMEAwHQYDVR0O BBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MA0GCSqGSIb3DQEBDAUAA4ICAQBc1HwNz/cBfUGZZQxzxVKfy/jPmQZ/G9pDFZ+eAlVXlhTxUjwn h5Qo7R86ATeidvxTUMCEm8ZrTrqMIU+ijlVikfNpFdi8iOPEqgv976jpS1UqBiBtVXgpGe5fMFxL JBFV/ySabl4qK+4LTZ9/9wE4lBSVQwcJ+2Cp7hyrEoygml6nmGpZbYs/CPvI0UWvGBVkkBIPcygu xeIkTvxY7PD0Rf4is+svjtLZRWEFwZdvqHZyj4uMNq+/DQXOcY3mpm8fbKZxYsXY0INyDPFnEYkM nBNMcjTfvNVx36px3eG5bIw8El1l2r1XErZDa//l3k1mEVHPma7sF7bocZGM3kn+3TVxohUnlBzP YeMmu2+jZyUhXebdHQsuaBs7gq/sg2eF1JhRdLG5mYCJ/394GVx5SmAukkCuTDcqLMnHYsgOXfc2 W8rgJSUBtN0aB5x3AD/Q3NXsPdT6uz/MhdZvf6kt37kC9/WXmrU12sNnsIdKqSieI47/XCdr4bBP 8wfuAC7UWYfLUkGV6vRH1+5kQVV8jVkCld1incK57loodISlm7eQxwwH3/WJNnQy1ijBsLAL4JxM wxzW/ONptUdGgS+igqvTY0RwxI3/LTO6rY97tXCIrj4Zz0Ao2PzIkLtdmSL1UuZYxR+IMUPuiB3X xo48Q2odpxjefT0W8WL5ypCo/TCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJKoZI hvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VS VHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMwMTIz MTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGln byBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkqKtLN nFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfbM3wc caNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+LbnTe ef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmHfpsE kzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMBAAGj ggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy/Ava lNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBHMEWg Q6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVzZXJ0 cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiMAN0X 13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vhNn9d NqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHitcPr 5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDpVRH9 9lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7T2ww C+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI9oKS ChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RIZllX 4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDonM8V/ 2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQz3lC NObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMIIGKzCCBROgAwIBAgIRAPuElTZ4 EhaY10ByhNJltnIwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTkwODI0MDAwMDAwWhcNMjIwODIzMjM1OTU5WjCCATcxCzAJBgNVBAYTAlVT MQ4wDAYDVQQREwU5NDA4OTELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTEcMBoGA1UE CRMTMTEzMyBJbm5vdmF0aW9uIFdheTEeMBwGA1UEChMVSnVuaXBlciBOZXR3b3JrcywgSW5jMR4w HAYDVQQLExVTb2Z0d2FyZSBFbmdpbmVlciBMYWIxOzA5BgNVBAsTMklzc3VlZCB0aHJvdWdoIEp1 bmlwZXIgTmV0d29ya3MsIEluYyBFLVBLSSBNYW5hZ2VyMR8wHQYDVQQLExZDb3Jwb3JhdGUgU2Vj dXJlIEVtYWlsMRUwEwYDVQQDEwxHdXkgRmVkb3Jrb3cxJDAiBgkqhkiG9w0BCQEWFWdmZWRvcmtv d0BqdW5pcGVyLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Fewgz3OFG1Go3 cuoLYIbLNRTSEFgN+GLUaqB6g5VuCf0UTvgARSlxgDmsvE5qwTtb8JOtJ64OylVNvz28uslsfvg4 WCc0InZUo1B6JkgNamxa3HI31h63s5wVm/wZgglg5Dv7WH7gmAPrgeoWpBC2GN1sxWHfcJOi2fzg M5LWst0Iwz4M7vqFsZ77AOkUFDNm5p19Fu8HRjVlsE0fNGieZB5GEiL2CN2YoxyOKrJdqWHNMkK8 Q5owvlDnSR0tb8oJgHDX8EESSo5TDA5zqnva48zFfFWCrOdobNgf1To4uBskX6B+QEmrSNLuSdpK JOHw9IdrPofgpjZCmFwvtS8CAwEAAaOCAc4wggHKMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZ Qs/J4K0AMB0GA1UdDgQWBBQPfL+xFDoZAlQisKraMq/Y34eQGjAOBgNVHQ8BAf8EBAMCBaAwDAYD VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1Bgwr BgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAg BgNVHREEGTAXgRVnZmVkb3Jrb3dAanVuaXBlci5uZXQwDQYJKoZIhvcNAQELBQADggEBALilLU71 sn7XVNFoUU4MqcHXXFiFiOjCQmq1nqijMa6L4fKm/VX9LZtrsQs3CZTUiHuW2pyLapLVIEXdubNX L877oIVJmeAoSWz1+AYelK6CIpuGUUcGSsXKd4Xl9yOTrmLb7PTjrRpXsWSHJi//jrXTrR/X6M+U TterfzhR5gYPFyvX65Zie9M7k7V2yB3YJJPzT8EtfrJc+eDzYAgiWK8X/ToMZOG7noa/Er8FEARn joL7pKHVOkHTOM9UNaublWlhiUEzzXx9kYPKjgqjAetRo4zh1KBFm9MBlXeigAVBx+BQpP0OdmHb 5vcX3pUR4lkRpnVeLKFR++q6z+bViYAxggRnMIIEYwIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAPuElTZ4EhaY10ByhNJltnIwCQYFKw4DAhoFAKCCAo8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODIyMDAzNzQ3WjAjBgkq hkiG9w0BCQQxFgQUfa2552eI8nUIR0E0LJMAn/2GJuswga0GCSqGSIb3DQEJDzGBnzCBnDALBgkq hkiG9w0BAQcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCSqGSIb3DQEBCjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBvQYJKwYBBAGCNxAEMYGvMIGs MIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA+4SVNngSFpjXQHKE0mW2 cjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+ MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD7hJU2eBIWmNdAcoTSZbZyMA0GCSqGSIb3DQEBAQUABIIBABxb1T9UiM0mX4GCeuYF AggY/EagdzRo0VJ2MSrXgKL8n+xCTKNV0Cg/3o+28frqZfb5RjgSuWzGmFZHz1c00RdgbYuD5qMS 8nbhAv3fkqHQEkKCjAuia1HxD1qtyEQ0HN+Eywywk2zmaRv753OaTTEOR1q+upXw6Z3QnA5rxOYR E/pruGsAJpyDmc8VWsZt/eJlcdMRpRyMtaSHxbHHt3c2IU8O9WJ403nAdOv+AtIOrXUAwt3w5Uj8 jjlhsdf+20SW9dSesuiHgwAX+i9Y9KD3AuKTLZjNgbsiyHQ+DJ7F0PMsm3u4AygpzvDGQGov3BHl NBOh9tfj8KqJGcIb3+QAAAAAAAA= ------=_NextPart_000_013F_01D677FA.EE3AF960-- From nobody Mon Aug 24 11:04:52 2020 Return-Path: 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 D05653A0980 for ; Mon, 24 Aug 2020 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 Glw5ES4NE77b for ; Mon, 24 Aug 2020 11:04:49 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA063A0983 for ; Mon, 24 Aug 2020 11:04:49 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id AGpskqxWkCtRoAGpskPSzm; Mon, 24 Aug 2020 11:04:48 -0700 X-CMAE-Analysis: v=2.3 cv=Qu4gIm6d c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=kj9zAlcOel0A:10 a=1uOtSH1RXhCRRGUQolUA:9 a=CjuIK1q_8ugA:10 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: Date: Mon, 24 Aug 2020 11:04:48 -0700 To: rats@ietf.org X-Mailer: Apple Mail (2.3445.104.15) X-CMAE-Envelope: MS4wfCvs3gS8o9p7iOTebQpC1HjLSGRXbzWIM6FW4ackR6Qyw6B38SlMYD7aFZC/bULM2EMknPpjoEwqFHfk0yTA6y+18vrTEVwur90VF08yyTJ8pLREMbr3 vVT4mNgJysYCoiimyuO3XacI0GkH+gGK/OLktWlcCByG9h0/PXqCMd3R Archived-At: Subject: [Rats] Quantum-safe attestation X-BeenThere: rats@ietf.org 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, 24 Aug 2020 18:04:50 -0000 We probably want RATS architecture to be able to use quantum-safe = algorithms. On low cost and low speed devices that might mean HMAC is = used since SHA-2 and such seem to be quantum-safe. On higher cost and = higher speed devices there may be alternatives that look more like PKI. Comments? LL =20= From nobody Mon Aug 24 14:17:02 2020 Return-Path: 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 033CD3A0C9F for ; Mon, 24 Aug 2020 14:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bHMjPe318ooL for ; Mon, 24 Aug 2020 14:16:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A3B3A0C9E for ; Mon, 24 Aug 2020 14:16:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D1988389AE; Mon, 24 Aug 2020 16:55:59 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5KVAI_dKmg4p; Mon, 24 Aug 2020 16:55:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DC73B389A1; Mon, 24 Aug 2020 16:55:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5B4253F; Mon, 24 Aug 2020 17:16:55 -0400 (EDT) From: Michael Richardson To: Laurence Lundblade , rats@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Rats] Quantum-safe attestation X-BeenThere: rats@ietf.org 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, 24 Aug 2020 21:17:00 -0000 --=-=-= Content-Type: text/plain Laurence Lundblade wrote: > We probably want RATS architecture to be able to use quantum-safe > algorithms. On low cost and low speed devices that might mean HMAC is > used since SHA-2 and such seem to be quantum-safe. On higher cost and > higher speed devices there may be alternatives that look more like > PKI. Yes/no. Use of a keyed HMAC requires a symmetric key, which will be a hassle to provision the verifier, and effectively locks the device to a single (likely manufacturer provided) verifier. It will also raise questions of non-repudiation. Better *might* be RFC8778 HSS/LMS Hash-Based Signature Algorithms. They are bigger, and have a limited number of uses. I would say that the architecture does not need to say anything about the algorithms. These are functional requirements, not design requirements. There will have to be firmware updates to the Attesting Environment once either we have quantum-safe asymmetric algorithms, or when we have a QM breach. That can be done with SUIT signed by RFC8778. I don't think that our architecture need worry about that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9ELkcACgkQgItw+93Q 3WWz2Af+MugLRpG+Tm2leV0klTk45xtB2vfrl0tgOdUm7E8/3y7LgZJuEqq60qEu iys4kE6CWu9WivvDcIBBNFRngjKVaeitxcj+D0J0Me50UaOXojZ9UIAyDo4mvr4Q 9ogpRSWNZDo1dtz6LgCSlU1mVdu230M7soS/by5aKDzKj9yg2zCsS0p7SPU6hNp/ 1A7mvg8I7CJ5g+1b8+J5nBGYD2wKZ/tP8TUCD+rcS6wgwzpULXHS2NvPdr/j4ks5 qmlB7HZKr1XRywLSkcf9WdUBwiiiPD5t2xjIdELnTsCww7FcevqE6mL24nWqitqw HV5mUkuqAOgKkKeuasyCW3CgRU6tdA== =Njn3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 24 14:24:49 2020 Return-Path: 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 C594F3A0CB4 for ; Mon, 24 Aug 2020 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 xmbpR1IfDmI4 for ; Mon, 24 Aug 2020 14:24:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E158D3A0CB3 for ; Mon, 24 Aug 2020 14:24:46 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07OLOeev000610; Mon, 24 Aug 2020 22:24:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=FS1u7rY00Myp4SN29dJWXAQ7LFcE3NjANynfJJDJTSU=; b=jmnIBtZGof+6tPXB+yXX3U/VtpWqJGtX1yvSN/IFkcsfbDF4L6uH4p72vzNX5/73EROf Qc2KKfZYFmbkPWB0VNRCuMriD5jo0ftQbee3IMLL0ZkZQxFTKFz/sL1VZtICbap5jka/ 0jZHedfwSLoDHsxznsu/L7Ue0ivdpuxGSov3IMPhqhiJnl8jcWOtycDBZwXgRWE7Zmhv mlrQxv3cGzIm4TU71J8LvS2s92pUL/Vs2SxmDtQuYYRPTGHsasMXId/FiYmxlZ28M2Xr +mqIkApCxIv24V191rOC6XHK/qq+LSNKshoimbgtK3JRSwmgZ0RB2HEow/AV7q33nU5E XQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 33486ys6uf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 22:24:45 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07OLGeMM015669; Mon, 24 Aug 2020 17:24:44 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 332xpxh2es-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 17:24:44 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 24 Aug 2020 17:24:43 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Mon, 24 Aug 2020 17:24:43 -0400 From: "Salz, Rich" To: Michael Richardson , Laurence Lundblade , "rats@ietf.org" Thread-Topic: [Rats] Quantum-safe attestation Thread-Index: AQHWekETX3z6gwskwU6+9M4pcSw8w6lIBlWA//+/H4A= Date: Mon, 24 Aug 2020 21:24:42 +0000 Message-ID: <4F1E3DEC-ED9A-49C3-A340-5BBFBA1DDB2A@akamai.com> References: <28631.1598303815@localhost> In-Reply-To: <28631.1598303815@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <295BA2A17E068541873A78405475045A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxlogscore=718 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008240165 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=676 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008240168 Archived-At: Subject: Re: [Rats] Quantum-safe attestation X-BeenThere: rats@ietf.org 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, 24 Aug 2020 21:24:48 -0000 PiAgICBJIGRvbid0IHRoaW5rIHRoYXQgb3VyIGFyY2hpdGVjdHVyZSBuZWVkIHdvcnJ5IGFib3V0 IHRoYXQuDQoNCkFncmVlLg0KDQo= From nobody Mon Aug 24 15:23:27 2020 Return-Path: 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 592AD3A0E14 for ; Mon, 24 Aug 2020 15:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j94YoQjanaBI for ; Mon, 24 Aug 2020 15:23:24 -0700 (PDT) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C513A0E12 for ; Mon, 24 Aug 2020 15:23:24 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id AKs7krbi5O7UfAKs7kGSB5; Mon, 24 Aug 2020 15:23:23 -0700 X-CMAE-Analysis: v=2.3 cv=LLoYv6e9 c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=WWjOsw5lXiujUdI6GIQA:9 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Laurence Lundblade In-Reply-To: <28631.1598303815@localhost> Date: Mon, 24 Aug 2020 15:23:23 -0700 Cc: rats@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <265F46D1-76F8-4B0B-9390-AB15A44E0B0D@island-resort.com> References: <28631.1598303815@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.15) X-CMAE-Envelope: MS4wfEhrG1aSzRkKDskyhaP1JDzLsG9u7SRkbWTPbXAErjxG7Xm5ebFIg4WoSRwmAcUWy7cL1OxVsi4+GXHbADzwBNCB9E5BoVplDslTWdVHBYWxPM0h4wDE gT5nq6/r2Oyfm3z4cND2QO2CfuSGC7IJIBCkpankIGcq5ipMFgSyMyPGvFwBnHqeHcPWCYAkuLpl2kH2f+RmTTDo1PvypIv3E4Q= Archived-At: Subject: Re: [Rats] Quantum-safe attestation X-BeenThere: rats@ietf.org 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, 24 Aug 2020 22:23:26 -0000 I don=E2=80=99t want the RATS architecture to pick one algorithm or go = into detail about algorithms. I expect the RATS architecture to be fully flexible to use what ever = algorithms can do the job. In particular it must not assume PKI. Most = other crypto-using IETF standards do not assume PKI. They often work = better with PKI, but they allow for other algorithms. RATS needs to be = the same. The particular manifestation I can think of for RATS is that = Endorsements must support confidentiality. If endorsements do not = support confidentiality an assumption that only PKI-based attestation = can be used is made.=20 I don=E2=80=99t know of any other manifestations that moving to = quantum-safe crypto would have on the architecture, but it seems worth = thinking through. LL > On Aug 24, 2020, at 2:16 PM, Michael Richardson = wrote: >=20 >=20 > Laurence Lundblade wrote: >> We probably want RATS architecture to be able to use quantum-safe >> algorithms. On low cost and low speed devices that might mean HMAC is >> used since SHA-2 and such seem to be quantum-safe. On higher cost and >> higher speed devices there may be alternatives that look more like >> PKI. >=20 > Yes/no. >=20 > Use of a keyed HMAC requires a symmetric key, which will be a hassle = to > provision the verifier, and effectively locks the device to a single = (likely > manufacturer provided) verifier. It will also raise questions of > non-repudiation. > Better *might* be RFC8778 HSS/LMS Hash-Based Signature Algorithms. > They are bigger, and have a limited number of uses. >=20 > I would say that the architecture does not need to say anything about = the > algorithms. These are functional requirements, not design = requirements. >=20 > There will have to be firmware updates to the Attesting Environment = once > either we have quantum-safe asymmetric algorithms, or when we have a = QM > breach. That can be done with SUIT signed by RFC8778. > I don't think that our architecture need worry about that. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats From nobody Mon Aug 24 19:22:12 2020 Return-Path: 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 71A3E3A0F2E for ; Mon, 24 Aug 2020 19:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T3fY8h-jVex8 for ; Mon, 24 Aug 2020 19:22:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A64F3A0949 for ; Mon, 24 Aug 2020 19:22:08 -0700 (PDT) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 32D01273F6BCDB6EAD17; Tue, 25 Aug 2020 03:22:05 +0100 (IST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 25 Aug 2020 03:22:04 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 25 Aug 2020 10:22:01 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 25 Aug 2020 10:22:01 +0800 From: "Panwei (William)" To: Laurence Lundblade , Michael Richardson CC: "rats@ietf.org" Thread-Topic: [Rats] Quantum-safe attestation Thread-Index: AQHWekEXO/hHx4ve/0iCTlgTs0mom6lHPSqAgAASkoCAAMVAQA== Date: Tue, 25 Aug 2020 02:22:01 +0000 Message-ID: References: <28631.1598303815@localhost> <265F46D1-76F8-4B0B-9390-AB15A44E0B0D@island-resort.com> In-Reply-To: <265F46D1-76F8-4B0B-9390-AB15A44E0B0D@island-resort.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Quantum-safe attestation X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 02:22:10 -0000 PiBMYXVyZW5jZSBMdW5kYmxhZGUgPGxnbEBpc2xhbmQtcmVzb3J0LmNvbT4gd3JvdGU6DQo+IA0K PiBJIGRvbuKAmXQgd2FudCB0aGUgUkFUUyBhcmNoaXRlY3R1cmUgdG8gcGljayBvbmUgYWxnb3Jp dGhtIG9yIGdvIGludG8gZGV0YWlsDQo+IGFib3V0IGFsZ29yaXRobXMuDQo+IA0KPiBJIGV4cGVj dCB0aGUgUkFUUyBhcmNoaXRlY3R1cmUgdG8gYmUgZnVsbHkgZmxleGlibGUgdG8gdXNlIHdoYXQg ZXZlcg0KPiBhbGdvcml0aG1zIGNhbiBkbyB0aGUgam9iLiBJbiBwYXJ0aWN1bGFyIGl0IG11c3Qg bm90IGFzc3VtZSBQS0kuIE1vc3Qgb3RoZXINCj4gY3J5cHRvLXVzaW5nIElFVEYgc3RhbmRhcmRz IGRvIG5vdCBhc3N1bWUgUEtJLiBUaGV5IG9mdGVuIHdvcmsgYmV0dGVyIHdpdGgNCj4gUEtJLCBi dXQgdGhleSBhbGxvdyBmb3Igb3RoZXIgYWxnb3JpdGhtcy4gUkFUUyBuZWVkcyB0byBiZSB0aGUg c2FtZS4NCj4gDQo+IFRoZSBwYXJ0aWN1bGFyIG1hbmlmZXN0YXRpb24gSSBjYW4gdGhpbmsgb2Yg Zm9yIFJBVFMgaXMgdGhhdCBFbmRvcnNlbWVudHMNCj4gbXVzdCBzdXBwb3J0IGNvbmZpZGVudGlh bGl0eS4gSWYgZW5kb3JzZW1lbnRzIGRvIG5vdCBzdXBwb3J0DQo+IGNvbmZpZGVudGlhbGl0eSBh biBhc3N1bXB0aW9uIHRoYXQgb25seSBQS0ktYmFzZWQgYXR0ZXN0YXRpb24gY2FuIGJlIHVzZWQN Cj4gaXMgbWFkZS4NCg0KVGhlIGNoYXJhY3RlcmlzdGljcyBvZiBFbmRvcnNlbWVudCBkZXBlbmQg b24gd2hhdCB0aGUgRW5kb3JzZW1lbnQgaXMuIEkgZG9uJ3QgZmVlbCBjdXJyZW50IGFyY2hpdGVj dHVyZSBhc3N1bWVzIHRoZSBFbmRvcnNlbWVudHMgYXJlIFBLSS1iYXNlZCBvciBsaW1pdHMgdGhl IGFsZ29yaXRobXMgdG8gb25seSB1c2UgUEtJLg0KDQpSZWdhcmRzICYgVGhhbmtzIQ0KV2VpIFBh bg0KDQo+IA0KPiBJIGRvbuKAmXQga25vdyBvZiBhbnkgb3RoZXIgbWFuaWZlc3RhdGlvbnMgdGhh dCBtb3ZpbmcgdG8gcXVhbnR1bS1zYWZlDQo+IGNyeXB0byB3b3VsZCBoYXZlIG9uIHRoZSBhcmNo aXRlY3R1cmUsIGJ1dCBpdCBzZWVtcyB3b3J0aCB0aGlua2luZw0KPiB0aHJvdWdoLg0KPiANCj4g TEwNCj4gDQo+IA0KPiANCj4gPiBPbiBBdWcgMjQsIDIwMjAsIGF0IDI6MTYgUE0sIE1pY2hhZWwg UmljaGFyZHNvbg0KPiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gPg0KPiA+DQo+ ID4gTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb20+IHdyb3RlOg0KPiA+ PiBXZSBwcm9iYWJseSB3YW50IFJBVFMgYXJjaGl0ZWN0dXJlIHRvIGJlIGFibGUgdG8gdXNlIHF1 YW50dW0tc2FmZQ0KPiA+PiBhbGdvcml0aG1zLiBPbiBsb3cgY29zdCBhbmQgbG93IHNwZWVkIGRl dmljZXMgdGhhdCBtaWdodCBtZWFuIEhNQUMNCj4gaXMNCj4gPj4gdXNlZCBzaW5jZSBTSEEtMiBh bmQgc3VjaCBzZWVtIHRvIGJlIHF1YW50dW0tc2FmZS4gT24gaGlnaGVyIGNvc3QNCj4gYW5kDQo+ ID4+IGhpZ2hlciBzcGVlZCBkZXZpY2VzIHRoZXJlIG1heSBiZSBhbHRlcm5hdGl2ZXMgdGhhdCBs b29rIG1vcmUgbGlrZQ0KPiA+PiBQS0kuDQo+ID4NCj4gPiBZZXMvbm8uDQo+ID4NCj4gPiBVc2Ug b2YgYSBrZXllZCBITUFDIHJlcXVpcmVzIGEgc3ltbWV0cmljIGtleSwgd2hpY2ggd2lsbCBiZSBh IGhhc3NsZQ0KPiA+IHRvIHByb3Zpc2lvbiB0aGUgdmVyaWZpZXIsIGFuZCBlZmZlY3RpdmVseSBs b2NrcyB0aGUgZGV2aWNlIHRvIGEgc2luZ2xlIChsaWtlbHkNCj4gPiBtYW51ZmFjdHVyZXIgcHJv dmlkZWQpIHZlcmlmaWVyLiAgIEl0IHdpbGwgYWxzbyByYWlzZSBxdWVzdGlvbnMgb2YNCj4gPiBu b24tcmVwdWRpYXRpb24uDQo+ID4gQmV0dGVyICptaWdodCogYmUgUkZDODc3OCBIU1MvTE1TIEhh c2gtQmFzZWQgU2lnbmF0dXJlIEFsZ29yaXRobXMuDQo+ID4gVGhleSBhcmUgYmlnZ2VyLCBhbmQg aGF2ZSBhIGxpbWl0ZWQgbnVtYmVyIG9mIHVzZXMuDQo+ID4NCj4gPiBJIHdvdWxkIHNheSB0aGF0 IHRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgbmVlZCB0byBzYXkgYW55dGhpbmcgYWJvdXQNCj4g PiB0aGUgYWxnb3JpdGhtcy4gIFRoZXNlIGFyZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywgbm90 IGRlc2lnbg0KPiByZXF1aXJlbWVudHMuDQo+ID4NCj4gPiBUaGVyZSB3aWxsIGhhdmUgdG8gYmUg ZmlybXdhcmUgdXBkYXRlcyB0byB0aGUgQXR0ZXN0aW5nIEVudmlyb25tZW50DQo+ID4gb25jZSBl aXRoZXIgd2UgaGF2ZSBxdWFudHVtLXNhZmUgYXN5bW1ldHJpYyBhbGdvcml0aG1zLCBvciB3aGVu IHdlDQo+ID4gaGF2ZSBhIFFNIGJyZWFjaC4gIFRoYXQgY2FuIGJlIGRvbmUgd2l0aCBTVUlUIHNp Z25lZCBieSBSRkM4Nzc4Lg0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhhdCBvdXIgYXJjaGl0ZWN0dXJl IG5lZWQgd29ycnkgYWJvdXQgdGhhdC4NCj4gPg0KPiA+IC0tDQo+ID4gTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUNCj4gV29ya3MN Cj4gPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBSQVRTIG1haWxpbmcgbGlzdA0KPiA+IFJB VFNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jh dHMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFJBVFMgbWFpbGluZyBsaXN0DQo+IFJBVFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYXRzDQo= From nobody Tue Aug 25 12:16:16 2020 Return-Path: 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 43B8D3A08B1 for ; Tue, 25 Aug 2020 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=x0LOYpBf; dkim=pass (1024-bit key) header.d=juniper.net header.b=lA8CpEwt 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 RLPmKQgizcqv for ; Tue, 25 Aug 2020 12:16:13 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2AB3A08AE for ; Tue, 25 Aug 2020 12:16:13 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07PJCvSu024358; Tue, 25 Aug 2020 12:16:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=YJ0irfGCyQI4hLdLkFTEAu09QDgaG847sA0LpjQoJEE=; b=x0LOYpBfXPXx5XH1olnmoy8fNSYgKo03jdHrDoikOkL+SrADxueUgsX3s32eE/UbcAVn 99CgFdtHJ6ZwgOTSTyFBT3f7A7R3IvypB1G3aLGCo0C9QRc1PsS8b4Huo3BK5cHK5Kzh LVtHRdVDW4+w/Bvhs9smudxxBoJboXSwrARnJbWfFO16lqjBjkeOr4Qw92/ihbRs7+Fo SyxkJG//GW6mLClj8vAL/2ZFVfGs34d2MgHEYW1UFqiU6GEM1H4pwIj7ztDDeCQPsvaz x2t/+OuG0fbyIMlsxGns/T7oBH+EAmaZ2r9gE1lGvt6CRHkXahW+SSmjbPUjAIT3+oO+ TA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2058.outbound.protection.outlook.com [104.47.36.58]) by mx0a-00273201.pphosted.com with ESMTP id 332y2qw63w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2020 12:16:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UtJFE6sf6bOQ7CXZSn/SDPA05ukj9AcZ5+IfvVdO/tR5fPSzwiIj4vf5FwPuxgvAslowZWjCGZvDAmR+NjkmiI47jL2AxKg+YmDxp4nSl5PUSvTIAilGXDZkfhKNnMQwd+Z98QHmo0h0vSyHy71zcQZ+sVVDlVeP5tSsotSku+Bprf9PwkWN2Nge3c223Z7H2e1pbVS8TiTsno5/6e/bBpINtSLziI+Xh53DuQjOYzRE9yHJQpLvbBLmomCnkz06S1oFZznCaXeovEMpf7WG4m5JGpS/YcJWq5GRErqeCxUUVFgUJ/YHUzFDZx1QeJjJ+cqPjzWPS0KX8/Iyl4cB8g== 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=YJ0irfGCyQI4hLdLkFTEAu09QDgaG847sA0LpjQoJEE=; b=FgdQtuSf/lol5FJI2BDlmj1TO14hSgjv1ogfrnW/r8Oz7cTx8HlaeO+oo/CGqwLvKtp9lNmv6z10iMIMXkUz5AQxM1UEAKsrN7hwqpNqagABT9JMAd9d22cV5VVoPYaNw6XcV//u2yGSL6K/F7tH1kqF7P7UgbU7emH04AxQ3Wx6oNwTfrsyZyhIuarnMGiNyVZjO79tmmQQsgnjmHVTywOke/6XgL5e4BO+LpfPmYtr9IBYZ7KnPRYUxRrQPQWxX8jrcJRdMwIRI55LsCAOGu/wG3Hn1Kjxc5vq3Q3UdgdSuxpxC0bJU5CdcSW0i/3vdtzK4BYDE8twKUtD5N1tHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YJ0irfGCyQI4hLdLkFTEAu09QDgaG847sA0LpjQoJEE=; b=lA8CpEwt55jNAW71Sg2NTeByibYIZFaz5Hjl2pZlhduw86ZLQnxxBRM1r+w6DNpWCICfD9sD2WktKTPRmgVXfFsn/g9qVr1WnaxuknzWtvFtRSPJFqGCmvH17BCC+AqGWH0bXLG4vAi2AHvNjfzXhh5mOtymDup/IlsxPSlu0do= Received: from DM6PR05MB6889.namprd05.prod.outlook.com (2603:10b6:5:204::22) by DM5PR0501MB3752.namprd05.prod.outlook.com (2603:10b6:4:79::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Tue, 25 Aug 2020 19:16:06 +0000 Received: from DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::951c:3bee:1ef0:7e1c]) by DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::951c:3bee:1ef0:7e1c%2]) with mapi id 15.20.3326.018; Tue, 25 Aug 2020 19:16:06 +0000 From: Guy Fedorkow To: "rats@ietf.org" CC: "Eric Voit (evoit)" , "Jessica Fitzgerald-McKay (jmfmckay@gmail.com)" Thread-Topic: TPM background for RIV Thread-Index: AdZ7FCxmPJt+FRfUTmKTg8duYuoerA== Date: Tue, 25 Aug 2020 19:16:05 +0000 Message-ID: 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-08-25T19:16:03Z; 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=47b39a74-6a0b-4d3a-a050-9f0eb7851dce; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6af4ab3f-7183-44f3-f6f8-08d8492b50d0 x-ms-traffictypediagnostic: DM5PR0501MB3752: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZRIhVCOVp61eAfmmrhg5PGyu+Fv5uN72Yh9Vh+Yaer+zo+KL4hi4BN150SF0lWJ+iVP1Se3CzVF54qRmmFmeqdNrQ2WNr6Mpj6SxHo34spH4jSis8m0OuCrKqUNRClgKblzw/DvFBxSJXQDboerwzWoWelflGOASZgZ92D2oDF73sVx+/u/3RCqQYWyrFT7KhnWi6j9GJd1LAlwWj5XdJQKj/MpduqtQubnt8cBHoruacXCW6l/tLmnfwH5WCWeica64E5rmaEc79obA6Yt0SpHN2XHlcZTvITMcr279c+6F0mAW7ZszP06crf017bIS9SPCWVb7s3DDHPjeYgMsDQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6889.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(346002)(39860400002)(366004)(66476007)(316002)(66616009)(8676002)(64756008)(66556008)(26005)(54906003)(4326008)(52536014)(66446008)(6506007)(33656002)(8936002)(5660300002)(186003)(478600001)(99936003)(76116006)(3480700007)(71200400001)(2906002)(7696005)(55016002)(9686003)(86362001)(83380400001)(6916009)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: VAFq1ikChL3K/JqHW1j4jrqZ4xRnhmECpNGBiP40unPJQme3colbZeYg2GwMx6Z1mBEptkIq33TVsiTgNylGwnlETrvxwr151kNcAbJfgfSqS+B5RE3GkFA9h7HrKck21HBgtyAHVAcnNFseljqB0euhH2/Xx8jv9zDHc5cxHaXL6YrTXHeFTq2LWn+JSo4WBHcrJxpiSfIRkfG9eAUUjgUYvTzA6kh2sL4+3CoqTVy7T8OpV5yBbtB7e8sknCa3xzG30Sv2u4PTBs8Slx27GuvQ9wqHi9x5hC6dJm5vCDytU7twpvwsm2hQvHZSNqBWwId1I67hjM8X4dWkm+VDUnC0idBb6D3Tc8M51HnclJgS3zuoa0W5HjfdptGkgvyP+MPdG0YUSb2OQBxnSbDD3+LiVASo+zy7qeD+5ARxwFfkEflDhG11eU0Z7PWBfGAD5qd2kw/zNp9fvv20Off+QzntJZp6SQSRd01jx7TZ5J+MMYvLjR8PvT+EmPju7oDn60GVOemetDjYeSLkDjdHGe/EY+dptZcaLtry7yxMR6fVHOoXVDjU/XX/+ffmsh+G1z1d/xc7vWKB+B6V3ZIvo0SxZ+i1LR6uSnWNyaKkc0O3a6gd2BGwbW9gAVee3mIfI/7PLVsKRRVgfvLEwVTrqg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F5_01D67AF2.A5D23760" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6889.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6af4ab3f-7183-44f3-f6f8-08d8492b50d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2020 19:16:05.9679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IFDzPyVmW2RNeb7JQcU88cFB3ZOC/QweLzijM69zswIp46vK3fy7EtDoNV/didsucwtDSc43ZEubFnKEDsAUYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3752 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-25_08:2020-08-25, 2020-08-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008250144 Archived-At: Subject: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 19:16:15 -0000 ------=_NextPart_000_00F5_01D67AF2.A5D23760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F6_01D67AF2.A5D25E70" ------=_NextPart_001_00F6_01D67AF2.A5D25E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A recent reviewer of the RIV document (that would be a RIViewer) pointed out that the doc assumes that the fundamental behavior of a TPM for attestation is already well known by the reader. Of course that may not be the case. Rather than add more tutorial material to be body of the document, I'd like to suggest adding the following subsection to the existing appendices, with cross references in a couple places in the doc. Let me know if this looks like it would be helpful to new readers. Thanks /guy *Appendix **Using a TPM for Attestation The Trusted Platform Module and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, and a standardized Event Log. Each TPM has at least sixteen PCRs, each one large enough to hold one hash value (SHA-1, SHA-256, and other algorithms can be used for this hashing depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint of all the security measurements extended into each PCR since the system was reset. Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to what event it was that generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident - any verification process can read the security measurement hash from the log events, compute the composite value and compare that to what ended up in the PCR. If there's a discrepancy, the logs do not provide an accurate view of what was placed into the PCR. The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them into a data structure signed by an Attestation Key (which is private key that is known only to the TPM). The Verifier uses the Quote and Log together. The Quote, containing the composite hash of the complete sequence of security measurement hashes, is used to verify the integrity of the Event Log. Each hash in the validated Quote can then be compared to corresponding expected values in the set of Reference Integrity Measurements to validate overall system integrity. Information about PCRs and Quotes can be found in {{TPM1.2}} and {{TPM2.0}}. Although there are several log formats, an example can be found in {{XX}} Juniper Business Use Only ------=_NextPart_001_00F6_01D67AF2.A5D25E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A recent reviewer of the RIV document (that would be a = RIViewer) pointed out that the doc assumes that the fundamental behavior = of a TPM for attestation is already well known by the reader.  Of = course that may not be the case.

  Rather than add more tutorial material to be = body of the document, I’d like to suggest adding the following = subsection to the existing appendices, with cross references in a couple = places in the doc.

  Let me know = if this looks like it would be helpful to new readers.

  Thanks

/guy

 

  =

 

*Appendix

 

**Using a = TPM for Attestation

 

  The = Trusted Platform Module and surrounding ecosystem provide three = interlocking capabilities to enable secure collection of evidence from a = remote device, Platform Configuration Registers (PCRs), a Quote = mechanism, and a standardized Event Log.

 

  Each = TPM has at least sixteen PCRs, each one large enough to hold one hash = value (SHA-1, SHA-256, and other algorithms can be used for this hashing = depending on TPM version).  PCRs can’t be accessed directly = from outside the chip, but the TPM interface provides a way to = “extend” a new security measurement hash into any PCR, a = process by which the existing value in the PCR is hashed with the new = security measurement hash, and the result placed back into the same = PCR.  The result is a composite fingerprint of all the security = measurements extended into each PCR since the system was = reset.

 

  Every time a PCR is extended, an entry should = be added to the corresponding Event Log.  Logs contain the security = measurement hash plus informative fields offering hints as to what event = it was that generated the security measurement.  The Event Log = itself is protected against accidental manipulation, but it is = implicitly tamper-evident – any verification process can read the = security measurement hash from the log events, compute the composite = value and compare that to what ended up in the PCR.   If = there’s a discrepancy, the logs do not provide an accurate view of = what was placed into the PCR.

 

  The = TPM provides another mechanism called a Quote that can read the current = value of the PCRs and package them into a data structure signed by an = Attestation Key (which is private key that is known only to the = TPM).

 

The Verifier uses the Quote and Log together.  = The Quote, containing the composite hash of the complete sequence of = security measurement hashes, is used to verify the integrity of the = Event Log.  Each hash in the validated Quote can then be compared = to corresponding expected values in the set of Reference Integrity = Measurements to validate overall system integrity.

 

  = Information about PCRs and Quotes can be found in {{TPM1.2}} and = {{TPM2.0}}.  Although there are several log formats, an example can = be found in {{XX}}

 


Juniper = Business Use Only

------=_NextPart_001_00F6_01D67AF2.A5D25E70-- ------=_NextPart_000_00F5_01D67AF2.A5D23760 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISJTCCBd4w ggPGoAMCAQICEAH9bTD8o8pRqBu8ZA41Ay0wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTEwMDIwMTAwMDAwMFoXDTM4MDExODIzNTk1OVowgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw12 7c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NCtnby qTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQfjtTkUcYRZ0YIUcuG FFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy2 9lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnH a4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQN wZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sF qV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMnsQybQ v0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV 4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaNCMEAwHQYDVR0O BBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MA0GCSqGSIb3DQEBDAUAA4ICAQBc1HwNz/cBfUGZZQxzxVKfy/jPmQZ/G9pDFZ+eAlVXlhTxUjwn h5Qo7R86ATeidvxTUMCEm8ZrTrqMIU+ijlVikfNpFdi8iOPEqgv976jpS1UqBiBtVXgpGe5fMFxL JBFV/ySabl4qK+4LTZ9/9wE4lBSVQwcJ+2Cp7hyrEoygml6nmGpZbYs/CPvI0UWvGBVkkBIPcygu xeIkTvxY7PD0Rf4is+svjtLZRWEFwZdvqHZyj4uMNq+/DQXOcY3mpm8fbKZxYsXY0INyDPFnEYkM nBNMcjTfvNVx36px3eG5bIw8El1l2r1XErZDa//l3k1mEVHPma7sF7bocZGM3kn+3TVxohUnlBzP YeMmu2+jZyUhXebdHQsuaBs7gq/sg2eF1JhRdLG5mYCJ/394GVx5SmAukkCuTDcqLMnHYsgOXfc2 W8rgJSUBtN0aB5x3AD/Q3NXsPdT6uz/MhdZvf6kt37kC9/WXmrU12sNnsIdKqSieI47/XCdr4bBP 8wfuAC7UWYfLUkGV6vRH1+5kQVV8jVkCld1incK57loodISlm7eQxwwH3/WJNnQy1ijBsLAL4JxM wxzW/ONptUdGgS+igqvTY0RwxI3/LTO6rY97tXCIrj4Zz0Ao2PzIkLtdmSL1UuZYxR+IMUPuiB3X xo48Q2odpxjefT0W8WL5ypCo/TCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJKoZI hvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VS VHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMwMTIz MTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGln byBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkqKtLN nFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfbM3wc caNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+LbnTe ef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmHfpsE kzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMBAAGj ggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy/Ava lNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBHMEWg Q6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVzZXJ0 cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiMAN0X 13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vhNn9d NqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHitcPr 5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDpVRH9 9lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7T2ww C+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI9oKS ChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RIZllX 4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDonM8V/ 2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQz3lC NObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMIIGKzCCBROgAwIBAgIRAPuElTZ4 EhaY10ByhNJltnIwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTkwODI0MDAwMDAwWhcNMjIwODIzMjM1OTU5WjCCATcxCzAJBgNVBAYTAlVT MQ4wDAYDVQQREwU5NDA4OTELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTEcMBoGA1UE CRMTMTEzMyBJbm5vdmF0aW9uIFdheTEeMBwGA1UEChMVSnVuaXBlciBOZXR3b3JrcywgSW5jMR4w HAYDVQQLExVTb2Z0d2FyZSBFbmdpbmVlciBMYWIxOzA5BgNVBAsTMklzc3VlZCB0aHJvdWdoIEp1 bmlwZXIgTmV0d29ya3MsIEluYyBFLVBLSSBNYW5hZ2VyMR8wHQYDVQQLExZDb3Jwb3JhdGUgU2Vj dXJlIEVtYWlsMRUwEwYDVQQDEwxHdXkgRmVkb3Jrb3cxJDAiBgkqhkiG9w0BCQEWFWdmZWRvcmtv d0BqdW5pcGVyLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Fewgz3OFG1Go3 cuoLYIbLNRTSEFgN+GLUaqB6g5VuCf0UTvgARSlxgDmsvE5qwTtb8JOtJ64OylVNvz28uslsfvg4 WCc0InZUo1B6JkgNamxa3HI31h63s5wVm/wZgglg5Dv7WH7gmAPrgeoWpBC2GN1sxWHfcJOi2fzg M5LWst0Iwz4M7vqFsZ77AOkUFDNm5p19Fu8HRjVlsE0fNGieZB5GEiL2CN2YoxyOKrJdqWHNMkK8 Q5owvlDnSR0tb8oJgHDX8EESSo5TDA5zqnva48zFfFWCrOdobNgf1To4uBskX6B+QEmrSNLuSdpK JOHw9IdrPofgpjZCmFwvtS8CAwEAAaOCAc4wggHKMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZ Qs/J4K0AMB0GA1UdDgQWBBQPfL+xFDoZAlQisKraMq/Y34eQGjAOBgNVHQ8BAf8EBAMCBaAwDAYD VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1Bgwr BgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAg BgNVHREEGTAXgRVnZmVkb3Jrb3dAanVuaXBlci5uZXQwDQYJKoZIhvcNAQELBQADggEBALilLU71 sn7XVNFoUU4MqcHXXFiFiOjCQmq1nqijMa6L4fKm/VX9LZtrsQs3CZTUiHuW2pyLapLVIEXdubNX L877oIVJmeAoSWz1+AYelK6CIpuGUUcGSsXKd4Xl9yOTrmLb7PTjrRpXsWSHJi//jrXTrR/X6M+U TterfzhR5gYPFyvX65Zie9M7k7V2yB3YJJPzT8EtfrJc+eDzYAgiWK8X/ToMZOG7noa/Er8FEARn joL7pKHVOkHTOM9UNaublWlhiUEzzXx9kYPKjgqjAetRo4zh1KBFm9MBlXeigAVBx+BQpP0OdmHb 5vcX3pUR4lkRpnVeLKFR++q6z+bViYAxggRnMIIEYwIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAPuElTZ4EhaY10ByhNJltnIwCQYFKw4DAhoFAKCCAo8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODI1MTkxNjAzWjAjBgkq hkiG9w0BCQQxFgQUqCvzcwRScqEpcY5+cFgtmvsGrOUwga0GCSqGSIb3DQEJDzGBnzCBnDALBgkq hkiG9w0BAQcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCSqGSIb3DQEBCjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBvQYJKwYBBAGCNxAEMYGvMIGs MIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA+4SVNngSFpjXQHKE0mW2 cjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+ MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD7hJU2eBIWmNdAcoTSZbZyMA0GCSqGSIb3DQEBAQUABIIBAC50rJBOI/ER7Xhy993f rX6VnLaM33qrhPC1FF0WvTjpOrknQmC/gSLox7Ex0XTtpPhR/SszsnXv01MlR2MlaHAQevY6cMpy 5zpuKf5Rpvr5VNMgIgQqw7BTJgYBtV0zGBDJvbABEKvgX6Exm67VlQPY0HUVxN3NM/s/jPj4aLRJ sJAMuKiZjvx+RmWHARBZfE/QgT+6KcDV7+m8mkNbCpyapb9IgtE7Otvz35c442etNYziLIKaXqU/ NBB+v1ihMUtTlw31u9x1G3mdkEg2Fz1xuaCnoLLU9sqtc1NaAl/Si7wmagQmSCTZrsirIGyhCTo+ sXuTDB1dtGy0qemsEekAAAAAAAA= ------=_NextPart_000_00F5_01D67AF2.A5D23760-- From nobody Tue Aug 25 13:52:29 2020 Return-Path: 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 B4BD13A0BF1 for ; Tue, 25 Aug 2020 13:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 4PnI1vEIP1Hk for ; Tue, 25 Aug 2020 13:52:19 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2130.outbound.protection.outlook.com [40.107.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030533A0BAD for ; Tue, 25 Aug 2020 13:52:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lh5BrZLtwbMjgXUNZyM/cbALq9xJG9mFM4sltNpWubI/NCM6IJr3cuE0vvvenahktFBJxMqXDu44Y8O9VKG8cCoLlxWclCwFUMRpoEyb4x/uEc/YTECat5aMQ1Y2WjDaG5aEQRfrM2pppkAbX2Y27pUYZq58jjvNAVOJjOeHAg7cUQH+yzXcT4u5ObS/d6t3wTXx2mh/XpdGMcC2riY4oMB02dw6hxG80UzS7E7vm9+MfSnLIDxTqMkOtCW4iEHMSED2Yga+asc5HHvKllr/R4JfVsV0jnvJdPAS0pPp8hB539GTxS5p+LvIYoNKV7QaMK0b8DUUQhfJKEfcx4cPRg== 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=cRSluWxM0aCDRyo/8XHRtKiPMH8GJhY9yKWyzE0TQJg=; b=kPX9c5Rxp0y8ir7YpK/dtr+L0BJybZAsLtyOytBMQQI2x6bLn/1Cj7VGdf0s4q57uL/Ofr/oAoBoSpFm3bVF71fD2z2LFEbuFTDQ3deiJTO1VaS0dxEayB1XRm7sT85PrsWMdUaB2DiWOVu9aTiHUOM1wqTyOVmdXQB4fWPX4xzU/15ZYR27FJy/X8V6zaKVjOk2uSYYAz8wHDcogGZEiEKGE4F5qZfahBONFVvmT3z0Fzb9co6AdcGi7mfS/KgRSZQOKDDzlviBSQaJZpi7iee/QGwLh1HBaCVp8xhRhAk3ZcNJZ9bCToHffO3HeGRiFNib6T2Eq1go8EWK27Hlvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cRSluWxM0aCDRyo/8XHRtKiPMH8GJhY9yKWyzE0TQJg=; b=ACuVyWQYiwIoYF5lDpqpUujDYj+DFTZWfQF0qg2PVK2gKIvv1bTOl2IU+VYT+1S7P/MOqp+utvk4KSA60OD4B4yGF8J9iVsZXN1xlZzyqnRtqNv2XA/HlpFvktSEX8RwePi57//QZFFK4Q22Hy7dZ7PRac3HL9p5ml3H7UiTobg= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB0931.namprd21.prod.outlook.com (2603:10b6:207:30::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.5; Tue, 25 Aug 2020 20:52:15 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::38e4:fb96:4484:251c]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::38e4:fb96:4484:251c%9]) with mapi id 15.20.3326.019; Tue, 25 Aug 2020 20:52:15 +0000 From: Dave Thaler To: Guy Fedorkow , "rats@ietf.org" CC: "Jessica Fitzgerald-McKay (jmfmckay@gmail.com)" , "Eric Voit (evoit)" Thread-Topic: TPM background for RIV Thread-Index: AdZ7FCxmPJt+FRfUTmKTg8duYuoerAADV2Fg Date: Tue, 25 Aug 2020 20:52:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-25T19:16:03Z; 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=47b39a74-6a0b-4d3a-a050-9f0eb7851dce; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-25T20:52:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=c834a13c-8d4c-4750-9d29-267c3cb31afb; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:9780:16f0:f414:8582:a91e:5486] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 889bfc57-7399-464a-ffa4-08d84938bfd3 x-ms-traffictypediagnostic: BL0PR2101MB0931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lixTYCnbd+EN3hIaITzITHA1V4ibmzoN0Ya/Sft22uYUIv0/cnoenzFC6T0/9yVUMJH7nN3V6P5C1gFi8kD4CTxVf3LXv/pWkTDbrf8rBuwwwh4Fru8Xy5TwIREfjQTWVN1u8pBh0/biux9EziyQV9m4UDVoKAtEK+tjJ0DctHIxiNuDGtpkwSvzNEN7Z9KwLjaUkF7CaqFuvB8f51hv3nNm6s1oqFbV0XClXhZipXi1SnYIiHule5QEt9rSy+JCPBBFydNm8y2y7LGP/dlnu6kjMvXcEM1ZpIkrEW+OHFiJ+pt6KbJcIR3fp6SyKCjAXFb426jI5PTGgT6Qz/pdYA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(66556008)(10290500003)(82950400001)(8936002)(6506007)(71200400001)(52536014)(5660300002)(55016002)(53546011)(9686003)(8676002)(7696005)(478600001)(54906003)(64756008)(76116006)(66946007)(186003)(66446008)(33656002)(82960400001)(316002)(66476007)(86362001)(2906002)(83380400001)(110136005)(8990500004)(4326008)(3480700007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NFl1iJ8TDeZkkFPIO4XhMs7riiSpjPXVX1G8n0x/ki6uqZh/+yxVu6oUrz5Y9GayFr270Pr2kzDybR1b53mhBunqqNgitXcwBHawRGCz0pdDKPg3zyZkKK5GIiRhtazNPttOK/sfWq3YvpfAFmhpyNFVjnVVKnTP6DQxuBB5Zl896PyV3z0FEFBHPw/mPBkq5f/rxpUnUnnXywh270z6FtcMp3+yhoff5qt9y4WiQUHJ7FsmLZ6puNOf6esTR4QxNStaTYHtOWDIEO+QhQdj18PKqkE+o57M4g2K6YLkaBjN/KUFxMREDA74ZGMdpM8+rDyvEsSOe+GBq3urv7Jhsx1qTBAQYi+OHVU7Q2iLfb+vwKMu8sCUp7nvACCXYd0pjQa3yNJgPJrECdRUgBsBGiHJXUefKfJMwO6NRX1g1aIIgPMzR/fqKBPkNQ4KJUKp8RdzZWeCEtkcKZAxJueTOHXeOvAq9rriSyEV0ZYhWPrkJWG7G7eqyX7fzBIaJ+bluU3avYUPLAmfXrHk85la/UYUVGHZA9UxnSEZPmbe/3+CUsikGOOlgOh0i1MeT7pXkix5HwOqQ/6+Qbz6grkGL5srUoT3VOHgptGKb4KJnjiOv560V9M5Dhx/kunyP0ZToSDJ3z1nfnc+qEUKSkYA1KHF6E0jvdM6KafwnMb5Iq2NUI8HyYaiQvfb9yM3GL3hTimvbp4MjCbzCzc0R+V7/Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027C26AA6CA901A4CAE5F43A3570BL0PR2101MB1027_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 889bfc57-7399-464a-ffa4-08d84938bfd3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2020 20:52:15.6824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LXVWEnhPo9xzZf9CIv9YoVtwTAKSXJnYe2XmbZsBqVXY8hrJ9ru7t6xUIWUl8FoT0+6qwMxwQ95cIlmVd4rgbnaa4X1zG01+3rkBNtuiERQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0931 Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 20:52:27 -0000 --_000_BL0PR2101MB1027C26AA6CA901A4CAE5F43A3570BL0PR2101MB1027_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That looks like a great improvement to me. Dave From: RATS On Behalf Of Guy Fedorkow Sent: Tuesday, August 25, 2020 12:16 PM To: rats@ietf.org Cc: Jessica Fitzgerald-McKay (jmfmckay@gmail.com) ; Eri= c Voit (evoit) Subject: [Rats] TPM background for RIV A recent reviewer of the RIV document (that would be a RIViewer) pointed ou= t that the doc assumes that the fundamental behavior of a TPM for attestati= on is already well known by the reader. Of course that may not be the case= . Rather than add more tutorial material to be body of the document, I'd li= ke to suggest adding the following subsection to the existing appendices, w= ith cross references in a couple places in the doc. Let me know if this looks like it would be helpful to new readers. Thanks /guy *Appendix **Using a TPM for Attestation The Trusted Platform Module and surrounding ecosystem provide three inter= locking capabilities to enable secure collection of evidence from a remote = device, Platform Configuration Registers (PCRs), a Quote mechanism, and a s= tandardized Event Log. Each TPM has at least sixteen PCRs, each one large enough to hold one has= h value (SHA-1, SHA-256, and other algorithms can be used for this hashing = depending on TPM version). PCRs can't be accessed directly from outside th= e chip, but the TPM interface provides a way to "extend" a new security mea= surement hash into any PCR, a process by which the existing value in the PC= R is hashed with the new security measurement hash, and the result placed b= ack into the same PCR. The result is a composite fingerprint of all the se= curity measurements extended into each PCR since the system was reset. Every time a PCR is extended, an entry should be added to the correspondi= ng Event Log. Logs contain the security measurement hash plus informative = fields offering hints as to what event it was that generated the security m= easurement. The Event Log itself is protected against accidental manipulat= ion, but it is implicitly tamper-evident - any verification process can rea= d the security measurement hash from the log events, compute the composite = value and compare that to what ended up in the PCR. If there's a discrepa= ncy, the logs do not provide an accurate view of what was placed into the P= CR. The TPM provides another mechanism called a Quote that can read the curre= nt value of the PCRs and package them into a data structure signed by an At= testation Key (which is private key that is known only to the TPM). The Verifier uses the Quote and Log together. The Quote, containing the co= mposite hash of the complete sequence of security measurement hashes, is us= ed to verify the integrity of the Event Log. Each hash in the validated Qu= ote can then be compared to corresponding expected values in the set of Ref= erence Integrity Measurements to validate overall system integrity. Information about PCRs and Quotes can be found in {{TPM1.2}} and {{TPM2.0= }}. Although there are several log formats, an example can be found in {{X= X}} Juniper Business Use Only --_000_BL0PR2101MB1027C26AA6CA901A4CAE5F43A3570BL0PR2101MB1027_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That looks like a grea= t improvement to me.

 

Dave=

 

From: RATS <rats-bounces@ietf.org> O= n Behalf Of Guy Fedorkow
Sent: Tuesday, August 25, 2020 12:16 PM
To: rats@ietf.org
Cc: Jessica Fitzgerald-McKay (jmfmckay@gmail.com) <jmfmckay@gmail= .com>; Eric Voit (evoit) <evoit@cisco.com>
Subject: [Rats] TPM background for RIV

 

A recent reviewer of the RIV document (that would be= a RIViewer) pointed out that the doc assumes that the fundamental behavior= of a TPM for attestation is already well known by the reader.  Of cou= rse that may not be the case.

  Rather than add more tutorial material to be = body of the document, I’d like to suggest adding the following subsec= tion to the existing appendices, with cross references in a couple places i= n the doc.

  Let me know if this looks like it would be he= lpful to new readers.

  Thanks

/guy

 

 

 

*Appendix

 

**Using a TPM for Attestation

 

  The Trusted Platform Module and surrounding e= cosystem provide three interlocking capabilities to enable secure collectio= n of evidence from a remote device, Platform Configuration Registers (PCRs)= , a Quote mechanism, and a standardized Event Log.

 

  Each TPM has at least sixteen PCRs, each one = large enough to hold one hash value (SHA-1, SHA-256, and other algorithms c= an be used for this hashing depending on TPM version).  PCRs can’= ;t be accessed directly from outside the chip, but the TPM interface provides a way to “extend” a new security me= asurement hash into any PCR, a process by which the existing value in the P= CR is hashed with the new security measurement hash, and the result placed = back into the same PCR.  The result is a composite fingerprint of all the security measurements extended into each PCR since = the system was reset.

 

  Every time a PCR is extended, an entry should= be added to the corresponding Event Log.  Logs contain the security m= easurement hash plus informative fields offering hints as to what event it = was that generated the security measurement.  The Event Log itself is protected against accidental manipulation, but it = is implicitly tamper-evident – any verification process can read the = security measurement hash from the log events, compute the composite value = and compare that to what ended up in the PCR.   If there’s a discrepancy, the logs do not provide a= n accurate view of what was placed into the PCR.

 

  The TPM provides another mechanism called a Q= uote that can read the current value of the PCRs and package them into a da= ta structure signed by an Attestation Key (which is private key that is kno= wn only to the TPM).

 

The Verifier uses the Quote and Log together.  = The Quote, containing the composite hash of the complete sequence of securi= ty measurement hashes, is used to verify the integrity of the Event Log.&nb= sp; Each hash in the validated Quote can then be compared to corresponding expected values in the set of Reference Integ= rity Measurements to validate overall system integrity.

 

  Information about PCRs and Quotes can be foun= d in {{TPM1.2}} and {{TPM2.0}}.  Although there are several log format= s, an example can be found in {{XX}}

 

 

Juniper Business Use Only

--_000_BL0PR2101MB1027C26AA6CA901A4CAE5F43A3570BL0PR2101MB1027_-- From nobody Tue Aug 25 14:01:28 2020 Return-Path: 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 33F253A0BE0 for ; Tue, 25 Aug 2020 14:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 leobNF9T2NBr for ; Tue, 25 Aug 2020 14:01:24 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D943A0BDF for ; Tue, 25 Aug 2020 14:01:24 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id d11so18164521ejt.13 for ; Tue, 25 Aug 2020 14:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UQBRRhAnKhQh6XncAkArQrB2K29meIbArT0QKLc/oe0=; b=chVMj6JIyKBfqideEE2iLAnV4OTiTbbvPjXq2W+KzFPNYTuwFBZJ0ZxA/CfInqRj+s dIVMgyjWJIk4WfdJJ38h2vnnGuJuXx9lG6uAwQdWMXDR9l2NCU9eiaSaEtv9z7Ybmgqa TYBUDhObGXXhfIP6S1TnwszISnK2ekek9T2jeU8XS/1zOp1gWMnnZGgfg206hPkCePc0 FzifvBF4ntsaWD+l/DCmF+KFhN23Cjs8h7kA282knIHMzj45x9/WYSlLpwKM+4c8rdze MUWVmLYSY/xV4G31KmktPKRTb81x486oeKFWUfyEbY3LW718ZryxzvZnEXwtBZmrGFoP k2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UQBRRhAnKhQh6XncAkArQrB2K29meIbArT0QKLc/oe0=; b=c4xDz+2BgpaZA8QSxgVp6b4zS7kFN8w1O7aP4dJ31bTMIbdH91RjSUyywd6K+7o88n Swqv3m1BKVWqmc7GQutn5BFwfGts+DI7fgqCCn/zQF40VEwNNlX4RLHOIvRpeH0fDWea qUs1Ux2fLOBDzcwH2st9QFW8ZgjAjkUh7sgHc9lbH8R10kIzV+xYpOSrN31TeE0JJ1k/ LbdnlK/SN0+g/WHHJ2VKTJnQ04rpC/PkEYNCeB8jdJTq1qyfra20Knb0ZQtmaHDJNFVG kKCXDstHM5Lbs0+RGZgdeg3nPkZANTx+jMGQ0UQ3Mf6MFcCiX7BRHE6B+qQpdQOktGfi ORuA== X-Gm-Message-State: AOAM530tY+DRQj8PWMi0KEwqgGvUqKdrssfw5r+aG4zsdAPgv1CgTVbB p3AAFaoIs4sreI/u/Q+aSMmw9F2XtSQ7n/kUocI= X-Google-Smtp-Source: ABdhPJy/fHO75tNPmSsYBFgBA645OLrzdk2ob/n02ExrEP6gS2YlgNrTuzhI/u7JPxJrAIhgu2ZaWDxtGrC1gyVBMMc= X-Received: by 2002:a17:906:1a07:: with SMTP id i7mr8047649ejf.122.1598389282679; Tue, 25 Aug 2020 14:01:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Tue, 25 Aug 2020 17:00:46 -0400 Message-ID: To: Dave Thaler Cc: Guy Fedorkow , "rats@ietf.org" , "Jessica Fitzgerald-McKay (jmfmckay@gmail.com)" , "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary="0000000000006832a905adba01c9" Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 21:01:26 -0000 --0000000000006832a905adba01c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To me as well. Which reference can I use to look at the formats for TPM attestations? Thanks, Kathleen On Tue, Aug 25, 2020 at 4:53 PM Dave Thaler wrote: > That looks like a great improvement to me. > > > > Dave > > > > *From:* RATS *On Behalf Of * Guy Fedorkow > *Sent:* Tuesday, August 25, 2020 12:16 PM > *To:* rats@ietf.org > *Cc:* Jessica Fitzgerald-McKay (jmfmckay@gmail.com) = ; > Eric Voit (evoit) > *Subject:* [Rats] TPM background for RIV > > > > A recent reviewer of the RIV document (that would be a RIViewer) pointed > out that the doc assumes that the fundamental behavior of a TPM for > attestation is already well known by the reader. Of course that may not = be > the case. > > Rather than add more tutorial material to be body of the document, I=E2= =80=99d > like to suggest adding the following subsection to the existing appendice= s, > with cross references in a couple places in the doc. > > Let me know if this looks like it would be helpful to new readers. > > Thanks > > /guy > > > > > > > > *Appendix > > > > **Using a TPM for Attestation > > > > The Trusted Platform Module and surrounding ecosystem provide three > interlocking capabilities to enable secure collection of evidence from a > remote device, Platform Configuration Registers (PCRs), a Quote mechanism= , > and a standardized Event Log. > > > > Each TPM has at least sixteen PCRs, each one large enough to hold one > hash value (SHA-1, SHA-256, and other algorithms can be used for this > hashing depending on TPM version). PCRs can=E2=80=99t be accessed direct= ly from > outside the chip, but the TPM interface provides a way to =E2=80=9Cextend= =E2=80=9D a new > security measurement hash into any PCR, a process by which the existing > value in the PCR is hashed with the new security measurement hash, and th= e > result placed back into the same PCR. The result is a composite > fingerprint of all the security measurements extended into each PCR since > the system was reset. > > > > Every time a PCR is extended, an entry should be added to the > corresponding Event Log. Logs contain the security measurement hash plus > informative fields offering hints as to what event it was that generated > the security measurement. The Event Log itself is protected against > accidental manipulation, but it is implicitly tamper-evident =E2=80=93 an= y > verification process can read the security measurement hash from the log > events, compute the composite value and compare that to what ended up in > the PCR. If there=E2=80=99s a discrepancy, the logs do not provide an a= ccurate > view of what was placed into the PCR. > > > > The TPM provides another mechanism called a Quote that can read the > current value of the PCRs and package them into a data structure signed b= y > an Attestation Key (which is private key that is known only to the TPM). > > > > The Verifier uses the Quote and Log together. The Quote, containing the > composite hash of the complete sequence of security measurement hashes, i= s > used to verify the integrity of the Event Log. Each hash in the validate= d > Quote can then be compared to corresponding expected values in the set of > Reference Integrity Measurements to validate overall system integrity. > > > > Information about PCRs and Quotes can be found in {{TPM1.2}} and > {{TPM2.0}}. Although there are several log formats, an example can be > found in {{XX}} > > > > > > Juniper Business Use Only > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --=20 Best regards, Kathleen --0000000000006832a905adba01c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To me as well.=C2=A0 Which reference can I use to look at = the formats for TPM attestations?

Thanks,
Kath= leen

On Tue, Aug 25, 2020 at 4:53 PM Dave Thaler <dthaler=3D40microsoft.com@dmarc.ietf.org> wrote:

That looks like= a great improvement to me.

=C2=A0

Dave<= /u>

=C2=A0

From: RATS <rats-bounces@ietf.org> On Behalf Of = Guy Fedorkow
Sent: Tuesday, August 25, 2020 12:16 PM
To: rats@ietf.org=
Cc: Jessica Fitzgerald-McKay (jmfmckay@gmail.com) <jmfmckay@gmail..com>; Eric= Voit (evoit) <evoi= t@cisco.com>
Subject: [Rats] TPM background for RIV

=C2=A0

A recent reviewer of the RIV document (that would be= a RIViewer) pointed out that the doc assumes that the fundamental behavior= of a TPM for attestation is already well known by the reader.=C2=A0 Of cou= rse that may not be the case.

=C2=A0 Rather than add more tutorial material to be = body of the document, I=E2=80=99d like to suggest adding the following subs= ection to the existing appendices, with cross references in a couple places= in the doc.

=C2=A0 Let me know if this looks like it would be he= lpful to new readers.

=C2=A0 Thanks

/guy

=C2=A0

=C2=A0

=C2=A0

*Appendix

=C2=A0

**Using a TPM for Attestation

=C2=A0

=C2=A0 The Trusted Platform Module and surrounding e= cosystem provide three interlocking capabilities to enable secure collectio= n of evidence from a remote device, Platform Configuration Registers (PCRs)= , a Quote mechanism, and a standardized Event Log.

=C2=A0

=C2=A0 Each TPM has at least sixteen PCRs, each one = large enough to hold one hash value (SHA-1, SHA-256, and other algorithms c= an be used for this hashing depending on TPM version).=C2=A0 PCRs can=E2=80= =99t be accessed directly from outside the chip, but the TPM interface provides a way to =E2=80=9Cextend=E2=80=9D a new securit= y measurement hash into any PCR, a process by which the existing value in t= he PCR is hashed with the new security measurement hash, and the result pla= ced back into the same PCR.=C2=A0 The result is a composite fingerprint of all the security measurements extended into each PCR since = the system was reset.

=C2=A0

=C2=A0 Every time a PCR is extended, an entry should= be added to the corresponding Event Log.=C2=A0 Logs contain the security m= easurement hash plus informative fields offering hints as to what event it = was that generated the security measurement.=C2=A0 The Event Log itself is protected against accidental manipulation, but it = is implicitly tamper-evident =E2=80=93 any verification process can read th= e security measurement hash from the log events, compute the composite valu= e and compare that to what ended up in the PCR.=C2=A0=C2=A0 If there=E2=80=99s a discrepancy, the logs do not provide= an accurate view of what was placed into the PCR.

=C2=A0

=C2=A0 The TPM provides another mechanism called a Q= uote that can read the current value of the PCRs and package them into a da= ta structure signed by an Attestation Key (which is private key that is kno= wn only to the TPM).

=C2=A0

The Verifier uses the Quote and Log together.=C2=A0 = The Quote, containing the composite hash of the complete sequence of securi= ty measurement hashes, is used to verify the integrity of the Event Log.=C2= =A0 Each hash in the validated Quote can then be compared to corresponding expected values in the set of Reference Integ= rity Measurements to validate overall system integrity.

=C2=A0

=C2=A0 Information about PCRs and Quotes can be foun= d in {{TPM1.2}} and {{TPM2.0}}.=C2=A0 Although there are several log format= s, an example can be found in {{XX}}

=C2=A0

=C2=A0

Ju= niper Business Use Only

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats


--

Best regards,
Kathleen
--0000000000006832a905adba01c9-- From nobody Tue Aug 25 14:04:29 2020 Return-Path: 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 D8EBA3A0BE7 for ; Tue, 25 Aug 2020 14:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IEHjI-1gyLpO for ; Tue, 25 Aug 2020 14:04:26 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF73B3A0BE0 for ; Tue, 25 Aug 2020 14:04:25 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id u131so137583vsu.11 for ; Tue, 25 Aug 2020 14:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zYnpvehfrc1pbFm2lZWfKRd5Or8MFVH0ei1CZfFUEzc=; b=L1OTfdjTTR52Vp8rpSjlSbX7ugbDoZZ6k46Qkz8y+jsJ1kF+6Yxi9cvBhbbftr1U+n tRVN0R3JH3nhXejKDgL4Cq/8dKevzIyMIWs17RUCO09RerysHAff0p4JFQKTFfHDzmHG IpDmfhkIY5FfM+LEGpV4Wrms/jFwGMLNFRWqL1c+Oo2kEBT3i4mQbYCgE1wnIFIRHatr z3IpJDsCdi8R3Qi3O5OOyjP9pSYLaPrkiFUm+DJ7QZr/t+fdra8/QKU4E2yQQ2cIR+G7 vIv1O5R+INqMVx3ox9kiwd4uKlkj7DRRHmeJ4hYRnFGfeg2TzUodGcdrXmngQ80l86wH GKzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zYnpvehfrc1pbFm2lZWfKRd5Or8MFVH0ei1CZfFUEzc=; b=mvBFX3qVqU857UaU+e8ed7jNlxocp3nVf+Wy42Bfraa4ssoSGXLFRejOC+Zc/ygXUd ZMSzrxSoI7NHb+HNb5+nVVFVGEgTYP8Ced+reM0R/UjTynzqo+DUbQZJ5BiBu+HDsQa3 g59ToUhrzKrQ8eiM/SxMX8zxiDddnV+zWPZbHhr2jffnXN4kmrYg7jCJyRHOpv4Lc/yN XVH+s/0KCMQHOXWPUHRX858xmU/1v1MrnhxrgYO6xiiW2ZwTm96UwvrlYTlGFZuA0vQM Y5C2kCY9PIdVvwZ36HOputX46h25hmz6k/C/vjyb/hvi4UMGI8idlcQ3Id2zlZ1pqfp2 TGzw== X-Gm-Message-State: AOAM531+R85Cc5q32XWSQMgdetpvYaasQdRvlyxiRyVNheNBPdtZs+nx 4IpDDC6qdiH5CHipYbfTTySlnRxwpIcyaa5iCw8= X-Google-Smtp-Source: ABdhPJxOpYHgCW0pk1KmZ0hyDvR+ww+gvVMDFUPgbVHWRv1EWdUZdpardcJViRsw1if3N4lL0c5ee2vQNhR8RM8z584= X-Received: by 2002:a67:ea56:: with SMTP id r22mr6941667vso.29.1598389464959; Tue, 25 Aug 2020 14:04:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ira McDonald Date: Tue, 25 Aug 2020 17:04:07 -0400 Message-ID: To: Guy Fedorkow , Ira McDonald Cc: "rats@ietf.org" , "Jessica Fitzgerald-McKay (jmfmckay@gmail.com)" , "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary="000000000000458de505adba0c21" Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 21:04:29 -0000 --000000000000458de505adba0c21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Guy, Thanks for this excellent proposed text. Small note: Although you say each TPM has at least 16 PCRs, in fact the TPM 2.0 Mobile Common Profile (2015) only requires the implementation of one SHA-256 bank of 8 PCRs (a SHA-1 bank is prohibited here). That design choice was made to avoid the squabbles over the inconsistent usage of PCR8 through PCR15 across various TPM 2.0 profiles. Cheers, - Ira (editor of TPM 2.0 Mobile Common Profile) *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/hi= ghnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Tue, Aug 25, 2020 at 3:16 PM Guy Fedorkow wrote: > A recent reviewer of the RIV document (that would be a RIViewer) pointed > out that the doc assumes that the fundamental behavior of a TPM for > attestation is already well known by the reader. Of course that may not = be > the case. > > Rather than add more tutorial material to be body of the document, I=E2= =80=99d > like to suggest adding the following subsection to the existing appendice= s, > with cross references in a couple places in the doc. > > Let me know if this looks like it would be helpful to new readers. > > Thanks > > /guy > > > > > > > > *Appendix > > > > **Using a TPM for Attestation > > > > The Trusted Platform Module and surrounding ecosystem provide three > interlocking capabilities to enable secure collection of evidence from a > remote device, Platform Configuration Registers (PCRs), a Quote mechanism= , > and a standardized Event Log. > > > > Each TPM has at least sixteen PCRs, each one large enough to hold one > hash value (SHA-1, SHA-256, and other algorithms can be used for this > hashing depending on TPM version). PCRs can=E2=80=99t be accessed direct= ly from > outside the chip, but the TPM interface provides a way to =E2=80=9Cextend= =E2=80=9D a new > security measurement hash into any PCR, a process by which the existing > value in the PCR is hashed with the new security measurement hash, and th= e > result placed back into the same PCR. The result is a composite > fingerprint of all the security measurements extended into each PCR since > the system was reset. > > > > Every time a PCR is extended, an entry should be added to the > corresponding Event Log. Logs contain the security measurement hash plus > informative fields offering hints as to what event it was that generated > the security measurement. The Event Log itself is protected against > accidental manipulation, but it is implicitly tamper-evident =E2=80=93 an= y > verification process can read the security measurement hash from the log > events, compute the composite value and compare that to what ended up in > the PCR. If there=E2=80=99s a discrepancy, the logs do not provide an a= ccurate > view of what was placed into the PCR. > > > > The TPM provides another mechanism called a Quote that can read the > current value of the PCRs and package them into a data structure signed b= y > an Attestation Key (which is private key that is known only to the TPM). > > > > The Verifier uses the Quote and Log together. The Quote, containing the > composite hash of the complete sequence of security measurement hashes, i= s > used to verify the integrity of the Event Log. Each hash in the validate= d > Quote can then be compared to corresponding expected values in the set of > Reference Integrity Measurements to validate overall system integrity. > > > > Information about PCRs and Quotes can be found in {{TPM1.2}} and > {{TPM2.0}}. Although there are several log formats, an example can be > found in {{XX}} > > > > Juniper Business Use Only > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --000000000000458de505adba0c21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Guy,

Thanks for this exce= llent proposed text.

Small note:=C2=A0 Although yo= u say each TPM has at least 16 PCRs, in fact the TPM 2.0 Mobile Common Prof= ile
(2015) only requires the implementation of one SHA-256 bank o= f 8 PCRs (a SHA-1 bank is prohibited here).=C2=A0
That desig= n choice was made to avoid the squabbles over the inconsistent usage of PCR= 8 through PCR15
across various TPM 2.0 profiles.
<= br>
Cheers,
- Ira (editor of=20 TPM 2.0 Mobile Common Profile)

=
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG T= rusted Mobility Solutions WG
Co-Ch= air - TCG Metadata Access Protocol SG
= Chair - Linux Foundation Open Printing WG
Secretary = - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Prin= ting Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue = Roof Music / High North Inc
http://sites.go= ogle.com/site/blueroofmusic
http://sit= es.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent)= PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Tue, Aug 25, 2020 at 3:16 PM= Guy Fedorkow <gfedorkow=3D40juniper.net@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= p class=3D"MsoNormal">A recent reviewer of the RIV document (that would be = a RIViewer) pointed out that the doc assumes that the fundamental behavior = of a TPM for attestation is already well known by the reader.=C2=A0 Of cour= se that may not be the case.

=C2=A0= Rather than add more tutorial material to be body of the document, I=E2=80= =99d like to suggest adding the following subsection to the existing append= ices, with cross references in a couple places in the doc.

=C2=A0 Let me know if this looks like it would be h= elpful to new readers.

=C2=A0 Thank= s

/guy

=C2=A0

=C2=A0

=C2=A0

*Appendix

=C2=A0<= /p>

**Using a TPM for Attestation

=C2=A0

=C2=A0 = The Trusted Platform Module and surrounding ecosystem provide three interlo= cking capabilities to enable secure collection of evidence from a remote de= vice, Platform Configuration Registers (PCRs), a Quote mechanism, and a sta= ndardized Event Log.

=C2=A0<= u>

=C2=A0 Each TPM has at least sixteen PCRs,= each one large enough to hold one hash value (SHA-1, SHA-256, and other al= gorithms can be used for this hashing depending on TPM version).=C2=A0 PCRs= can=E2=80=99t be accessed directly from outside the chip, but the TPM inte= rface provides a way to =E2=80=9Cextend=E2=80=9D a new security measurement= hash into any PCR, a process by which the existing value in the PCR is has= hed with the new security measurement hash, and the result placed back into= the same PCR.=C2=A0 The result is a composite fingerprint of all the secur= ity measurements extended into each PCR since the system was reset.<= u>

=C2=A0

=C2=A0 Every time a PCR is extended, an entry should be added to the c= orresponding Event Log.=C2=A0 Logs contain the security measurement hash pl= us informative fields offering hints as to what event it was that generated= the security measurement.=C2=A0 The Event Log itself is protected against = accidental manipulation, but it is implicitly tamper-evident =E2=80=93 any = verification process can read the security measurement hash from the log ev= ents, compute the composite value and compare that to what ended up in the = PCR.=C2=A0=C2=A0 If there=E2=80=99s a discrepancy, the logs do not provide = an accurate view of what was placed into the PCR.

=C2=A0

=C2=A0 The TP= M provides another mechanism called a Quote that can read the current value= of the PCRs and package them into a data structure signed by an Attestatio= n Key (which is private key that is known only to the TPM).

=C2=A0

The= Verifier uses the Quote and Log together.=C2=A0 The Quote, containing the = composite hash of the complete sequence of security measurement hashes, is = used to verify the integrity of the Event Log.=C2=A0 Each hash in the valid= ated Quote can then be compared to corresponding expected values in the set= of Reference Integrity Measurements to validate overall system integrity.<= u>

=C2=A0

=C2=A0 Information about PCRs and Quotes can be found in {{TPM1= .2}} and {{TPM2.0}}.=C2=A0 Although there are several log formats, an examp= le can be found in {{XX}}

= =C2=A0


Juniper Business Us= e Only

______________________________________________= _
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--000000000000458de505adba0c21-- From nobody Tue Aug 25 15:29:38 2020 Return-Path: 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 F3E3A3A08CC for ; Tue, 25 Aug 2020 15:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RECCWaj9ONOY for ; Tue, 25 Aug 2020 15:29:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F31B3A0819 for ; Tue, 25 Aug 2020 15:29:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BE03F389A0; Tue, 25 Aug 2020 18:08:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6bfsYkoTk6sQ; Tue, 25 Aug 2020 18:08:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BC073899E; Tue, 25 Aug 2020 18:08:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 973D4478; Tue, 25 Aug 2020 18:29:25 -0400 (EDT) From: Michael Richardson To: Ira McDonald , "rats@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 25 Aug 2020 18:29:25 -0400 Message-ID: <19865.1598394565@localhost> Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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: Tue, 25 Aug 2020 22:29:36 -0000 Ira McDonald wrote: > Small note: Although you say each TPM has at least 16 PCRs, in fact the > TPM 2.0 Mobile Common Profile > (2015) only requires the implementation of one SHA-256 bank of 8 PCRs (a > SHA-1 bank is prohibited here). > That design choice was made to avoid the squabbles over the inconsistent > usage of PCR8 through PCR15 > across various TPM 2.0 profiles. I just want to understand. TPM 2 mobile, only requires PCR0-7. It doesn't forbid PCR8->15 though? Do devices tend to implement them all? Or? So what do the profiles do now? What is the impact on RIV? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Aug 25 18:37:13 2020 Return-Path: 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 003023A0B76 for ; Tue, 25 Aug 2020 18:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: 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=unavailable autolearn_force=no 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 skL0DamLxjJz for ; Tue, 25 Aug 2020 18:37:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75AD3A0B79 for ; Tue, 25 Aug 2020 18:37:09 -0700 (PDT) Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6AA30E81594D582F0933 for ; Wed, 26 Aug 2020 02:37:08 +0100 (IST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 02:37:07 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 09:37:05 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 26 Aug 2020 09:37:05 +0800 From: "Panwei (William)" To: "Eric Voit (evoit)" CC: "rats@ietf.org" Thread-Topic: Which Asymmetric algorithms for Charra? Thread-Index: AdZwFfR0sMtRnzzORw2twimiOLxijgAX+PawABmh0rACmwjsIA== Date: Wed, 26 Aug 2020 01:37:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.120.6] Content-Type: multipart/alternative; boundary="_000_c166a285dbc647e59599076cc42dc7bchuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Which Asymmetric algorithms for Charra? X-BeenThere: rats@ietf.org 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, 26 Aug 2020 01:37:12 -0000 --_000_c166a285dbc647e59599076cc42dc7bchuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Got it. Now I have no questions. Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Thursday, August 13, 2020 3:20 AM To: Panwei (William) Cc: rats@ietf.org Subject: Re: [Rats] Which Asymmetric algorithms for Charra? Hi Wei Pan, I don't think we need to define a key length for RSA. * None of our RPCs are involved with generating a new key. And we can = always discover the length of the key by referencing the information from t= he keystore using known information (e.g., the certificate-name). * Looking at the various SHA algorithms, they are actually different al= gorithms (since they produce different digest sizes). * If we just match to what is in the TCG spec, we don't have to define/= defend a different scoping than they have already made. Thanks, Eric From: RATS > On Behalf = Of Panwei (William) Sent: Wednesday, August 12, 2020 3:59 AM To: Eric Voit (evoit) > Cc: rats@ietf.org Subject: Re: [Rats] Which Asymmetric algorithms for Charra? 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 na= med with key length as a suffix, it also defines the ID values for the diff= erent curves used for elliptic curve cryptography. But it seems like that t= he TCG_Algorithm_Registry_r1p32_pub doesn't specify the key length of the R= SA algorithm. So do we need to define fine-granular RSA algorithms in the Y= ANG module? Regards & Thanks! Wei Pan From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, August 12, 2020 6:52 AM To: rats@ietf.org Subject: [Rats] Which Asymmetric algorithms for Charra? During the charra presentation at IETF 108, we said we were going to ask th= e following question to the list: "Should the algorithm set defined in YANG= be reduced to just those asymmetric algorithms currently exposed in the cu= rrent TPM 1.2 and 2 specifications?" This is reflected seen in https://www.ietf.org/proceedings/108/slides/slide= s-108-rats-sessb-charra-update-00, Slide 7. The proposal I would like to make is as follows: * The TCG tracked algorithms supportable by a TPM should be the only on= es 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 https://trustedcomp= utinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf con= tains the algorithms we should encode. * There are other types of information within this table, and we mig= ht as well encode the full table within a YANG model. That way we can exp= licitly make the scope of a "ietf-tcg-algs.yang" model the contents this TC= G table encoded in YANG. * The YANG model will indicate what TCG algorithms are deprecated by th= e IETF. However identities for these deprecated algorithms from the TCG ta= ble will be assigned. (e.g., SHA-1) Are there any objections/questions/comments on this proposal? I have a s= trawman YANG file posted at: https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit= :patch-4 Henk also is thinking of encoding this same Table information within CDDL. = That could be inserted as an additional informational element of the docum= ent for where people prefer CDDL. Eric Eric Voit Principal Engineer .:|:.:|:. Cisco Systems, Inc. --_000_c166a285dbc647e59599076cc42dc7bchuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Got it. Now I have no questions.

 

Regards & T= hanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Thursday, August 13, 2020 3:20 AM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats@ietf.org
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?

 

Hi Wei Pan,

 

I don't think we need to define= a key length for RSA. 

  • None of our RPCs are involved with generating a new key.  And we c= an always discover the length of the key by referencing the information fro= m the keystore using known information (e.g., the certificate-name).
  • Looking at the various S= HA algorithms, they are actually different algorithms (since they produce d= ifferent digest sizes).
  • If we just match to what = is in the TCG spec, we don't have to define/defend a different scoping than= they have already made.

 

Thanks,

Eric

 

From: RATS <rats-bounces@= ietf.org> On Behalf Of Panwei (William)
Sent: Wednesday, August 12, 2020 3:59 AM
To: Eric Voit (evoit) <evoit@c= isco.com>
Cc: rats@ietf.org
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?

 

Hi Eric,

 

Generally, I’m fine with your propos= al. I have only one question below.

 

The TCG_Algorithm_Registry_r1p32_pub defin= es a variety of SHA algorithms named with key length as a suffix, it also d= efines 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 algorith= m. So do we need to define fine-granular RSA algorithms in the YANG module?=

 

Regards & T= hanks!

Wei Pan

 

From: RATS [mailto:rats-boun= ces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
To: rats@ietf.org
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 lis= t: "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 https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-up= date-00, Slide 7.

 

The proposal I would like to ma= ke 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.
    • 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 ca= n explicitly make the scope of a "ietf-tcg-algs.yang" model the contents this TCG table encoded in YANG.
      • <= /ul>
    • 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/questi= ons/comments on this proposal?    I have a strawman YANG fil= e posted at:

    https://= github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:patch-4=

     

    Henk also is thinking of encodi= ng this same Table information within CDDL.  That could be inserted as= an additional informational element of the document for where people prefe= r CDDL.

     

    Eric

     

    Eric Voit

    Princ= ipal Engineer

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

     

--_000_c166a285dbc647e59599076cc42dc7bchuaweicom_-- From nobody Tue Aug 25 22:07:18 2020 Return-Path: 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 CFA4B3A0CF6 for ; Tue, 25 Aug 2020 22:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YzaOQ3p4X6fF for ; Tue, 25 Aug 2020 22:07:15 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303593A0CF8 for ; Tue, 25 Aug 2020 22:07:15 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id i20so144179vkk.2 for ; Tue, 25 Aug 2020 22:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OM/hMybzevwYWeh8jnb4WC0Z0hXtQc+os5tFf0lFybI=; b=Lc3e8xM9ORta64cNdZG5hJKf7ouUSXk31Zlue8OkTv4eVgBKShojHYfe99UOAM/y0o 05MWuehT9ME3dqcu2//WVPRHUjSZmHQg8v2R7ydpN2jxPxOKmAjd9V0/ZpxbOz+IDs0Y /zdgeYAp5hsejoZhLajr8yGok7ixYd2QA8vF5G/CTHayIHEijd9QZWzKN/cyp/YEpELd OPRQykEwk5DPcMICU8S8DmsL9Ye2RPcWAXbbyuDIHOv+5w+lsf2HMzTRgb8agqTgkgN7 fHx+ez9MMFIrU0EgwjGMakpCIWUkByQqmNHf4pU/DO5eTQ3odnH9jvlMEXbo6P8ApMTt qTfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OM/hMybzevwYWeh8jnb4WC0Z0hXtQc+os5tFf0lFybI=; b=KX5nwOrtEb7g2NMYjoJbJYi8hLf7Y9BDoB5pVBuLwFtyrbK9PbLovBfNeu7R6564eu ASp6w2xzAj5hYUE+v3GQI6QblM8BF7MpsWg9nqUb7i525UIHQmOuNWFjIZsiilIdEMPq jCp0lVbeMA/TWy0da0uMMnUthphkv4p9dTrvFfiRvu3jEhlBOUj+voA/a1n8i4bGJhM+ 284I9nSaR0p/YZVihWgaErwk+y+iPH3e1Q5qMXoyFS7OxE5L5w46/fPa2hsYxB5W1jG9 PINsoHipcNKYVtAcb8Wy10ukmty1Bxru5m2akvf25d88N3OhjCBFz41wwXbvygyOUsi0 IT6g== X-Gm-Message-State: AOAM533t8koxjZ/UvbshOGfKfk8X5PKodrdQJvN7oMin+HdGPCCxEteR x1P9UfaAhT/DlmimvqLbaFZLjf+MFQ2fhJDboKKrnoeU X-Google-Smtp-Source: ABdhPJxLzpGqg9rFIopI9izKGVvOb5wzJprm1DnmaFiJF4uaFy7Xsgvd+jmM6m4HTdM9YeRwR38nnMnKQ5+RXOMmsZM= X-Received: by 2002:a1f:b6d4:: with SMTP id g203mr7919251vkf.2.1598418434168; Tue, 25 Aug 2020 22:07:14 -0700 (PDT) MIME-Version: 1.0 References: <19865.1598394565@localhost> In-Reply-To: <19865.1598394565@localhost> From: Ira McDonald Date: Wed, 26 Aug 2020 01:07:02 -0400 Message-ID: To: Michael Richardson Cc: "rats@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f89cc005adc0ca36" Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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, 26 Aug 2020 05:07:17 -0000 --000000000000f89cc005adc0ca36 Content-Type: text/plain; charset="UTF-8" Hi Michael, Sorry for the confusion. No, the MCP doesn't forbid PCR8-PCR15, but it doesn't prescribe their usage either. No impact on RIV for network equipment. I was merely noting that TPM 2.0 Library is largely silent on specifics of PCR usage. And there is presently no TPM 2.0 profile for network equipment. Cheers, - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Tue, Aug 25, 2020 at 6:29 PM Michael Richardson wrote: > Ira McDonald wrote: > > Small note: Although you say each TPM has at least 16 PCRs, in fact > the > > TPM 2.0 Mobile Common Profile > > (2015) only requires the implementation of one SHA-256 bank of 8 > PCRs (a > > SHA-1 bank is prohibited here). > > That design choice was made to avoid the squabbles over the > inconsistent > > usage of PCR8 through PCR15 > > across various TPM 2.0 profiles. > > I just want to understand. > TPM 2 mobile, only requires PCR0-7. It doesn't forbid PCR8->15 though? > Do devices tend to implement them all? Or? > > So what do the profiles do now? > > What is the impact on RIV? > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > --000000000000f89cc005adc0ca36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Sorry for the co= nfusion.

No, the MCP doesn't forbid PCR8-PCR15= , but it doesn't prescribe
their usage either.=C2=A0 No = impact on RIV for network equipment.=C2=A0 I was
merely noting th= at TPM 2.0 Library is largely silent on specifics of
PCR usage.= =C2=A0 And there is presently no TPM 2.0 profile for network
equi= pment.

Cheers,
- Ira

=

Ira McDonald (Musician / Software Architect)
Co-Ch= air - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG I= nternet Printing Protocol WG
IETF Designated Expert - IPP & Printer = MIB
Blue Roof Music / High North Inc
htt= p://sites.google.com/site/blueroofmusic
= http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
(= permanent) PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Tue, Aug 25, 2020= at 6:29 PM Michael Richardson <mcr@= sandelman.ca> wrote:
Ira McDonald <blueroofmusic@gmail.com> wrote:
=C2=A0 =C2=A0 > Small note:=C2=A0 Although you say each TPM has at least= 16 PCRs, in fact the
=C2=A0 =C2=A0 > TPM 2.0 Mobile Common Profile
=C2=A0 =C2=A0 > (2015) only requires the implementation of one SHA-256 b= ank of 8 PCRs (a
=C2=A0 =C2=A0 > SHA-1 bank is prohibited here).
=C2=A0 =C2=A0 > That design choice was made to avoid the squabbles over = the inconsistent
=C2=A0 =C2=A0 > usage of PCR8 through PCR15
=C2=A0 =C2=A0 > across various TPM 2.0 profiles.

I just want to understand.
TPM 2 mobile, only requires PCR0-7.=C2=A0 It doesn't forbid PCR8->15= though?
Do devices tend to implement them all?=C2=A0 Or?

So what do the profiles do now?

What is the impact on RIV?

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

--000000000000f89cc005adc0ca36-- From nobody Wed Aug 26 00:07:15 2020 Return-Path: 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 D7E283A0937 for ; Wed, 26 Aug 2020 00:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 lsdfW4th1HDx for ; Wed, 26 Aug 2020 00:07:11 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80122.outbound.protection.outlook.com [40.107.8.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615263A043E for ; Wed, 26 Aug 2020 00:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UvhgG39KJDvK2GP2vwoeNeDNppI4N1qMtIrnwUPJJsiNSTOG4MUZdKtaMPxnLXS250rF/Y9i8fBXM0kw35eInIyV3Yfbd54vB5T6UTBYkseu9RrArdE69JVPmt9S3ujwFFUTDYKEgYGV7T4kjnCTwgXfNOBDSQURHtDN61Cpv8zw1wVTZkC1zX0ei4PZqOoThDmIXKpS/2vLmllMopjcGRnNHrp6O1ZzzuW0yb458GuaKn97lbT+zNaqc0Nra6PeflAlE8oDDO99PTSaY5HG2u6nb1lrIzr14szWpc6b/h0PuDD4jjJd5+POPXZrL2rWda9AyTu/ZliER+NqY5NJiw== 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=6PcudtOO7e62ckWc6MOaMfMFR7mqyZHHsq+KhWZCVJk=; b=eKLc6mWItJJn1bGG7FbjzuGF2SlrDwlViJy8aHwTvns9wS312TWWiBRHF/VqbwD6/8W4Hg87QE6VhA7dYsFVLogMb0RDeg1yhmJiosKc/q2OAx0aXTTkUeURVd0R7Me83ElHkckv+5vCUybkZjxk8Di4R7nFFTM+qmcHvGk9ZTFZGbpn2z837+fsZgVQwAEZoA44BnXDduilnBs9ZlaD6u5Zo1fa5gqfj7hZC2MRfKtUJxiEb5ej+s3Lx2lgttLO0fwIC85IbAajwyqtfAEj3mxnvU3RGYW2eD+ny/+hmR3Q29h1QkXig1Tc7RdqdgyCDXxK4Loyp07g2VWk/fzJNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6PcudtOO7e62ckWc6MOaMfMFR7mqyZHHsq+KhWZCVJk=; b=DEj2PyK3upz7C1CyirYbar9wYLeSeMk5YesCOBda2o5SAQLnQ7guaL7gP0JOpCJHzzJoC5B6ceWsZX7aO+Ri4v0Ynj8zgmUOEtSQ5L/ORHpAW7Nd0z4HgmZpAGTHPLjMljL9FGbe1v0qrsWOVUIrQ3kolo3Hr8QDFBozLkEXgL0= Received: from HE1PR07MB4252.eurprd07.prod.outlook.com (2603:10a6:7:9f::21) by HE1PR0702MB3804.eurprd07.prod.outlook.com (2603:10a6:7:8e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Wed, 26 Aug 2020 07:07:08 +0000 Received: from HE1PR07MB4252.eurprd07.prod.outlook.com ([fe80::89ef:773:e796:8ddc]) by HE1PR07MB4252.eurprd07.prod.outlook.com ([fe80::89ef:773:e796:8ddc%5]) with mapi id 15.20.3326.018; Wed, 26 Aug 2020 07:07:08 +0000 From: "Oliver, Ian (Nokia - FI/Espoo)" To: Michael Richardson , Ira McDonald , "rats@ietf.org" Thread-Topic: [Rats] TPM background for RIV Thread-Index: AQHWe0lxKX999NTcYUKITcp5giEHralJ96q0 Date: Wed, 26 Aug 2020 07:07:08 +0000 Message-ID: References: , <19865.1598394565@localhost> In-Reply-To: <19865.1598394565@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [131.228.2.3] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8fe541c5-6b7a-4bf5-b9f8-08d8498ea58f x-ms-traffictypediagnostic: HE1PR0702MB3804: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9POGyBYqtizsNbQk8ApGpAH18QquLn6e1Lk1R4rOCfmAWiLr1K+57ZKNUR+2PCtHq+oY5X1BfAJT/wW5NDbxC6dH54WNE2pu96ZyKbdmcholDZ7i4EJh+1Z9dMUBCb0TXC2pEQ35slAjBEQA0ylaI8cen3KkyJXSVRpcL3wj9//OqMoPsKtu/1WRkwDvrXBgZlPSnbP8gEQY/QAbJFuRrAm3E4xWjhDKeDCmfR8WCVGpHZEx8fszbGwd0gDvloJigb04kWPO23VkpyM3z48QxQSPn6neWpkNv2uhsDF7UP0rt1IT9GOhGyYrEEzRqO5hgOWTbRmrWSxCRD13sgdvBAMrHAU7QJMqygNBPbALQjA2ZIoecORqobd7q2wCQyPsCmcRrpT8Tjk9at//JUufmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4252.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(366004)(376002)(396003)(66446008)(478600001)(26005)(9686003)(8936002)(83380400001)(33656002)(55016002)(86362001)(8676002)(110136005)(7696005)(71200400001)(64756008)(6506007)(66946007)(52536014)(66476007)(166002)(66556008)(2906002)(53546011)(966005)(5660300002)(186003)(76116006)(316002)(19627405001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: fBXOz8pg1arUJi0G5SiKO8jxOivO/MpqHSAfA360liKjRcIt1w4P4fTW7jJJZjkkHI+7B1L4JN80DvBuRb+JR5CIcrYR+92aFgVhMaWoQtUq5DYSaQf0CsH/AjFWmFbZ5fGeR6UiuRzz8OKaOb6FdOjHL9rMi+36stvKv++frNGLQIz+wZqB6IBc1WkGM5QS2qRe53TLt+G+NlzA8QP1SQJaZUEzrIsirf5kGfuvg9VE7s7va82+BIrh21FuZuW6iMpsT0xSILLWY2W0YBk3NGvJtN+gxlHcmHQ922iDfwMNu4Oa7jwgo9ADDlqKxvyoW9QdRoXEKk7nL7KjF1vaqOEJX0rEMySUMMfhQzB85A02Dj8MnrmKbZscMsbhzdKfkPrimrIYQ/c/L2ktOIP6ibi/AKn+v+HjVHujaKglTZ9miFlX22Y065BlpffpfB6t7g3QXNOgMLDXXpnF0s3jTLLF3fwYQSZpV/mjAGCKO49tx+k4A0TRlO8rMy/TTahF4D8IgBW7CcdUT4xbytP22BCaa2Cqan3wm9Qj0QLEtfUiftccnW9ZsMG1K5MZ8s8exb9Lwf7QWtyKYJLXpYrgJ2FNMQfCWFZ/2FV193RnmEdKI8MHpagVwuzVapJOHgaYGJlcVtrMkhFuB+c9p2SGmw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB425261EEB8D1CEFA8EA6C2778F540HE1PR07MB4252eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4252.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fe541c5-6b7a-4bf5-b9f8-08d8498ea58f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 07:07:08.3999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a518qiNsn+bNsAFsYxud1k+Du0oNwpuJuHOt/7M87reMxBWZWpX52GAt1EcZCiMzeZEDc2sGG4x2gg+99VbGnD4dEN5idmIJ3zH9FB0RytI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3804 Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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, 26 Aug 2020 07:07:14 -0000 --_000_HE1PR07MB425261EEB8D1CEFA8EA6C2778F540HE1PR07MB4252eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doesn't the TPM 2 standard state PCRs 0 through to 23 with two banks being = provided SHA1 and SHA256 (at particular handles 0x4......?) It is the boot specification - at least for x86 - that states PCRs 0-7 are = utilised for specific purposes, ie: CRTM, BIOS, configuration, boot loader,= LCP and manufacturer defined. At least on some of our UEFI machines I see 8, 9 and 10 being used. 11 is the default for Linux IMA and 17 and 18 for Intel DRTM measurements There are restrictions due to locality, so at least on a PC, PCRS 16 and 23= are available to userland modification. Ian -- Dr. Ian Oliver Cybersecurity Research Distinguished Member of Technical Staff Nokia Bell Labs +358 50 483 6237 ________________________________ From: Michael Richardson Sent: 26 August 2020 01:29 To: Ira McDonald ; rats@ietf.org Subject: Re: [Rats] TPM background for RIV Ira McDonald wrote: > Small note: Although you say each TPM has at least 16 PCRs, in fact = the > TPM 2.0 Mobile Common Profile > (2015) only requires the implementation of one SHA-256 bank of 8 PCRs= (a > SHA-1 bank is prohibited here). > That design choice was made to avoid the squabbles over the inconsist= ent > usage of PCR8 through PCR15 > across various TPM 2.0 profiles. I just want to understand. TPM 2 mobile, only requires PCR0-7. It doesn't forbid PCR8->15 though? Do devices tend to implement them all? Or? So what do the profiles do now? What is the impact on RIV? -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --_000_HE1PR07MB425261EEB8D1CEFA8EA6C2778F540HE1PR07MB4252eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Doesn't the TPM 2 standard state PCRs 0 through to 23 with two banks being = provided SHA1 and SHA256 (at particular handles 0x4......?)

It is the boot specification - at least for x86 - that states PCRs 0-7 are = utilised for specific purposes, ie: CRTM, BIOS, configuration, boot loader,= LCP and manufacturer defined.

At least on some of our UEFI machines I see 8, 9 and 10 being used.

11 is the default for Linux IMA and 17 and 18 for Intel DRTM measurements

There are restrictions due to locality, so at least on a PC, PCRS 16 and 23= are available to userland modification.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237


From: Mich= ael Richardson <mcr@sandelman.ca>
Sent: 26 August 2020 01:29
To: Ira McDonald <blueroofmusic@gmail.com>; rats@ietf.org <= rats@ietf.org>
Subject: Re: [Rats] TPM background for RIV
 
Ira McDonald <blueroofmusic@gmail.com> wrote= :
    > Small note:  Although you say each TPM has at = least 16 PCRs, in fact the
    > TPM 2.0 Mobile Common Profile
    > (2015) only requires the implementation of one SHA-= 256 bank of 8 PCRs (a
    > SHA-1 bank is prohibited here).
    > That design choice was made to avoid the squabbles = over the inconsistent
    > usage of PCR8 through PCR15
    > across various TPM 2.0 profiles.

I just want to understand.
TPM 2 mobile, only requires PCR0-7.  It doesn't forbid PCR8->15 tho= ugh?
Do devices tend to implement them all?  Or?

So what do the profiles do now?

What is the impact on RIV?

--
]            &n= bsp;  Never tell me the odds!       = ;          | ipv6 mesh network= s [
]   Michael Richardson, Sandelman Software Works   = ;     |    IoT architect   [ ]     mcr@sandelman.ca  http://www.sandelman.ca/      =   |   ruby on rails    [


--_000_HE1PR07MB425261EEB8D1CEFA8EA6C2778F540HE1PR07MB4252eurp_-- From nobody Wed Aug 26 04:01:01 2020 Return-Path: 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 A01553A0EB0 for ; Wed, 26 Aug 2020 04:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R7_XwJDT65h4 for ; Wed, 26 Aug 2020 04:00:58 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE283A0EAD for ; Wed, 26 Aug 2020 04:00:58 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id k1so319594vkb.7 for ; Wed, 26 Aug 2020 04:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mdtu5WoolD56PgLgsN0753VYZmn0fpcxKD7xOvMlwQw=; b=XyQA/B/3/XASFaRb0Zr/9sCp6bhuHd5sg72HxTT6jmYQyO5wkZ8WZSUyi743VvsJ/I VrmSGwt3/m77gGmBA3MLR+FXEmgZSdiHSy0Jhv1tBZCwROMu0LHPO+klx01b4IyAxzkL DVE3tHrpU0zUhVtzooAaBz/uPgzJguZjFnrTkU+DMW861E3JBBYCSt1ukTpvhdxt1Q10 ZufFPAnJxvz41j+HpCqStFZQQICqKwU3xtv0AOUooAk6SeUDpdFZkS0nxUc0iGcP3O3f 4xhx+xo2Bw3Gj2jos9TgseR/dpfGsfTOHVe9//c6XwJA3KrwNKE+ErioTwCS0JBo2bpQ 7c1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mdtu5WoolD56PgLgsN0753VYZmn0fpcxKD7xOvMlwQw=; b=MX6MriGn854M9mxtVl3lNUxEYeSbPbNgKsrPFmf4OyQfDhrXuzp0ubEfRJ+SeKnIwv 3JgVk6/Odeg0k1SwjPduEsq/nu/3v2XMr4oJIPNKorIe9+fQrXOP1srPcvr2uO/yxn0U gcJedTNmj9gt9BRCfx11hKAxUoVpO2O1i3JV0LqM6DvDgWcCHdHAYMKt5CSMLpBA9Xf5 9WKduii4wqdTs7MFszWiI8LZWBRYWNvHGJMtFtgji0Vp7CN/bmU/CoQHInJzRkZDuOtb 65db6gr/0z00hmwKZxSlvP1vuGUHLzz3WlDeeShBiqtCM5Hf3DZhqAdHClCBKo7dpi+E FSUw== X-Gm-Message-State: AOAM531QYhMLrVbi2HlSZiQjxMCVE75+RXOHcAFAddOn1tSQ4CpyJh8/ x5e3NBhapaOf/QV8X80ecSB7B2qc/pu8cn3awg8= X-Google-Smtp-Source: ABdhPJwGHQE2JlcFJg6mVWm20EeHBPTZHamoOaF/XTJjDyAcxG1fhla9HnDUOk5XTLbEjmvlXTDS8ZmabRrcARbI0NQ= X-Received: by 2002:a1f:b6d4:: with SMTP id g203mr8442463vkf.2.1598439657803; Wed, 26 Aug 2020 04:00:57 -0700 (PDT) MIME-Version: 1.0 References: <19865.1598394565@localhost> In-Reply-To: From: Ira McDonald Date: Wed, 26 Aug 2020 07:00:45 -0400 Message-ID: To: "Oliver, Ian (Nokia - FI/Espoo)" , Ira McDonald Cc: Michael Richardson , "rats@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ff9d7505adc5bb54" Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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, 26 Aug 2020 11:01:01 -0000 --000000000000ff9d7505adc5bb54 Content-Type: text/plain; charset="UTF-8" Hi Ian, No, the TPM 2.0 Library standard (the base standard) does not specify the size (number of PCRs) or number of banks (different hash algorithms) for PCRs. That's only specified in specific profiles. And it's definitely not the same across all TCG profiles. Cheers, - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Wed, Aug 26, 2020 at 3:07 AM Oliver, Ian (Nokia - FI/Espoo) < ian.oliver@nokia-bell-labs.com> wrote: > Doesn't the TPM 2 standard state PCRs 0 through to 23 with two banks being > provided SHA1 and SHA256 (at particular handles 0x4......?) > > It is the boot specification - at least for x86 - that states PCRs 0-7 are > utilised for specific purposes, ie: CRTM, BIOS, configuration, boot loader, > LCP and manufacturer defined. > > At least on some of our UEFI machines I see 8, 9 and 10 being used. > > 11 is the default for Linux IMA and 17 and 18 for Intel DRTM measurements > > There are restrictions due to locality, so at least on a PC, PCRS 16 and > 23 are available to userland modification. > > Ian > > -- > > Dr. Ian Oliver > > Cybersecurity Research > > Distinguished Member of Technical Staff > > Nokia Bell Labs > > +358 50 483 6237 > > ------------------------------ > *From:* Michael Richardson > *Sent:* 26 August 2020 01:29 > *To:* Ira McDonald ; rats@ietf.org > > *Subject:* Re: [Rats] TPM background for RIV > > Ira McDonald wrote: > > Small note: Although you say each TPM has at least 16 PCRs, in fact > the > > TPM 2.0 Mobile Common Profile > > (2015) only requires the implementation of one SHA-256 bank of 8 > PCRs (a > > SHA-1 bank is prohibited here). > > That design choice was made to avoid the squabbles over the > inconsistent > > usage of PCR8 through PCR15 > > across various TPM 2.0 profiles. > > I just want to understand. > TPM 2 mobile, only requires PCR0-7. It doesn't forbid PCR8->15 though? > Do devices tend to implement them all? Or? > > So what do the profiles do now? > > What is the impact on RIV? > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > --000000000000ff9d7505adc5bb54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ian,

No, the TPM 2.0 Libr= ary standard (the base standard) does not specify the size
(= number of PCRs) or number of banks (different hash algorithms) for PCRs.

That's only specified in specific profiles.=C2= =A0 And it's definitely not the same across
all TCG profiles.=

Cheers,
- Ira

=
<= div dir=3D"ltr">
Ir= a McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobili= ty Solutions WG
Co-Chair - TCG Met= adata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO P= rinter Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol= WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / = High North Inc
http://sites.google.com/site= /blueroofmusic
http://sites.google.com/s= ite/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221=C2= =A0 Grand Marais, MI 49839=C2=A0 906-494-2434
<= /div>


On Wed, Aug 26, 2020 at 3:07 AM Oliver, Ian (= Nokia - FI/Espoo) <ian= .oliver@nokia-bell-labs.com> wrote:
Doesn't the TPM 2 standard state PCRs 0 through to 23 with two banks be= ing provided SHA1 and SHA256 (at particular handles 0x4......?)

It is the boot specification - at least for x86 - that states PCRs 0-7 are = utilised for specific purposes, ie: CRTM, BIOS, configuration, boot loader,= LCP and manufacturer defined.

At least on some of our UEFI machines I see 8, 9 and 10 being used.

11 is the default for Linux IMA and 17 and 18 for Intel DRTM measurements

There are restrictions due to locality, so at least on a PC, PCRS 16 and 23= are available to userland modification.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Techn= ical Staff

Nokia Bell Labs

+358 50 483 6237


Fro= m: Michael Richardson <mcr@sandelman.ca>
Sent: 26 August 2020 01:29
To: Ira McDonald <blueroofmusic@gmail.com>; rats@ietf.org <rats@ietf.org>
Subject: Re: [Rats] TPM background for RIV
=C2=A0
Ira McDonald <blueroofmusic@gmail.com> wrote:
=C2=A0=C2=A0=C2=A0 > Small note:=C2=A0 Although you say each TPM has at = least 16 PCRs, in fact the
=C2=A0=C2=A0=C2=A0 > TPM 2.0 Mobile Common Profile
=C2=A0=C2=A0=C2=A0 > (2015) only requires the implementation of one SHA-= 256 bank of 8 PCRs (a
=C2=A0=C2=A0=C2=A0 > SHA-1 bank is prohibited here).
=C2=A0=C2=A0=C2=A0 > That design choice was made to avoid the squabbles = over the inconsistent
=C2=A0=C2=A0=C2=A0 > usage of PCR8 through PCR15
=C2=A0=C2=A0=C2=A0 > across various TPM 2.0 profiles.

I just want to understand.
TPM 2 mobile, only requires PCR0-7.=C2=A0 It doesn't forbid PCR8->15= though?
Do devices tend to implement them all?=C2=A0 Or?

So what do the profiles do now?

What is the impact on RIV?

--
]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Never tell me the odds!=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | ipv6 mesh netwo= rks [
]=C2=A0=C2=A0 Michael Richardson, Sandelman Software Works=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 IoT architect=C2=A0=C2=A0 [=
]=C2=A0=C2=A0=C2=A0=C2=A0 mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0 ruby on rails=C2=A0=C2=A0=C2=A0 [


--000000000000ff9d7505adc5bb54-- From nobody Wed Aug 26 07:11:11 2020 Return-Path: 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 BDC9A3A14B6 for ; Wed, 26 Aug 2020 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4MOs4qXsBaEF for ; Wed, 26 Aug 2020 07:11:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC893A14B3 for ; Wed, 26 Aug 2020 07:11:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EA0F389A7; Wed, 26 Aug 2020 09:50:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gtMqpy16W3rQ; Wed, 26 Aug 2020 09:50:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7398038999; Wed, 26 Aug 2020 09:50:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C6F8476; Wed, 26 Aug 2020 10:11:06 -0400 (EDT) From: Michael Richardson To: Ira McDonald cc: "rats\@ietf.org" In-Reply-To: References: <19865.1598394565@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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, 26 Aug 2020 14:11:11 -0000 --=-=-= Content-Type: text/plain Ira McDonald wrote: > Sorry for the confusion. > No, the MCP doesn't forbid PCR8-PCR15, but it doesn't prescribe > their usage either. No impact on RIV for network equipment. I was > merely noting that TPM 2.0 Library is largely silent on specifics of > PCR usage. And there is presently no TPM 2.0 profile for network > equipment. So, could RIV be that profile? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9GbXoACgkQgItw+93Q 3WXoMQgAgePEiCdZ0ets3Lt6fmWOmSt1N7IwY9lQAl64U8AkCtUjhlh3e1J5glo+ jFdtgYaC8IJLJizNhC+MMLWQSiL8+tq/5t6IvPufjCM6rONe01DnB/xnYZ1kOD7O wXIwhRCqR3C+gYHGZxLFq9PgwriPvMP9m1MkaIdarmjuTwRw4MyoCTP/JDYxCE2s F/cCae99Seon8DMASnuhNpigwWD3KMDRgxEhx3cBcZm5wFz1ftFtSAJWmY+zBSwV G1uSXkCQg9vLgtm0pze5DW0CxAxmdzaWmP6rGO4OQCncEdWPrEvgT5m5YMvmH8ki 9RauwsoqVEOUOAkucXS9cmeuQ7F1ow== =CUvM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 26 07:22:35 2020 Return-Path: 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 66C1F3A150D for ; Wed, 26 Aug 2020 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UuGY-DV9BFle for ; Wed, 26 Aug 2020 07:22:33 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C866D3A150A for ; Wed, 26 Aug 2020 07:22:32 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id a1so1035303vsp.4 for ; Wed, 26 Aug 2020 07:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iQgSwb2IaBHEvyGR4dnuXSsbhcNda/6/phyDlDhG/ZE=; b=ofYz+b7m5LdZ3vRwnuVefH3trkbnc3Ub+fyDhMSnftkx1oYZjBy8FK2s/Hu0W/v27Z Ry+Rbz04UC9+CrQ9X5wboFVo8VJ+5CVD02Qd1mNcxeff7HLtc+Psz13Tm6m2lWfXtpZB Wx/Zna8gdxOGqZMzb2LLOmC972X/dMIPtCvnZNjUeiiOy/TztHf2SkqtyI3qyJfW5OMJ tpJzQ392PLBr+22mnksDc9KSBOK9ilnKLyNWe35sWEQyG8SE8++Y2yNQwKX22UpuXm6S rdBIAZwIN17AFvipldSnaP6I9TtepNdLY8BvlLPODsn4R/thgS1yTT4xDCGLrGNEkVFc EIag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iQgSwb2IaBHEvyGR4dnuXSsbhcNda/6/phyDlDhG/ZE=; b=K+o75eN0Wba+kfTZDYhbbturcQtQKqZ38Fjp+pSswLNLFiyLftLDMdFKIadc2bw+iv 7V1oObWk54f9dzTfVTj3MtpKavtUl+skBFPDaj792ERNea2ccKDZsIrvmB1OTFdVvXMf 0pjkCqsIK15bDyDuQWCOc4xJDDs7hLFY+o44jJy0xTiJRwr+e7FqmAmBPoCvRazJG4FJ IHx1uTas+8KTGsLHGfVY5+udt2gdv8w0wcjI1IU4MPixZY0Azxeq5Wg0gQMDZyah+B6o LfKBYcJoBreG8gWaXBtJkk2fmWSNCdszW2RPLqnpsRwB0zv1eoxULiNWwUCsYJ9xf5T2 L1qA== X-Gm-Message-State: AOAM5305MfuQmRJutnZZkNX/smIDDuAYPfo8Q5ZCRb/oANFEzpHoHhIP y0Bjp31Vh9SEfp+OaqfQnEp3xi3WiIHAw4e15q0= X-Google-Smtp-Source: ABdhPJy2D3UkzAFFe6NR2Yy00CUIPmfw3zklDj4X3kF98eArxgLGPRO5msdvENXOiJi8ac7CfExLYCEkkTP1ifZzPvE= X-Received: by 2002:a67:fbcc:: with SMTP id o12mr8991186vsr.213.1598451751676; Wed, 26 Aug 2020 07:22:31 -0700 (PDT) MIME-Version: 1.0 References: <19865.1598394565@localhost> <28707.1598451066@localhost> In-Reply-To: <28707.1598451066@localhost> From: Ira McDonald Date: Wed, 26 Aug 2020 10:22:14 -0400 Message-ID: To: Michael Richardson , Ira McDonald Cc: "rats@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d9706705adc88c97" Archived-At: Subject: Re: [Rats] TPM background for RIV X-BeenThere: rats@ietf.org 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, 26 Aug 2020 14:22:34 -0000 --000000000000d9706705adc88c97 Content-Type: text/plain; charset="UTF-8" Hi Michael, The TCG Network Equipment WG could develop a TCG-approved TPM 2.0 profile for network equipment. The IETF RATS RIV spec could not be that official profile, under TCG rules. It's also not structured in the proforma structure of a TCG profile. For an example of that structure, see: https://trustedcomputinggroup.org/wp-content/uploads/TPM_2.0_Mobile_Common_Profile_v2r31_FINAL.pdf Cheers, - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Wed, Aug 26, 2020 at 10:11 AM Michael Richardson wrote: > > Ira McDonald wrote: > > Sorry for the confusion. > > > No, the MCP doesn't forbid PCR8-PCR15, but it doesn't prescribe > > their usage either. No impact on RIV for network equipment. I was > > merely noting that TPM 2.0 Library is largely silent on specifics of > > PCR usage. And there is presently no TPM 2.0 profile for network > > equipment. > > So, could RIV be that profile? > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --000000000000d9706705adc88c97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

The TCG Network = Equipment WG could develop a TCG-approved TPM 2.0
profile for net= work equipment.=C2=A0 The IETF RATS RIV spec could not be that
official profile, under TCG rules.=C2=A0 It's also not structured in= the proforma
structure of a TCG profile.=C2=A0 For an example of= that structure, see:


Cheers,
<= div>- Ira

=
Ira McDonald (Musician / Software Architec= t)
Co-Chair - TCG Trusted Mobility Solutions WG
= Co-Chair - TCG Metadata Access Protocol SG
<= /div>
Chair - Linux Foundation Open Pri= nting WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-= ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP &= ; Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.= com
(permanent) PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-49= 4-2434

On Wed, A= ug 26, 2020 at 10:11 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Ira McDonald <blueroofmusic@gmail.com> wrote:
=C2=A0 =C2=A0 > Sorry for the confusion.

=C2=A0 =C2=A0 > No, the MCP doesn't forbid PCR8-PCR15, but it doesn&= #39;t prescribe
=C2=A0 =C2=A0 > their usage either.=C2=A0 No impact on RIV for network e= quipment.=C2=A0 I was
=C2=A0 =C2=A0 > merely noting that TPM 2.0 Library is largely silent on = specifics of
=C2=A0 =C2=A0 > PCR usage.=C2=A0 And there is presently no TPM 2.0 profi= le for network
=C2=A0 =C2=A0 > equipment.

So, could RIV be that profile?


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--000000000000d9706705adc88c97-- From nobody Fri Aug 28 06:53:18 2020 Return-Path: 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 1FB813A0BEF; Fri, 28 Aug 2020 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 g8XyM1nRuPsS; Fri, 28 Aug 2020 06:53:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A163A0BC8; Fri, 28 Aug 2020 06:53:14 -0700 (PDT) Received: from lhreml719-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A71D2F657CEB120231F1; Fri, 28 Aug 2020 14:53:11 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 14:53:10 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 21:53:08 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Fri, 28 Aug 2020 21:53:08 +0800 From: "Panwei (William)" To: "draft-ietf-rats-yang-tpm-charra@ietf.org" CC: "rats@ietf.org" Thread-Topic: Propose a new event-log-type in CHARRA Thread-Index: AdZ9F2S3YE6HUmniRGqctvSTG8eYFQ== Date: Fri, 28 Aug 2020 13:53:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.233.71] Content-Type: multipart/alternative; boundary="_000_f92d4256061948a3aa89952b912c81e3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Rats] Propose a new event-log-type in CHARRA X-BeenThere: rats@ietf.org 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: Fri, 28 Aug 2020 13:53:16 -0000 --_000_f92d4256061948a3aa89952b912c81e3huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, all, We've proposed a new attested-event-log-type in the Github (PR#5) a while ago, but unfortuna= tely there is little discussion about it. This is also mentioned at IETF 10= 8 meeting. I think it might be better to bring this topic to the mailing li= st and give more description about it. The blue part below is the format of the new type of log that we propose. I= t literally looks somewhat similar to the IMA log format, because it uses p= art of the IMA's concepts in the devices boot measurement. When the device boots, it needs to load/execute a lot of files, but the ord= er in which these files are loaded/executed is not deterministic or hard to= keep fixed, so it's difficult to give an accurate reference value. The method to overcome this difficulty is below: 1. The Attester measures each file before execution, extends the hash value= of the file into PCR, and records the measurement information of the file = in the log. 2. When doing the remote attestation, the Attester sends the final values o= f the PCRs and the detailed logs to the Verifier. 3. The Verifier has a list of reference values for all files. It compares t= he hash value of each file recorded in the log with the corresponding refer= ence value. If all files' hash values match with their reference values, th= en the Verifier extends the hash values one by one according to the order r= ecorded in the log, gets the final value, and compares the final value with= the PCR value sent by the Attester. Based on this method, we propose the new type of log. Any thoughts? +--ro output +--ro system-event-logs +--ro node-data* [] +--ro tpm-name? string +--ro up-time? uint32 +--ro log-result +--ro (attested-event-log-type) +--:(bios) | +--ro bios-event-logs | +--ro bios-event-entry* [event-number] | +--ro event-number uint32 | +--ro event-type? uint32 | +--ro pcr-index? pcr | +--ro digest-list* [] | | +--ro hash-algo? identityref | | +--ro digest* binary | +--ro event-size? uint32 | +--ro event-data* uint8 +--:(netequip-boot) | +--ro boot-event-logs | +--ro boot-event-entry* [event-number] | +--ro event-number uint64 | +--ro filename-hint? string | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro file-version? string | +--ro file-type? string | +--ro pcr-index? pcr +--:(ima) +--ro ima-event-logs +--ro ima-event-entry* [event-number] +--ro event-number uint64 +--ro ima-template? string +--ro filename-hint? string +--ro filedata-hash? binary +--ro filedata-hash-algorithm? string +--ro template-hash-algorithm? string +--ro template-hash? binary +--ro pcr-index? pcr +--ro signature? binary Regards & Thanks! Wei Pan --_000_f92d4256061948a3aa89952b912c81e3huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors, all,

 

We’ve proposed a new attested-event-log-type in the Github (PR#5= ) a while ago, but unfortunately there is little discussion about it. This i= s also mentioned at IETF 108 meeting. I think it might be better to bring t= his topic to the mailing list and give more description about it.

The blue part below is the format of the new type of log that we pro= pose. It literally looks somewhat similar to the IMA log format, because it uses part of the IMA’s concepts in the device= s boot measurement.

When the device boots, it needs to load/execute a lot of files, but = the order in which these files are loaded/executed is not deterministic or hard to keep fixed, so it’s difficult to giv= e an accurate reference value.

The method to overcome this difficulty is below:

1. The Attester measures each file before executi= on, extends the hash value of the file into PCR, and records the measurement information of the file in the log.

2. When doing the remote attestation, the Atteste= r sends the final values of the PCRs and the detailed logs to the Verifier.

3. The Verifier has a list of reference values fo= r all files. It compares the hash value of each file recorded in the log with the corresponding reference value. If all files&#= 8217; hash values match with their reference values, then the Verifier exte= nds the hash values one by one according to the order recorded in the log, = gets the final value, and compares the final value with the PCR value sent by the Attester.

Based on this method, we propose the new type of log. Any thoughts?<= o:p>

 

+--ro output

   +--ro system= -event-logs

     = ; +--ro node-data* []

     = ;    +--ro tpm-name?     string=

     = ;    +--ro up-time?      uint32=

     = ;    +--ro log-result

     = ;       +--ro (attested-event-log-type)

     = ;          +--:(bios)=

     = ;          |  +--ro b= ios-event-logs

     = ;          |   =   +--ro bios-event-entry* [event-number]

     = ;          |   =      +--ro event-number    uint32

     = ;          |   =      +--ro event-type?     uint= 32

     = ;          |   =      +--ro pcr-index?     = pcr

     = ;          |   =      +--ro digest-list* []

     = ;          |   =      |  +--ro hash-algo?   identityr= ef

     = ;          |   =      |  +--ro digest*    &= nbsp; binary

     = ;          |   =      +--ro event-size?     uint= 32

     = ;          |   =      +--ro event-data*     uint= 8

  &nb= sp;            += --:(netequip-boot)

  &nb= sp;            |&nbs= p; +--ro boot-event-logs

  &nb= sp;            |&nbs= p;    +--ro boot-event-entry* [event-number]<= /span>

  &nb= sp;            |&nbs= p;       +--ro event-number  &n= bsp;            uint= 64

  &nb= sp;            |&nbs= p;       +--ro filename-hint?  =            string

  &nb= sp;            |&nbs= p;       +--ro filedata-hash?  =            binary

  &nb= sp;            |&nbs= p;       +--ro filedata-hash-algorithm?&n= bsp;  string

  &nb= sp;            |&nbs= p;       +--ro file-version?  &= nbsp;           string

  &nb= sp;            |&nbs= p;       +--ro file-type?  &nbs= p;            &= nbsp; string

  &nb= sp;            |&nbs= p;       +--ro pcr-index?  &nbs= p;            &= nbsp; pcr

     = ;          +--:(ima)<= /o:p>

     = ;             &= #43;--ro ima-event-logs

     = ;            &n= bsp;   +--ro ima-event-entry* [event-number]

     = ;            &n= bsp;      +--ro event-number   =             uint64

     = ;            &n= bsp;      +--ro ima-template?   = ;           string

     = ;            &n= bsp;      +--ro filename-hint?  &nbs= p;          string<= /span>

     = ;            &n= bsp;      +--ro filedata-hash?  &nbs= p;          binary<= /span>

     = ;            &n= bsp;      +--ro filedata-hash-algorithm? =   string

     = ;            &n= bsp;      +--ro template-hash-algorithm? =   string

     = ;            &n= bsp;      +--ro template-hash?  &nbs= p;          binary<= /span>

     = ;            &n= bsp;      +--ro pcr-index?   &n= bsp;            = ; pcr

     = ;            &n= bsp;      +--ro signature?   &n= bsp;            = ; binary

 

Regards & Thanks!

Wei Pan=

--_000_f92d4256061948a3aa89952b912c81e3huaweicom_-- From nobody Fri Aug 28 07:08:05 2020 Return-Path: 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 15B223A0B56; Fri, 28 Aug 2020 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OINOqi-iP-yi; Fri, 28 Aug 2020 07:08:00 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4B43A0B6C; Fri, 28 Aug 2020 07:08:00 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id s29so406616uae.1; Fri, 28 Aug 2020 07:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8mzVJNBumB3ZlmivNkN4tMEO/Js3GGVPZj5XeIMT0gU=; b=kTcn8CChJbVTE07LH6JFmEo3qppHgONCNuKLZ3tp4ByiDavAD+n4N0zkB8YpKqrlHp zV30p5ovbvNS/VKGhY0lQVjsIWI0xJ6oZ6GjXHK0oSGIXJpW/mTVPgMoBUg8t6++rz6Z TxS1IhgIaQJBtdWsUryfKoBc5fqqpMkOCmeSHGmMj5NB4NVZetsmBYRLBJa8revcGqA1 HbH8ZdqYzwFzNatDQv0coIZyTvtT6tmGpijUBVZT59aE9FNiagHqcVYxr/5H8NmX2+A3 QQrN3D5QXPRnlJCJzB5YeE3Ebs+OC+FAZ0bctij890rdY7sEYC5s+NjavKkhPy88a679 iM4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8mzVJNBumB3ZlmivNkN4tMEO/Js3GGVPZj5XeIMT0gU=; b=kFSHPtd+slO4Miq1SPxTMObVfuWrdnIzQ4YCFUpEDzPITsJ0XDvusc13PIL4OPd1yK sg6nkt7msETzpktBZp4FH0wUT86Q/akJ+8BTMPhkU5hHKSMlGdrnIkdyqHDhO1JHKRKJ 6XLXAghO7OQt9QO7t02nixg34gxgH6wP5sz+nuVH3Y0oWFONWmjgZnkDGaqKZcgC5MQD VVMYfRGVD2RSSfoUf5zxkY2J3ZeaUxA+SnKf6HfRnPng5NJwzdIzwCvxS3qeXtyvQki3 iesAagMCp+IybeNdzfJOqqQTKK2H568ihY/CH++VXy62Pgi7A6qm61XsWEOomJcxaZP1 7GGA== X-Gm-Message-State: AOAM530BdXhRukKwnMubPfqaEPGp2MPADHffYM4sGIPGU9MimxAkbcL3 Rzf5JL3KM362TdIWX71YPeP5n+70AsUpXkm6Ff8= X-Google-Smtp-Source: ABdhPJz7+fNnTzgADld+q95DrC3Y98fKU4+D4uXdDr9j8xfkcoJAae8YvnsVCFlJkug4r4YIlcCcd5gipaDdJBR/s3Y= X-Received: by 2002:a9f:324a:: with SMTP id y10mr254174uad.88.1598623679078; Fri, 28 Aug 2020 07:07:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ira McDonald Date: Fri, 28 Aug 2020 10:07:43 -0400 Message-ID: To: "Panwei (William)" , Ira McDonald Cc: "draft-ietf-rats-yang-tpm-charra@ietf.org" , "rats@ietf.org" Content-Type: multipart/alternative; boundary="00000000000085671c05adf0949d" Archived-At: Subject: Re: [Rats] Propose a new event-log-type in CHARRA X-BeenThere: rats@ietf.org 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: Fri, 28 Aug 2020 14:08:03 -0000 --00000000000085671c05adf0949d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, +1 I've worried about this fragility in RIMs (Reference Integrity Metrics) all along. You might be able to fix the boot order of drivers (well maybe not), but yo= u certainly almost always can't fix the load order of applications and libraries. Cheers, - Ira *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/hi= ghnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Fri, Aug 28, 2020 at 9:53 AM Panwei (William) wrote: > Hi authors, all, > > > > We=E2=80=99ve proposed a new attested-event-log-type in the Github (PR#5 > ) a while ago, > but unfortunately there is little discussion about it. This is also > mentioned at IETF 108 meeting. I think it might be better to bring this > topic to the mailing list and give more description about it. > > The blue part below is the format of the new type of log that we propose. > It literally looks somewhat similar to the IMA log format, because it use= s > part of the IMA=E2=80=99s concepts in the devices boot measurement. > > When the device boots, it needs to load/execute a lot of files, but the > order in which these files are loaded/executed is not deterministic or ha= rd > to keep fixed, so it=E2=80=99s difficult to give an accurate reference va= lue. > > The method to overcome this difficulty is below: > > 1. The Attester measures each file before execution, extends the hash > value of the file into PCR, and records the measurement information of th= e > file in the log. > > 2. When doing the remote attestation, the Attester sends the final values > of the PCRs and the detailed logs to the Verifier. > > 3. The Verifier has a list of reference values for all files. It compares > the hash value of each file recorded in the log with the corresponding > reference value. If all files=E2=80=99 hash values match with their refer= ence > values, then the Verifier extends the hash values one by one according to > the order recorded in the log, gets the final value, and compares the fin= al > value with the PCR value sent by the Attester. > > Based on this method, we propose the new type of log. Any thoughts? > > > > +--ro output > > +--ro system-event-logs > > +--ro node-data* [] > > +--ro tpm-name? string > > +--ro up-time? uint32 > > +--ro log-result > > +--ro (attested-event-log-type) > > +--:(bios) > > | +--ro bios-event-logs > > | +--ro bios-event-entry* [event-number] > > | +--ro event-number uint32 > > | +--ro event-type? uint32 > > | +--ro pcr-index? pcr > > | +--ro digest-list* [] > > | | +--ro hash-algo? identityref > > | | +--ro digest* binary > > | +--ro event-size? uint32 > > | +--ro event-data* uint8 > > +--:(netequip-boot) > > | +--ro boot-event-logs > > | +--ro boot-event-entry* [event-number] > > | +--ro event-number uint64 > > | +--ro filename-hint? string > > | +--ro filedata-hash? binary > > | +--ro filedata-hash-algorithm? string > > | +--ro file-version? string > > | +--ro file-type? string > > | +--ro pcr-index? pcr > > +--:(ima) > > +--ro ima-event-logs > > +--ro ima-event-entry* [event-number] > > +--ro event-number uint64 > > +--ro ima-template? string > > +--ro filename-hint? string > > +--ro filedata-hash? binary > > +--ro filedata-hash-algorithm? string > > +--ro template-hash-algorithm? string > > +--ro template-hash? binary > > +--ro pcr-index? pcr > > +--ro signature? binary > > > > Regards & Thanks! > > Wei Pan > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > --00000000000085671c05adf0949d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

+1

<= div>I've worried about this fragility in RIMs (Reference Integrity Metr= ics) all along.

You might be able to fix the boot = order of drivers (well maybe not), but you
certainly almost alway= s can't fix the load order of applications and libraries.
Cheers,
- Ira

<= div dir=3D"ltr">
Ira McDonald (Mus= ician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG=
Co-Chair - TCG Metadata Access Pr= otocol SG
Chair - = Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working = Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Des= ignated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc<= br>http://sites.google.com/site/blueroofmusic<= /a>
http://sites.google.com/site/highnorthin= c
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221=C2=A0 Grand Marais= , MI 49839=C2=A0 906-494-2434


On Fri, Aug 28, 2020 at 9:53 AM Panwei (William) <william.panwei@huawei.com> wr= ote:

Hi authors, all,

=C2=A0

We=E2=80=99ve proposed a new attested-event-log-type in the Github (PR#5) a while ago, but unfortunately there is little discussion about it. This i= s also mentioned at IETF 108 meeting. I think it might be better to bring t= his topic to the mailing list and give more description about it.=

The blue part below is the format of the new type of log that we propo= se. It literally looks somewhat similar to the IMA log format, because it uses part of the IMA=E2=80=99s concepts in the devi= ces boot measurement.

When the device boots, it needs to load/execute a lot of files, but th= e order in which these files are loaded/executed is not deterministic or hard to keep fixed, so it=E2=80=99s difficult to g= ive an accurate reference value.

The method to overcome this difficulty is below:<= /p>

1. The Attester measures each file before execution, = extends the hash value of the file into PCR, and records the measurement information of the file in the log.<= /span>

2. When doing the remote attestation, the Attester se= nds the final values of the PCRs and the detailed logs to the Verifier.

3. The Verifier has a list of reference values for al= l files. It compares the hash value of each file recorded in the log with the corresponding reference value. If all files= =E2=80=99 hash values match with their reference values, then the Verifier = extends the hash values one by one according to the order recorded in the l= og, gets the final value, and compares the final value with the PCR value sent by the Attester.<= /p>

Based on this method, we propose the new type of log. Any thoughts?=

=C2=A0

+--ro output

=C2=A0=C2=A0 +--ro system-event= -logs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--ro node-data* []

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--ro tpm-name?=C2=A0=C2=A0=C2=A0=C2=A0 string=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--ro up-time?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--ro log-result

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (attested-event-log-type)=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(bios)=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro bios-e= vent-logs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0 +--ro bios-event-entry* [event-number]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-number=C2=A0=C2=A0=C2=A0 uint32=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-type?=C2=A0=C2=A0=C2=A0=C2=A0 uint32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro pcr-index?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pcr=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro digest-list* []

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro hash-algo?=C2=A0=C2=A0 identityref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro digest*=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 binary

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-size?=C2=A0=C2=A0=C2=A0=C2=A0 uint32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-data*=C2=A0=C2=A0=C2=A0=C2=A0 uint8=

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--:(netequip-boot)

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0 +--ro boot-event-logs

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro boot-event-entry* [event-number]=

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-number=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ui= nt64

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro filename-hint?=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro filedata-hash?=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binary

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0+--ro filedata-hash-algorithm?= =C2=A0=C2=A0 string

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro file-version?=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 strin= g

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro file-type?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 string

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro pcr-index?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 pcr

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(ima)<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-= -ro ima-event-logs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +--ro ima-event-entry* [event-number]<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro event-number=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint64

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro ima-template?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro filename-hint?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro filedata-hash?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binary

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro filedata-hash-algorithm?=C2=A0=C2= =A0 string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro template-hash-algorithm?=C2=A0=C2= =A0 string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro template-hash?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 binary

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro pcr-index?=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pc= r

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro signature?=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bi= nary

=C2=A0

Regards & Thanks!

Wei Pan

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--00000000000085671c05adf0949d-- From nobody Fri Aug 28 13:37:06 2020 Return-Path: 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 9A2BB3A0BD9 for ; Fri, 28 Aug 2020 13:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UMSPcyGSJcnJ for ; Fri, 28 Aug 2020 13:37:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993243A0BD7 for ; Fri, 28 Aug 2020 13:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 228D7389DE; Fri, 28 Aug 2020 16:16:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1e18FPUz02Nf; Fri, 28 Aug 2020 16:16:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E828389DC; Fri, 28 Aug 2020 16:16:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 33634B3; Fri, 28 Aug 2020 16:37:00 -0400 (EDT) From: Michael Richardson To: "Panwei \(William\)" , "rats\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Rats] Propose a new event-log-type in CHARRA X-BeenThere: rats@ietf.org 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: Fri, 28 Aug 2020 20:37:05 -0000 --=-=-= Content-Type: text/plain Panwei (William) wrote: > When the device boots, it needs to load/execute a lot of files, but the > order in which these files are loaded/executed is not deterministic or > hard to keep fixed, so it's difficult to give an accurate reference > value. > The method to overcome this difficulty is below: > 1. The Attester measures each file before execution, extends the hash > value of the file into PCR, and records the measurement information of > the file in the log. Does the Attester measure the files in a deterministic order? > 2. When doing the remote attestation, the Attester sends the final > values of the PCRs and the detailed logs to the Verifier. I remember this discussion. > 3. The Verifier has a list of reference values for all files. It > compares the hash value of each file recorded in the log with the > corresponding reference value. If all files' hash values match with > their reference values, then the Verifier extends the hash values one > by one according to the order recorded in the log, gets the final > value, and compares the final value with the PCR value sent by the > Attester. Why not impose some canonical ordering (even alphabetical) to how the files are recorded into the PCR, regardless of the order they are executed? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JausACgkQgItw+93Q 3WVjOAf/e4FNMJ7KVX3ycyc1GE//u4SD39yE2x306xOmacagO5scV5Zhf1GoeUqx OZN33GVmBXFYBg0cxFPeEep1YH+RdMIHbdIhARdUBKMZHgLUfhkJqXomVpB9914O mwWmpN8nXtWTH3YNg4RtjI+dNDro+/nQEIPOPVp+TvxZt7ZkMP3KoNdERxTn7/xP 5EnB3IDqc148rpKJYWBmw0ZSeYUdYEcfbJQSgXr+fo+xgtune1WMyBuqQ5iBttrG CJXaz01QFF7JnG2B+ETVJxuJMjUa/JW68bozWe6/63tCfTpzQnbrHBxbSOxWjs4X Sn+tM/r/+jJ1UmVEhW0HUb41uEx9jA== =87l3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 19:04:14 2020 Return-Path: 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 B9EF43A0F12 for ; Fri, 28 Aug 2020 19:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1k9bfRFrED8M for ; Fri, 28 Aug 2020 19:04:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4697F3A0F10 for ; Fri, 28 Aug 2020 19:04:12 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B7208617BDBC88392AEB; Sat, 29 Aug 2020 03:04:10 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 03:04:10 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 10:04:07 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Sat, 29 Aug 2020 10:04:07 +0800 From: "Panwei (William)" To: Michael Richardson , "rats@ietf.org" Thread-Topic: [Rats] Propose a new event-log-type in CHARRA Thread-Index: AdZ9F2S3YE6HUmniRGqctvSTG8eYFQAIIfcAABnn4vA= Date: Sat, 29 Aug 2020 02:04:07 +0000 Message-ID: <49bfbed9e55f4089aa2f9e57b1201725@huawei.com> References: <28425.1598647020@localhost> In-Reply-To: <28425.1598647020@localhost> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.99.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Rats] Propose a new event-log-type in CHARRA X-BeenThere: rats@ietf.org 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: Sat, 29 Aug 2020 02:04:14 -0000 From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Panwei (William) wrote: > > When the device boots, it needs to load/execute a lot of files, but= the > > order in which these files are loaded/executed is not deterministic= or > > hard to keep fixed, so it's difficult to give an accurate reference > > value. >=20 > > The method to overcome this difficulty is below: > > 1. The Attester measures each file before execution, extends the ha= sh > > value of the file into PCR, and records the measurement information > of > > the file in the log. >=20 > Does the Attester measure the files in a deterministic order? No, the order can't be guaranteed. > > 2. When doing the remote attestation, the Attester sends the final > > values of the PCRs and the detailed logs to the Verifier. >=20 > I remember this discussion. >=20 > > 3. The Verifier has a list of reference values for all files. It > > compares the hash value of each file recorded in the log with the > > corresponding reference value. If all files' hash values match with > > their reference values, then the Verifier extends the hash values o= ne > > by one according to the order recorded in the log, gets the final > > value, and compares the final value with the PCR value sent by the > > Attester. >=20 > Why not impose some canonical ordering (even alphabetical) to how the > files are recorded into the PCR, regardless of the order they are execute= d? This is not a secure manner, you need to cache the hash values before they = are extended into the PCR, so if a malicious file is executed it has the op= portunity to change its hash value before being extended into the PCR. So the secure manner is to extend the hash value of the file into PCR befor= e executing it. Regards & Thanks! Wei Pan > -- > Michael Richardson , Sandelman Software > Works -=3D IPv6 IoT consulting =3D- From nobody Mon Aug 31 13:11:52 2020 Return-Path: X-Original-To: rats@ietf.org Delivered-To: rats@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62A83A1933; Mon, 31 Aug 2020 13:11:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rats@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rats@ietf.org Message-ID: <159890470975.22734.105813408534177682@ietfa.amsl.com> Date: Mon, 31 Aug 2020 13:11:49 -0700 Archived-At: Subject: [Rats] I-D Action: draft-ietf-rats-eat-04.txt X-BeenThere: rats@ietf.org X-Mailman-Version: 2.1.29 List-Id: Remote ATtestation procedureS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 20:11:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote ATtestation ProcedureS WG of the IETF. Title : The Entity Attestation Token (EAT) Authors : Giridhar Mandyam Laurence Lundblade Miguel Ballesteros Jeremy O'Donoghue Filename : draft-ietf-rats-eat-04.txt Pages : 35 Date : 2020-08-31 Abstract: An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device. These claims are used by a relying party to determine how much it wishes to trust the entity. An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT. Contributing TBD The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rats-eat-04 https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-eat-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 31 13:13:42 2020 Return-Path: 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 E888C3A1935 for ; Mon, 31 Aug 2020 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com header.b=wnLSiOZU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=qualcomm.onmicrosoft.com header.b=Aburi14Z 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 UjOL_c9yja75 for ; Mon, 31 Aug 2020 13:13:39 -0700 (PDT) Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788403A1937 for ; Mon, 31 Aug 2020 13:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1598904819; x=1630440819; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sIVZyu/Z0q7KQWcPLMN19orWxCdDbDMY2kuLXDw4gFc=; b=wnLSiOZUQbUaUVrnYhPMWzTu+ljMgIvql+X+OwVlS2rg0xYLOZ+Z4wi8 FFOVYnWyIkJ1r0ZXYbR+nK3mDMVhbB4U6NyyJdxagq/QWYbtIIOXzx/dM iKh2jYz9jK7xa2Y8exlTXv43G7NQm7kL/Yim8gKjyhi1TdggnmecbvK9/ 0=; Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 31 Aug 2020 13:13:38 -0700 Received: from nasanexm03e.na.qualcomm.com ([10.85.0.48]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 31 Aug 2020 13:13:38 -0700 Received: from nasanexm03e.na.qualcomm.com (10.85.0.48) by nasanexm03e.na.qualcomm.com (10.85.0.48) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 13:13:38 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (199.106.107.6) by nasanexm03e.na.qualcomm.com (10.85.0.48) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 31 Aug 2020 13:13:38 -0700 Received: from BYAPR02MB4422.namprd02.prod.outlook.com (2603:10b6:a03:5c::31) by BY5PR02MB6593.namprd02.prod.outlook.com (2603:10b6:a03:213::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Mon, 31 Aug 2020 20:13:37 +0000 Received: from BYAPR02MB4422.namprd02.prod.outlook.com ([fe80::dc8c:ff85:33bc:1a6e]) by BYAPR02MB4422.namprd02.prod.outlook.com ([fe80::dc8c:ff85:33bc:1a6e%3]) with mapi id 15.20.3305.026; Mon, 31 Aug 2020 20:13:37 +0000 From: Giridhar Mandyam To: "rats@ietf.org" Thread-Topic: [Rats] I-D Action: draft-ietf-rats-eat-04.txt Thread-Index: AQHWf9L/vVS5CCvPkU2wXfQ8s4DBbKlSpoAA Date: Mon, 31 Aug 2020 20:13:37 +0000 Message-ID: References: <159890470975.22734.105813408534177682@ietfa.amsl.com> In-Reply-To: <159890470975.22734.105813408534177682@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=qti.qualcomm.com; x-originating-ip: [75.80.179.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 95a5ec6c-5c37-4ebb-d607-08d84dea584c x-ms-traffictypediagnostic: BY5PR02MB6593: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1051; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2ILw38+PLIWliPzEWFhXzRkkkp4UHz+JePYSqeysD1YPmDy8ixKFcG4tfeoxHoVYZs3RaYYfe/UVfQqFiwxhBQNhWnoOix5a0H8qYmNrEsKSNW7ZgtqvWI49fJkV3KEH6KPP4xGF+gmPHOh4L+88Y3R7X/pt2TUJDY/iYR5eRkDZT4QQdkRh3OhbbLjRa2MRqjAPESx1bnKH0t5RJMKh/PzKEniu6bw6O9Q0LlWHHM8nGvQYWHSnrxJqaJciI/Kt0umrOG88COyoK3Xpb0vAGut0nI95kY2hDGYAmMv+iEARSsf9qqc+aJOem7Hti7ovld0Kdd3DHajZvSyj8RY4JC1C3l4cyLPMqLDVfV1c/fGeiQ5JwwkIMjImfXn998iLChaKibNNvB3iQpfLrY/B4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB4422.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(346002)(39860400002)(376002)(2906002)(71200400001)(52536014)(8676002)(186003)(478600001)(83380400001)(33656002)(66574015)(26005)(8936002)(7696005)(6916009)(316002)(5660300002)(66946007)(66476007)(966005)(6506007)(55016002)(9686003)(64756008)(66446008)(66556008)(86362001)(76116006)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 67tcxeVoVOM+bJ57gxWoI9G1hOeigqXJ37rb56UoVkIDgXDM4T7eRxXS1HicMR397+bwnlzsbBXFGlORHvz6NCfUueZ/jnY6a89XRzp6E98ZxL/OXaNPK9hSMPNI6gJkBxzjUGKIBBsqAySY+0JEVN7n13zqAmk1+ResmbrRqIxEbgTHYh9FfRI8+qeL03YiIDRARafZzrKsOca1EtKBeCvcqd8pK8fJLIVRhj/0HlMKtL/Mljk/PSMbFFGpZXGT29KkwXEQQbdVVE4gEGc10N5rwnxjcmqw5FW0BXm/FmzU6Rp++DIHiKIJkQS0vR+26OywOeBGvSeAxBNeIm5hhpbjyn9EIN9j9Fo6/DrekPsLDSZItiSBQbmt4uBUuWm4eMUZah01XhVCZjjfe23xShW6iyxX1EL9anK9FLMJrMLXSHrhY0ZJm3OkTzEt4qWCGEAtnwgX1XPDLPL7WPaFYU7Jg49Qy5G5UyvLQKZX7lDIDXNsYAttQzjLumn9sXBU144h0tyHKsDB0Zh7bGXdCvcN0EKEjl4xz4ojVhdVRXmTE6AroXH06qFsHPc86Oo6z5CuVAwafQmXZJew3z8JDVCAHMuzHPrrkzi7JHMOsPz38YwKeMfVMSID0GgDwwqAPHEfMx4kR5gYlvyODf/yGA== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mkiz9KtT77x3pmTy36ONe1vXrKe7Vxvcaqhyjj1TAJGPWgwGNixkHqAoSNXRtEv8oJ2X5mwP2P716/C4DXbIL4mOFfeE83wy8lJMfSTF5WjS1EGqZ0HQ0rsHGDmIYoAHDzT4iHr2Me7n1MJ34/kY2dIHPgq0vBNv/DYjdbjTpLKIcl0J5oQ/NcsAut8T4ZyaxK21FCnzumtYEw2G8dr0hHkkNEYI4Pb/pJRtSk/uVEt/pVvdol5gq2LeGZW2vkn8DXi/EIrMZRzv75ivMXYWD9bJG+aaVXakZoZo8UN5pxUoEpAY/7jgkRimcyA7Gu23Rilq7MAvHheo+HLpN5i6xA== 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=6SV1z5TcXMshDagveDsp416D7i+YChIdrBPhPsZap9Q=; b=D7gOLcMWUeelkrzFuUZJGJEe/+Jph0lk9HZXY8GWfdxOH/+u8PT3a8WJjvgOMHH558WECSz/0Ima6sl9+gi6n9FSbcf/6L2tVwNdQYTyKFQFIbp30Q/s6+uUL59eAsB/J1GsmYu6rFgkvdewBrd+IuetGPrhHI72K6zAWhkvrm7XcbmEyGE6bajwA9W/PrPBLrq2CD2lXFiw9OZWHpPYW37r+JEwwPk9q2h8CaD5hp/5oCeeigCIZarmJUkgG3cOw8avzqhXBq3I4cb47lv+Xu4gBXBP1ZyYX/OueMNLMrjw+I3+QCffxDoZuFj+MqAKiuuIf04wJUW4g+2Ke/U0Rg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.onmicrosoft.com; s=selector1-qualcomm-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6SV1z5TcXMshDagveDsp416D7i+YChIdrBPhPsZap9Q=; b=Aburi14ZBK/AiReGKmIM9gM1DBQ5BgoJbxODc17tBIb70K7ysDzes7Nl7KD6CnsPPmskuaGu437xtX1jn5dyGi9QY/IhawfTN0auilBCQzJ+I8zucDMQNC0FDEa7Av1qSqHUMsl+i+b4TOHTtXs2YYxoc1G847LKuAb14rw+NP0= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR02MB4422.namprd02.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 95a5ec6c-5c37-4ebb-d607-08d84dea584c x-ms-exchange-crosstenant-originalarrivaltime: 31 Aug 2020 20:13:37.0902 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: nbWoDdTKATBvqkttxalofdO5+ZXiXqN7L4Nm7dI+0b14FYD5jLD39L4614+xM5UO/O2c/DhvL1zXTBgj/cuYLGJBU2D5885YECo52JRlXII= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR02MB6593 x-originatororg: qti.qualcomm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Rats] I-D Action: draft-ietf-rats-eat-04.txt X-BeenThere: rats@ietf.org 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, 31 Aug 2020 20:13:41 -0000 Please note that this is a touch-up to un-expire the draft. There are no c= hanges since ver. 0.3. -Giri -----Original Message----- From: RATS On Behalf Of internet-drafts@ietf.org Sent: Monday, August 31, 2020 1:12 PM To: i-d-announce@ietf.org Cc: rats@ietf.org Subject: [Rats] I-D Action: draft-ietf-rats-eat-04.txt ------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. ------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Remote ATtestation ProcedureS WG of the IE= TF. Title : The Entity Attestation Token (EAT) Authors : Giridhar Mandyam Laurence Lundblade Miguel Ballesteros Jeremy O'Donoghue Filename : draft-ietf-rats-eat-04.txt Pages : 35 Date : 2020-08-31 Abstract: An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device. These claims are used by a relying party to determine how much it wishes to trust the entity. An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT. Contributing TBD The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rats-eat-04 https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rats-eat-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats