[OAUTH-WG] Re: We cannot trust Issuers
John Bradley <ve7jtb@ve7jtb.com> Mon, 22 July 2024 22:30 UTC
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D012C1D620D for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2024 15:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20230601.gappssmtp.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 KaMfdS8NCiiG for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2024 15:30:08 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 70C5DC1DA1F2 for <oauth@ietf.org>; Mon, 22 Jul 2024 15:30:08 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-52f04c1e58eso1935894e87.3 for <oauth@ietf.org>; Mon, 22 Jul 2024 15:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20230601.gappssmtp.com; s=20230601; t=1721687406; x=1722292206; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qRAeh5e7s+gUeAaQQn+2nrrxZGJnyX8NgVsXLdU1pBw=; b=G7phlDyJCVnpz4kDUIpxwK3LPayRpUtn0gHSN/IAJZCGqWTjoBwGFnaVSVTBvyimxr ZQc2DX6Z5MwscIxlavWlQsyDADUMjqnGJBwvZ3AnN7OO3M0uGl2CYDvR3LB/LhNmmQht 3A4aHxBuR5z27Gn2Gr+hqBGKO6e+ftSHghq4ZKAThui7yzgs/i2tw2HdgKFK0rnAA6V9 r8f00Kz5h3y+Fd11P5G7Us2p2K0StDiTLAkdHcIfGZJW1Xje285a+bYLtKqyvL3gI6Gc xnIZyApXHUPvsYctIfU6c/b3CUf9gGgfA/POBsNTZlkUIMQIOT5IFZjHQLTIX7j3GB/3 u/3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721687406; x=1722292206; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qRAeh5e7s+gUeAaQQn+2nrrxZGJnyX8NgVsXLdU1pBw=; b=YMIeuYWax7LK6I6d6O0kaFc9SJdnHiIybTq0Jr4Nxhe9Z0FJgudR+Hk56o4zjaZG+9 PILr3hidnjnMjU2YLxlHLkonuOtHpuTqOunD71M9bsJbYP9ghQJHrIPoIPJZIA0ICEgG CwptB9q2gOGBmQzHj4ABo12ghnXELnnET9pFBKhwZ3n6CJDG37XcbI91gIWLqm8OUmCj zV9Rua33S0p9Oc5sVrsc2YXoYkGr5vRp2V1G2i0SLhZev8OiUD8woAXUAP+Nsyt+GEPM 1Jf6bxbx7JOTgAh9vJcJQFECzreqgNMS7UrJe2hkQIEXxSwNKSSUjRJky3G/fOQSmG/y nDpA==
X-Gm-Message-State: AOJu0Yw5tjbd/wvNubqQVQHAZziQr9RyqpkkySnmwoJYigpX7zYqgXOV LQW9k3F8Xa2eV8oRq/LtDI5RpPBYAeUEikJd4K+zS/WJYd1Ez39W7lMQ4uMJp3IwgQOYFfN0GXr YQo+lS/fsabKlsl1N+u1GDvYdYuU3k/Fw6XFJMpsYTTOex+C6LG4qUw==
X-Google-Smtp-Source: AGHT+IH2Mgb34Zdq8v3GF+ycf/fLqiUlX71t8wby3EqLevISNLunbAvvU5l8py9Bkb1V05bPNXJBK6e8iMAmQ1CBed8=
X-Received: by 2002:a05:6512:3b82:b0:52e:9f7a:6e6 with SMTP id 2adb3069b0e04-52efb7ae437mr6837411e87.41.1721687406138; Mon, 22 Jul 2024 15:30:06 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0cmy03viT6wboUZeVu_8Yf-m7As0rxcjpda2W_Xw6ohKNg@mail.gmail.com>
In-Reply-To: <CACsn0cmy03viT6wboUZeVu_8Yf-m7As0rxcjpda2W_Xw6ohKNg@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Mon, 22 Jul 2024 15:29:53 -0700
Message-ID: <CAANoGhLsm1yqJvKuPEH_is-ep60EVNfLfi17T9M17KJFfAFiNQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000041faf1061ddd9632"
Message-ID-Hash: ENFPVSQGUUWNFD4VZNRIMXMHZXE7SZDQ
X-Message-ID-Hash: ENFPVSQGUUWNFD4VZNRIMXMHZXE7SZDQ
X-MailFrom: ve7jtb@ve7jtb.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF oauth WG <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: We cannot trust Issuers
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bT3lkhNfTj955VpuIyjsYnm7OJo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
I agree that single-use proof keys and batch issuance are a must. Issuer verifier collusion is admittedly a problem. To address that we do need different cryptographic methods. MDOC also has the same issue. We should document the risk, but short of stopping EUID and mobile driver's license deployment, we have limited options. Hopefully, we can make quick progress on JWP. John B. On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd <watsonbladd@gmail.com> wrote: > Dear Oauth, > > I'm disappointed to see SD-JWT work continue with inadequate privacy > considerations. The fact is an Issuer can link any showings to > issuance of the credential. This is not foregrounded sufficiently in > privacy considerations, nor do we discuss how to ensure users are > aware. We really need to use more RFC 2119 language and highlight > these issues. Section 11.1 about local storage which has never been an > IETF concern before is far more prescriptive than 11.4, and that's not > a good thing. To be clear, the threat model must include an issuer > that is a government issuing credentials that if used to verify age on > certain websites or via a digital wallet on site, and learned about by > the issuer who may have access to data from the site, will result in > imprisonment or execution. This is not a hypothetical scenario. > > Users and UX designers will have intuitions that do not match the > reality and that result in bad decisions being made. That's on us. A > driver's license doesn't leave a trace of where you showed it, but the > SD-JWT does. > > At a minimum I think we mandate batch issuance and one time usage > using RFC 2119 language. We need to say in clear, unambiguous English > that this mechanism enables an issuer to connect every presentation of > a credential to the issuance. > > Sincerely, > Watson Ladd > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org >
- [OAUTH-WG] We cannot trust Issuers Watson Ladd
- [OAUTH-WG] Re: We cannot trust Issuers John Bradley
- [OAUTH-WG] Re: We cannot trust Issuers Watson Ladd
- [OAUTH-WG] Re: We cannot trust Issuers Richard Barnes
- [OAUTH-WG] Re: We cannot trust Issuers Michael Prorock
- [OAUTH-WG] Re: We cannot trust Issuers Dick Hardt
- [OAUTH-WG] Re: We cannot trust Issuers Wayne Chang
- [OAUTH-WG] Re: We cannot trust Issuers Leif Johansson
- [OAUTH-WG] Re: We cannot trust Issuers Wayne Chang
- [OAUTH-WG] Re: We cannot trust Issuers Watson Ladd
- [OAUTH-WG] Re: We cannot trust Issuers Nat Sakimura
- [OAUTH-WG] Re: We cannot trust Issuers Brian Campbell
- [OAUTH-WG] Re: We cannot trust Issuers Tom Jones
- [OAUTH-WG] Re: We cannot trust Issuers Watson Ladd
- [OAUTH-WG] Re: We cannot trust Issuers Brian Campbell
- [OAUTH-WG] Re: We cannot trust Issuers Watson Ladd