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.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

Reply via email to