Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix RFC 7250 Compliance #1

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Fix RFC 7250 Compliance #1

wants to merge 1 commit into from

Conversation

holodorum
Copy link
Owner

  • We worked with the assumption that a client would never send a RawPublicKey Certificate Type in the ClientHello if the server does not support RawPublicKeys. If a client did send a RawPublicKey Certificate Type in the ClientHello, the handshake would fail with an UnsolicitedCertificateTypeExtension.
  • In practice, this is not the case. Clients may send a RawPublicKey Certificate Type in the ClientHello even if the server does not support RawPublicKeys.
  • This commit fixes the issue by changing the way the server handles the certificate_type_extensions in the ClientHello.
  • Also added a test to check if the server can handle a RawPublicKey Certificate Type in the ClientHello even if the server does not support RawPublicKeys.
  • The client is handling the certificate_type_extensions in the ServerHello in the same way as before

- We worked with the assumption that a client
  would never send a RawPublicKey Certificate Type in the
  ClientHello if the server does not support RawPublicKeys.
  If a client did send a RawPublicKey Certificate Type in the
  ClientHello, the handshake would fail with
  an `UnsolicitedCertificateTypeExtension`.
- In practice, this is not the case. Clients may send a
  RawPublicKey Certificate Type in the ClientHello even if
  the server does not support RawPublicKeys.
- This commit fixes the issue by changing the way the server handles
  the `certificate_type_extensions` in the ClientHello.
- Also added a test to check if the server can handle a RawPublicKey
  Certificate Type in the ClientHello even if the server does not
  support RawPublicKeys.
- The client is handling the `certificate_type_extensions` in the
  ServerHello in the same way as before
@@ -697,13 +697,13 @@ pub(super) fn process_server_cert_type_extension(
.requires_raw_public_keys();
let server_offers_rpk = matches!(server_cert_extension, Some(CertificateType::RawPublicKey));

let raw_key_negotation_params = RawKeyNegotiationParams {
let raw_key_negotation_params = NegotationCertificateTypeExtension {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik vind de naam NegotationCertificateTypeExtension onduidelijk. Kun je het uitleggen, of kunnen we beter iets anders gebruiken, zoals CertificateTypeExtensionNegotiationParams of CertificateTypeExtensionParams?

Daarnaast moeten we de naam van de variabele updaten (nu heet het nog raw_key_negotation_params)

@@ -735,3 +742,33 @@ pub(crate) enum HandshakeHashOrBuffer {
Buffer(HandshakeHashBuffer),
Hash(HandshakeHash),
}

#[derive(Debug)]
struct NegotationCertificateTypeExtension {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deze struct heeft dezelfde naam als die andere boven, dat lijkt me verwarrend. Zou NegotatedCertificateTypeExtension een duidelijkere naam zijn?

fn validate_certificate_type_extension(
&self,
) -> CertificateTypeExtensionNegotationResult {
// TODO WHAT IS MORE CLEAR? THE MATCH OR THE IF ELSE?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik heb wat ideeën om dit te herschrijven, zonder een match

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants