OASIS PKCS 11 TC

 View Only

  • 1.  Potential changes to our identifiers.

    Posted 09-24-2024 20:26
    After looking at the oids that NIST has allocated form the *-DSA pq
    signatures, Tim made the following suggestings to me. I've included them
    with my input.

    1) The 'prehash' oids only has the name 'hash' in them rather than
    pre-hash. He recommends we name our mechanisms similiarly.

    I'm ambivalent, but would be find with s/PREHASH/HASH/ on all our new
    algorithms. It will be an easy change to the ids and the headers. I
    don't think they are integrated into the main document yet, so that
    shouldn't cause an issue.

    2) NIST prefers not missing the prehash and normal hash keys, so Tim 
    recommends separate key types:

    Adding CKK_ML_DSA_[PRE]HASH and CKK_SHL_DSA_[PRE]HASH should be fine.
    I'm OK with this idea.

    3) NIST defines separate oids for each parameter set. Tim wonders if we
    should make separate mechanisms for each parameter set as well.

    I'm pretty resistant to this idea. I think we have more flexibility in
    the way we've defined things. We regularly map multiple oids to the same
    underlying mechanism, and we've already seen this in cases like AES,
    here in some cases there is an AES oid for each key size (and in other
    cases there's a single AES oid and a separate key length).

    We can discuss these tomorrow.


  • 2.  RE: Potential changes to our identifiers.

    Posted 09-24-2024 21:40
    Thanks for the prompt to get the details out wider to the TC - it has been a busy couple of weeks.

    I don't see deterministic as separate mechanisms - I see those as parameters as to whether or not additional random is used. The input processing logic in terms of function calls for the user is identical.

    The signatures are verified via an identical process and there are no separate OIDs defined for variations that are deterministic and hedged. Hedged is the recommended default with deterministic to only be used on platforms where there is no decent RNG available (i.e. effectively almost nowhere these days).

    By contrast, the HASH versions have entirely separate OIDs and the function calls you use to process them will be different in application logic - you will have to perform the HASH operations before calling the signing (or verification) functions.

    A deterministic hash based signature and a deterministic non-hash based signature have different signatures and for verification the user has to know which they are dealing with for the processing logic (verification will be done differently - in that for hash you have to go off and do the hashing first). Those to me are very different contexts and should be different mechanisms.

    That you have a different OID and that they are treated differently in applications to me is a very clear indicator that we should have different mechanisms.

    In KMIP we have HASH as separate, and we do not see deterministic as anything other than a parameter to the operation. The corresponding algorithm identifiers (when mapped into language specific naming using the KMIP english-to-identifier mapping rules are:

    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_768
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_1024

    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_44
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_65
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_87
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_44_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_65_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_87_WITH_SHA512

    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_128S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_128F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_192S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_192F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_256S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_256F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_128S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_128F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_192S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_192F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_256S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_256F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_128S_WITH_SHA256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_128F_WITH_SHA256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_192S_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_192F_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_256S_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_256F_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_128S_WITH_SHAKE128
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_128F_WITH_SHAKE128
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_192S_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_192F_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_256S_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_256F_WITH_SHAKE256

    Note that these precisely match NISTs terminology (and that is also the KMIP philosophy to not introduce different naming schemes without compelling reasons).

    In PKCS#11 we have made groups (ML-KEM, ML-DSA, SLH-DSA) and added parameter sets. 
    In API usage where the end user interacts in various programming languages it is mostly handled as entirely independent strings (i.e. the user does not ask for "ML-KEM" - they ask for "ML-KEM-512" - there is no concept of the "family" having any meaning - the family without the parameter set is non-usable. 

    Personally I see the NIST naming convention for SLH-DSA at odds with the approach taken in ML-DSA where they could have simply had a table of parameter sets rather than using the building block of the various constituent parts in the naming. But in KMIP terms, we follow whatever the convention of the origin specification is - inconsistencies and all. 

    There is also an interesting contrast in HPKE with DHKEM where the parameter sets have numeric identifiers but the names list the constituent parts.

    And ML-DSA or ML-KEM based naming would have had given us:
      DHKEM-16
      DHKEM-17
      DHKEM-18 
      DHKEM-32
      DHKEM-33

    But if we were following SLH-DSA naming we would get:
      DHKEM-P256-HKDF-SHA256
      DHKEM-P384-HKDF-SHA384
      DHKEM-P521-HKDF-SHA512
      DHKEM-X25519-HKDF-SHA256
      DHKEM-X448-HKDF-SHA512

    Again in HPKE there is no concept of combining arbitrary building blocks - the combination has to be known and there has to be a mapping to the identifiers used which come out in the encoding. 

    In OpenSSL terms for HPKE we see the parameter set as an identifier that has to be provided. They have been shortened to the following:
    OSSL_HPKE_KEM_ID_P256
    OSSL_HPKE_KEM_ID_P384
    OSSL_HPKE_KEM_ID_P521
    OSSL_HPKE_KEM_ID_X25519
    OSSL_HPKE_KEM_ID_X448
    So not as verbose as a SHL-DSA -like naming scheme but not as short as a ML-DSA-like or ML-KEM-like naming scheme. The ML-KEM being the approach which I expect other KEMs will start following going forward.

    I'll be updating the KMIP specification for DHKEM handling as we currently haven't got the KEM parameter set handled for HPKE yet.

    Tim.




    Original Message


  • 3.  RE: Potential changes to our identifiers.

    Posted 09-25-2024 13:33
    On 9/24/24 6:39 PM, Tim Hudson wrote:
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">
    Thanks for the prompt to get the details out wider to the TC - it has been a busy couple of weeks.

    I don't see deterministic as separate mechanisms - I see those as parameters as to whether or not additional random is used. The input processing logic in terms of function calls for the user is identical.
    Sigh, we discussed that last week. I had gone back and forth and finally we decided that the TC would make a decision, so I'm less sold on it, but I prefer not to keep flip-flopping in it either. Initially I wanted to ignore it (and the token just gave you want it wanted), but there were some cases where the application may want to  force the issue (either it insists on non-deterministic for "reasons", or it wants deterministic for test vectors or applications where you need all signatures on the same data to be the same) or a token could only support one (like deterministic because it has a crummy entropy source/rng). Having it as a mechanism means that the application can tell which can be performed before hand so it can choose an appropriate token for it's needs.
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">

    The signatures are verified via an identical process and there are no separate OIDs defined for variations that are deterministic and hedged. Hedged is the recommended default with deterministic to only be used on platforms where there is no decent RNG available (i.e. effectively almost nowhere these days).
    Yes, verification is identical. In most cases the verify doesn't know or care which type of signature it is. Again I am very much against trying to match our mechanisms to OIDS one-for-one. Not all use cases are captured by the OIDS and they way the OIDS are used and mechanisms are used have never been one-for-one historically.
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">

    By contrast, the HASH versions have entirely separate OIDs and the function calls you use to process them will be different in application logic - you will have to perform the HASH operations before calling the signing (or verification) functions.

    A deterministic hash based signature and a deterministic non-hash based signature have different signatures and for verification the user has to know which they are dealing with for the processing logic (verification will be done differently - in that for hash you have to go off and do the hashing first). Those to me are very different contexts and should be different mechanisms.
    They are in our proposals. We have the combined hash/sign and the raw sign, at least for pre-hash. There is no definition for these separate operations for the non-prehash versions. This mirrors what we already do with ECDSA and RSA (both raw and hash mechanisms are defined).
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">

    That you have a different OID and that they are treated differently in applications to me is a very clear indicator that we should have different mechanisms.
    Again, I strongly disagree with the premise, though in your example, we have exactly that. What we don't have is different mechanism for different key strengths, which I am strongly *against* doing. Your oid argument does not even come close to convincing me.
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">

    In KMIP we have HASH as separate, and we do not see deterministic as anything other than a parameter to the operation. The corresponding algorithm identifiers (when mapped into language specific naming using the KMIP english-to-identifier mapping rules are:

    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_768
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_KEM_1024
    I am definitely against this one. There is no reason for separate mechanisms for the same algorithm with different parameter sets.
    kaQXupKo99qu8h3hMDxoTt8TorzQ6w@mail.gmail.com">

    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_44
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_65
    KMIP_CRYPTOGRAPHIC_ALGORITHM_ML_DSA_87
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_44_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_65_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_ML_DSA_87_WITH_SHA512

    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_128S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_128F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_192S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_192F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_256S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHA2_256F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_128S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_128F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_192S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_192F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_256S
    KMIP_CRYPTOGRAPHIC_ALGORITHM_SLH_DSA_SHAKE_256F
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_128S_WITH_SHA256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_128F_WITH_SHA256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_192S_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_192F_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_256S_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHA2_256F_WITH_SHA512
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_128S_WITH_SHAKE128
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_128F_WITH_SHAKE128
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_192S_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_192F_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_256S_WITH_SHAKE256
    KMIP_CRYPTOGRAPHIC_ALGORITHM_HASH_SLH_DSA_SHAKE_256F_WITH_SHAKE256

    Note that these precisely match NISTs terminology (and that is also the KMIP philosophy to not introduce different naming schemes without compelling reasons).

    In PKCS#11 we have made groups (ML-KEM, ML-DSA, SLH-DSA) and added parameter sets. 
    In API usage where the end user interacts in various programming languages it is mostly handled as entirely independent strings (i.e. the user does not ask for "ML-KEM" - they ask for "ML-KEM-512" - there is no concept of the "family" having any meaning - the family without the parameter set is non-usable. 

    Personally I see the NIST naming convention for SLH-DSA at odds with the approach taken in ML-DSA where they could have simply had a table of parameter sets rather than using the building block of the various constituent parts in the naming. But in KMIP terms, we follow whatever the convention of the origin specification is - inconsistencies and all. 

    There is also an interesting contrast in HPKE with DHKEM where the parameter sets have numeric identifiers but the names list the constituent parts.

    And ML-DSA or ML-KEM based naming would have had given us:
      DHKEM-16
      DHKEM-17
      DHKEM-18 
      DHKEM-32
      DHKEM-33

    But if we were following SLH-DSA naming we would get:
      DHKEM-P256-HKDF-SHA256
      DHKEM-P384-HKDF-SHA384
      DHKEM-P521-HKDF-SHA512
      DHKEM-X25519-HKDF-SHA256
      DHKEM-X448-HKDF-SHA512

    Again in HPKE there is no concept of combining arbitrary building blocks - the combination has to be known and there has to be a mapping to the identifiers used which come out in the encoding. 

    In OpenSSL terms for HPKE we see the parameter set as an identifier that has to be provided. They have been shortened to the following:
    OSSL_HPKE_KEM_ID_P256
    OSSL_HPKE_KEM_ID_P384
    OSSL_HPKE_KEM_ID_P521
    OSSL_HPKE_KEM_ID_X25519
    OSSL_HPKE_KEM_ID_X448
    So not as verbose as a SHL-DSA -like naming scheme but not as short as a ML-DSA-like or ML-KEM-like naming scheme. The ML-KEM being the approach which I expect other KEMs will start following going forward.

    I'll be updating the KMIP specification for DHKEM handling as we currently haven't got the KEM parameter set handled for HPKE yet.

    Tim.





    Original Message


Related Content