[CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA
Anthony Scarpino
anthony.scarpino at oracle.com
Tue May 19 20:25:00 UTC 2020
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
>>
>
More information about the security-dev
mailing list