True, the current handling of the extra bytes in parseKey() and decode()
are kind of opposite, one does not allow any extra bytes but the other
ignores all. The trailing bytes may look harmless but simply ignores it
may open up something unexpected.
Given that this is key related class, I t
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.
For RSASSA-PSS signature algorithm, if the signature parameters are
generated/derived, they should be included somewhere with the signed jar.
I assume that the .RSA contains only the signature bytes? If the format
is not extensible, maybe we need a mechanism for including the parameters.
Vale
Not complicated at all. It works and I've updated the CSR.
--Max
> On May 20, 2020, at 4:40 AM, Anthony Scarpino
> wrote:
>
> If the code exists that reusing the old extensions, then that's probably
> best. But if it requires a large reworking of the code maybe it's not worth
> all that wo
If the code exists that reusing the old extensions, then that's probably
best. But if it requires a large reworking of the code maybe it's not
worth all that work when two new extension values are easier. I'm ok
either way you want to proceed.
Tony
On 5/19/20 1:30 PM, Weijun Wang wrote:
T
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 写道：
>
> 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.
>
>
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
> 在 2020年5月20日，00:03，Xuelei Fan 写道：
>
> It may be a stupid question, can RSASSA-PSS share the 'rsa', and EdDSA share
> or the 'ec' block file extension?
This is a brave idea. It should work.
—Max
On 5/19/20 6:58 AM, Weijun Wang wrote:
One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg Ed448"? It looks like
we should support it because we can call Signature.getInstance() on it, but even if so, the block extension name will
still be "EDD" (or "EdDSA").
The exten
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
Hello Bernd, Michael,
We’ve been working on the same issue and found that the Windows LDAP server
with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding
(based on the TLS server certificate):
• The client calculates a hash of the TLS server certificate. The hash
On 5/19/2020 6:58 AM, Weijun Wang wrote:
One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg
Ed448"?
I would like to have the two options.
It looks like we should support it because we can call Signature.getInstance() on it, but even if
so, the block extension name wi
One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg
Ed448"? It looks like we should support it because we can call
Signature.getInstance() on it, but even if so, the block extension name will
still be "EDD" (or "EdDSA").
--Max
> On May 19, 2020, at 5:43 PM, Weijun Wang
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
14 matches
Mail list logo
