<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
<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>
<p>Thanks & hope you get enough sleep during this difficult
time... <br>
</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>
</body>
</html>