RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA
Weijun Wang
weijun.wang at oracle.com
Tue Jun 2 08:07:01 UTC 2020
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.wang at 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.wang at 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
>>
>
More information about the security-dev
mailing list