<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Valerie - <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">In line<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/3/2020 5:32 PM, Valerie Peng
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Mike,</p>
<p>We can update SunPKCS11 provider when the PKCS#11 official
header files are updated with SHA3 and Hmac w/ SHA3. <br>
</p>
<p>I agree with you on the ideal case is to have no lagging in JCA
and the SunPKCS11 provider.</p>
<p>The main reason for the lagging is that we need to test and
make sure the added functionality works. I checked NSS which is
what existing PKCS11 regression tests use and it does not have
any SHA3 support. Do you know other PKCS11 vendors which
supports SHA3 and Hmac w/ SHA3? If there are many, it'll help me
justifying this when the official headers are not updated yet.</p>
</blockquote>
<p>I've got an include file from Utimaco dated 27 March 2017 that
includes the SHA3 assignments from PKCS11 - and their collateral
says they implement SHA3 (this is all of the message digest, hmac
and signature mechanisms, and key derivation mechanisms specified
for PKCS11 3.0. <br>
</p>
<p>Safenet ProtectServer has it
<a class="moz-txt-link-freetext" href="https://data-protection-updates.gemalto.com/2018/04/27/product-release-safenet-protecttoolkit-5-6/">https://data-protection-updates.gemalto.com/2018/04/27/product-release-safenet-protecttoolkit-5-6/</a></p>
<p>I can't find anything that says nCipher has it.</p>
<p>That's two out of three of the big ones.<br>
</p>
<blockquote type="cite"
cite="mid:87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com">
<p>I am not sure if I understand your suggestion of PKCS11
specific mechanism naming convention. Is it about duplicating
the pending SHA3 mechanism definitions in SunPKCS11 provider?
It's trivial to add the SHA3 related mechanism definitions to
SunPKCS11 provider, but the convention is to add things only
after they are official as it may be hard to change due to
backward compatibility concern.</p>
</blockquote>
<p>Something like MessageDigest.getInstance ("SHA3_256",
pkcs11provider) ends up mapping to an underlying call
"CK_MECHANISM m = new CK_MECHANISM (CKM_SHA3_256);" where
CKM_SHA3_256 is "public static long CKM_SHA3_256 = 0x000002b0L;"</p>
<p>There are at times a number of proprietary or provider specific
algorithms that the underlying PKCS11 dll might support, but for
which the Java PKCS11 provider doesn't have the string (name) to
mechanism number mapping, but for which the API is the same as for
any other algorithm of its class. <br>
</p>
<p>For example, the Utimaco PKCS11 definitions include <br>
</p>
<p>#define CKM_DES3_RETAIL_MAC 0x80000135 //
Retail-MAC with 0-Padding</p>
<p>Which is unlikely to be part of any PKCS11 standard, but could be
accessed by <br>
</p>
<p>Mac.getInstance ("PKCS11_MAC_16_80000135", pkcs11provider); //
16 is the mac length.<br>
</p>
<p>So this is an escape mechanism to permit access to provider
extensions without having to reflect them back into the Java
PKCS11 provider. <br>
</p>
<p>(When support for EC algorithms were being kept from various
software - including NSS - due to nervousness about patent claims,
I ended up using the PKCS11 wrapper classes directly specifically
because I couldn't do an ECDSA via the PKCS11 provider. That
hasn't been the case for a while, but it's always bothered me that
the JCA got in the way of the underlying provider.)</p>
<p>I don't know that is doable given the current architecture (which
usually requires an OID for a mechanism to register it for
SunPKCS11), but something to think about. <br>
</p>
<blockquote type="cite"
cite="mid:87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com">
<p>Thanks & hope you get enough sleep during this difficult
time... <br>
</p>
</blockquote>
<p>*laugh* I'm doing better thanks. I wrenched something in my
shoulder and it kept me awake or woke me up when I was sleeping.
Much better now.</p>
<p>Thanks! Mike</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com">
<p> </p>
<p>Valerie<br>
</p>
<div class="moz-cite-prefix">On 3/31/2020 10:15 AM, Michael
StJohns wrote:<br>
</div>
<blockquote type="cite"
cite="mid:492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net">
<div class="moz-cite-prefix">Sorry - this one got past me.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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 <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<p class="CCode"><span lang="IT">#define CKM_SHA3_256<span>
</span><span> </span><span> </span>0x000002B0</span></p>
</blockquote>
</div>
<div class="moz-cite-prefix">Just a thought. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks - Mike</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/19/2020 5:27 PM, Valerie Peng
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com">Hi
Mike, <br>
<br>
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? <br>
<br>
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. <br>
<br>
Valerie <br>
<br>
On 3/18/2020 4:07 PM, Michael StJohns wrote: <br>
<blockquote type="cite">On 3/18/2020 6:57 PM, Valerie Peng
wrote: <br>
<blockquote type="cite"> <br>
Anyone has time to help review this straight forward RFE?
It's to add SHA-3 support to Hmac. <br>
<br>
RFE: <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8172680"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8172680</a>
<br>
<br>
Webrev: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/"
moz-do-not-send="true">http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/</a>
<br>
<br>
Mach5 run is clean. <br>
<br>
Thanks, <br>
Valerie <br>
</blockquote>
<br>
Valerie - <br>
<br>
I know the RFE says no PKCS11 because 2.40 doesn't include
those items, but OASIS PKCS11 has proposed SHA3 identifiers
at <a class="moz-txt-link-freetext"
href="https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result"
moz-do-not-send="true">https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result</a>
- maybe reach out and ask if these have been allocated
pending the next release? <br>
<br>
Mike <br>
<br>
<br>
#define CKM_SHA3_256 0x000002b0UL <br>
#define CKM_SHA3_256_HMAC 0x000002b1UL <br>
#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL <br>
#define CKM_SHA3_224 0x000002b5UL <br>
#define CKM_SHA3_224_HMAC 0x000002b6UL <br>
#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL <br>
#define CKM_SHA3_384 0x000002c0UL <br>
#define CKM_SHA3_384_HMAC 0x000002c1UL <br>
#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL <br>
#define CKM_SHA3_512 0x000002d0UL <br>
#define CKM_SHA3_512_HMAC 0x000002d1UL <br>
#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL <br>
<br>
<br>
</blockquote>
</blockquote>
<p><br>
</p>
</blockquote>
</blockquote>
<p><br>
</p>
</body>
</html>