[security-dev 00791]: Failing compile jdk7/jdk/windows/native/sun/windows/awt_Window.cpp

Is anyone else having a compile failure for the subject class when doing a complete rebuild? (This is using VC 2008). The error occurs around line 489 in the call to GetStringRegion. Looking at the other call to GetStringRegion in this file it looks like the warningString arg is missing a re

[security-dev 00821]: smartcardio - detecting smart token plug in

The current smart card model (javax.smartcardio) permits the application to sit and wait for actions on a collection of "Terminals" (e.g. smart card insertion). The set of terminals you can watch are limited to the terminals that are connected to the system at the time you call the method. Un

[security-dev 01164]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS

This appears to be related specifically to PKCS11. Specifically, PKCS11 v2.20 has some ambiguity of the representation of an EC point (which is different in the text than an ASN1 ECPoint). This is being clarified in v2.30 with the unencoded point format (e.g.the format described in X9.62, wh

[security-dev 01166]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS

At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >2009/9/2 Michael StJohns : >>  This appears to be related specifically to PKCS11. Specifically, PKCS11 >> v2.20 has some ambiguity of the representation of an EC point (which is >> different in the text than an ASN1 ECPoint)

[security-dev 01170]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

At 03:14 PM 9/2/2009, Andrew John Hughes wrote: >Ok here is a new webrev: > >http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ > >with a slightly revised version of your change (you can't throw a >PKCS11Exception which only takes a long ID from the native code, so I >changed this to an Illeg

[security-dev 01172]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

At 01:39 PM 9/3/2009, Andrew John Hughes wrote: >2009/9/3 Michael StJohns : >> >> >> >> At 03:14 PM 9/2/2009, Andrew John Hughes wrote: >>>Ok here is a new webrev: >>> >>>http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >&

[security-dev 01194]: PKCS11 and Win X64?

Any idea why the win x64 jdk and jre 6 builds (1.6.0_16) are shipping without the sunpkcs11.jar? The only posted bug I see on this is from 1.5 ( 6571044) and its marked as resolved. I'm in the process of moving over to an x64 system and this is a prelim to doing an x64 build of jdk6. Its po

[security-dev 01199]: Re: PKCS11 and Win X64?

that could not be tested at >all and could potentially be DOA. > >I looked for a bugid, but don't see one offhand. > >It shouldn't be too hard to enable such a build. > >Brad > > >Michael StJohns wrote: >>Any idea why the win x64 jdk and jre 6 build

[security-dev 01256]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

eroperability or backwards compatibility issues. > > > >Andrew John Hughes wrote: >> 2009/9/2 Andrew John Hughes : >>> 2009/9/2 Michael StJohns : >>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>> 2009/9/2 Michael StJohns : >>>>

[security-dev 01356]: Re: Elliptic curve bugs?

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 th

[security-dev 01541]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

ity issues. > > > >Andrew John Hughes wrote: >> 2009/9/2 Andrew John Hughes : >>> 2009/9/2 Michael StJohns : >>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>> 2009/9/2 Michael StJohns : >>>>>> Â This appears to be r

[security-dev 01549]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

x27;t know how many they need to wake up and review the patch. >>> >>> 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. >>> >>>

[security-dev 01747]: Re: '\0' in alias name of a pkcs11 keystore

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

[security-dev 01751]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore

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 tha

Re: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore

yObject(...) w/ the desired alias. >>Is a custom PKCS11 config file used here? If yes, perhaps it specifies that >>token key be generated for key generation? >>Valerie >>On 03/31/10 17:51, Michael StJohns wrote: >>>KeyPairGenerator should be generating a "Sessi

Re: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore

t'). > >Kind regards, >Tomas > > >Valerie (Yu-Ching) Peng wrote: >>You can use your custom PKCS11 config and as long as you call the KeyStore >>API to store the key (generated as session key) under the desired alias, it >>will be saved as a token key as

Re: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

kcs11.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. > > >

Re: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

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 whic

Re: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

s I'm 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

Re: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

At 08:09 PM 6/27/2010, Andrew John Hughes wrote: >On 28 June 2010 01:05, Michael StJohns 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 >>

Re: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

ease. >Not all bugs 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 StJo

Re: Supporting SHA224WithECDSA

Hi Tomas - I think the current provider is a PKCS11 v2.20 based provider. SHA224withECDSA is being added in v2.30. I remember seeing someone mention an intention to do wholesale pass on PKCS11 to update to 2.30 at some point, but I don't think that's in progress yet. A quick look at the curr

javax.security.auth.Destroyable

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 where possible? Should the methods that use secret and private keys check to see if those k

Re: javax.security.auth.Destroyable

s an instance of Destroyable >or they may call the key's destroy 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 se

Re: Smart Cards in Java Kerberos

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" wrote: > I'm not authoritative, but AFAIK there is no smart card support in Java, > though there

Re: Creating an EC Public Key using Named Curves

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 ECGenP

Re: Creating an EC Public Key using Named Curves

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) wher

Re: Creating an EC Public Key using Named Curves

14 PM 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

Re: Creating an EC Public Key using Named Curves

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. > >>>>>

Re: AES GCM slow

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 s

Re: AES GCM slow

n-US/docs/NSS/NSS_3.14.2_release_notes >-- >Sent from my mobile device. > >Michael StJohns 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 fas

Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary

Actually, www.rfc-editor.org/rfc/rfc.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 wrote: > > I did a similar doc bug fix in the past and one of the comments suggested > using the tool

Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary

df: >http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf >html: >http://tools.ietf.org/html/rfc > >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,

Re: com.sun.crypto.provider.GHASH performance fix

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

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

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

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

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 alwa

BigInteger magnitude (Related to RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes)

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 le

Re: RFR 8068720: ArrayIndexOutOfBoundsException in JSSE with NetscapeCertType "SSL client"

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 set/retri

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

ms. Mike >The intent is to reduce potential confusion with the extended algorithm >Strings specifying MGF functions (withand) by using >the word "in" for conjunction and to append "Format" to the format name. > >Would you be ok with this solution? > &g

Re: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently

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 > destinationLe

Re: RFR 8023546: sun/security/mscapi/ShortRSAKey1024.sh fails intermittently

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 shoul

Re: Please Review: required security algorithms for Java SE 7 implementations

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 work?

Re: 7007966: Add Brainpool ECC support (RFC 5639)

At 08:04 PM 12/23/2010, Brad Wetmore wrote: >> To use those EC curves in TLS, IANA need to register these curves[*]. >> Do you know any effort to use these curves in TLS? > >Xuelei was primarily asking about this from the TLS perspective. RFC 5639 >just claims its use would be consistent with the

Re: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11

Hi Vincent - Sorry - it took me a few days to look at this. I can't support it. I think this the wrong way to do things - specifically the dependence on the presence of a PKCS11 attribute in the Vendor space. You've got a value in PKCS11Constants +/* Only the raw encoding for an EC

Re: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11

)? 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

Re: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11

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

Re: 7054637 closed/lib/security/cacerts/VerifyCACerts.java failed on solaris 11

cX963Encoding' just >like 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 StJoh

Re: code review request: 7099399: cannot deal with CRL file larger than 16MB

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 < 0x

Re: code review request: 7099399: cannot deal with CRL file larger than 16MB

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 co

Re: Is there an algorithm that computes the strength of a digest alg?

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 to

Re: code review request: 7109096: keytool -genkeypair needn't call -selfcert

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 insta

Algorithm Names - registry?

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 buil

Re: Algorithm Names - registry?

e used across >implementations. Having three possible aliases like for SHA1 (SHA-1, SHA1, >SHA) 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 completel

Possible changes to javax.smartcardio

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. Basicall

Re: Code review request: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc

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 wrote: >> >>> Please review the following change: >>> http://cr.openjdk.java.net/~vinnie/7142888/webrev.00/ >>> >>> for http://bugs.sun.com/bugdatabase/view_bug.do?bu

Re: Code Review Request for 7146728 and 7130959

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 en

Re: Code Review Request for 7146728 and 7130959

that RFC 2631 wasn't authoritative on the matter for the RAW >operation's data representation. As mentioned, 800-56A:C1 is a better >reference/justification. > >Brad > > > >On 3/1/2012 2:08 PM, Michael StJohns wrote: >>Hi Brad - >> >>The out

Re: Code Review Request for 7146728 and 7130959

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 byte

Dates and certificates

Hi - I've been trying to figure out which changes would be necessary to support the "inifinite" date used in RFC5280 for certificates that don't expire (e.g. 1231255959).(e.g. java.security.cert.X509Certificate) I first thought this would be as easy as supporting the use of Calendar in

Re: Dates and certificates

s to Vincent and Xueming for the info on what 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 ch

Re: How to detect if a PKCS11 token presents in a system?

C_GetSlotInfo will tell you whether or not there is a token in the slot. Sent from my iPad On Jun 15, 2012, at 7:49, Andrey Atapin wrote: > Hello, > Right now I'm solving this problem by calling 'getMechanismsList' on > the PKCS11 wrapper object. Considering that Windows x86-64 doesn't > have

Re: 7168191: Signature validation can fail under certain circumstances

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 n

Re: 7168191: Signature validation can fail under certain circumstances

root key may not be bound into a certificate at all. Thanks! Mike >On 06/19/12 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 val

Re: code review request for 6880559: Enable PKCS11 64-bit windows builds

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 wrote: > Please review this changeset to (finally) add support for PKCS11 on 64-bit > Windows. > > Bug Report: > http://bugs.sun.com/bugdatabase/view_bug.do?bug

Re: Code review request: 7197245: Eliminate sun.security.ssl.JsseJce dependency on sun.security.ec

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

Re: Code review request: 7197245: Eliminate sun.security.ssl.JsseJce dependency on sun.security.ec

At 06:31 AM 9/12/2012, Vincent Ryan wrote: >>Also, instead of the function trimZeroes, how about instead a >>"static byte getMagnitude (BigInteger val, int magSize)" method which is >>really what you're trying to do. Still throw the RuntimeError, but do it >>inside that method. This is a meth

Re: Code review request: 7197245: Eliminate sun.security.ssl.JsseJce dependency on sun.security.ec

At 06:31 AM 9/12/2012, Vincent Ryan wrote: >>Also, instead of the function trimZeroes, how about instead a >>"static byte getMagnitude (BigInteger val, int magSize)" method which is >>really what you're trying to do. Still throw the RuntimeError, but do it >>inside that method. This is a meth

Re: Code review request: 7197245: Eliminate sun.security.ssl.JsseJce dependency on sun.security.ec

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 gr

Re: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores

At 08:27 PM 9/28/2012, [email protected] 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 algo

Re: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores

kits and web browsers. Yup - 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/201

Re: JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores

oring, and you don't 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

Re: Request for comment: Supporting password expiration alert in JAAS

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

Re: Request for comment: Supporting password expiration alert in JAAS

*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 "PrincipalAt

Re: RFR: 8001579, security code modifications that eliminate compiler warnings, etc.

For the PKCS11 wrapper stuff, would it be legitimate to tie this to JNA? The current version of the wrapper is about 8 years old - and doesn't support a lot of the new mechanisms. At some point, this is going to need an update to support PKCS11 v2.30 and other new mechanisms. I had a thought t

Re: Transitioning the default keystore format to PKCS#12

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 >f

Re: Transitioning the default keystore format to PKCS#12

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 implem

Re: Transitioning the default keystore format to PKCS#12

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. >

Re: Transitioning the default keystore format to PKCS#12

anchor". I can't find an OID that means this and I've looked. >On 4 Nov 2012, at 21:31, Michael StJohns wrote: > >> At 11:14 PM 11/1/2012, Michael StJohns wrote: >>> The appeal of re-purposing the extendedKeyUsage attribute is that it is >>> alr

Re: Transitioning the default keystore format to PKCS#12

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

Re: Transitioning the default keystore format to PKCS#12

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 po

Re: Code Review Request, 7109274, Consider disabling support for X.509 certificates with RSA keys less than 1024 bits

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 signa

Re: Code Review Request for 6996769: support AEAD ciphers

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 mec

Re: Code Review Request, 7109274, Consider disabling support for X.509 certificates with RSA keys less than 1024 bits

robably consider updating the release notes 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

Re: Code Review Request for 6996769: support AEAD ciphers

ou really want is some state to continue from Cipher.init to Cipher.init call without reference to an externally twiddleable object. 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 probabl

Re: Code Review Request for 6996769: support AEAD ciphers

te the IV (IV >>generator). (Hmm... possibly a common interface method for AEAD and CTR mode >>parameter spec object). >> >>For the pass back and forth between the GCMAlgorithmParameter object and >>this, just reflect the state at the time called. >>

Re: Code Review Request for 6996769: support AEAD ciphers

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

Re: JEP 123: SecureRandom First Draft and Implementation.

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 wi

Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.

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. E

Re: [8] Code review request for 8005408: KeyStore API enhancements

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 PKCS12Attri

Re: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name

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/ > >Thanks. This first is not a comment on the change - but a "why can't ja

Re: RFR: JDK-8007607

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, V

Re: RFR JDK-8006182

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. Neith

Re: RFR JDK-8006182

CERTIFICATE and BEGIN NEW CERTIFICATE..."), and not care about white space between the "-" and the beginning or end of the sentinel string. To answer the question you didn't quite ask - no, this isn't critical, but since the code is open... just a thought. Mike >-

Re: RFR JDK-8006182

/2013, 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

Re: RFR JDK-8006182

n of course propose a separate patch, but I >don't think it should prevent this proceeding. Agreed. >-Chris > >On 15 Feb 2013, at 20:26, Michael StJohns wrote: > >> At 11:57 AM 2/15/2013, Chris Hegarty wrote: >>> Mike, >>> >>> I believe t

Re: Conceptual feedback on new ECC JEP

On 9/18/2018 4:01 PM, Adam Petcher wrote: On 9/11/2018 11:07 AM, Adam Petcher wrote: I still haven't been convinced that this lack of interoperability is a significant problem. In the proposed design, the new KeyFactory will not support ECPrivateKeySpec, and the implementation will produce

Re: Conceptual feedback on new ECC JEP

On 9/19/2018 11:45 AM, Adam Petcher wrote: On 9/18/2018 4:24 PM, Michael StJohns wrote: Adam - Basically, the JCE is all about plugging in not about the implementations.  If this is truly an EC library, I should be able to get the benefit of your library with very minimal changes - e.g

Re: Conceptual feedback on new ECC JEP

On 9/25/2018 12:06 PM, Xuelei Fan wrote: On 9/25/2018 8:34 AM, Adam Petcher wrote: Yes, it is possible, at the expense of some assurance related to security against side-channel attacks. This interoperable implementation will be available by default in SunEC. A higher-assurance form of the s

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

On 10/10/2018 10:42 AM, Weijun Wang wrote: On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before ch

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

Any thought to just deprecating keytool as such and adding a new tool with more modern semantics?    e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel.   A lot more

  1   2   3   >