On 8/7/2017 4:37 PM, Adam Petcher wrote:
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman
with X25519 and X448). I know some of you have been anxious to talk
about how this would fit into JCA, and I appreciate your patience
while I learned enough about JCA and existing crypto
On 8/4/2017 3:05 PM, Anders Rundgren wrote:
https://lists.oasis-open.org/archives/pkcs11/201708/msg6.html
C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
Yeah, I know that open source <> open ideas but the world needs a
direction.
Feel completely free dismissing
On 7/10/2017 2:28 PM, Adam Petcher wrote:
On 7/10/2017 1:55 PM, Michael StJohns wrote:
What I'm mostly trying to get at here is to decouple or remove the
list of curves in ecdecode.c in favor of the list in the java stuff
(CurveDB.java) (or elsewhere). The C code should mostly only have
of curves in ecdecode.c in favor of the list in the java stuff
(CurveDB.java) (or elsewhere). The C code should mostly only have to
deal with the math and not the housekeeping.
Mike
On 7/10/2017 12:17 PM, Michael StJohns wrote:
Actually - wouldn't it make a lot more sense to generalize the
p
Actually - wouldn't it make a lot more sense to generalize the provider
so it can take ANY set of curve data? Locking this to only what has an
OID to parameters mapping doesn't seem to be actually meeting the
contract for an EC key generator.
I understand a number of tools (e.g. PKIX
Inline.
On 6/26/2017 2:56 PM, Anders Rundgren wrote:
On 2017-06-26 17:58, Michael StJohns wrote:
Umm... SHOULD is not a MUST - JDK8 does comply with the RFC, it just
doesn't provide the "convenient" field:
I always thought that RFC5915 should have specified "MAY&
On 6/25/2017 2:21 AM, Anders Rundgren wrote:
During the work with https://github.com/cyberphone/java-cfrg-spec I
had to look at the PKCS #8 spec as well.
It turns out that JDK 8 does not comply with RFC 5915's SHOULD since
EC private keys created by KeyPairGenerator do not contain public key
a GeneralizedTime with
a long fractional part and "openssl asn1parse" accepts it and
displays all the digits.
I can read X.680 but it does not mention any restriction.
Thanks
Max
On 06/13/2017 01:07 AM, Michael StJohns wrote
The actual bound in GeneralizedTime is 6 digits of fracti
On 6/12/2017 9:18 AM, Weijun Wang wrote:
On 06/12/2017 08:47 PM, Vincent Ryan wrote:
This approach looks fine to me given the limitation on the precision
of Date.
Just one issue: why remove the upper bound at l.277 in
DerInputBuffer.java
Before this fix, the maximum length of a
On 1/12/2017 1:50 PM, Michael StJohns wrote:
On 1/12/2017 3:03 AM, Weijun Wang wrote:
I am writing a tool to warn about weak key usage in a certificate or
CRL. One of the warnings is if it's signed by a cert with a small key
size.
But the signer's cert is not always available. I can see
On 1/12/2017 3:03 AM, Weijun Wang wrote:
I am writing a tool to warn about weak key usage in a certificate or
CRL. One of the warnings is if it's signed by a cert with a small key
size.
But the signer's cert is not always available. I can see that the
signature's size depends on the signer's
On 9/29/2016 11:28 AM, Andrew Haley wrote:
GCM allows most of the work in an encryption to be done offline (and
ahead of time) by other processors, reducing latency and increasing
throughput. It'd be lovely if we could do this in Java, but I can't
really see a way to fit this in to the platform
from blowing up existing implementations.
In any event, that's a different problem than the current one.
Thanks for the review and feedback, it's very helpful,
You're welcome - Mike
Valerie
On 8/18/2016 2:25 PM, Michael StJohns wrote:
On 8/18/2016 4:49 PM, Valerie Peng wrote:
Hi Mike
Hi -
Looking at Valeries changes to the above made me take a closer look at
the current definitions of the various RSA key interfaces. What would be
the impact of the following changes?:
Make RSAMultiPrimePrivateCrtKeySpec extend RSAPrivateCrtKeyKeySpec
instead of RSAPrivateKeySpec.
it and provide you unverified code you can integrate.
On 8/17/2016 9:55 AM, Michael StJohns wrote:
On 8/16/2016 9:24 PM, Valerie Peng wrote:
Anyone has time to review a straightforward fix? The current PKCS11
code assume that if public exponent is available for RSA Private
Key, the
On 8/16/2016 9:24 PM, Valerie Peng wrote:
Anyone has time to review a straightforward fix? The current PKCS11
code assume that if public exponent is available for RSA Private Key,
then it's a RSA CRT key. However, not all vendor implementation works
this way. Changing to a tighter check and
On 6/28/2016 1:02 PM, Artem Smotrakov wrote:
Hi Xuelei,
Even if the tests keep using UDP to transfer data, they may not be
realistic since they run on local host. UDP implementation is based on
functions provided by OS. If I remember correctly, Solaris may do some
optimizations for localhost
On 5/21/2016 5:01 AM, Wang Weijun wrote:
I meant coding style.
--Max
I agree with Max. I'd rather have too long lines than break in the
middle of an arg definition.
In the current case, for all except the first line - replaceAll, break
before "BiFunction" or "Function". For the
Hi -
To be very specific here - if a certificate has extensions, it MUST be
version 3, otherwise it SHOULD be version 1, but may be version 2 or 3.
(If a certificate has either of the issuer or subject unique ID fields,
it must be at least version 2 - but those fields are deprecated as a
On 5/10/2016 2:37 AM, Wang Weijun wrote:
On May 10, 2016, at 7:58 AM, Xuelei Fan <xuelei@oracle.com> wrote:
On 5/10/2016 12:16 AM, Michael StJohns wrote:
You're going to hate me, but shouldn't this be checking the Provider
rather than the OS when trying to determine which test to
You're going to hate me, but shouldn't this be checking the Provider
rather than the OS when trying to determine which test to ignore?
Mike
On 5/9/2016 10:36 AM, Xuelei Fan wrote:
Updated to ignore the test on Solaris only:
http://cr.openjdk.java.net/~xuelei/8154344/webrev.01/
Thanks,
Does anyone else think there's something wrong with SecureRandom being
serializable? In general, the internal state of a random number
generator shouldn't be extract-able or even saveable.
I realize this behavior has probably been in the class since the
beginning - but I hadn't actually read
On 5/6/2016 10:40 AM, Xuelei Fan wrote:
Hi,
Please review this simple test failure fix:
http://cr.openjdk.java.net/~xuelei/8154344/webrev.00/
The underlying crypto lib may generate DH private keys out of the normal
expected range. This fix removes the range checking for DH private keys.
Quick side question - how does the "Standard Algorithm Names" doc get
updated to include SHA3 stuff? Should it be folded into this change or?
Mike
On 5/4/2016 10:08 PM, Valerie Peng wrote:
Hi,
Can someone help reviewing the changes for SHA-3?
The result has been validated against the NIST
On 4/20/2016 1:40 PM, Jamil Nimeh wrote:
On 04/15/2016 05:02 PM, Michael StJohns wrote:
On 4/15/2016 5:33 PM, Jamil Nimeh wrote:
Hi Mike, thanks for your comments and suggestions, I need to digest
some of this but I have some follow-up questions to start:
On 04/15/2016 12:54 PM, Michael
On 4/15/2016 5:33 PM, Jamil Nimeh wrote:
Hi Mike, thanks for your comments and suggestions, I need to digest
some of this but I have some follow-up questions to start:
On 04/15/2016 12:54 PM, Michael StJohns wrote:
Hi Jamil -
I need to look at this a bit more, but I think its probably
Hi Jamil -
I need to look at this a bit more, but I think its probably incorrect.
Basically, KDFs should be able to provide multiple keys from a single
call, not a single key as you've described here. They may also may
need to provide non-key cryptographic material such as IV's. The
this would allow other PKCS11 DLLs to work with the SunPKCS11
provider even before you implement the SHA3 support in the underlying
Solaris/NSS crypto libraries.
If you're willing to do the update, I'm willing to do the grunt work of
merging in the new constants and mappings.
Later, Mike
Rega
On 2/17/2016 7:49 PM, Valerie Peng wrote:
Please review this drafted JEP for adding SHA-3 Hash Algorithm support
to JDK 9:
https://bugs.openjdk.java.net/browse/JDK-8064399
Thanks,
Valerie
This looks pretty good. However, I wouldn't throw PKCS11 to the side of
the road.
I believe you need to take "a mod p" to get the correct value. If you
google for one of the other values in the table, you can find
implementations that pre-reduce this and have a value for a that is 3
less than p.
BTW - this is generally not the place to ask non-JDK questions.
Mike
Hmm...
It is possible to randomly generate a prime which is expressed in less than the
full number of provided bytes so it is possible (and legal) for sourceLength to
be less than or equal to destination length. What should probably be checked
here though is :
if (sourceLength
At 12:21 AM 6/22/2015, Michael StJohns wrote:
Hmm...
It is possible to randomly generate a prime which is expressed in less than
the full number of provided bytes so it is possible (and legal) for
sourceLength to be less than or equal to destination length. What should
probably be checked
Not critical and more work, but maybe just update this to use java.util.BitSet?
Mike
At 04:04 PM 1/28/2015, Ivan Gerasimov wrote:
Hello!
Behavior of sun.security.x509.NetscapeCertTypeExtension turns out to be
inconsistent.
It greatly depends on the order in which the entries are
In the code for dealing with R and S in the ECDSA engine is the same construct
I've seen several times and programmed in several different ways mostly inside
the security code. To wit:
Given a positive BigInteger, return a byte array of the magnitude of a specific
length, right adjusted and
At 05:42 PM 1/26/2015, Sean Mullan wrote:
On 01/25/2015 11:15 PM, Michael StJohns wrote:
Sorry - I missed this the first time around I think this may not
be the right approach...
I'm concerned with trying to overload ECDSA and DSA which have always
had relationships with very specific
Sorry - I missed this the first time around I think this may not be the
right approach...
I'm concerned with trying to overload ECDSA and DSA which have always had
relationships with very specific specifications and trying to make them also
cover P1363.
A better approach may be to create
Just for curiosity, what was the improvement in performance?
I'm wondering if it might be worthwhile to see if its possible to add a plugin
to use the hardware instructions:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf
/rfcnum.txt.pdf
html:
http://tools.ietf.org/html/rfcnum
For Java docs, I think the html version may be better to track the
history and links.
Xuelei
On 1/7/2015 3:49 PM, Weijun Wang wrote:
On 1/7/2015 14:26, Michael StJohns wrote:
Actually,www.rfc-editor.org/rfc/rfcnum.txt is probably a better long
Actually, www.rfc-editor.org/rfc/rfcnum.txt is probably a better long term
normative reference for documents in the RFC series.
Mike
Sent from my iPad
On Jan 7, 2015, at 00:06, Jamil Nimeh jamil.j.ni...@oracle.com wrote:
I did a similar doc bug fix in the past and one of the comments
At 09:23 AM 1/27/2014, Mark Christiaens wrote:
Silly me, forgot to mention that I'm working on Ubuntu, 64 bit, 13.10.
So, AES-CBC seems to be reasonably fast (100 MiB/s) but AES-GCM is slow (5.2
MiB/s). Â I'm particularly curious about the GCM one because I get the
impression that OpenSSL
/NSS_3.14.2_release_notes
--
Sent from my mobile device.
Michael StJohns mstjo...@comcast.net wrote:
At 09:23 AM 1/27/2014, Mark Christiaens wrote:
Silly me, forgot to mention that I'm working on Ubuntu, 64 bit, 13.10.
So, AES-CBC seems to be reasonably fast (100 MiB/s) but AES-GCM is slow (5.2
I use this construct a lot, but there are a number of cases (e.g. where I'm
trying to take an EC key and turn it into a structure to send to a smart card)
where what I really need is to be able to produce an EllipticCurve (actually
ECParamaterSpec) from a name.
I started looking at why
At 01:38 PM 10/8/2013, Vincent Ryan wrote:
On 8 Oct 2013, at 17:56, Michael StJohns wrote:
I use this construct a lot, but there are a number of cases (e.g. where I'm
trying to take an EC key and turn it into a structure to send to a smart
card) where what I really need is to be able
10/8/2013, Michael StJohns wrote:
At 01:38 PM 10/8/2013, Vincent Ryan wrote:
On 8 Oct 2013, at 17:56, Michael StJohns wrote:
I use this construct a lot, but there are a number of cases (e.g. where I'm
trying to take an EC key and turn it into a structure to send to a smart
card) where what I
At 03:44 PM 10/8/2013, Michael StJohns wrote:
This fails using bouncy castle. There is no EC factory for
AlgorithmParameters for BC 1.49.
Mike
I'm going to try out this construct on BouncyCastle and see if it works for
their curve tables.
However you can generate named curves using
Java provides the javax.smartcardio package for direct access to the smart
card. But that's probably not what he's looking for. Mike
Sent from my iPad
On Jun 25, 2013, at 19:29, Henry B. Hotz hbh...@lavenderwine.com wrote:
I'm not authoritative, but AFAIK there is no smart card support in
method and handle the possible exception.
On 14 Jun 2013, at 17:42, Michael StJohns wrote:
Generic questions for possible future work:
As a general guideline, would it make sense to add
javax.security.auth.Destroyable to the set of interfaces for SecretKey and
PrivateKey implementation objects
Is the mime variant of Base64 the correct one for this? I ask because that
variant ignores extraneous characters rather than throwing an error on decode.
Also, reading the code for the Base64 implementation, it silently fixes the
case where there are missing padding = characters. Neither of
, Xueming Shen wrote:
On 2/15/13 8:52 AM, Michael StJohns wrote:
Is the mime variant of Base64 the correct one for this? I ask because that
variant ignores extraneous characters rather than throwing an error on
decode. Also, reading the code for the Base64 implementation, it silently
fixes the case
a separate patch, but I
don't think it should prevent this proceeding.
Agreed.
-Chris
On 15 Feb 2013, at 20:26, Michael StJohns mstjo...@comcast.net wrote:
At 11:57 AM 2/15/2013, Chris Hegarty wrote:
Mike,
I believe that Marks changes are a like for like replacement with what was
there before
It seems to me that this is a pretty common pattern. Would it make better
sense to define standard jni_malloc and jni_calloc functions that throw an OOM
if the underlying allocation fails and use those rather than having to add the
if statement check everywhere?
Mike
At 03:19 PM 2/8/2013,
At 08:47 AM 1/25/2013, Vincent Ryan wrote:
Please review this fix to correct a failing PKCS12 test:
Webrev:
http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/
Thanks.
This first is not a comment on the change - but a why can't java do
In KeyStore.java -
Attribute should probably be abstract rather than interface - mainly because
you need to define equals properly to honor the Set contract for an attribute.
E.g. the equals is only against the name - not the encoded name/value. This
can be overridden later.
In
At 09:45 AM 1/9/2013, Sean Mullan wrote:
think it is unlikely that 2 providers would implement the same SecureRandom
algorithm, since the names are not standardized like other cryptographic
algorithms such as SHA-256, RSA, etc.
Can this be fixed? There really should be a flavor for this.
Hi Brad et al -
I think its possible you're focusing too much on implementations and less on
the class of random number generator.
There are basically three types of RNG - a true RNG which uses a noise source
of some sort for its entropy (and which may be *conditioned* in its output to
deal
At 09:17 PM 1/3/2013, Valerie (Yu-Ching) Peng wrote:
Michael,
I thought this some more. I think a cleaner way to do what you wanted may be
achieved by adding an AlgorithmParameterGenerator impl for GCM.
*sigh* I forgot to answer this.
I think this would probably work too. But I agree that
. Cipher.updateIV which would do an internal reset and then update the
parameter counter appropriately to get a new IV for the next message?
Something similar will probably be needed for CCM as well.
Valerie
On 12/13/12 20:07, Michael StJohns wrote:
Sorry for the late comment -
You might want to consider
Does this go far enough?
If you're going with NIST recommendations, anything less that 112 bits of
strength is now considered weak. The guidance is those strengths are
deprecated now, and prohibited after the end of 2013. In addition, SHA1 is
deprecated now and prohibited after 2013 for
Sorry for the late comment -
You might want to consider section 9.1, first paragraph of SP800-38D which
defines the GCM mode. Basically, for FIPS validated implementations, to
prevent accidental reuse, the IV needs to be generated inside the cryptographic
boundary using one of the defined
to note that the default
could change again in 2013 or 2014 to the even stronger values (and SHA1
removed) and how to re-enable the weaker strengths.
Thanks - Mike
Xuelei
On 12/14/2012 11:21 AM, Michael StJohns wrote:
Does this go far enough?
If you're going with NIST recommendations
At 03:52 PM 11/5/2012, Vincent Ryan wrote:
On 05/11/2012 18:28, Michael StJohns wrote:
At 09:17 AM 11/5/2012, Vincent Ryan wrote:
Thanks for your suggestion Mike. I quite like that approach but I'm
concerned that existing tools and
browsers do not support this new type of PKCS12 safe bag.
I went
At 02:20 PM 11/6/2012, Vincent Ryan wrote:
A certificate unpaired with a private key will not be imported with existing
tools. (MS certmgr and firefox/thunderbird). If its paired with a private
key, it gets imported into the personal cert portion of the certificate
store. It's possible
At 11:14 PM 11/1/2012, Michael StJohns wrote:
The appeal of re-purposing the extendedKeyUsage attribute is that it is
already well known as a certificate extension. And in addition, it can be used
by keystore owners to limit a cert's trust level to quite specific purposes.
This is one of those
At 12:55 PM 10/31/2012, Vincent Ryan wrote:
Before considering migrating the platform default keystore format to PKCS12
its keystore implementation
must at least match the functionality of JKS.
I have developed a prototype of a multi-format keystore that understands both
JKS and PKCS12
formats
At 02:26 PM 11/1/2012, Vincent Ryan wrote:
On 1 Nov 2012, at 17:50, Michael StJohns wrote:
At 12:55 PM 10/31/2012, Vincent Ryan wrote:
Before considering migrating the platform default keystore format to PKCS12
its keystore implementation
must at least match the functionality of JKS.
I
This seems too specific to password based authentication.
How about something like a PrincipalAttributes interface to go along with
Refreshable and Destroyable?
Properties getAttributes();
define a few names: accountExpiration, passwordExpiration, lastLoginTime etc
and their default meanings.
*sigh*
Not Refreshable and Destroyable, but Group and UserPrincipal...
Mike
At 11:25 AM 10/17/2012, Michael StJohns wrote:
This seems too specific to password based authentication.
How about something like a PrincipalAttributes interface to go along with
Refreshable and Destroyable
At 08:27 PM 9/28/2012, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/166
- Mark
This seems at least partially related to JEP 121 and maybe even dependent on
it. Might be useful to have a cross reference. Also, probably useful to
decide/state a new default PKCS12
- but someone has to be first :-)
Mike
Is there any interest among those on this list in promoting wider support for
these PBE algorithms?
Thanks.
On 1 Oct 2012, at 17:06, Michael StJohns wrote:
At 08:27 PM 9/28/2012, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps
specify the algorithm, you get the
default (perhaps specified in java.security props file next to the keystore
default type?)
Mike
Mike
On 1 Oct 2012, at 18:50, Michael StJohns wrote:
My main reason for suggesting this is that the all but one of the algorithm
suites defined in PKCS12
Sorry - additional comment. I think this one needs to be entered as a bug as
it needs to be fixed both places.
In encodePoint at 426,427
int n = (data.length -1 ) / 2; // fix component size calculation.
if ( n != ((curve.getField().getFieldSize() + 7 ) 3)) { // has to be equal,
not just
There's a number of places where Arrays.copyOfRange might be a better choice
than System.arraycopy and the various array creations - if only for
readability.
Also, instead of the function trimZeroes, how about instead a
static byte getMagnitude (BigInteger val, int magSize) method which is
Any chance this will get back-ported to jdk7? (or has it already?)
Mike
Sent from my iPad
On Jul 12, 2012, at 16:48, Vincent Ryan vincent.x.r...@oracle.com wrote:
Please review this changeset to (finally) add support for PKCS11 on 64-bit
Windows.
Bug Report:
09:48 PM, Michael StJohns wrote:
Hi - there's two different varieties of authorityKeyIdentifier - you only
fixed one.
If the child cert has an akid consisting of the value of the parent skid,
then you're good to go. But there's also the akid variant which contains
issuerName/serialNumber of its
Hi - there's two different varieties of authorityKeyIdentifier - you only fixed
one.
If the child cert has an akid consisting of the value of the parent skid, then
you're good to go. But there's also the akid variant which contains
issuerName/serialNumber of its parent where the parent has
I was doing wrong with
Calendar. Both hints were needed to resolve the issue.
Mike
At 11:23 AM 4/10/2012, Sean Mullan wrote:
On 04/09/2012 02:07 PM, Michael StJohns wrote:
Hi -
I've been trying to figure out which changes would be necessary to
support the inifinite date used in RFC5280
Sorry for the late comment here -
It may make sense to make a utility function with the calling sequence similar
to
static byte[] getBytesFixedLength (BigInteger x, int numBits)
throws IllegalArgumentException
some where in the security utility code.
The length of the returned
Hi Brad -
The output of the DH calculation needs to preserve leading zeros.
The RFC unfortunately doesn't specify the Integer to Byte conversion primitive,
but both X9.42 and the equivalent text in NIST SP800-56A (appendix C.1) make
it clear that the conversion from Integer to Byte string
At 12:24 PM 2/13/2012, Vincent Ryan wrote:
On 02/13/12 05:04 PM, Xuelei Fan wrote:
On Feb 14, 2012, at 12:47 AM, Vincent Ryan vincent.x.r...@oracle.com wrote:
Please review the following change:
http://cr.openjdk.java.net/~vinnie/7142888/webrev.00/
for
Hi -
I've been looking javax.smartcardio with an eye to making two changes - one
that can be handled completely within the sun.security.smartcard.SunPCSC
provider, and one that will need an API change.
The first is adding support in the provider for the plug and play
pseudo-terminal.
) just makes things confusing for end users.
Hadn't really thought about adding Javacard algids here. I know outside
Oracle this shouldn't matter, but they're a completely different group.
My $.02.
Brad
On 11/28/2011 10:30 AM, Michael StJohns wrote:
One of the items that seems terribly out
One of the items that seems terribly out of date is the Standard Names list.
Also, sometimes its difficult to tell which algorithm - specifically - the name
applies to.
I'm wondering if it isn't time to create something like a Wiki for name
registration and - for example - let the folks
Looking at the API definitions, it's possible for an RSAPublicKey
implementation to have an encoding that is not X.509. So, the right check
really is publicKey.getFormat().equalsIgnoreCase(X.509) and not publicKey
instanceof RSAPublicKey. No need for the or check. Or maybe the instance
Assuming that a1 and a2 both refer to MessageDigest implementations, then you
could simply compare MessageDigest.getInstance(a1).getDigestLength(). It
won't give you an absolute - MD5 for example is weaker than its bit length
would lead you to believe.
Also, getDigestLength() can return 0
the encoder method in P11ECKeyFactory.java
The updated webrev is at:
http://cr.openjdk.java.net/~vinnie/7099228/webrev.00/
(NOTE: I've used a new bug ID for this change)
Thanks.
On 09/24/11 01:24 AM, Michael StJohns wrote:
At 04:13 PM 9/23/2011, Vincent Ryan wrote:
On 09/23/11 05:41 PM, Michael
Two things -
1) Why not just extend this to support unsigned long rather than just the 32
bit value - not saying it will be needed, but seems like you might as well do
this once.
2) How about cleaning up this section of code and moving it to an iterative
model:
long length = 0;
if (n
At 04:06 PM 10/11/2011, Weijun Wang wrote:
2) How about cleaning up this section of code and moving it to an iterative
model:
Yes, your codes look more correct. However, this is a regression bug and we
need to fix it fast and with zero risk. Therefore, I choose this stupid and
lazy code
)?
Otherwise I'm fine with this fix.
Mike
At 11:41 AM 9/23/2011, Vincent Ryan wrote:
Thanks for your feedback Michael. I agree that your provider-based solution is
preferable. Here's a revised webrev:
http://cr.openjdk.java.net/~vinnie/7054637/webrev.01/
On 09/22/11 11:18 PM, Michael StJohns wrote
At 04:13 PM 9/23/2011, Vincent Ryan wrote:
On 09/23/11 05:41 PM, Michael StJohns wrote:
Heh - I thought this looked familiar.
Please take a look at my comments in bug 6763530, especially the fix for
P11Key around line 1017.
I didn't see any comments from you in bug 6763530?
The 29
Is it possible to deprecate the signing part of the mechanism while requiring
the verification part?
There's a whole pile of MD5withRSA and MD2withRSA root certificates.
Obviously, you don't want to support further signatures, but it would be useful
if you can still verify.
Or too much
are backported, it's subject to RE's discretion.
I've opened a subCR against this particular release train and Vinnie can
decide what to do w/ this once he returns from vacation.
Regards,
Valerie
On 06/27/10 17:13, Michael StJohns wrote:
At 08:09 PM 6/27/2010, Andrew John Hughes wrote:
On 28
.jar provider not getting regenerated and rebundled during the
release process?
Mike
At 01:28 PM 1/21/2010, Michael StJohns wrote:
At 05:12 AM 1/21/2010, Vincent Ryan wrote:
I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today.
On 21/01/2010 07:44, Tomas Gustavsson
PS - I know this is the openjdk list - but I thought this one was getting back
ported.
Mike
At 05:37 PM 6/27/2010, Michael StJohns wrote:
Hi guys -
I see from the Mercurial logs that this went in to both the jdk6 and jdk7
repositories. For jdk6 - it's rev 302 which looks like this should
working with would rather use the pre-packaged Windows version etc etc etc...
*sigh*.
Thanks - Mike
At 07:17 PM 6/27/2010, Andrew John Hughes wrote:
At 05:37 PM 6/27/2010, Michael StJohns wrote:
Hi guys -
I see from the Mercurial logs that this went in to both the jdk6 and jdk7
repositories
At 08:09 PM 6/27/2010, Andrew John Hughes wrote:
On 28 June 2010 01:05, Michael StJohns mstjo...@comcast.net wrote:
Hi Andrew -
I really need to work on fleshing out my emails... :-/
The _20 release of the normal (non-OpenJDK) is missing this update. Â I had
thought that this fix
?
Valerie
On 04/19/10 08:08, Tomas Gustavsson wrote:
If we need it it's usually for all keys, both RSA and EC.
Cheers,
Tomas
Michael StJohns mstjo...@comcast.net wrote:
At 04:34 AM 4/19/2010, Tomas Gustavsson wrote:
Hi,
Sorry being late, I was away on vacation.
Yes in most cases we do use
This may actually be a bug in the PKCS11 provider.
KeyPairGenerator should be generating a Session key pair.
When you write the key store object, the underlying function should do a
C_CopyObject from the Session object to a Token object. (Or from a software
key to a Token object). At that
At 03:05 AM 3/26/2010, Tomas Gustavsson wrote:
You can set an alias by providing it using pkcs11 attributes through the
provider, but that alias is provider global (for all generated key pairs)
which is not very usable.
The work around for this is to open up the provider different times with
.
The new release of IcedTea6 1.7 is imminent and will include the fix
so it should at least be resolved on the next version shipping with
most GNU/Linux distributions.
Regards,
Tomas Gustavsson
PrimeKey Solutions AB
On Wed, 20 Jan 2010, Michael StJohns wrote:
Hi - this seems to have
I submitted the fix a while ago at
https://bugs.openjdk.java.net/show_bug.cgi?id=100048
Still pending... Mike
At 03:38 AM 11/2/2009, Tomas Gustavsson wrote:
Hi,
I found this by for Elliptic curve crypto:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6738532
It's quite old and there
101 - 200 of 205 matches
Mail list logo
