Extension Token Status List to x509

[steffenschwalm]

Currently Token Status List not useable for revocation x509 credentials which is critical in context of eIDAS where

a) each QEAA has to be signed with xqualified signature or seal based on x509 certificates
b) credentials in x509 legally possible and covered in ETSI TS 119 472-1 [Token Status List ]
(https://docbox.etsi.org/esi/Open/Latest_Drafts/ETSI%20DRAFT%20TS_119_472-1v0.0.6-public.pdf)

to avoid that trust service providers have to provide 2 different approaches for revocation, so 1 for credential 1 for its signature x509 shall be covered by Token Status List Spec. As mentioned by @paulbastian in brief discussion it could be possible to define an X.509 extension in ASN.1, analogous to the CRL Distribution Endpoint:

TokenStatusListDisitrubionEndpoint ::= SEQUENCE {
uri [0] RelativeDistinguishedName,
index [1] INTEGER }

Furthermore, minimal adjustments to the Validation Logic section would be necessary.

[tplooker]

Hi @steffenschwalm

Thanks for the suggestion.

Considering X.509 infrastructure is pre-existing, two approaches to revocation is where one is based on CRL for the certificates while the other based on this draft for the reference tokens is un-avoidable.

Secondly many implementers that are using X.509 certificates as the basis of trust for digital credentials issued under eIDAS are looking to use pre-existing X.509 libraries and PKI without modification and this proposal would require all this infrastructure / code libraries be updated for little benefit.

Thirdly the basis of this draft from the beginning was about catering to reference tokens in the JOSE and COSE formats and not other data structures such as X.509 certificates. The draft is already quite significant (in terms of length) and our preference as editors is that if implementation interest emerges for this that we could define an extension specification later that fulfils this need. For those reasons we're going to mark this issue pending close as its out of scope for our draft.

[steffenschwalm]

@tplooker thanks for your comment.

1. it`s not unavoidable as shown, especially not if you use signatures for JWT
2. that`s wrong as it would mean for QTSP to provide 2 different revocations for same subject:

• QEAA require QES(QSeal acc. annex V eIDAS regulation
• in case StatusToken List used for attestation itself your great approach would mean: 1 revocation for attestation, 1 for its signature and both have to be correlated, certified etc. acc. to ETSI TS 119 471, 472-1 etc. The only one who appreciate this are consultants and Conformity Assessment Bodies but not the trust service providers who have to deal with it

3. This was birth defect from beginning especially after eIDAS 2.0 was published. Now is chance to change it

Recommend that decision done by Working Group and not editors of which no one is QTSP who have to deal with your specification. Means if you close I`ll open again and request decision by WG