Unclear that a Key Config includes multiple HPKE Symmetric Algorithmses

[davidben]

Section 3.1 defines the following structure:

HPKE Symmetric Algorithms {
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
}

Key Config {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE Public Key (Npk * 8),
  HPKE Symmetric Algorithms Length (16),
  HPKE Symmetric Algorithms (32..262140),
}

https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-06.html#section-3.1

First, a nit pick: "and a set HPKE symmetric algorithms" should say "and a set of HPKE symmetric algorithms".

More importantly, it's unclear that there is meant to be a sequence of HPKE Symmetric Algorithms in the last field.

I'm not as familiar with the RFC 9000 syntax. From https://www.rfc-editor.org/rfc/rfc9000#section-1.3, I see there is a x (L) ... syntax, so perhaps HPKE Symmetric Algorithms (32) ...,. But then we there probably needs to be prose to link the overall length to HPKE Symmetric Algorithms Length.

[martinthomson]

Does the updated Section 3.1 work for you? We realized this shortcoming ourselves and made some changes.

[davidben]

Ah whoops, I forgot to check the editor's draft! That does indeed look much clearer! I'm not as familiar with the QUIC syntax... is it common to just handle this style of repeated field in prose?

My read of https://www.rfc-editor.org/rfc/rfc9000#section-1.3 is that HPKE Symmetric Algorithms (32..524256) still implies a single HPKE Symmetric Algorithms, but I could just be misunderstanding. Either way, the prose clears it up, but should it perhaps be:

Key Config {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE Public Key (Npk * 8),
  HPKE Symmetric Algorithms Length (16) = 32..524256,
  HPKE Symmetric Algorithms (32) ...,
}

(Where does 524256 come from?)

https://www.rfc-editor.org/rfc/rfc9000#section-18 seems to do something similar.

[martinthomson]

There is not any real correspondence between the test in the diagram and the prose, except convention. The diagram is illustrative, not normative.

You are right about the 32..524256, the value is in bytes (not bits!) and so should just be 4..65532.

Edit: Sorry, should have said instead that the form you describe is right, though the value for the length field will be a big-endian number in bytes (524256 is a length in bits and wouldn't fit).