[gnutls-devel] GnuTLS | Read Certificate Transparency (RFC 6962) SCT extension (!1367)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Sun Mar 21 19:31:38 CET 2021
Daiki Ueno commented on a discussion on lib/x509/x509_ext.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1367#note_534253834
> + return get_sigalg_for_sha1(sig_algo);
> + case 3: /* sha224 */
> + return get_sigalg_for_sha224(sig_algo);
> + case 4: /* sha256 */
> + return get_sigalg_for_sha256(sig_algo);
> + case 5: /* sha384 */
> + return get_sigalg_for_sha384(sig_algo);
> + case 6: /* sha512 */
> + return get_sigalg_for_sha512(sig_algo);
> + }
> +}
> +
> +static int write_sigalg(gnutls_sign_algorithm_t sigalg, uint8_t *out)
> +{
> + switch (sigalg) {
> + case GNUTLS_SIGN_RSA_MD5:
I was thinking something like below, similar to the arrays defined in `lib/algorithms/*`:
```c
struct sct_sign_algorithm_st {
uint8_t codepoint[2];
gnutls_sign_algorithm_t sign_algo;
gnutls_hash_algorithm_t hash_algo;
};
const struct sct_sign_algorithm_st[] = {
...
{
.codepoint = { 0x05, 0x01 },
.sign_algo = GNUTLS_SIGN_RSA_SHA384,
.hash_algo = GNUTLS_DIG_SHA384,
},
...
};
```
It would be slower than the accessing 2-dimensional matrix, as it requires searching on the array, but given the fact that there is only 18 (= 6 * 3) elements, that wouldn't affect performance much.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1367#note_534253834
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210321/3b1e4c38/attachment-0001.html>
More information about the Gnutls-devel
mailing list