If the code exists that reusing the old extensions, then that's probably
best. But if it requires a large reworking of the code maybe it's not
worth all that work when two new extension values are easier. I'm ok
either way you want to proceed.
Tony
On 5/19/20 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.scarp...@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
