Ok.
Thanks everyone. It is clear. This was our assumption, but wanted clarification.
I think we should update the description. Even something as simple as this should be enough.
6.65.5 HSS without hashing
The HSS without hashing mechanism, denoted CKM_HSS, is a mechanism for single-part signatures and verification for HSS. (This mechanism corresponds only to the part of LMS that processes the hash value, which may be of any length;
it does not compute the hash value.)
6.65.5 HSS without hashing
The HSS without hashing mechanism, denoted CKM_HSS, is a mechanism for single-part signatures and verification for HSS. This mechanism performs the full signature generation as defined in section 6.2 of [RFC 8554].
The two main changes being
- since this is the HSS mechanism, the description should call out the HSS signature rather than LMS.
- the description calls out the complete signature algorithm, rather than a part of the signature.
Unless for the avoidance of doubt, we think we should also add a blurb about the description, or as another footnote to table 266 that states that the âpData that is passed to C_Sign is assumed to be the message to be signed, as defined in
[RFC 8554]â. But I donât think we need that with the updates suggested above.
Thoughts?
-----Original Message-----
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Monday, February 20, 2023 2:49 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] HSS in version 3.1 of the specification
On 2/17/23 8:23 PM, JOHNSON Darren wrote:
> Right.
>
> sorry, I thought q was private. It is hashed in to K. But I forgot that it is also concatenated to the final public key making it fully eposed. So "Q = H(I || u32str(q) || u16str(D_MESG) || C || message)" could be pre-computed.
> So is that the intent of CKM_HSS? Is it assuming that the application passed in Q?
>
>
> Or is CKM_HSS assuming that "message" is passed in? My assumption was that it should expect "message". Which is why it can accept "any" length.
As Jonathan confirmed (and my statement assumed), it's message, not Q.
I'm pretty sure NIST would not want to validate an implementation that
passed Q and left the hashing external to the signature.
> But if it expects Q, then the input can't be "any".
>
>
>
> The description in the spec states that is only a part of LMS.... See my other response to Bob.
>
>
>
> NIST certainly expects/assumes everything is in the module.
>
> Is it mandated in this case? SP800-208 states that C is generated using an approved DRBG. And it also states this "Implementations of the key generation and signature algorithms in this document shall only be validated for use within hardware cryptographic
modules. The cryptographic modules shall be validated".
>
> I would not want to try and argue that C can be generated outside the module...
That, of course, is only on the signature side. But, yes, another reason
a Q based implementation would not be NIST validatable.
>
>
> From: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com>
> Sent: Friday, February 17, 2023 3:44 PM
> To: JOHNSON Darren <darren.johnson@thalesgroup.com>; pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] HSS in version 3.1 of the specification
>
>
>
> The reference in 6.65 should be [NIST SP800-208] not [NIST 802-208].
>
>
>
> Section 4.3 of RFC 8554 indicates that I and q are part of the public key. It should be possible to generate the first step without the private key and outside the module. Adding some language to 6.65.5 would be helpful.
>
>
>
> I'd wager that NIST would be happier if H(I || u32str(q) || u16str(D_MESG) || C || message) was computed inside the module's boundary so that C is properly generated, but I don't see where they've mandated it in SP800-208.
>
>
>
> Sincerely,
>
> Jonathan
>
>
>
>
>
> From: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com>
> Sent: Friday, February 17, 2023 3:44 PM
> To: JOHNSON Darren <darren.johnson@thalesgroup.com>; pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] HSS in version 3.1 of the specification
>
>
>
> The reference in 6.65 should be [NIST SP800-208] not [NIST 802-208].
>
>
>
> Section 4.3 of RFC 8554 indicates that I and q are part of the public key. It should be possible to generate the first step without the private key and outside the module. Adding some language to 6.65.5 would be helpful.
>
>
>
> I'd wager that NIST would be happier if H(I || u32str(q) || u16str(D_MESG) || C || message) was computed inside the module's boundary so that C is properly generated, but I don't see where they've mandated it in SP800-208.
>
>
>
> Sincerely,
>
> Jonathan
>
>
>
>
>
> From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren
> Sent: Thursday, February 16, 2023 9:10 AM
> To: pkcs11@lists.oasis-open.org
> Subject: [EXT][pkcs11] HSS in version 3.1 of the specifciation
>
>
>
> THIS MESSAGE COMES FROM AN EXTERNAL SOURCE. PLEASE VERIFY THE CONTENTS OF THIS MESSAGE BEFORE PROCEEDING.
>
> Hi,
>
> we are trying to adopt the HSS definition from version 3.1 of the specification, and it doesn't seem to make sense.
>
> This overlaps with the discussions you started for PQC signatures for v3.2. So we may just decide to part this discussion and update HSS once we resolve the other questions you raised.
>
> Let me know if that is what you want to do.
>
> Or... if I'm missing some detail and I'm wrong, please let me know.
>
>
>
> It only has one type of signature... "HSS without hashing" which defines the single part signature. The single part aspect is fine as defining multi-part APIs for hash based signatures is being worked on for v3.2.
>
>
>
> But the general description of this signature doesn't make sense.
>
> This section states "This mechanism corresponds only to the part of LMS that processes the hash value, which may be of any length; it does not compute the hash value".
>
> What "hash value" is this referring to. The first step of LMS is "Q = H(I || u32str(q) || u16str(D_MESG) || C || message)", for simplicity, lets just call it "Q=hash(private key | random | message)". An application can't pass Q.
>
>
> Similar to your new definitions for SPHINCS, Dilitium, etc, should this section just be "HSS Signature"?
>
> And the multi part APIs and the topic of hash-than-sign will be sorted out with v3.2?
>
>
>
> Thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: