OASIS PKCS 11 TC

All,

while integrating PQ Signature Update 2 into PKCS#11 v3.2 working draft 06, I stumbled upon the following inconsistency / ambiguity (please notice that sections number refer to the sections in the PDF proposal, not in the Word working draft):

• section 1.1.2 defines "CK_XMSS_OID is the XMSS oid defined in [RFC 8391] and [NIST SP800-208]." , typedefs CK_XMSS_OID as CK_ULONG, and uses CK_XMSS_OID as data type in CKA_PARAMETER_SET. The example uses value 0x01 for the oid.
• section 1.1.3 has same wording and typedef for CK_XMSSMT_OID
• in section 1.1.4 and 1.1.5, "Byte array" is declared as data type for CKA_PARAMETER_SET, while the description talks about "oid as defined above". The example again uses 0x01 as value for the oid.

I assume that this inconsistency is left over from a previous draft. Unless anyone objects, I will replace "byte array" by CK_XMSS_OID / CK_XMSSMT_OID

... but wait ...

I see an ambiguity in using the term "OID":

• RFC 8391 uses the term OID but doesn't define any. SP800-208 does not use the term OID but uses the term "parameter set" instead. Both standards are thus inconsistent with regard to wording.
• When reading "OID" I think of object identifier or algorithm identifier of the form a.b.c.d... , e.g. the XMSS public key OID id-alg-xmss-hashsig  OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) reserved(127)  etsi-identified-organization(0) isara(15) algorithms(1) asymmetric(1) xmss(13) 0 } defined in Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS (ietf.org) but this is not encodable in CK_ULONG, and we don't reference this page
• The parameter sets in SP800-208 are small integer values and can easily be encoded in CK_ULONG

I guess CKA_PARAMETER_SET shall encode the parameter set as defined in SP800-208. We may resolve the current ambiguity by

1. Keep using the terms oid and CK_XMSS_OID/CK_XMSSMT_OID, but explicitly state in the text that oid means parameter set as defined in SP800-208; or
2. Remove the definition of CK_XMSS_OID/CK_XMSSMT_OID, and instead talk about XMSS/XMSSMT parameter sets, and use data type CK_ULONG for CKA_PARAMETER_SET

I have a preference for option 2, as it avoids any confusion between oid and parameter set. What do you think?

Thanks,

Dieter

Update for solving the ambiguity -> 3 options:

1. Keep using the terms oid and CK_XMSS_OID/CK_XMSSMT_OID, but explicitly state in the text that oid means parameter set as defined in SP800-208; or
2. Remove the definition of CK_XMSS_OID/CK_XMSSMT_OID, and instead talk about XMSS/XMSSMT parameter sets, and use data type CK_ULONG for CKA_PARAMETER_SET
3. Rename CK_XMSS_OID/CK_XMSSMT_OID to CK_XMSS_PARAMETER_SET_TYPE/ CK_XMSSMT_PARAMETER_SET_TYPE and thus use a similar naming as in "typedef CK_ULONG CK_ML_DSA_PARAMETER_SET_TYPE"

Having added option 3, this becomes my preferred option.

All,

while integrating PQ Signature Update 2 into PKCS#11 v3.2 working draft 06, I stumbled upon the following inconsistency / ambiguity (please notice that sections number refer to the sections in the PDF proposal, not in the Word working draft):

• section 1.1.2 defines "CK_XMSS_OID is the XMSS oid defined in [RFC 8391] and [NIST SP800-208]." , typedefs CK_XMSS_OID as CK_ULONG, and uses CK_XMSS_OID as data type in CKA_PARAMETER_SET. The example uses value 0x01 for the oid.
• section 1.1.3 has same wording and typedef for CK_XMSSMT_OID
• in section 1.1.4 and 1.1.5, "Byte array" is declared as data type for CKA_PARAMETER_SET, while the description talks about "oid as defined above". The example again uses 0x01 as value for the oid.

I assume that this inconsistency is left over from a previous draft. Unless anyone objects, I will replace "byte array" by CK_XMSS_OID / CK_XMSSMT_OID

... but wait ...

I see an ambiguity in using the term "OID":

• RFC 8391 uses the term OID but doesn't define any. SP800-208 does not use the term OID but uses the term "parameter set" instead. Both standards are thus inconsistent with regard to wording.
• When reading "OID" I think of object identifier or algorithm identifier of the form a.b.c.d... , e.g. the XMSS public key OID id-alg-xmss-hashsig  OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) reserved(127)  etsi-identified-organization(0) isara(15) algorithms(1) asymmetric(1) xmss(13) 0 } defined in Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS (ietf.org) but this is not encodable in CK_ULONG, and we don't reference this page
• The parameter sets in SP800-208 are small integer values and can easily be encoded in CK_ULONG

I guess CKA_PARAMETER_SET shall encode the parameter set as defined in SP800-208. We may resolve the current ambiguity by

1. Keep using the terms oid and CK_XMSS_OID/CK_XMSSMT_OID, but explicitly state in the text that oid means parameter set as defined in SP800-208; or
2. Remove the definition of CK_XMSS_OID/CK_XMSSMT_OID, and instead talk about XMSS/XMSSMT parameter sets, and use data type CK_ULONG for CKA_PARAMETER_SET

I have a preference for option 2, as it avoids any confusion between oid and parameter set. What do you think?

Thanks,

Dieter

THALES GROUP LIMITED DISTRIBUTION to email recipients

Hi,

I think all the options make sense. If I had to vote, I vote for option 3 mostly because we have started to use "parameter set" for many other algorithms.

Rather than call it an OID, we culd explain it as something like "the Numeric Identifier defined in SP800-108".

Thanks

Darren

Update for solving the ambiguity -> 3 options:

1. Keep using the terms oid and CK_XMSS_OID/CK_XMSSMT_OID, but explicitly state in the text that oid means parameter set as defined in SP800-208; or
2. Remove the definition of CK_XMSS_OID/CK_XMSSMT_OID, and instead talk about XMSS/XMSSMT parameter sets, and use data type CK_ULONG for CKA_PARAMETER_SET
3. Rename CK_XMSS_OID/CK_XMSSMT_OID to CK_XMSS_PARAMETER_SET_TYPE/ CK_XMSSMT_PARAMETER_SET_TYPE and thus use a similar naming as in "typedef CK_ULONG CK_ML_DSA_PARAMETER_SET_TYPE"

Having added option 3, this becomes my preferred option.

All,

while integrating PQ Signature Update 2 into PKCS#11 v3.2 working draft 06, I stumbled upon the following inconsistency / ambiguity (please notice that sections number refer to the sections in the PDF proposal, not in the Word working draft):

• section 1.1.2 defines "CK_XMSS_OID is the XMSS oid defined in [RFC 8391] and [NIST SP800-208]." , typedefs CK_XMSS_OID as CK_ULONG, and uses CK_XMSS_OID as data type in CKA_PARAMETER_SET. The example uses value 0x01 for the oid.
• section 1.1.3 has same wording and typedef for CK_XMSSMT_OID
• in section 1.1.4 and 1.1.5, "Byte array" is declared as data type for CKA_PARAMETER_SET, while the description talks about "oid as defined above". The example again uses 0x01 as value for the oid.

I assume that this inconsistency is left over from a previous draft. Unless anyone objects, I will replace "byte array" by CK_XMSS_OID / CK_XMSSMT_OID

... but wait ...

I see an ambiguity in using the term "OID":

• RFC 8391 uses the term OID but doesn't define any. SP800-208 does not use the term OID but uses the term "parameter set" instead. Both standards are thus inconsistent with regard to wording.
• When reading "OID" I think of object identifier or algorithm identifier of the form a.b.c.d... , e.g. the XMSS public key OID id-alg-xmss-hashsig  OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) reserved(127)  etsi-identified-organization(0) isara(15) algorithms(1) asymmetric(1) xmss(13) 0 } defined in Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS (ietf.org) but this is not encodable in CK_ULONG, and we don't reference this page
• The parameter sets in SP800-208 are small integer values and can easily be encoded in CK_ULONG

I guess CKA_PARAMETER_SET shall encode the parameter set as defined in SP800-208. We may resolve the current ambiguity by

1. Keep using the terms oid and CK_XMSS_OID/CK_XMSSMT_OID, but explicitly state in the text that oid means parameter set as defined in SP800-208; or
2. Remove the definition of CK_XMSS_OID/CK_XMSSMT_OID, and instead talk about XMSS/XMSSMT parameter sets, and use data type CK_ULONG for CKA_PARAMETER_SET

I have a preference for option 2, as it avoids any confusion between oid and parameter set. What do you think?

Thanks,

Dieter