Implement full TLS1.3 OQS signature support

[baentsch]

Warning: This is a big issue. Anyone willing to tackle it should consider this requires substantial OpenSSL3 support (see for example openssl/openssl#10512). Also helpful to get started may be discussions documented here.

[baentsch]

email input by @anhu:

My goal is to avoid any source code conflict with any patch that would be accepted into the OpenSSL code base so I think that upstream uptake is definitely a joint goal.
How can I get started helping you? Let me know via github please!

Here's what my plan is (in terms of github issues and in order of resolving): #2, #6, #7, #8, #3 and concluding with #9. From the work on the KEM provider I fully expect upstream changes to be(come) necessary well before concluding #9/openssl/openssl#10512. Thus, depending on how fast we progress on the issues above relative to the OSSL3 release timeline, we may either do upstream PRs or a fork of upstream master. For either option to work out, please be aware that you (probably your employer) need to sign up to this: From my own corporate history I have the hunch that getting this signed may take "longish", so why no get started on this now, @anhu? If you agree with all of this, I'd suggest technical work to begin by looking at this and then "diving into" #2: After we'll have a standalone SIG-capable provider (e.g., doing CMS), I'd expect the TLS parts to be relatively straightforward.

[anhu]

Hi Michael ,

Thanks! I have already signed up for the OpenSSL Contributors Agreement since we wanted to make 2 minor contributions to the OpenSSL code base:

• 0a8e6c1fb77612feba350a67dad3e548300785a7
• 2555285fa5e4248ad4a5a0bc14ae4606443856c2

It likely comes as no surprise to you that we are implementing our own closed source provider. I am actually currently looking into #2, but for our provider. Of course, our provider will be different from oqs-proivder's internals. As such, the code that I will have will be distinctly different than what you will need and will obviously not patch in cleanly. However, I would be happy to give pointers, helpful hints and warnings about potential dead ends. For example, you won't need to write encoder import methods because there are no other implementations of these algorithms to import from. When I first started looking at the provider encoder documentation I spent a lot of time trying to figure what I needed to do for the encoder's import API and finally figured out that it was not necessary. Hopefully, I've prevented you from wasting that time like I did.

[baentsch]

Hopefully, I've prevented you from wasting that time like I did.

Quite possibly: I have spent a lot of time scratching my head about the encoder/decoder concepts and how they'd need to use the X509 APIs -- and still do :-( so anything I don't need to wonder about helps.

[anhu]

Same here!! It does not help that encode_key2any.c is hard to read (for me) due to macro defines.
I started with text encoder because it seemed simpler. Unfortunately, this means I can't really test it so I don't know that I got it right.
I only implemented

• OSSL_FUNC_ENCODER_NEWCTX
• OSSL_FUNC_ENCODER_FREECTX
• OSSL_FUNC_ENCODER_GETTABLE_PARAMS
• OSSL_FUNC_ENCODER_GET_PARAMS
• OSSL_FUNC_ENCODER_ENCODE

For me newctx() and freectx() were trivial. encode_key2text.c is a bit easier to follow. Might be a good guide/template for you as well.

TIP: You'll also need to get openssl's OSSL_FUNC_BIO_VPRINTF function pointer .

[anhu]

I'd like to propose a direction for this issue:

Providers that supply new and unknown sigalgs for TLS 1.3 signature verification should be able to do so via a fully pluggable mechanism called the capabilities query. OpenSSL will query the provider asking it what kind of sigalgs it supports. During this call, the provider will register the name and the TLS 1.3 code point of the sigalgs it supports. That name can be referenced in .conf files or command line parameters to specify supported sigalgs.

This would be similar to the way it currently works for supported groups in TLS 1.3.

Something that needs to also be considered is the OIDs for the signature and public key of the registered sigalgs. Do the OIDs need to be associated with the codepoint and name as well?

[baentsch]

Fully agree: All this "registration" (or reference) information (at the very least name and OID) needs to be accessible to OpenSSL.
The one question I'd have is why this would necessitate a new(?) capabilities query: Wouldn't/shouldn't it be so that name+OID are automatically associated (and thus made available to all OpenSSL piece-parts, incl. signature reference APIs & command line parameters) with the relevant (algorithm's) code the moment the provider is loaded?

[anhu]

Yes. Name+OID are automatically associated already.

But much like groups, you need to associate the sigalg code points with the name as well. Perhaps the term "code point" is obscure so I'll just explicitly paste the relevant section from the TLS 1.3 spec here:

      enum {
          /* RSASSA-PKCS1-v1_5 algorithms */
          rsa_pkcs1_sha256(0x0401),
          rsa_pkcs1_sha384(0x0501),
          rsa_pkcs1_sha512(0x0601),

          /* ECDSA algorithms */
          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

          /* RSASSA-PSS algorithms with public key OID rsaEncryption */
          rsa_pss_rsae_sha256(0x0804),
          rsa_pss_rsae_sha384(0x0805),
          rsa_pss_rsae_sha512(0x0806),

          /* EdDSA algorithms */
          ed25519(0x0807),
          ed448(0x0808),

          /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
          rsa_pss_pss_sha256(0x0809),
          rsa_pss_pss_sha384(0x080a),
          rsa_pss_pss_sha512(0x080b),

          /* Legacy algorithms */
          rsa_pkcs1_sha1(0x0201),
          ecdsa_sha1(0x0203),

          /* Reserved Code Points */
          private_use(0xFE00..0xFFFF),
          (0xFFFF)
      } SignatureScheme;

As I'm sure you'll remember with your work with groups, you had to return your code points during a capabilities query. The same thing would have to happen with signature algorithms. OpenSSL would have to do a capabilities query for signatures and it would pass the name of a signature algorithm and then the provider would respond with the code point that corresponds to that name if it supports that algorithm.

Hopefully, this makes things clearer?

[baentsch]

Fixed by openssl/openssl#19312