[gnutls-devel] GnuTLS | Read Certificate Transparency (RFC 6962) SCT extension (!1367)

[Read-only notification of GnuTLS library development activities]

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>