RFR 8154005: Add algorithm constraint that specifies the restriction date

[Ivan Gerasimov]

Thanks Anthony!


On 13.05.2016 19:04, Anthony Scarpino wrote:
> Hi Ivan,
>
> I added your comments.. I had thought usePattern() wouldn't reuse the 
> entry, but apparently the description is not the way I read it.
>
> You comments are incorporated into the webrev.01 that I posted previously
>
Looks good to me.
Though, as I'm not a member of the security group, you may want to get a 
review from someone with that kind of power :)

With kind regards,
Ivan


> thanks
>
> Tony
>
>
> On 05/12/2016 04:13 PM, Ivan Gerasimov wrote:
>> Hi Anthony!
>>
>>
>> A few minor comments:
>>
>> *AlgorithmChecker.java*
>>
>> It would be more consistent to use {@code ...} tags in place of
>> <code>...</code>
>>
>>
>> *DisabledAlgorithmConstraints.java*
>>
>> 275 Matcher dmatch = denyAfterPattern.matcher(entry);
>>
>> 296 } else if (dmatch.matches()) {
>>
>>
>> It might be a bit more efficient to reuse already declared `Matcher
>> matcher` like this:
>>
>>      } else if (matcher.usePattern(denyAfterPattern).matches()) {
>>
>>
>>
>> With kind regards,
>> Ivan
>>
>>
>> On 13.05.2016 0:34, Anthony Scarpino wrote:
>>> I've updated the webrev to at:
>>> http://cr.openjdk.java.net/~ascarpino/8154005/webrev.01/
>>>
>>> Comments addressed below...
>>>
>>> On 05/11/2016 04:55 PM, ecki at zusammenkunft.net wrote:
>>>> Hello,
>>>>
>>>> In AlgorithmChecker the Javadoc seems to not follow "@param name
>>>> desc" format (in two places). Also it should most likely describe
>>>> something like "time the signature claimed to be made to check time
>>>> range limited ciphers after that date or similiar)
>>>>
>>>> * @param PKIXParameter timestamp (or null)
>>>
>>> Thanks for seeing that.. I updated them.
>>>
>>>>
>>>> DisabledAlgorithmConstrained: The regular expression allows
>>>> denyafter20160101 its clear, but \s+ might be clearer? Can optional
>>>> iso  Idate seperators,  be added. "(\d {4})-?(\d {2})-?...."
>>>
>>> I think I prefer to require '-' as standard syntax and not use
>>> YYYYMMDD.  Sometimes YYYYMMDD not as clear to read as YYYY-MM-DD. I
>>> would like to not have two valid formats.
>>>
>>>>
>>>> The lowercase constraint classes are rather strange, but fits into
>>>> existing code...
>>>>
>>>> I dont see in the patch how the date param is certified. Is this only
>>>> the issued date as certified (by the weak) signature or does it look
>>>> at timestamps (especially codesigning) too?
>>>
>>> The date is passed as part of PKIX, it's optional that PKIX can have a
>>> date parameter set to specify a time date.
>>> The date disallows a certificate with the disabled algorithm on that
>>> date.  It does not check validity of the certificate.  This is meant
>>> to shutoff the algorithm in certificate checking.  There maybe a
>>> exception to this to allowing codesigning certificates a bit longer,
>>> but that hasn't been completely decided yet.
>>>
>>>>
>>>> There are a few conditions which could be unit tested:
>>>>
>>>> RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter
>>>> 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101
>>>> // not valid Etc
>>>
>>> Yes.  There are a number of tests that are in the closed test repo
>>> because they use certificates that are not for public use.
>>>
>>> thanks
>>>
>>> Tony
>>>
>>>>
>>>> Gruss
>>> >
>>>> Bernd
>>>>
>>>
>>>
>>
>
>