JOSE.OpenSSL.Headers is not compatible with platforms like iOSDevice or Android.

[wlandgraf]

I believe the reason JOSE.OpenSSL.Headers exist is because there are a few OpenSSL functions that are not imported by Indy, is that correct? Still, why there are many functions imported there that are already in Indy? Like PEM_read_bio_PUBKEY, SHA* functions, among others?

Is there a reason for this, or can this be refactored to use Indy OpenSSL functions directly? I can do that, but I just wanted to know if I'm missing something and if there a different reason for those functions to be imported in such unit. Thanks.

[wlandgraf]

In any case, there are functions that need to be used, like PEM_read_bio_RSA_PUBKEY. However, this makes the library incompatible with iOSDevice, because only static OpenSSL is allowed in such platform. Is there any idea about how to support iOSDevice?

[paolo-rossi]

Hello @wlandgraf

Yes the the reason for JOSE.OpenSSL.Headers is to integrate function not present in Indy OpenSSL header files... I don't know if in the meantime Indy developers added those function but I think that even with the last version of Indy I will need mine for sure.

If you can use Indy function to to the RSA and ECDSA signing it's ok (we can work on that together) but I fear that it's not possible... plus I want to implement the JWK standard and I already looked and need more function from OpenSSL that are not in Indy.

Let me conclude that in 2022 not having (in Delphi) a reliable crypto API like Java (or any other modern language) has, it's very sad! I've lost countless hours to implement something that it had to be in the language! :-( (ok, rant finished)

Ciao,
Paolo.

[wlandgraf]

Hi @paolo-rossi, yes, I understand and agree. But in the end, it's not possible to use RSA encryption in iOSDevice (to verify signatures of identity tokens, for example) because of the need of static linking.

I understand that this might be considered low priority as iOS Device is not a "popular" platform in Delphi, and making the binding static requires a significant effort.

But well, this issue is open nevertheless, for the record...

[JediThumper]

Hi Thank for responding and picking this issue up.

For me the issue is simply one of having FB4D able to work on iOS.

I'm hoping others will jump into this discussion ( I'm a hobby programmer so not as wise as many :)

Does FB4D even need the functions that won't compile? I'll in the other group also.

Once again thanks for the hard work and I hope we can get this fixed.

Alan

[SchneiderInfosystems]

The FB4D library uses the TJWS.SetKeyFromCert function to verify that the token is real and signed by the Firebase Cloud Authorization Service. If the situation is such that this function can no longer be provided for iOS plattform, I will simply remove this functionalty for iOS so that the whole project at least remains compilable for iOS. Thanks for an update in this thread if this issue gets resolved by the Indy team.