code review request: 7149012: jarsigner needs not warn about cert expiration if the jar has a TSA timestamp
Weijun Wang
weijun.wang at oracle.com
Tue Feb 28 14:43:42 UTC 2012
On 02/28/2012 10:29 PM, Xuelei Fan wrote:
> On Feb 28, 2012, at 6:19 AM, Weijun Wang<weijun.wang at oracle.com> wrote:
>
>> Hi Andrew
>>
>> Well, this code change is to make jarsigner behaviors to be consistent with Java Plugin, that is to say, if Java Plugin allows something jarsigner should also.
>>
>> If you believe that Java Plugin's behavior itself is problematic, we can suspend this code change for a while and focus on Java Plugin.
>>
> Please don't. My previous comment only a suggestion to rethink about the signer's behaviors. It may be a potential enhancement. Please go on with the bug fix.
>
> BTW, I thought java plugin only do validation. It also do jobs to sign something, is it?
No, it does not sign. My fix is also mainly on verification side of
jarsigner.
-Max
>
> Thanks,
> Xuelei
>
>> Thanks
>> Max
>>
>> On 02/28/2012 10:11 PM, Xuelei Fan wrote:
>>> I have not read the changes, just some minor comments about the description.
>>>
>>> On Feb 26, 2012, at 11:00 PM, Weijun Wang<weijun.wang at oracle.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> Please take a look at this code change:
>>>>
>>>> http://cr.openjdk.java.net/~weijun/7149012/webrev.00/
>>>>
>>>> Jarsigner will not print a warning if the signer cert is expired but a timestamp shows the jar was signed before the expiration date.
>>>>
>>>> Another change is that the chainNotValidated flag now does not cover hasExpiredCert and notYetValidCert anymore. The result is that when trying to sign (or verify) with an expired cert, instead of the duplicated and somewhat confusing
>>>>
>>>> The signer certificate has expired.
>>>> The signer's certificate chain is not validated.
>>>>
>>>> warnings, user will only see
>>>>
>>>> The signer certificate has expired.
>>>>
>>> It seems that we allow the singer sigh jars with expired certificate. It's flexible, but as may not comply to the policy of certificate authority. At most of the time, CA will not take any responsibility to expired certificate. I know the compatibility may be the concerns, but I really think we should forbid the sign behaviors by default, and allow the verification behaviors by default if time stamped.
>>>
>>> Xuelei
>>>
>>>> User will still see the chainNotValidated warning if the CertPath is not validated because of other reasons.
>>>>
>>>> On the other hand, since these 3 flags share the same exit code (4), users will not notice the exit code change when -strict is on.
>>>>
>>>> There is no regression test added to the openjdk repository because it's not easy to generate a timestamp with an old date. I have found an old signed jar with a timestamp and signed by a now-expired cert. I will include these binary files into the jdk/test/closed repository and the test is a simple "jarsigner -verify -strict" call.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> -------- Original Message --------
>>>> *Change Request ID*: 7149012
>>>>
>>>> *Synopsis*: jarsigner needs not warn about cert expiration if the jar has a TSA timestamp
>>>>
>>>> === *Description* ============================================================
>>>> If the cert used to sign a jar is expired, jarsigner will print out a warning, and if -strict is specified, exits with an error. However, if there is a TSA timestamp attached to the jar (and the timestamp is shown to be before the expiration), it's completely valid and jarsigner should not report any warning or error.
>>>>
More information about the security-dev
mailing list