Sorry - this one got past me.
For PKCS11 - the assignment of mechanism numbers can happen at any time
and doesn't necessarily result in a new version of the specification.
In this case, the API won't change, so there's no reason - since the
mechanism numbers have been assigned since last May at least - to wait
for V3. Among other things, I would expect that various vendors have
already implemented these in their 2.xx implementations.
One of the reasons I ended up using the SunPKCS11 wrapper classes
directly quite a while ago was that the PKCS11 spec hadn't been updated,
but that my PKCS11 provider was supplying various EC mechanisms that I
needed. Ideally, the JCA and SunPKCS11 provider support should
*precede* any given underlying PKCS11 device support, not trail it by
6-12 months.
The assignment of mechanism numbers is exactly equivalent to the
assignment of TLS cipher suite numbers - the underlying protocol doesn't
change, so this is mostly a change to the mapping tables and enclosed
classes.
In any event, any given PKCS11 implementation may or may not support any
given set of mechanisms - the provider really ought to be calling
C_GetMechanismList() and using that as the list of supported JNA mechanisms.
Sorry - I'm dealing with a bit of lack of sleep here so I may be
babbling, but I'm wondering if it might not be a bad idea to add some
sort of PKCS11 specific mechanism naming convention to allow for the
lag/lead problem? E.g PKCS11_DIGEST_000002B0 would be PKCS11's
CKM_SHA3_256 hashing function given
#define CKM_SHA3_2560x000002B0
Just a thought.
Thanks - Mike
On 3/19/2020 5:27 PM, Valerie Peng wrote:
Hi Mike,
Thanks for heads up. From what I can gather, SHA3 inclusion is part of
PKCS#11 v3. Is this the next release which you are referring to? Or
will there be an update to v2.40? Is there any schedule info for these
update/release do you know?
Following the convention, we normally don't add something which the
underlying library has no support yet. With the new 6-month JDK
release cycle, it's much faster for the added functionality to be
available. So, I'd still prefer to update SunPKCS11 provider with
SHA-3 once they are officially included.
Valerie
On 3/18/2020 4:07 PM, Michael StJohns wrote:
On 3/18/2020 6:57 PM, Valerie Peng wrote:
Anyone has time to help review this straight forward RFE? It's to
add SHA-3 support to Hmac.
RFE: https://bugs.openjdk.java.net/browse/JDK-8172680
Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/
Mach5 run is clean.
Thanks,
Valerie
Valerie -
I know the RFE says no PKCS11 because 2.40 doesn't include those
items, but OASIS PKCS11 has proposed SHA3 identifiers at
https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result
- maybe reach out and ask if these have been allocated pending the
next release?
Mike
#define CKM_SHA3_256 0x000002b0UL
#define CKM_SHA3_256_HMAC 0x000002b1UL
#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL
#define CKM_SHA3_224 0x000002b5UL
#define CKM_SHA3_224_HMAC 0x000002b6UL
#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL
#define CKM_SHA3_384 0x000002c0UL
#define CKM_SHA3_384_HMAC 0x000002c1UL
#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL
#define CKM_SHA3_512 0x000002d0UL
#define CKM_SHA3_512_HMAC 0x000002d1UL
#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL
