[CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA

[Valerie Peng]

Great, if the block file is PKCS7 and contains the signature AlgorithmId 
encoding, then the generated RSASSA-PSS parameter can be included inside 
along with the RSASSA-PSS oid.

Valerie

On 5/19/2020 1:30 PM, Weijun Wang wrote:
> The block file is a pkcs7 in DER. It contains every algid you want. IIRC you can put a DSA signature in a .RSA file.
>
> —Max
>
>> 在 2020年5月20日，04:25，Anthony Scarpino <anthony.scarpino at oracle.com> 写道：
>>
>> I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required.
>>
>> Are these signature files just a byte array of the signature result?  Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key.  In my quick look at the spec, I don't see any the file format definition.
>>
>> Tony
>>
>>> On 5/19/20 11:03 AM, Anthony Scarpino wrote:
>>>> On 5/19/20 2:43 AM, Weijun Wang wrote:
>>>> Please review the CSR at
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8245274
>>>>
>>>> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging.
>>> Is the block file extension just the old FAT 8.3 filename format?  Is there something requiring we have an extension or that it be three or fewer?  I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name.
>>>> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e.
>>>>
>>>>       // Same values for RSA and DSA
>>>>       private static String ifcFfcStrength (int bitLength) {
>>>>           if (bitLength > 7680) { // 256 bits
>>>>               return "SHA512";
>>>>           } else if (bitLength > 3072) {  // 192 bits
>>>>               return "SHA384";
>>>>           } else  { // 128 bits and less
>>>>               return "SHA256";
>>>>           }
>>>>       }
>>>>
>>>> and it's not adjustable. I don't know what the best place is for this info.
>>> Does that make it different than other algorithms that require the parameters to be set?  It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly.
>>> Tony
>>>> Thanks,
>>>> Max
>>>>