> Sorry, I am not sure I am awake enough to remember the details, but
> aren't you mixing signatures OIDs with key OIDs here ?
NIST specifially said they were the same. The oids are for both
signatures a keys.
>
> I do not recall there being multiple key OIDs beyond the ones defined
> for the security levels perhaps. But I may be very wrong.
There aren't currently, but the ones allocated are specifically for both
keys and signatures. Since the hash algorithm is fixed for ML-DSA, that
one doesn't matter. For ML-HashDSA, they only defined SHA-512 variants.
The did not define a straight up ML-HashDSA oid for the key. I'm
guessing NIST doesn't want to mix hashes with the same key (sigh). I'm
kinda thinking this isn't good for crypto agility... but...
bob
>
> Simo.
Original Message:
Sent: 11/13/2024 9:19:00 AM
From: Simo Sorce
Subject: RE: CKA_SEED uploaded
On Tue, 2024-11-12 at 20:12 +0000, Darren Johnson via OASIS wrote:
> If we do try to use hash specific OIDS
Sorry, I am not sure I am awake enough to remember the details, but
aren't you mixing signatures OIDs with key OIDs here ?
I do not recall there being multiple key OIDs beyond the ones defined
for the security levels perhaps. But I may be very wrong.
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Original Message:
Sent: 11/12/2024 3:12:00 PM
From: Darren Johnson
Subject: RE: CKA_SEED uploaded
THALES GROUP LIMITED DISTRIBUTION to email recipients
We certainly could trim down that section and just refer to the current IETF documents. Less baggage for us to maintain in our spec.
Looking at the list of OIDs, this brings us back to that discussion that was mainly between you and Tim I believe. Our keys are not bound to the hash algorithm unless a key has CKA_ALLOWED_MECHANISMS attribute is set to a sub set of the possible values; but some of the OIDs are hash specific. Do we need a paragraph explaining which OID a token should/will use? And what would that be?
For an inbound/unwrapped keys, should a token interpret the hash-bound OID and map it to an appropriate CKA_ALLOWED_MECHANISM... if a token supports that attribute?
For outbound/wrapped keys, should tokens follow a similar model where it will use a hash-bound OID if it can decide deterministically what to use? But if it can't, should it use the non-hash-bound OID? That would be odd for a key that is being used with CKM_HASH_ML_DSA, but I'm not sure how else to handled it. Any ideas?
If we do try to use hash specific OIDS, there may also be the problem related to NIST only defining SHA-512. We will probably have more OIDs defined at a later date. And if a token doesn't support an OID for inbound it should reject it. But of outbound, the key has have CKA_ALLOWED_MECHANISMS set correctly, but the token just may not know about the hash specific OID yet. So in that case, is the key just not able to be wrapped or does a token fall back to the non-hash-specific OIDs?
Original Message:
Sent: 11/12/2024 1:15:00 PM
From: Robert Relyea
Subject: CKA_SEED uploaded
Submitter's message
Some questions.
1) We repeat a lot of stuff about pkcs #8 in our document. Should we just leave it out and point to the current ietf documents here directly? I can still keep pkcs #11 specific things like the comment on encoding both seed and value for the best combatibility for ml-kem* and ml-dsa* and ml-hash-dsa*
2) ML-KEM actually has 2 seeds, one at the high level and one at the internal level. I've specified CKA_SEED to be the concatenation of the two seed. You need both to get a full ML-KEM key.
3) I didn't add a footnote number for the description of the interplay between CKA_SEED and CKA_VALUE, but did add a footnote under the table.
-- Mr. Robert Relyea
---------------------------------
Robert Relyea
Principle Software Engineer
Red Hat
Mountain View CA
---------------------------------