On 3/3/21 11:25 AM, Stefan Eissing wrote:
>
>
>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rpl...@apache.org>:
>>
>>
>>
>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>
>>>
>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing
>>>> <stefan.eiss...@greenbytes.de>:
>>>>
>>>>
>>>>
>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing
>>>>>>> <stefan.eiss...@greenbytes.de>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> typedef struct ap_bytes ap_bytes;
>>> struct {
>>> const char *data;
>>> apr_size_t len;
>>> } ap_bytes;
>>>
>>> AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char
>>> *server_name, const ap_bytes **pcertificate_key_pem);
>>
>> Crossing posts :-). Quick questions:
>>
>> 1. What is the need for the len field above? I think PEM encoded data could
>> be nul terminated. Or do you want to leave an option
>> for DER data?
>
> I have been in too much contact with languages that do not NUL-terminate
> strings, it seems. We could just make it a "const char **" then.
>
> I do not like to define something generic parameters where the additionals
> use cases are unclear and may never happen. So, no DER foreseen by me. I
> think for the amount of data that is passed with keys/certificates, a PEM
> encoding is the most portable and should work fine.
PEM seems to be a good choice and having a clear interface as well. Hence +1 to
PEM only.
>
>> 2. As there is only one ap_bytes ** above, do you want to merge the PEM
>> encoded certificate and key in one string?
>
> That was the thought. When I started with mod_md, I kept them separate
> because everyone else seem to be doing it. But I do not really see any
> benefit in that, really. But then, I am ignorant of a lot of things, I found
> in life...
I think having them together is fine, the only question is if this makes it
harder to use for others if they keep them separate.
Regards
Rüdiger
