Hi Steffen,
with my chair hat on: Discussions at the OAuth security workshop do not
impact decision-making in this group, as the workshop is not an official
IETF activity.
That said, I wonder if it might make sense to propose the status list
extension for X.509 certificates to a group where the relevant expertise
is present, namely LAMPS. The advantage of this approach is that it
would also engage the community working on PKI infrastructure (such as
RAs/CAs), allowing them to be informed about this work and share their
perspectives.
Ciao
Hannes
Am 05.03.2025 um 09:30 schrieb Steffen Schwalm:
Hi Christian,
although it´s a bit unusual to use one workshop as seemingly feedback
for decision: if you think that covering x509 with TokenStatusList is
out of scope of OauthWG the scope of the TokenStatusList shall be more
precise.
Currently it only mention that “This document defines a Status List
data structure that describes the individual statuses of multiple
Referenced Tokens. A Referenced Token may be of any format, but is
most commonly a data structures secured by JOSE or COSE.”
Means you focus on credentials like SD-JWT VC, mDoc. In case you focus
on eIDAS or similar it shall be clear that the spec is useable for
Personal Identification Data (PID) resp. any credential without any
signatures based on x509 certificate only.
Reason: In case of (Q)/pubEAA the credential will be signed with an
advanced or qualified signature using x509 where TokenStatusList not
useable and as for x509 OCSP or similar might be used the privacy
advantage of TokenStatuslist can be eliminated.
For those ones thinking that only for QEAA a QES/QSeal needed: sorry,
also for pubEAA or EAA in case of Proof of Origin (also PoE, as TS
contains at least AES) needed, and issue occurs for AES/ASeal too.
Best
Steffen
*Von:*Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org>
*Gesendet:* Donnerstag, 27. Februar 2025 16:41
*An:* Michael Jones <michael_b_jo...@hotmail.com>; Brian Campbell
<bcampb...@pingidentity.com>; Filip Skokan <panva...@gmail.com>
*Cc:* oauth <oauth@ietf.org>
*Betreff:* [OAUTH-WG] Re: Status List Feature Request
*Caution:* This email originated from outside of the organization.
Despite an upstream security check of attachments and links by
Microsoft Defender for Office, a residual risk always remains. Only
open attachments and links from known and trusted senders.
Hi all,
We had a session on this topic in the OAuth Security Workshop
(with Brian, Filip and Mike present) and asked for feedback.
Everyone that voiced their opinion was against this extension in the
scope of the current
draft and the OAuth Working Group, but there was the remark to make
sure that this draft
allows for this feature if people wish to create this extension (as
Filip also stated previously
here on the mailing list).
Slides we used with short notes on the Feedback we got:
https://docs.google.com/presentation/d/1NGYsJgwGOBDRbop9OLAbj6_0Aoo3FhAyabu-aE4ghyk/edit#slide=id.g33a15d709f8_0_331
Best Regards,
Christian
*From: *Michael Jones <michael_b_jo...@hotmail.com>
*Date: *Wednesday, 26. February 2025 at 18:05
*To: *Brian Campbell <bcampb...@pingidentity.com>, Filip Skokan
<panva...@gmail.com>
*Cc: *Christian Bormann <chris.borm...@gmx.de>, oauth <oauth@ietf.org>
*Subject: *RE: [OAUTH-WG] Re: Status List Feature Request
X.509 already has its own revocation infrastructure (in fact, more
than one kind!). We needn’t complicate this spec to add another one
for X.509.
-- Mike
*From:*Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>
*Sent:* Wednesday, February 26, 2025 4:46 PM
*To:* Filip Skokan <panva...@gmail.com>
*Cc:* Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org>; oauth
<oauth@ietf.org>
*Subject:* [OAUTH-WG] Re: Status List Feature Request
I concur with Filip's perspective.
On Wed, Feb 26, 2025, 4:21 PM Filip Skokan <panva...@gmail.com
<mailto:panva...@gmail.com>> wrote:
I believe it is inappropriate and wildly out of scope for an oauth
document to define X.509 extensions, which IIUC is needed in order
to define the Status Claim for X.509? The important thing to make
sure is that the document does not preclude a future X.509
extension being drafted (wherever its appropriate place may be)
that makes use of the status list, and that already appears to be
the case.
S pozdravem,
*Filip Skokan*
On Fri, 7 Feb 2025 at 14:57, Christian Bormann
<chris.bormann=40gmx...@dmarc.ietf.org
<mailto:40gmx...@dmarc.ietf.org>> wrote:
Hi all,
While going through the feedback and issues on github, there
was one bigger discussion point that we would like to bring to
the mailing list. Steffen Schwalm asked for support for X.509
Certificate revocation with the Status List - in that case the
Status List describing the status of an X.509 Certificate
(relevant issue
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243
<https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243>).
That would mean defining an extension to X.509 to embed the
relevant information for a Status List (URI and index) and
creating validation rules etc.
While we understand the general motivation as is discussed in
more detail in the issue, it would be somewhat of a change of
scope for the Status List draft. We felt it might be out of
scope of the OAuth Working Group and rather in scope of other
working groups like lamps? Any comments/opinions would be
appreciated!
Best Regards,
Christian Bormann
_______________________________________________
OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org>
To unsubscribe send an email to oauth-le...@ietf.org
<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org>
To unsubscribe send an email to oauth-le...@ietf.org
<mailto:oauth-le...@ietf.org>
*/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly
prohibited. If you have received this communication in error, please
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./*
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
