Re: [OAUTH-WG] [SPICE] SPICE Revocation
Denis <denis.ietf@free.fr> Fri, 29 March 2024 09:50 UTC
Return-Path: <denis.ietf@free.fr>
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 49CA5C18DBB3; Fri, 29 Mar 2024 02:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.937
X-Spam-Level:
X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-2.064, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 agGrHwCspivd; Fri, 29 Mar 2024 02:50:15 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 A4BA9C180B4F; Fri, 29 Mar 2024 02:50:15 -0700 (PDT)
Received: from [192.168.1.11] (unknown [90.91.46.145]) (Authenticated sender: pinkas@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id 31528780516; Fri, 29 Mar 2024 10:50:09 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------TQM9QjmVUyKyll86JCIh8IfH"
Message-ID: <b8af9e6c-4391-f0df-a2e1-1a031f9c1013@free.fr>
Date: Fri, 29 Mar 2024 10:50:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-GB
To: Orie Steele <orie@transmute.industries>
Cc: spice@ietf.org, oauth <oauth@ietf.org>, Michael Prorock <mprorock@mesur.io>
References: <CAN8C-_Kw1ajnH0zBVengsX-Y_wGk4G3DmOcmbQYYbV+NN03kKA@mail.gmail.com> <CAGJKSNSxRsZN_vMkU60-qVV=5i61tvbD8eDkOxEW5+zfHw0EPA@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
In-Reply-To: <CAGJKSNSxRsZN_vMkU60-qVV=5i61tvbD8eDkOxEW5+zfHw0EPA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/39dFi890Y76ntjjAHkuuWdq8YAo>
Subject: Re: [OAUTH-WG] [SPICE] SPICE Revocation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2024 09:50:20 -0000
This thread is related to the three roles model, i.e, Holder, Issuer and Verifier. However, I also copy this email to the OAuth WG, since it is currently developing draft-ietf-oauth-status-list. Thanks to Orie for providing the second link: https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal.md?ref_type=heads#ocsp-stapling. What first follows a copy/paste of some parts of the "Architecture Proposal for the German eIDAS Implementation". Then after, my observations follow. Various use cases and scenarios may require revocation: * the PID/(Q)EAA Provider wants to revoke its issued credential because the contained data is no longer valid * the Wallet Provider wants to revoke a Wallet Instance because Wallet Security Cryptographic Device (WSCD) or the Wallet Instance application is compromised or vulnerable * the user wants to revoke their Wallet Instance because they lost their smartphone * the user wants to revoke their PID * the PID Provider wants to revoke a PID because the person has died To enable revocation within the EUDI Wallet ecosystem, the following mechanisms for revocation are considered: (a) Certificate Revocation Lists (b) Status Lists (c) Online Certificate Status Protocol (OCSP) (d) OCSP stapling *My observations:* For case (a): "CRLs have seen some scalability limitations in the Browser TLS context, and it remains open to evaluate if CRL sizes remain manageable within the eIDAS ecosystem". For case (b): "it remains open to evaluate if this is sufficient for the eIDAS ecosystem". For case (c): "Therefore, usage of OSCP is /not/ recommended". For case (d): "a proposal applying the concepts to the PID credential formats is under development <https://datatracker.ietf.org/doc/draft-demarco-oauth-status-attestations/>. [i.e., draft-demarco-oauth-status-attestations-00] the concept has the privacy potential as the Relying Party does not fetch the revocation information itself". draft-demarco-oauth-status-attestations-00 looks interesting. Presently, this draft does not include a privacy considerations section. It is thus questionable whether it is able to support the unlinkability property [it cannot be distinguished whether two transactions are related to the same user or not]. Some nice characteristics are : * "the Relying Party does not fetch the revocation information itself". * "both the wallet and the verifier work without internet connectivity during the presentation phase". But what about a mechanism where, in addition, the holder does not fetch the revocation information itself ? Yes, neither the holder, nor the verifier, fetch itself any revocation information. Is it "mission impossible"? No, it isn't. A Wallet Provider is in a position to suspend (i.e., which is equivalent to a temporary revocation) any digital credential placed in a Wallet Instance. It is also in a position to invalidate the use of a Wallet Instance or to remove any digital credential placed in a Wallet Instance (which is equivalent to a definitive revocation). A Wallet instance is THE Holder, i.e., an application that needs to be a Trusted Application (TA) running in a TEE. Every time the holder (application) is online, it can transparently connect to the Wallet Provider. If instructed by a Credential Issuer, aWallet Provider can suspend any digital credential issued by that Credential Issuer. The digital credentials placed in a Wallet Instance will only be usable if the Wallet Instance has been online during, e.g., the last 24 or 36 hours. From a holder point of view (or a Wallet Instance point of view), each time it is online, it will connect to its Wallet Provider. If no digital credential needs to be suspended, then all the digital credentials will be usable during the next 24 or 36 hours, but no longer. The query made by the Wallet Instance to its Wallet Provider can be transparently repeated, e.g., every hour. If a suspension is requested by a Credential Issuer while the Wallet Instance is online, the suspension will occur at latest within, e.g., the next hour. The same mechanism can also be used to revoke the Wallet Instance when the individual lost his smart phone. All the other approaches would require the revocation (or the suspension) of each digital credential, one by one. This approach avoids to define new data structures that would need to be exchanged between a Holder and a Verifier or fetched by a Verifier. This approach would be fully privacy preserving. In particular, the unlinkability property will be supported. Note also that a suspension is much better than a revocation; for example, if a lost smart phone is found again by the legitimate individual. With this flexibility, the individual will no more necessarily ask for an immediate revocation which has sad consequences in terms of availability. The suspension state allows to recover the use of the wallet, e.g., within the same day. Whereas an individual was afraid of the consequences of the revocation, he will not be afraid of the consequences of a (temporary) suspension. This allows to reduce the risks and hence to improve the security level. eIDAS 2.0 does not currently allow the suspension state. Once, that approach will be known, maybe the eIDAS.2.0 draft will be modified. It is only a draft at this moment. Denis > Orie - this is great work. I definitely think that scoping out how > this approach could be used with SD-CWT could be an important part of > documenting the architecture. > > Mike Prorock > Founder > https://mesur.io/ > > > > On Thu, Mar 28, 2024 at 12:53 PM Orie Steele > <orie@transmute.industries> wrote: > > Hello, > > At IETF 119 OAUTH session, I shared some alternative solutions to > the "dynamic credential state" or "suspension and revocation > problem", in digital credentials. > > https://datatracker.ietf.org/doc/draft-demarco-oauth-status-attestations > > This approach offers some advantages and disadvantages over status > lists / CRL type dynamic state mechanisms that need to be fetched > over a network by relying parties, or fetched by holders and > presented alongside the credentials they monitor. > > The primary improvements are: > > 1. Reduce implementer burden for relying parties, many of which > might be forbidden from calling out to networks. > 2. Eliminate the bitstring status list, which can include decoy / > dummy values that can be used to track relying parties, or that > communicate or update state for credentials which are not > relevant to the transaction. > > There is some interesting commentary on this approach here: > > https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal.md?ref_type=heads#ocsp-stapling > > Which you might all find interesting. > > As a general comment, CRLs and OCSP can both address revocation > use cases and approaches in JOSE and COSE, and applications of > this approach to SD-CWT or SCITT Receipts are particularly > interesting to consider. > > Regards, > > OS > > -- > > > ORIE STEELEChief Technology Officerwww.transmute.industries > > <https://streaklinks.com/B6DNq7fQ0K3-fblaFg95UjF6/https%3A%2F%2Ftransmute.industries> > > ᐧ > -- > SPICE mailing list > SPICE@ietf.org > https://www.ietf.org/mailman/listinfo/spice > >