(unknown)

[Jun Sun]

Hi there,
I realized it may be a bug in this class when raw signature is support by crypto provider. The thing is:

1. The "build" method of this class return a new ContentVerifierProvider.
2. In "get" method of ContentVerifierProvider, couple of things are done:
a. a SignatureOutputStream object is created with normal algorithm ID such as "SHA256WITHxxx".
b. a raw signature object is created with "NONEWITHxxx" as algorithm ID, in case raw signature is supported by the crypto provider.
c. the raw signature object is returned in RawSigVerifier object.
3. The problem here is: RawSigVerifier extends SigVerifier and only implemented a verify function defined in RawContentVerifier interface with 2 parameters:
public boolean verify(byte[] digest, byte[] expected)
but the return type of get method is ContentVerifier, which defines a verify function with only 1 parameter:
boolean verify(byte[] expected);
4. When the verify method is called, the 1 parameter version is used, actually it goes to the verify method defined in SigVerifier class, and it actually calls stream.verify that use the normal signature object instead of raw signature object verify the signature. That means the raw signature is never used.

So I think it may be a bug.


Jun?

[Jun Sun]

Sorry, seems the subject is removed by server. The previous e-mail is talking about a possible bug in JcaContentVerifierProviderBuilder.?


Jun


________________________________
From: Jun Sun <jun.sun-Z1FLSDVp6HyfsxuIvKNZIgC/***@public.gmane.org>
Sent: July-30-14 12:43 PM
To: dev-crypto-***@public.gmane.org
Subject: [dev-crypto]

Hi there,
I realized it may be a bug in this class when raw signature is support by crypto provider. The thing is:

1. The "build" method of this class return a new ContentVerifierProvider.
2. In "get" method of ContentVerifierProvider, couple of things are done:
a. a SignatureOutputStream object is created with normal algorithm ID such as "SHA256WITHxxx".
b. a raw signature object is created with "NONEWITHxxx" as algorithm ID, in case raw signature is supported by the crypto provider.
c. the raw signature object is returned in RawSigVerifier object.
3. The problem here is: RawSigVerifier extends SigVerifier and only implemented a verify function defined in RawContentVerifier interface with 2 parameters:
public boolean verify(byte[] digest, byte[] expected)
but the return type of get method is ContentVerifier, which defines a verify function with only 1 parameter:
boolean verify(byte[] expected);
4. When the verify method is called, the 1 parameter version is used, actually it goes to the verify method defined in SigVerifier class, and it actually calls stream.verify that use the normal signature object instead of raw signature object verify the signature. That means the raw signature is never used.

So I think it may be a bug.


Jun?

[David Hook]

If you have a look at lines 486 to 499 of SignerInformation you should
see how this is used.

Regards,

David

Post by Jun Sun
Sorry, seems the subject is removed by server. The previous e-mail is
talking about a possible bug in JcaContentVerifierProviderBuilder.​
Jun
------------------------------------------------------------------------
*Sent:* July-30-14 12:43 PM
*Subject:* [dev-crypto]
Hi there,
I realized it may be a bug in this class when raw signature is support
1. The "build" method of this class return a new ContentVerifierProvider.
a. a SignatureOutputStream object is created with normal algorithm
ID such as "SHA256WITHxxx".
b. a raw signature object is created with "NONEWITHxxx" as
algorithm ID, in case raw signature is supported by the crypto provider.
c. the raw signature object is returned in RawSigVerifier object.
3. The problem here is: RawSigVerifier extends SigVerifier and only
implemented a verify function defined
public boolean verify(byte[] digest, byte[] expected)
but the return type of get method is ContentVerifier, which
boolean verify(byte[] expected);
4. When the verify method is called, the 1 parameter version is used,
actually it goes to the verify method defined in SigVerifier class,
and it actually calls stream.verify that use the normal signature
object instead of raw signature object verify the signature. That
means the raw signature is never used.
So I think it may be a bug.
Jun​

[Jun Sun]

Hi David,

Sorry, I forgot to mention in my case, it is called from:

public boolean isSignatureValid(ContentVerifierProvider verifierProvider)

throws CertException

in X509CRLHolder


Jun


________________________________
From: David Hook <dgh-lQXO3U89oAbxy1ys+oinMti2O/***@public.gmane.org>
Sent: July-31-14 1:18 AM
To: dev-crypto-***@public.gmane.org
Subject: Re: [dev-crypto]


If you have a look at lines 486 to 499 of SignerInformation you should see how this is used.

Regards,

David

On 31/07/14 07:03, Jun Sun wrote:

Sorry, seems the subject is removed by server. The previous e-mail is talking about a possible bug in JcaContentVerifierProviderBuilder.?


Jun


________________________________
From: Jun Sun <jun.sun-Z1FLSDVp6HyfsxuIvKNZIgC/***@public.gmane.org><mailto:jun.sun-Z1FLSDVp6HyfsxuIvKNZIgC/***@public.gmane.org>
Sent: July-30-14 12:43 PM
To: dev-crypto-***@public.gmane.org<mailto:dev-crypto-***@public.gmane.org>
Subject: [dev-crypto]

Hi there,
I realized it may be a bug in this class when raw signature is support by crypto provider. The thing is:

1. The "build" method of this class return a new ContentVerifierProvider.
2. In "get" method of ContentVerifierProvider, couple of things are done:
a. a SignatureOutputStream object is created with normal algorithm ID such as "SHA256WITHxxx".
b. a raw signature object is created with "NONEWITHxxx" as algorithm ID, in case raw signature is supported by the crypto provider.
c. the raw signature object is returned in RawSigVerifier object.
3. The problem here is: RawSigVerifier extends SigVerifier and only implemented a verify function defined in RawContentVerifier interface with 2 parameters:
public boolean verify(byte[] digest, byte[] expected)
but the return type of get method is ContentVerifier, which defines a verify function with only 1 parameter:
boolean verify(byte[] expected);
4. When the verify method is called, the 1 parameter version is used, actually it goes to the verify method defined in SigVerifier class, and it actually calls stream.verify that use the normal signature object instead of raw signature object verify the signature. That means the raw signature is never used.

So I think it may be a bug.


Jun?

[David Hook]

Ah okay, that's not actually a bug... more like a lot of work. I'll have
to think about it.

The issue is that if you want to verify a signature on a CRL/Certificate
that way you'll also have to be able to create a message digest to
process the TBS structure that's associated with it (resultDigest in
SignerInformation's case). At a minimum this would mean adding an extra
method which takes both a ContentVerifierProvider and a
DigestCalculatorProvider as just the ContentVerifier by itself is no
longer sufficient to perform the full signature calculation.

Regards,

David

Post by Jun Sun
Hi David,
public boolean isSignatureValid(ContentVerifierProvider
verifierProvider)
throws CertException
in X509CRLHolder
Jun
------------------------------------------------------------------------
*Sent:* July-31-14 1:18 AM
*Subject:* Re: [dev-crypto]
If you have a look at lines 486 to 499 of SignerInformation you should
see how this is used.
Regards,
David

Post by Jun Sun
Sorry, seems the subject is removed by server. The previous e-mail is
talking about a possible bug in JcaContentVerifierProviderBuilder.​
Jun
------------------------------------------------------------------------
*Sent:* July-30-14 12:43 PM
*Subject:* [dev-crypto]
Hi there,
I realized it may be a bug in this class when raw signature is
1. The "build" method of this class return a new ContentVerifierProvider.
a. a SignatureOutputStream object is created with normal
algorithm ID such as "SHA256WITHxxx".
b. a raw signature object is created with "NONEWITHxxx" as
algorithm ID, in case raw signature is supported by the crypto provider.
c. the raw signature object is returned in RawSigVerifier object.
3. The problem here is: RawSigVerifier extends SigVerifier and only
implemented a verify function defined
public boolean verify(byte[] digest, byte[] expected)
but the return type of get method is ContentVerifier, which
boolean verify(byte[] expected);
4. When the verify method is called, the 1 parameter version is used,
actually it goes to the verify method defined in SigVerifier class,
and it actually calls stream.verify that use the normal signature
object instead of raw signature object verify the signature. That
means the raw signature is never used.
So I think it may be a bug.
Jun​