encoder: pass the data type up through the encoder chain

In encoder_process(), the data type (the name of the encoder
implementation that produced the current encoding) is determined at the
deepest recursion level, but was not propagated up through the
recursion together with the other results of the recursive call.  As a
consequence, the abstract object handed to a chained encoder
implementation contained an OSSL_OBJECT_PARAM_DATA_TYPE parameter with
NULL data, in violation of provider-object(7), which specifies it as a
UTF8 string carrying the type of the object content.

This went unnoticed because no encoders provided by OpenSSL itself are
ever chained.

Also extend endecode_api_test to verify that a chained encoder
implementation receives the correct data type.

Assisted-by: Claude:claude-fable-5
Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Merge-date: Thu Aug 27 13:45:07 2026
Merged-from: https://github.com/openssl/openssl/pull/32019

1 files changed, 7 insertions, 0 deletions

diff --git a/test/endecode_api_test.c b/test/endecode_api_test.c
index 768bf215c04..44d45fa19d7 100644
--- a/test/endecode_api_test.c
+++ b/test/endecode_api_test.c
@@ -119,6 +119,13 @@ static int inter2pem_encode(void *vctx, OSSL_CORE_BIO *cout,
         || memcmp(p->data, STRUCTURE_NAME, p->data_size) != 0)
         return 0;
 
+    /* Likewise the data type, naming the encoder that produced the data */
+    p = OSSL_PARAM_locate_const(obj_abstract, OSSL_OBJECT_PARAM_DATA_TYPE);
+    if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING
+        || p->data == NULL || p->data_size != strlen(KEY_NAME)
+        || memcmp(p->data, KEY_NAME, p->data_size) != 0)
+        return 0;
+
     p = OSSL_PARAM_locate_const(obj_abstract, OSSL_OBJECT_PARAM_DATA);
     if (p == NULL || p->data_type != OSSL_PARAM_OCTET_STRING)
         return 0;