Conversation
|
@petrovr, I think you're interested. It should start to answer questions you have asked recently. |
|
Richard Levitte wrote:
@petrovr, I think you're interested. It should start to answer questions you have asked recently.
Right now it look like separate functionality and at moment I cannot see
relation to key management.
Roumen
|
It's for internal management of keys that are stored in the provider. Without that, we would have to replicate its functionality in every public key operation type (such as keyexch) we create. I could have placed the OSSL_STORE stuff in KEYMGMT, but since OSSL_STORE handles more than just keys, that doesn't seem appropriate. |
|
What I just failed to say is that there's a need for something that manages the relationship between an |
|
Well, I like that something moves about Providers / STORE / KEYMGMT. |
This is made in the same fashion as the EVP_PKEY_*_fromdata functions, for uniformity.
This adds a new function, OSSL_STORE_open_ex(), which works like OSSL_STORE_open(), but also takes a library context and a property query string.
levitte
force-pushed
the
ossl_store-for-providers
branch
from
249aa54 to
cea5f6a
Compare
|
I've done a bit of an update. It's not at all ready yet to get out of WIP, but getting closer. One thing I added today was the provider interface documentation, |
|
|
||
| A STORE implementation may pass an object in raw encoded form in the | ||
| "rawdata" form, and indicate the encoding with "rawencoding". | ||
| Currently, the only supported encoding is "DER". |
There was a problem hiding this comment.
Do we specifically reject non-DER BER/etc.?
There was a problem hiding this comment.
There are certain non-DER features that we don't support, yeah
There was a problem hiding this comment.
That's not a terribly confidence-inspiring answer -- if we claim to only support "DER" I would interpret that to be "strict DER" and that we reject all non-DER features, not just some of them.
There was a problem hiding this comment.
Well, strictly speaking, we will support whatever the d2i functions support. I think it's strict DER, but am not 100% sure.
| In both cases, the identity is a byte string. Exactly what that byte | ||
| string contains is undefined here. This depends on the provider and | ||
| what it handles. | ||
|
|
There was a problem hiding this comment.
This page would probably benefit from an example of some form (not necessarily a worked example of using the API; a concrete statement of what parameters are created from a particular identity string might suffice).
There was a problem hiding this comment.
I'm not sure I understand. Doesn''t "The result is written to I<*ppkey>." answer that question?
There was a problem hiding this comment.
I was thinking in the general vein of "such as DSA parameters p, q, and g L<openssl-dsaparam(1)>"
There was a problem hiding this comment.
So basically, what we actually need is a general description of an EVP_PKEY, and link to that.
There was a problem hiding this comment.
That description could match something quite useful, yes. (It could also match something else, so ... I'll try to look at a PR if one appears.)
|
Hi @levitte , After quick review I wonder how to deal with specific key "handle" (a reference to external data that allows key to be identified). Next I cannot see why is responsible for UI prompts? The external provider(device) may require password/pin to access data. It could be for whole "store" or for "certain" elements. Next pass may be requested on each key use (FIPS requirement). I'm not familiar with provider API so may be above questions are not relevant. |
|
Closing this in favour of #12512 |
4 participants
This is a very early draft, just to show a line of thought to implement this.