It is observed that when running crypto benchmark with large number of threads,
a lot of time is spent on the synchronized block inside the
Provider.getService() method. The cause for this is that Provider.getService()
method first uses the 'serviceMap' field to find the requested service.
Howe
On Wed, 17 Nov 2021 14:06:00 GMT, Weijun Wang wrote:
>> There is no need to check for the KeyUsage extension when validating a TSA
>> certificate.
>>
>> A test is modified where a TSA cert has a KeyUsage but without the
>> DigitalSignature bit.
>
> Weijun Wang has updated the pull request incr
On Mon, 22 Nov 2021 12:09:30 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote:
> The S4U2proxy extension requires that the service ticket to the first service
> has the forwardable flag set, but some versions of Windows Server do not set
> the forwardable flag in a S4U2self response and accept it in a S4U2proxy
> reque
On Thu, 28 Oct 2021 19:21:02 GMT, Martin Balao wrote:
> * The names 'second' and 'secondTicket' -that were used before- don't look
> ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU
> (v.20.0). In the case of 'additionalTickets', it's defined in RFC 4120 but
> more from a
On Fri, 19 Nov 2021 23:34:11 GMT, Valerie Peng wrote:
>> The S4U2proxy extension requires that the service ticket to the first
>> service has the forwardable flag set, but some versions of Windows Server do
>> not set the forwardable flag in a S4U2self response and accept it in a
>> S4U2proxy
On Mon, 1 Nov 2021 17:24:48 GMT, Weijun Wang wrote:
>> The S4U2proxy extension requires that the service ticket to the first
>> service has the forwardable flag set, but some versions of Windows Server do
>> not set the forwardable flag in a S4U2self response and accept it in a
>> S4U2proxy re
On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote:
> The S4U2proxy extension requires that the service ticket to the first service
> has the forwardable flag set, but some versions of Windows Server do not set
> the forwardable flag in a S4U2self response and accept it in a S4U2proxy
> reque
On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote:
> The S4U2proxy extension requires that the service ticket to the first service
> has the forwardable flag set, but some versions of Windows Server do not set
> the forwardable flag in a S4U2self response and accept it in a S4U2proxy
> reque
On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote:
> The S4U2proxy extension requires that the service ticket to the first service
> has the forwardable flag set, but some versions of Windows Server do not set
> the forwardable flag in a S4U2self response and accept it in a S4U2proxy
> reque
On Mon, 1 Nov 2021 14:42:32 GMT, Martin Balao wrote:
> But the question that concerns me most is if we really want to make such a
> tight check, or we are willing to forward everything.
Alexey said their customer has at least 50 KDCs. It will be quite a waste of
time if we go through each of t
On Mon, 1 Nov 2021 14:42:32 GMT, Martin Balao wrote:
>>> * The names 'second' and 'secondTicket' -that were used before- don't look
>>> ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU
>>> (v.20.0). In the case of 'additionalTickets', it's defined in RFC 4120 but
>>> more
The S4U2proxy extension requires that the service ticket to the first service
has the forwardable flag set, but some versions of Windows Server do not set
the forwardable flag in a S4U2self response and accept it in a S4U2proxy
request.
There are 2 commits now. The 1st is a refactoring that sen
On Thu, 28 Oct 2021 21:49:54 GMT, Weijun Wang wrote:
>
> > * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for
> > S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we
> > check at S4U2Proxy level (for all 'second' tickets, S4U2Self and
> > non-S4U2Self
You’ll be amused to find out that the code that generated the Rekor TS cert has
been changed to use digitalSignature as its KU.
https://github.com/sigstore/rekor/pull/504/files
I think the change you made is correct, but you probably won’t see a
nonRepudiation bit for a while again. Mike
Sent
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
17 matches
Mail list logo
