IETF Logo Mail Archive

Re: [Privacy-pass] Regarding the role of attester

Christopher Wood <caw@heapingbits.net> Mon, 15 May 2023 18:14 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22B7C1DF960 for <privacy-pass@ietfa.amsl.com>; Mon, 15 May 2023 11:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b="tlYphAGV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="E7KHtU9w"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVc85BCDjzWy for <privacy-pass@ietfa.amsl.com>; Mon, 15 May 2023 11:14:38 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC2FC1CCCB5 for <privacy-pass@ietf.org>; Mon, 15 May 2023 11:14:38 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 574A55C0200; Mon, 15 May 2023 14:14:37 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 15 May 2023 14:14:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1684174477; x=1684260877; bh=F5Hh5G+SlMCDj4zbXSwktC6BX GCWxfS57Mr6/RHZ3JM=; b=tlYphAGVGkKHYrqMkFN2dvseEtog+2OmRLGdxpY9X DiCljB0drtBpDmsovKtzO7YIA8acIV/D46SY98mVJd3SINN8dloIIl6WWIMdX1xl Vva3rxstn031bNVokLb8+hRWzv7qIorO0prQj6mjAuE0EsAUIjWMv0pvI/U1Qb16 ZankPhFvauP7NWwvAOwmid+6a4dJDa2j97+F+2uhw+0tYckDkyJJwD4EiPGWaHGb yK6xzUtV6DrxKVpFF3AOL5WmvxGTRkYN5RX4S21em32H4B29tVIC1Qjfo0zpIwrd +NQNdRrtIrmKjRjHZPHZSf1aRErH898JRJavZxBYGFr3g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684174477; x=1684260877; bh=F5Hh5G+SlMCDj4zbXSwktC6BXGCWxfS57Mr 6/RHZ3JM=; b=E7KHtU9wIeCqerCBl0gqwqsdsq9ya001emebgsKEYUcI5zlLA8H shAcdpGGNqs8SOe/Pkad6udtbgxivH4v1wdDCZlsTWtGOw4tfuxnOuj5hDZ5ciyf wv+0NX13D3V6WslAqAafHYzxpHiW/0GozstArvjzh75UnzXcczXV4sfYfdLpIMZp OX1yOS++l2fQPjVtTcLjoCfFWZ3CWNmPPhPLHgmi3FNcM28bTuyV+M1uGxc0u8FW gOiejl/8lqBz703wkx7OjdsBoQKFgat4OtdPdtuD0U3LndOgUX5mu57WgGYNS5OQ 6GfcpKpKmwebue7/eZJHvd/7ivI3kJBqN7w==
X-ME-Sender: <xms:jXZiZMGWcuigWUreFky-awMbl2JI_bGvnKg1AUCWCCY_rDy55tR_1A> <xme:jXZiZFWyHYyiJCA_vAU-dqe_csdUM-Wbqvj5TfZtSnuecdiSGyrhNqwHkG5hfvnMC YFHD3V2UenIyBMpZQw>
X-ME-Received: <xmr:jXZiZGKkmWqoAa7ubbQId5-aPBNEN_r2k_NjTK0_ageVQUiLaGET07OTkrXhk8AOV5m3QdQBC4f-etyJTEba-ImQjTO-0e-OE74LiTt4EZexOXa1z74Acw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeehjedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffvefgkfhfvffose htqhhmtdhhtdejnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeffudetlefhhe dtleeuteeuueehkeefffdtgeefvdetveehjefgheevfeetgedvvdenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:jXZiZOF1VjhyZ0xRNYBnBu7cFl3j3ekTUJFmq5FHXJtCoTvqiOHKYg> <xmx:jXZiZCUbaLDVI_rVjyLMlT7gYDCHlD_JS4xhvwaM_2nH2a4jA8iTbA> <xmx:jXZiZBNpuUGrPA_G6QLGJTuCLaHTDQHZ53sMdBKI_uK8CUxXG3Slkg> <xmx:jXZiZLcrXvMK51tbXNndY88qFCGiX-q8TSAvXgIo7JffF0CNc2xyag>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 May 2023 14:14:37 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Christopher Wood <caw@heapingbits.net>
In-Reply-To: <f9627a100be64813bfd6f5d93fb6a63b@huawei.com>
Date: Mon, 15 May 2023 14:14:35 -0400
Cc: "privacy-pass@ietf.org" <privacy-pass@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A91A6466-B655-436C-A96E-10D20A6A0F66@heapingbits.net>
References: <f9627a100be64813bfd6f5d93fb6a63b@huawei.com>
To: Wang Haiguang <wang.haiguang.shieldlab=40huawei.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/cE6D0jYl78aeRQsr4sil10BX1PE>
Subject: Re: [Privacy-pass] Regarding the role of attester
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2023 18:14:42 -0000

In Section 3.4.1., we clarify this discrepancy:

   [RFC9334] describes an architecture for attestation procedures. Using that architecture as a conceptual basis, Clients are RATS attesters that produce attestation evidence, and Attesters are RATS verifiers that appraise the validity of attestation evidence

We could update the definition in Section 2 to also make this clear, if desired. Reworking the entire architecture document and mental models of people using Privacy Pass today — especially for a document that’s through WGLC — seems like a big lift for alignment with the output of a different working group. I would be fine clarifying the existing terminology.

Best,
Chris

> On May 15, 2023, at 3:48 AM, Wang Haiguang <wang.haiguang.shieldlab=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi, all
> 
> I am reading the draft named the privacy pass architecture. 
> 
> I found there is a definition for attester as follows:
> Page 3, Attester: an entity that attests to properties of clients for the purpose of token issuance. 
> 
> However, in the RFC 9334, it has following statement:
> Page 8, the Attester role is assigned to entities that create Evidence that is conveyed to a Verifier. 
> 
> It seems the two documents have different indication on the role of attester.
> 
> In RFC 9334, the attester collects the evidence and sent to verifier for attestation.  In the document for the architecture of privacy pass, the attester is more like a verifier. I am not sure my understanding if correct or not. 
> 
> Can we align the definition of attester of RFC 9334 and the one in the privacy pass architecture to the same meaning?
> 
> Best regards
> 
> Haiguang Wang
> 
> Senior Researcher
> Huawei International Pte. Ltd 
> 
> 
>  
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass

v2.23.0 | Report a Bug | By Email