Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBT] 11-26/1163r2

The main issue I have with mixing fields and elements in this manner is that it requires special cases for processing the frames and that is something that should really be avoided especially in security related areas. It is ideal if the receiver can first go through the fields from the beginning of the payload and then use a generic parser routine for parsing all the elements. Doing what this document is proposing is allowing that whereas any other approach (that I'm aware of) would result in either require special cases in the parsing (e.g., knowing that there are suddenly fields after a specific element) or inefficient encoding and processing (use of Fragment element).

On Wed, Jun 17, 2026 at 10:44 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,

Thank you for your efforts on this.

I would like to understand the exact parsing issue if we design the PQC parameters as follows: Place the KEM Encapsulation key field and KEM Ciphertext field immediately after the PQC Parameter element.



                  |<-------------------------------PQC Parameter element-------------------------------à|
Element ID
Length
Element ID   Extension
Security Profile   Number
Content Presence   field
Public Key   Parameter
KEM   Encapsulation Key
KEM Ciphertext
Octets: 1                         1                        1                1                          1                        variable               variable                variable


The receiver parses it as follows:

  1. If the PQC element is not present, the KEM Encapsulation key and KEM ciphertext are also not present. The receiver does not need to decode the additional two fields if it cannot find the PQC Parameter element based on the element PQC Parameter element's TLV information.
  2. If  the PQC Parameter element  is present, based on the indication in  the Content Presence field. For example, if  the Content Presence   field indicates that the ML-KEM public key is included in the KEM Encapsulation key field , the receiver will continue to decode the KEM Encapsulation key field after decoding  the PQC Parameter element.
  3. If  the PQC Parameter element  is present, based on the indication in  the Content Presence field. For example, if  the Content Presence field  indicates that  the KEM Encapsulation key or KEM ciphertext are not present (e.g., Content Presence field equals 0 (No parameter present) ), the receiver will not decode  the KEM Encapsulation key or KEM ciphertext   after finishing the decoding of  the PQC Parameter element. Instead,   it will continue to decode other elements based on the TLV information.

If we proceed in this direction, we could address a number of comments (compatibility issues, frame-by-frame design issues, etc.) we received during the call.

Welcome to more insights from you and the group.




Thanks

Best Regards

Jay Yang (杨志杰)


Original
Date: 2026年06月18日 02:25  
Subject: [STDS-802-11-TGBT] 11-26/1163r2  
 
  Po-kai,
 
  In the teleconference today you said that the changes I’m proposing in 11-26/1163r2 also require changes to the PQC Security Profile Number values but you didn’t say what they are. Can you explain what changes my document is missing?  Thanks.
 
  Regards,
 
  Dan.
 
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
 
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1

To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1

To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1