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

Tommy Pauly <tpauly@apple.com> Mon, 15 May 2023 18:35 UTC

Return-Path: <tpauly@apple.com>
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 2F068C1DF989 for <privacy-pass@ietfa.amsl.com>; Mon, 15 May 2023 11:35:33 -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, 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=apple.com
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 PgOhTvkgPuPI for <privacy-pass@ietfa.amsl.com>; Mon, 15 May 2023 11:35:32 -0700 (PDT)
Received: from rn-mailsvcp-mx-lapp02.apple.com (rn-mailsvcp-mx-lapp02.apple.com [17.179.253.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 9E529C1DF97B for <privacy-pass@ietf.org>; Mon, 15 May 2023 11:35:32 -0700 (PDT)
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-mx-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPS id <0RUP00F7ZQB7IY30@rn-mailsvcp-mx-lapp02.rno.apple.com> for privacy-pass@ietf.org; Mon, 15 May 2023 11:35:32 -0700 (PDT)
X-Proofpoint-GUID: 2rA8pQul0rtwMJyUn6RamNa5rdNj5r8b
X-Proofpoint-ORIG-GUID: 2rA8pQul0rtwMJyUn6RamNa5rdNj5r8b
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.957 definitions=2023-05-15_17:2023-05-05, 2023-05-15 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305150156
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=iOdLr26GUF2cw3gQhSWYEFaA1dhIqa0Q5/jtvdTzr7o=; b=vd71GJsZsNrrIQESe5HWikr1enGBxLpWjaTtXMUoVtxSu4BMafbMaUK1mwSIbdMH/0mr +dpV2Q8sZxHVTMiyEFhZpuL/tQUHttK2Cyg508o8wvmPp74LIqM0NO9UVCK2UBqkdjIA ocZRnej/WeOggTk8aQYcxJ7o/fjaZAWKkvmRUzAJUun/v8XXipf8ubU1sHPTT7we412x SK6znLYMHefuuXfmJ++luhu6J4nkk+E7tc9QyuCo3qOqxciUZax+8/2esafj6dECzJXk 1ELwQvUt9SXMAUFw370fUPo3AXTXnAA75Cx7QhT4QGlgfwUFylFWqYhCkZHu3fw3BVni XQ==
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPS id <0RUP008ASQB7VYR0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 15 May 2023 11:35:32 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) id <0RUP00V00Q8WHY00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 15 May 2023 11:35:31 -0700 (PDT)
X-Va-A:
X-Va-T-CD: a76e746662f71e8f03430028ee5d52f3
X-Va-E-CD: 70e3f6de3bfdefac10fcc1fd7bdf2ff2
X-Va-R-CD: 33df8080cee492a9a1d1fc7b1cff90aa
X-Va-ID: b97a25be-5208-4add-ba8f-93c96d7acccd
X-Va-CD: 0
X-V-A:
X-V-T-CD: a76e746662f71e8f03430028ee5d52f3
X-V-E-CD: 70e3f6de3bfdefac10fcc1fd7bdf2ff2
X-V-R-CD: 33df8080cee492a9a1d1fc7b1cff90aa
X-V-ID: 5ac94580-2978-403d-9daf-a65a569bb5ee
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.957 definitions=2023-05-15_17:2023-05-05, 2023-05-15 signatures=0
Received: from smtpclient.apple (unknown [17.11.174.20]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPSA id <0RUP00DCEQB7U300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 15 May 2023 11:35:31 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3755.100.3\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <A91A6466-B655-436C-A96E-10D20A6A0F66@heapingbits.net>
Date: Mon, 15 May 2023 11:35:21 -0700
Cc: Wang Haiguang <wang.haiguang.shieldlab=40huawei.com@dmarc.ietf.org>, "privacy-pass@ietf.org" <privacy-pass@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <37D31378-F2E8-4A45-8998-5E92C9557B32@apple.com>
References: <f9627a100be64813bfd6f5d93fb6a63b@huawei.com> <A91A6466-B655-436C-A96E-10D20A6A0F66@heapingbits.net>
To: Christopher Wood <caw@heapingbits.net>
X-Mailer: Apple Mail (2.3755.100.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/4zE2jvPFMVwbDSzvOHlT5TdSFkc>
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:35:33 -0000

I agree with Chris that it’d be preferable to keep the terminology here consistent, given that Privacy Pass has been using this for a while now, and it’s been adopted outside of the IETF WG. We did discuss this as we added references to RATS, and that led to the section that Chris pointed out where we provide the translation between RATS and Privacy Pass terminology.

Within RATS, the “attester” is the client, because the entire architecture is about attestation. In Privacy Pass, the client has several roles, and providing attestation evidence is only one part — calling the privacy pass client the “attester” throughout the documents would be highly confusing.

I’d support any further updates for clarity to the document to make sure this is obvious to readers, but I don’t think we should change the terminology for Privacy Pass.

Thanks,
Tommy

> On May 15, 2023, at 11:14 AM, Christopher Wood <caw@heapingbits.net> wrote:
> 
> 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
> 
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass