New webrev at

    http://cr.openjdk.java.net/~weijun/8242068/webrev.03/

Changes since webrev.02:

- Does not add OID.1.2.3.4 into KnownOIDs's name2enum map. Instead, check for 
the "OID." prefix in SignatureUtil::checkName.

- Add a new "directsign" property to JarSigner.Builder::setProperty.

- s/signManifest/sectionsonly/ and s/externalSF/internalsf/ in JarSigner, to be 
consistent with jarsigner option names.

- When directsign == false, always uses PKCS7.generateNewSignedData

- A new functional test to check several JarSigner properties

CSR (withdrawn and) updated on the new JarSigner property at

    https://bugs.openjdk.java.net/browse/JDK-8245274

Thanks,
Max

> On Jun 2, 2020, at 4:07 PM, Weijun Wang <weijun.w...@oracle.com> wrote:
> 
> Updated again at
> 
>   https://cr.openjdk.java.net/~weijun/8242068/webrev.02
> 
> Major changes this time:
> 
> 1. Use Signed Attributes in generateNewSignedData(direct==false). This means 
> for Ed448 we will use SHAKE256-LEN so there is no interop issue (BTW, BC 
> recently added support to SHAKE256 in 166b07), hence removed the newly added 
> system property in webrev.01.
> 
> 2. Better interop with providers using Ed448 and Ed25519 as key algorithm 
> names.
> 
> Major changes previously:
> 
> 1. Always encode the whole signature algorithm identifier (instead of 
> encryption algorithmid) in PKCS7 SignerInfo.
> 
> 2. New SignatureUtil methods
> 
> Thanks,
> Max
> 
>> On May 27, 2020, at 8:21 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
>> 
>> Webrev updated at
>> 
>>   http://cr.openjdk.java.net/~weijun/8242068/webrev.01/
>> 
>> Two major changes:
>> 
>> 1. Always use the signature algorithm directly in 
>> SignerInfo::signatureAlgorithm:
>> 
>> In PKCS7 SignerInfo
>> 
>>     SignerInfo ::= SEQUENCE {
>>       version CMSVersion,
>>       sid SignerIdentifier,
>>       digestAlgorithm DigestAlgorithmIdentifier,
>>       signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
>>       signatureAlgorithm SignatureAlgorithmIdentifier,
>>       signature SignatureValue,
>>       unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>> 
>> We have always been putting "SHA-1" etc into DigestAlgorithmIdentifier, and 
>> "RSA", "DSA", "EC" into signatureAlgorithm.
>> 
>> The latest https://tools.ietf.org/html/rfc5652#section-10.1.2 claims it to be
>> 
>>  The SignatureAlgorithmIdentifier type identifies a signature
>>  algorithm, and it can also identify a message digest algorithm.
>>  Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
>>  SHA-256. 
>> 
>> It's complicated to always divide a signature algorithm into a digest 
>> algorithm and an encryption algorithm (and with the new RSASSA-PSS and EdDSA 
>> it's not easy to define it), therefore I decide to use the signature 
>> algorithm directly from now on. Fortunately Java has been able to parse this 
>> for a very long time so there is no compatibility issue. I noticed 
>> BouncyCastle has been doing the same, and OpenSSL too except for RSA.
>> 
>> 2. Support both SHAKE256 and SHAKE256-LEN while parsing a Ed448 SignerInfo. 
>> They are both described in https://www.rfc-editor.org/rfc/rfc8419.html 
>> although it's a little complicated. To be standard compliant 
>> (https://www.rfc-editor.org/rfc/rfc8419.html#section-3.2 and we don't use 
>> Signed Attributes), by default Java will use SHAKE256 as the 
>> digestAlgorithm. However I noticed BouncyCastle does not recognize it, so if 
>> you set the system property "jdk.security.pkcs7.ed448.digalg.haslen" to 
>> "true", it will use SHAKE256-LEN (len == 512). I haven't described this 
>> system property in the CSR yet.
>> 
>> Thanks,
>> Max
>> 
>> 
>>> On May 22, 2020, at 10:30 PM, Weijun Wang <weijun.w...@oracle.com> wrote:
>>> 
>>> Please take a review at
>>> 
>>>    CSR : https://bugs.openjdk.java.net/browse/JDK-8245274
>>> webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/
>>> 
>>> Major points in CSR:
>>> 
>>> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in 
>>> jarsigner
>>> 
>>> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a 
>>> signed JAR) are reused for new signature algorithms
>>> 
>>> major code changes:
>>> 
>>> - Move signature related utilities methods from AlgorithmId.java to 
>>> SignatureUtil.java
>>> 
>>> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify 
>>> creating Signature and getting its AlgorithmId
>>> 
>>> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>>> 
>>> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of 
>>> all old and new signature algorithms
>>> 
>>> - Mark all -altsign related code deprecated and they can be removed once 
>>> ContentSigner is removed
>>> 
>>> Next I'll do some basic interop tests with openssl and BouncyCastle.
>>> 
>>> Thanks,
>>> Max
>>> 
>> 
> 

Reply via email to