Draft: draft-ietf-ohai-ohttp

Commentary: We previously only had figures , which are sort of illustrative only , they do n't really work as normative specification . The content of these really needs to have words that describe what was intended . The definition for the request was already sort - of there , so what I 've is a tiny bit repetitive , but I think that it 's OK in this case to have the descriptions at different levels of specificity . The big error here was that the length field in the key configuration was impossible to decipher . We never said whether it was length in bytes ( what has been implemented ) or length in number of items . The bounds on the field length were not helpful here as they were not correct in any way . I 've corrected this value , but would appreciate a sanity check . No one identified this as a problem in the reviews . I guess that means that the QUIC format is clear and understandable . Maybe I should have made it less so . The TLS format is consistently misunderstood , which I used to think was a disadvantage ...
The definitions for the identifiers used in HPKE and the semantics of
the algorithms they identify can be found in HPKE.  The "Npk"
parameter is determined by the choice of HPKE KEM, which can also be
found in HPKE.
This plaintext Request is encapsulated into a message in ""message/
ohttp-req"" form by generating an .  An comprises a key identifier;
HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated
KEM shared secret (or "enc"); and the HPKE-protected binary HTTP
request message.
The Nenc parameter corresponding to the KEM used in HPKE can be found
in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size
of the encapsulated KEM shared secret, in bytes.
This plaintext Request is encapsulated into a message in ""message/
ohttp-req"" form by generating an .  An comprises a key identifier;
HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated
KEM shared secret (or "enc"); and an HPKE-protected binary HTTP
request message.
That is, an comprises a Key Identifier, HPKE KEM ID, HPKE KDF ID,
HPKE AEAD ID, Encapsulated KEM Shared Secret, and HPKE-Protected
Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD
ID fields are defined in key-config.  The Encapsulated KEM Shared
Secret is the output of the "Encap()" function for the KEM, which is
"Nenc" bytes in length, as defined in HPKE.
The Nn and Nk values correspond to parameters of the AEAD used in
HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2].
Nn and Nk refer to the size of the AEAD nonce and key respectively,
in bytes.  The nonce length is set to the larger of these two
lengths, i.e., max(Nn, Nk).
That is, an contains a Nonce and an AEAD-Protected Response.  The
Nonce field is either "Nn" or "Nk" bytes long, whichever is larger.
The "Nn" and "Nk" values correspond to parameters of the AEAD used in
HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [1].
"Nn" and "Nk" refer to the size of the AEAD nonce and key
respectively, in bytes.
Please update the "Media Types" registry at
https://iana.org/assignments/media-types [3] for the media types
"application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),
and "message/ohttp-res" (iana-res).
Please update the "HTTP Problem Types" registry at
https://iana.org/assignments/http-problem-types [4] for the types
"date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key).
Please update the "Media Types" registry at
https://iana.org/assignments/media-types [2] for the media types
"application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),
and "message/ohttp-res" (iana-res).
Please update the "HTTP Problem Types" registry at
https://iana.org/assignments/http-problem-types [3] for the types
"date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key).