Accepting CMS with signing time outside of signing certificate validity time?

[Tim Bruijnzeels]

Hi,

We recently upgraded to bouncy castle 1.47. Since then we we occasionally get a "verifier not valid at sigingTime" error for CMS objects that we try to verify (code snippet below). I believe, however, that this may be a little too strict.

The current CMS RFC 5652 (http://tools.ietf.org/html/rfc5652#section-11.3) has this text:

"No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly."

Which suggests that one should not (always) reject a CMS in this case.

And in our case we are using this to validate a specific CMS for which the signing time "MAY be present", but "MUST NOT affect the validity of the signed object":
http://tools.ietf.org/html/rfc6488#section-2.1.6.4.3

So my questions:
= Do you agree that this check is too strict?
= Or, are we just doing it wrong -- is there a way to let bouncy castle validate and not be strict on this (even if the signing time is present).
(for now we work around this by using on of the deprecated verify methods that does not enforce this)


Thanks,

Tim Bruijnzeels
Senior Software Engineer
RIPE NCC

=====

Relevant code in bouncy castle:

org.bouncycastle.cms.SignerInformation:

/**
* Verify that the given verifier can successfully verify the signature on
* this SignerInformation object.
*
* @param verifier a suitably configured SignerInformationVerifier.
* @return true if the signer information is verified, false otherwise.
* @throws org.bouncycastle.cms.CMSVerifierCertificateNotValidException if the provider has an associated certificate and the certificate is not valid at the time given as the SignerInfo's signing time.
* @throws org.bouncycastle.cms.CMSException if the verifier is unable to create a ContentVerifiers or DigestCalculators.
*/
public boolean verify(SignerInformationVerifier verifier)
throws CMSException
{
Time signingTime = getSigningTime(); // has to be validated if present.

if (verifier.hasAssociatedCertificate())
{
if (signingTime != null)
{
X509CertificateHolder dcv = verifier.getAssociatedCertificate();

if (!dcv.isValidOn(signingTime.getDate()))
{
throw new CMSVerifierCertificateNotValidException("verifier not valid at signingTime");
}
}
}

return doVerify(verifier);
}

[martijn.list]

Post by Tim Bruijnzeels
Hi,
We recently upgraded to bouncy castle 1.47. Since then we we
occasionally get a "verifier not valid at sigingTime" error for CMS
objects that we try to verify (code snippet below). I believe, however,
that this may be a little too strict.
The current CMS RFC 5652
"No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly."
Which suggests that one should not (always) reject a CMS in this case.

The way I read it is that it's not a requirement and that it's up to the
implementer how to handle this. If they wanted to suggest that it's
better not to validate the time, they probably would have used something
like "should not".

Post by Tim Bruijnzeels
And in our case we are using this to validate a specific CMS for which
the signing time "MAY be present", but "MUST NOT affect the validity
http://tools.ietf.org/html/rfc6488#section-2.1.6.4.3
= Do you agree that this check is too strict?

It might be an idea to add some boolean to disable this check. But, see
below on how to make sure the check is skipped

Post by Tim Bruijnzeels
= Or, are we just doing it wrong -- is there a way to let bouncy castle
validate and not be strict on this (even if the signing time is present).
(for now we work around this by using on of the deprecated
verify methods that does not enforce this)

The siging time is only checked *if* you have provided an associated
certificate. Can't you just use JcaSimpleSignerInfoVerifierBuilder and
only provide the key and *not* the certificate:

JcaSimpleSignerInfoVerifierBuilder verifierBuilder =
new JcaSimpleSignerInfoVerifierBuilder();

signerInformation.verify(verifierBuilder.build(key));

Where key is the public key

Kind regards,

Martijn Brinkers
--
DJIGZO email encryption


[SNIP]

Post by Tim Bruijnzeels
/**
* Verify that the given verifier can successfully verify the signature on
* this SignerInformation object.
*
org.bouncycastle.cms.CMSVerifierCertificateNotValidException if the
provider has an associated certificate and the certificate is not valid
at the time given as the SignerInfo's signing time.
unable to create a ContentVerifiers or DigestCalculators.
*/
public boolean verify(SignerInformationVerifier verifier)
throws CMSException
{
Time signingTime = getSigningTime(); // has to be validated if
present.
if (verifier.hasAssociatedCertificate())
{
if (signingTime != null)
{
X509CertificateHolder dcv =
verifier.getAssociatedCertificate();
if (!dcv.isValidOn(signingTime.getDate()))
{
throw new CMSVerifierCertificateNotValidException("verifier not valid at signingTime");
}
}
}
return doVerify(verifier);
}

[Tim Bruijnzeels]

Hi Martijn,

Thank you for your response.

Post by Tim Bruijnzeels
Hi,
We recently upgraded to bouncy castle 1.47. Since then we we
occasionally get a "verifier not valid at sigingTime" error for CMS
objects that we try to verify (code snippet below). I believe, however,
that this may be a little too strict.
The current CMS RFC 5652
"No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly."
Which suggests that one should not (always) reject a CMS in this case.

The way I read it is that it's not a requirement and that it's up to the implementer how to handle this. If they wanted to suggest that it's better not to validate the time, they probably would have used something like "should not".

Okay, although I agree with the bouncy castle default, I think "recipient's discretion" in this case should refer to me as a user of the bouncy castle library implementing other code. I want to be able to make this choice, because in this case the RFCs for the specific objects that I am dealing with actually stipulate "MUST NOT affect the validity" for this.

Having said that it seems I can… see below..

Post by Tim Bruijnzeels
And in our case we are using this to validate a specific CMS for which
the signing time "MAY be present", but "MUST NOT affect the validity
http://tools.ietf.org/html/rfc6488#section-2.1.6.4.3
= Do you agree that this check is too strict?

It might be an idea to add some boolean to disable this check. But, see below on how to make sure the check is skipped

I am not sure about this. I think it's probably better to keep the api clean. I am not a huge fan of booleans like this.

Post by Tim Bruijnzeels
= Or, are we just doing it wrong -- is there a way to let bouncy castle
validate and not be strict on this (even if the signing time is present).
(for now we work around this by using on of the deprecated
verify methods that does not enforce this)

JcaSimpleSignerInfoVerifierBuilder verifierBuilder =
new JcaSimpleSignerInfoVerifierBuilder();
signerInformation.verify(verifierBuilder.build(key));
Where key is the public key

I rechecked the code and it seems that no other checks are done here using the certificate, apart from the cross checking of signing time and certificate validity time. So in our case just verifying with the public key does what we need. I changed the code, tested it, it works. If this weren't the case I would rather have another SignerInformationVerifier type, or flag when I construct one using a certificate, that would allow me to use the associated certificate but accept the signing time. Seems this is not needed though.

And yes we do validate the certificate itself as well, as a separate step.


Thanks

Tim

[Hubert Kario]

Post by Tim Bruijnzeels
Hi,
We recently upgraded to bouncy castle 1.47. Since then we we occasionally
get a "verifier not valid at sigingTime" error for CMS objects that we try
to verify (code snippet below). I believe, however, that this may be a
little too strict.
"No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly."
Which suggests that one should not (always) reject a CMS in this case.
And in our case we are using this to validate a specific CMS for which the
signing time "MAY be present", but "MUST NOT affect the validity of the
signed object": http://tools.ietf.org/html/rfc6488#section-2.1.6.4.3
= Do you agree that this check is too strict?
= Or, are we just doing it wrong -- is there a way to let bouncy castle
validate and not be strict on this (even if the signing time is present).
(for now we work around this by using on of the deprecated verify methods
that does not enforce this)

The default like this should be strict to minimize the number of people that
can use the API incorrectly.

You can always do CMS verification independent of certificate verification and
certificate verifier can take argument that specifies >when< the validation
should take place.

This opens a new can of worms if you want to validate using CRLs and expect
some of the certificates to be revoked (before the signing time, of course)...
For details, see:
http://bouncy-castle.1462172.n4.nabble.com/BC-1-47-Bug-Validation-in-past-of-revoked-certificates-fails-td4655355.html

Regards,