Hi Christian,
+ 1 to Benjamin
I am not comfortable either with the proposed change.
The current EKU is there to be used with Status List Tokens that contain
a compressed byte array of statuses.
Using the same EKU would work, if an addition would be made to include
into the current draft the second format
... but nobody has proposed such addition during the second WGLC.
In order to use a structure that would contain "an array of identifiers
similar to CRL instead of the compressed byte array
that status list uses", a different EKU should be defined in another
document that explains this structure.
Denis
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 <[email protected]> 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 [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
