Incorrect LCP Certificate Revocation List URL (Distribution Point) about swift-toolkit HOT 7 CLOSED

Readium_LCP_Root_CA.crl is the Authority Revocation List (ARL) and EDRLab_CA.crl is the Certificate Revocation List (CRL). Both are managed by a tier, not EDRLab.
If a license provider stop being part of the LCP Network, its provider certificate is added to the CRL. This is the file which has to be looked at by the reading application.
Only if EDRLab was not managing anymore the LCP Network, then its certificate (which is used as root certificate in our app but is in fact an intermediate certificate) would be added to the ARL.
A change in managing authority is something to study in the future, just in case, but I think that no modification is needed in our R2 code for the time being.
But please look again at the R1 codebase because I can't believe we grab the ARL instead of the CRL there.

from swift-toolkit.

Oh I see, so the fact that Readium_LCP_Root_CA.crl is referenced from the certificate that "ships" with the apps (i.e. plain text cert file in Readium1, but binary-encoded inside the Readium2 lib) is normal, right?
I imagine that EDRLab_CA.crl is referenced from the certificate that comes within individual LCP licenses, right? (I will test this)
If both statements above are true, then I think that the Readium1 readium-lcp-client C++ lib indeed fetches the correct CRL URL for revocation of provider certs specific to individually-issued LCP licenses (in fact, I believe you did run a live test with one of the LCP vendors, right?) Additionally, if I am not mistaken, the Readium1 implementation also checks the CRL URL for revocation of the "root" EDRLab cert common to all apps. This is something the Readium2 implementations don't do.

from swift-toolkit.

What is strange is that the ARL should not be advertised as a CRL ... unless maybe this is normal procedure in x509 certs (I am no expert in this field).

from swift-toolkit.

Regarding Readium1 / readium-lcp-client: Laurent, could you please confirm that wasteland-from-revoked-provider.lcp.epub was successfully tested? (iOS / Android apps)

Just to verify my assumptions in r2-lcp-js, I added code to extract the CRL/ARL URLs from both types of certificates (i.e. app-shipped "root" cert (RSA key) + license-bundled "provider" cert (ECDSA key)), instead of using hard-coded ones. I can indeed see the correct URLs. I added code comments to record this conversation:
readium/r2-lcp-js@c84fbc6

Naturally, I double-checked (once again) that the existing r2-lcp-js CRL implementation works against Laurent's sample test file ("wasteland-from-revoked-provider.lcp.epub") => indeed, the revoked provider certificate is correctly handled (i.e. the native LCP lib returns an error message, and the app informs the user that the publication cannot be opened).

from swift-toolkit.

Yes, Readium_LCP_Root_CA.crl is referenced from the certificate that "ships" with the apps (the EDRLab "root" certificate). And EDRLab_CA.crl is referenced from each provider certificate.

The CRL control is still not ready on the iOS R2 Reader test app, but it should be ok on the Android R2 Reader, Aferdita is checking that.

from swift-toolkit.

Resolution:
Right now, the Android, iOS and NodeJS implementations of LCP (i.e. r2-lcp-[kotlin|swift|js]) all implement the same hard-coded URL for the CRL "Distribution Point", instead of extracting it dynamically from the provider certificate stored in the LCP license. This is fine I think, because the URL is "stable".

However, if the URL changes in the future, the implementations will break, because even though newly-generated LCP licenses will contain provider certificates with the correct updated CRL "Distribution Point" URL, implementations will continue to use the old one which may resolve in error (in which case: CRL ignored, dummy used instead), or success (in which case: probably outdated list of revoked certs).

from swift-toolkit.

The other CRL "Distribution Point" URL supplied by the "root" certificate that shipped with the app (in Readium1, via the app bundle itself, in Readium2, hard-coded into the native r2-lcp-client lib for both LCP 1.0-prod and basic-test profiles) ... this one is not used anywhere. I guess this is okay, because CRL is critical for revoking provider certs, not root.

Closing this issue now (and the other platforms too).

from swift-toolkit.