I simplified the issue. In fact, for RSASSA-PSS, we also need to pass the PSSParameters itself to the ContentSigner because it also needs to be encoded in SignerInfo. So another method getSignatureAlgorithmParameters() is needed. Or, to make things general, we can deprecate getSignatureAlgorithm() and add 2 new methods
getSignatureAlgorithmIdentifiers() and getDigestAlgorithmIdentifiers() --Max > On Apr 10, 2020, at 10:02 PM, Weijun Wang <weijun.w...@oracle.com> wrote: > > Currently, ContentSignerParameters has an interface method > getSignatureAlgorithm(), the return value (Ex: SHA1withRSA) is then used by > the ContentSigner to extract the digest algorithm (SHA1) to be put into a > PKCS7 SignerInfo [1]. > > But the new algorithms are not named this way. For RSASSA-PSS, the digest > algorithm is inside its PSSParameters. For EdDSA, in the private key (which > tells if it's Ed25519 or Ed448). > > So, we'll need a new interface method getDigestAlgorithm(). > > It's awkward to add a new method to a deprecated interface. > > --Max > > [1] https://tools.ietf.org/html/rfc5652#section-5.3 > >> On Apr 10, 2020, at 8:52 PM, Sean Mullan <sean.mul...@oracle.com> wrote: >> >> Fair point, these two features are tightly coupled together so it probably >> doesn't make sense to remove (or keep) one w/o the other. >> >> So, I recommend marking the ContentSigner APIs deprecated for removal in 15, >> and delaying the removal of the APIs *and* the jarsigner -altsigner and >> -altsignerpath options until 16. >> >> Whether we remove these in 15 or 16 is not going to make much of a >> difference in the long run. >> >> --Sean >> >> On 4/10/20 5:07 AM, Peter Levart wrote: >>> What's the use of allowing compiling some classes if those classes can't be >>> used anywhere? They would be unusable in the new release of jarsigner. Ok, >>> they could be used in some older jarsigner if the classes were compiled >>> with appropriate -release option. So the usecase for not removing the >>> classes would be in a project that builds an implementation of >>> ContentSigner and then publishes it to be used in a project that still uses >>> an old jarsigner. Such ContentSigner project could then be upgraded to use >>> the new JDK/javac with appropriate -release option for compiling >>> ContentSigner implementation classes. >>> Peter >>> On 4/10/20 3:58 AM, Wang Weijun wrote: >>>> So the classes will be useless but at least old program still compiles. >>>> I'll modify the CSR and see how Joe thinks of this. >>>> >>>> Thanks, >>>> Max >>>> >>>>> 在 2020年4月9日，22:58，Sean Mullan <sean.mul...@oracle.com> 写道： >>>>> >>>>> On 4/9/20 10:52 AM, Weijun Wang wrote: >>>>>> All info for signing are passed into a ContentSigner through a >>>>>> ContentSignerParameters object. In order to pass more info, I’ll need to >>>>>> create new interface methods for it. >>>>> But you can just use your solution in JarSigner in the webrev below where >>>>> you are calling PKCS7.generateSignedData instead of ContentSigner. Just >>>>> because the ContentSigner APIs are still there doesn't mean you have to >>>>> use it in jarsigner (unless I am missing something). >>>>> >>>>> --Sean >>>>> >>>>>> —Max >>>>>>>> 在 2020年4月9日，21:27，Sean Mullan <sean.mul...@oracle.com> 写道： >>>>>>> On 4/9/20 3:13 AM, Wang Weijun wrote: >>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and >>>>>>>> EdDSA. Sigh. >>>>>>> Why would you need to do that if they are deprecated? >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> --Max >>>>>>>>>> 在 2020年4月9日，01:58，Sean Mullan <sean.mul...@oracle.com> 写道： >>>>>>>>> We never actually deprecated the com.sun.jarsigner package with a >>>>>>>>> forRemoval=true flag, so while it may be very low-risk to remove >>>>>>>>> these APIs, I feel that we should not remove it w/o prior notice. >>>>>>>>> >>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs >>>>>>>>> instead, and plan on removing it in JDK 16 or 17. >>>>>>>>> >>>>>>>>> I'm ok with removing the jarsigner options because the man page >>>>>>>>> already warned that they may be removed. >>>>>>>>> >>>>>>>>> --Sean >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote: >>>>>>>>>> I am thinking about removing the `jarsigner -altsigner >>>>>>>>>> -altsignerpath` options and underlying classes: >>>>>>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8242260 >>>>>>>>>> Please review everything at: >>>>>>>>>> Release note : https://bugs.openjdk.java.net/browse/JDK-8242261 >>>>>>>>>> CSR : https://bugs.openjdk.java.net/browse/JDK-8242262 >>>>>>>>>> webrev : >>>>>>>>>> http://cr.openjdk.java.net/~weijun/8242260/webrev.00/ >>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove >>>>>>>>>> it now. >>>>>>>>>> Thanks, >>>>>>>>>> Max >
