@mulmarta and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19.
The current PSK proposal validation forbids resumption with usage other than applications. The branch and reinit sections call for the creation of PSK proposals with types branch and reinit. Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows branch and reinit in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.)
The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track.
GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions.
The msg_type field of the Proposal object was inconsistently referred to as both msg_type and proposal_type. This PR changes it to be proposal_type everywhere.
seanturner
commented
1 year ago
@mulmarta and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19.
The current PSK proposal validation forbids
resumptionwithusageother thanapplications. The branch and reinit sections call for the creation of PSK proposals with typesbranchandreinit. Given the text in the PSK section, these proposals would be invalid. This PR explicitly allowsbranchandreinitin the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.)The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track.
GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions.
The
msg_typefield of the Proposal object was inconsistently referred to as bothmsg_typeandproposal_type. This PR changes it to beproposal_typeeverywhere.