Documentation for the provider Key Exchange operation#9506
Documentation for the provider Key Exchange operation#9506mattcaswell wants to merge 1 commit intoopenssl:masterfrom
Conversation
|
Just a question: does this mean a vendor can add its own custom cipher suites to TLS protocol, for instance TLS1.3, without modifying the code in |
|
It doesn't yet, but it could be possible in the future. |
paulidale
left a comment
paulidale
left a comment
There was a problem hiding this comment.
Treat all these comments as suggestions (and one as a question).
I'm content with the documentation as it stands but please consider the minor wording changes.
| static ossl_inline OSSL_OP_keyexch_newctx_fn | ||
| OSSL_get_OP_keyexch_newctx(const OSSL_DISPATCH *opf); | ||
|
|
||
| B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as |
There was a problem hiding this comment.
s/numbers/integers/ perhaps? I'm not fussed either way.
There was a problem hiding this comment.
I left it as is for consistency with several other pages which have the same sentence.
| OP_keyexch_init() initialises a key exchange operation given a newly created | ||
| provider side key exchange context in the B<ctx> paramter, and a pointer to a | ||
| provider key object in the B<provkey> parameter. | ||
| The key object will have been previously generated, loaded or imported into the |
There was a problem hiding this comment.
s/will/should/ ?
Here and below.
Again, I'm not fussed if you don't want to change it.
There was a problem hiding this comment.
I changed it as requested.
|
|
||
| =head2 Shared Secret Derivation Functions | ||
|
|
||
| OP_keyexch_init() initialises a key exchange operation given a newly created |
There was a problem hiding this comment.
Does it have to be newly created to the initialised???
There was a problem hiding this comment.
I dropped the newly created bit.
| secret. | ||
| A previously initialised key exchange context is passed in the B<ctx> | ||
| parameter. | ||
| The derived secret should be written to the location B<secret> which should not |
There was a problem hiding this comment.
s/should/will/ ??
s/which should/but will/
There was a problem hiding this comment.
This is talking about the provider responsibilities when implementing these functions. "Should" seems to make more sense to me in that context.
| parameter. | ||
| The derived secret should be written to the location B<secret> which should not | ||
| exceed B<outlen> bytes. | ||
| The length of the shared secret should be written to B<*secretlen>. |
There was a problem hiding this comment.
s/should/will/
Again here and below.
|
|
||
| OP_keyexch_set_params() sets key exchange parameters associated with the given | ||
| provider side key exchange context B<ctx> to B<params>. | ||
| Any parameter settings are additional to any that were previously set. |
There was a problem hiding this comment.
Is this a can of worms we want to open?
We'll get ordering dependencies if we do but might lose some efficiency if we don't.
I'm having AES GCM flashbacks where everything can happen in any order -- the PARAMs approach can group everything together and let the provider side handle the ordering (I see this as the major improvement for PARAMs instead of ctrl calls).
There was a problem hiding this comment.
I think we have little choice in order to maintain compatibility with the way the existing ctrl functions work.
|
|
||
| =head1 RETURN VALUES | ||
|
|
||
| OP_keyexch_newctx() and OP_keyexch_dupctx() should return the newly created |
| provider side key exchange context, or NULL on failure. | ||
|
|
||
| OP_keyexch_init(), OP_keyexch_set_peer(), OP_keyexch_derive() and | ||
| OP_keyexch_set_params() should return 1 for success or 0 on error. |
|
Pushed. Thanks. |
Reviewed-by: Paul Dale <[email protected]> (Merged from #9506)
4 participants
No description provided.