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
