[Rats] 答复: Another RATS message flow model for consideration:

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Sat, 16 November 2019 10:16 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92029120122 for <rats@ietfa.amsl.com>; Sat, 16 Nov 2019 02:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 GJ3bvE-iRM53 for <rats@ietfa.amsl.com>; Sat, 16 Nov 2019 02:16:49 -0800 (PST)
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 F2713120119 for <rats@ietf.org>; Sat, 16 Nov 2019 02:16:48 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4162CFDD5CDFC5873BEE for <rats@ietf.org>; Sat, 16 Nov 2019 10:16:47 +0000 (GMT)
Received: from lhreml721-chm.china.huawei.com (10.201.108.72) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 16 Nov 2019 10:16:46 +0000
Received: from lhreml721-chm.china.huawei.com (10.201.108.72) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sat, 16 Nov 2019 10:16:46 +0000
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Sat, 16 Nov 2019 10:16:46 +0000
Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.245]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0439.000; Sat, 16 Nov 2019 18:16:39 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Another RATS message flow model for consideration:
Thread-Index: AdWcZLOLxoSOwSr8Rf6Q6jmW1MwH1gAAe8Vg
Date: Sat, 16 Nov 2019 10:16:39 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EA39666@DGGEMM531-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13EA3964E@DGGEMM531-MBS.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13EA3964E@DGGEMM531-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.32.53]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EA39666DGGEMM531MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/n7NnPqdd5NBXZ15u5I_PcYhRD4Y>
Subject: [Rats] 答复: Another RATS message flow model for consideration:
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Nov 2019 10:16:50 -0000

Oops, Some fixes of the below text:


发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Xialiang (Frank, Network Standard & Patent Dept)
发送时间: 2019年11月16日 18:13
收件人: rats@ietf.org
主题: [Rats] Another RATS message flow model for consideration:

Hi RATS architecture design team and all,
In addition to the current passport model and background check model. I think there is a third message flow model possibly for us to consider:
Attester < -------------------- > verifier < -------------------------------- > relying party
                               Evidence                              attestation results

The key point of the above model is that verifier has independent connection with attester and relying party respectively, and there are two independent message exchanges between the attester and verifier, between the verifier and the relying party. Of course, if needed, there can be some trigger condition and interaction between these two connections.
The relative advantage of the above model is simple, and each role only see what he needs to see, like: evidence is not seen by the relying party, attestation results is not seen by the attester.

I am wondering whether the architecture draft will consider it?

B.R.
Frank