Hi Ben, To give a bit of context: The question came up concretely for “identifier list”, which is getting defined in ISO 18013-5 (https://github.com/ISOWG10/ISO-18013/blob/main/Working%20Documents/Working%20Draft%20WG%2010_N2549_ISO-IEC%2018013-5-%20Personal%20identification%20%E2%80%94%20ISO-compliant%20driving%20licence%20%E2%80%94%20Part%205-%20Mobile%20driving%20lic.pdf) as a second option next to status list. Identifier list shares the overall structure and encoding of status list but for the payload uses an array of identifiers similar to CRL instead of the compressed byte array that status list uses. Since both options are allowed in that ISO draft, it would make sense to use the key for both options instead of defining a second EKU.
Generally speaking, I understand the concern that a credential issuer might not want to allow the certificate to be used with whatever status mechanism might exist in the future. Our mental modal was that the credential issuer is signing over each token/credential explicitly that selects the status mechanism (via the status claim). With that link, the issuer stays in full control of what status mechanism applies to the tokens/credentials they issue and we didn’t see problems in terms of possible abuse there. We could also change the text in the direction of the EKU being applied to status mechanisms that are using the status claim in the token/credential? That would make this limitation more explicit. Best Regards, Christian > On 22. Apr 2025, at 23:37, Benjamin Kaduk <ka...@mit.edu> wrote: > > On Tue, Apr 22, 2025 at 08:49:04AM +0200, Christian Bormann wrote: >> Hi all, >> >> >> >> We got feedback during the working group last call that we would like >> to >> incorporate: >> >> >> >> The Extended Key Usage is currently defined in a way that it can only >> be >> used for issuers >> >> of status list tokens. There are other mechanisms that are relatively >> similar to the token >> >> status list that would also benefit from this definition and we would >> like >> to loosen the text >> >> a bit to allow other status mechanisms to re-use the same EKU. >> >> >> >> PR: >> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/284/files >> >> >> >> Is anyone not comfortable with the proposed change? > > I'm not particularly comfortable with the proposal absent further > information about the scope of expected usage. OIDs are supposed to be > cheap, and are supposed to have well-specified semantics that do not change > over time. This proposal makes the semantics more vague and open to change > over time as new status mechanisms are defined. > > In particular, if the presence of this EKU is intended to be treated as the > issuer explicitly delegating signing authority, this proposal is having the > issuer sign a blank check that lets the holder of the EE certificate use > whatever new status mechanisms might be developed in the future. Without > some limitation on the scope of what constitutes such a status mechanism > it's hard to see that an issuer would have confidence it actually wants to > delegate that authority. > > Why can the parties responsible for these other status mechanisms not > define their own EKUs? > > -Ben > > _______________________________________________ > 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 To unsubscribe send an email to oauth-le...@ietf.org
