openssl: Cannot use the default DECODER with a provider-side STORE and KEYMGMT
I have a provider-side KEYMGMT and a provider-side STORE that calls default DECODER to decode a standard pubkey, which I want to IMPORT to my KEYMGMT. Decoding works great, but then ossl_store_handle_load_result / try_key_ref gets called, which compares the STORE provider with the KEYMGMT provider to determine whether to do LOAD or the EXPORT/IMPORT “dance”. It’s my STORE and my KEYMGMT so it does LOAD, but it’s the default DECODER that created the structure, so I end with an error.
https://github.com/openssl/openssl/blob/29b3fdad2b078f45f840f6e45b0fe483b77dbc6f/crypto/store/store_result.c#L209
This is a likely a re-appearance of a problem discussed in https://github.com/openssl/openssl/issues/13539 that the KEYMGMT provider is compared to the STORE provider, not the DECODER provider… it should really do the latter. See https://github.com/openssl/openssl/issues/13539#issuecomment-742426082 posted by @levitte.
Is this use-case supposed to work, please, or the STORE and the DECODER must belong to the same provider?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17 (17 by maintainers)
A store loader capable of loading keys must have a key manager associated with it in the same provider. When loading a key the store loader’s job is to load that key into a form that the associated key manager understands, and then the loader’s “load” function invokes the callback its been provided and supplies a reference to the associated key available from its key manager.
It absolutely must not pass back a key reference that it doesn’t understand, e.g. a key reference from some other provider’s key manager. A key reference is only useable in the scope of the provider that loaded it. A store loader’s key references implicitly are for the scope of the loaders own key manager.
It does not make sense to me for a store loader to pass back a key reference to some other provider’s key manager. For third party provider’s it is normal for them to be using a different libctx to the application (even a child libctx is counted as a “different” libctx). Therefore in the normal case the application may not even be able to get hold of the same key manager instance for this “other” provider because its been loaded into a libctx that the application does not have access to. It is a quirk of our own internal built-in providers (base and default) that they happen to use exactly the same libctx as the application - but this is not normally the case.
I suspect even our own file loader gets this wrong. I think it will just use any decoder (even those from another provider) and pass back unmodified “foreign” key references back to the application.
@levitte? Is my thinking above correct?