headers
Carlos Lozano | 14 Jul 2004 09:15

Re: Signature Validation on Expired certificate?

Hi Ian,
  In the case you describe, ( verify a signature made with a certificate
that has expired  in the moment of verification ) the verification should
fail. A common way to avoid this problem is to attach a timestamp token
(TST) to the digital signature in order to have a proof of when the
signature was made. I suggest you to have a look to RFC 3161, this document
provides a detailed explanataion on how to make timestamp tokens.
Permalink | Reply |
headers
Jmanuel.Zaera | 14 Jul 2004 09:24

Re: Signature Validation on Expired certificate?


If you use authenticated attributes with SigningTime attribute then the signature verification should not fail because the certificate was valid in the moment of signature.
Permalink | Reply |
headers
Ken Ballou | 14 Jul 2004 17:02

Re: Signature Validation on Expired certificate?

On Wed, Jul 14, 2004 at 09:24:27AM +0200, Jmanuel.Zaera@... wrote:
> If you use authenticated attributes with SigningTime attribute then the 
> signature verification should not fail because the certificate was valid 
> in the moment of signature.

SigningTime attributes are essentially worthless.  What prevents one from
using an expired certificate, creating a message with a false value for
the SigningTime attribute, and signing the message with the private key
corresponding to the expired certificate?

The signature on the message only prevents the SigningTime attribute value
from being altered after the signature is generated.  There's no basis to
establish the truth of the original SigningTime value before the signature
is generated.
Permalink | Reply |
headers
Jmanuel.Zaera | 15 Jul 2004 09:31

Re: Signature Validation on Expired certificate?


I know that SigningTime attribute does not assure the time when signature was made, but if you are not able to use a TSA the only reference time in signature that you have then is SigningTime. It is not the better approach but if you have no other way then I think you can consider this solution until you implement timestamping.
Permalink | Reply |
headers
Hes Siemelink | 14 Jul 2004 16:02

RE: Signature Validation on Expired certificate?

What would be the proper way to add a SigningTime attribute? I couldn’t find a class like that in the
BouncyCastle API.
I (naively) tried the following, but that does not seem to work…
Any hints anyone?

  ...
            ASN1EncodableVector signedAttrs = new ASN1EncodableVector();
            signedAttrs.add(new SigningTime(new Date()));
            SMIMESignedGenerator gen = new SMIMESignedGenerator();
            gen.addSigner(signingKey, signingCertificate,
                          SMIMESignedGenerator.DIGEST_SHA1,
                          new AttributeTable(signedAttrs), null);
    ...

    private static class SigningTime
      extends Attribute
    {
        public SigningTime(Date date) {
            super(new DERObjectIdentifier("1.2.840.113549.1.9.5"),
                  new DERSet(
              new DERTaggedObject(false, 1, new DERGeneralizedTime(date))));
        }

    }

Cheers,

	Hes.

________________________________________
From: Jmanuel.Zaera@...
[mailto:Jmanuel.Zaera@...] 
Sent: woensdag 14 juli 2004 9:24
To: dev-crypto@...
Subject: Re: [dev-crypto] Signature Validation on Expired certificate?

If you use authenticated attributes with SigningTime attribute then the signature verification should
not fail because the certificate was valid in the moment of signature.
Permalink | Reply |
headers
Carlos Lozano | 14 Jul 2004 14:14

Re: Signature Validation on Expired certificate?

The use of attribute SigningTime provides more reliability to a signature but it is not so effective as using a TimeStampToken (see RFC 3161), because the SigningTime attribute is signed by the private key of the same certificate you want to check, then you can't rely on this date.
When using a TimeStampToken the date inside the Token is signed by a Trusted Thrid Party with a different certificate from the one signing the original data, so you achieve a more secure way of getting the date when the signature was made.
 
By the way, Bouncy Castle does not provide classes for easy managament of TimeStampProtol as defined in RFC 3161, I think this enhancement would be very interesting for the library, is someone working on this?
 
 
----- Original Message -----
Sent: Wednesday, July 14, 2004 9:24 AM
Subject: Re: [dev-crypto] Signature Validation on Expired certificate?


If you use authenticated attributes with SigningTime attribute then the signature verification should not fail because the certificate was valid in the moment of signature.
Permalink | Reply |
headers
Franck Leroy | 15 Jul 2004 08:10
Picon

RE: Signature Validation on Expired certificate?

We have realized a package based on BC that makes TST, signature made with a P12.
We can help ... the package has been tested with openTSA succesfully.
 
Franck Leroy - PK7

De : Carlos Lozano [mailto:carlos-5tjumFP6e29BDgjK7y7TUQ@public.gmane.org]
Envoyé : mercredi 14 juillet 2004 14:14
À : dev-crypto-TtFiPYkqHGexCSWobqctBA@public.gmane.org
Objet : Re: [dev-crypto] Signature Validation on Expired certificate?

The use of attribute SigningTime provides more reliability to a signature but it is not so effective as using a TimeStampToken (see RFC 3161), because the SigningTime attribute is signed by the private key of the same certificate you want to check, then you can't rely on this date.
When using a TimeStampToken the date inside the Token is signed by a Trusted Thrid Party with a different certificate from the one signing the original data, so you achieve a more secure way of getting the date when the signature was made.
 
By the way, Bouncy Castle does not provide classes for easy managament of TimeStampProtol as defined in RFC 3161, I think this enhancement would be very interesting for the library, is someone working on this?
 
 
----- Original Message -----
Sent: Wednesday, July 14, 2004 9:24 AM
Subject: Re: [dev-crypto] Signature Validation on Expired certificate?


If you use authenticated attributes with SigningTime attribute then the signature verification should not fail because the certificate was valid in the moment of signature.
Permalink | Reply |
headers
Guilherme Martini Dalpian | 15 Jul 2004 14:18
Picon

Re: Signature Validation on Expired certificate?

 
    Is your package open source? If so, where can I download it?
    Best Regards,
 
    Guilherme Martini Dalpian
 
----- Original Message -----
Sent: Thursday, July 15, 2004 3:10 AM
Subject: RE: [dev-crypto] Signature Validation on Expired certificate?

We have realized a package based on BC that makes TST, signature made with a P12.
We can help ... the package has been tested with openTSA succesfully.
 
Franck Leroy - PK7

De : Carlos Lozano [mailto:carlos-5tjumFP6e29BDgjK7y7TUQ@public.gmane.org]
Envoyé : mercredi 14 juillet 2004 14:14
À : dev-crypto-TtFiPYkqHGexCSWobqctBA@public.gmane.org
Objet : Re: [dev-crypto] Signature Validation on Expired certificate?

The use of attribute SigningTime provides more reliability to a signature but it is not so effective as using a TimeStampToken (see RFC 3161), because the SigningTime attribute is signed by the private key of the same certificate you want to check, then you can't rely on this date.
When using a TimeStampToken the date inside the Token is signed by a Trusted Thrid Party with a different certificate from the one signing the original data, so you achieve a more secure way of getting the date when the signature was made.
 
By the way, Bouncy Castle does not provide classes for easy managament of TimeStampProtol as defined in RFC 3161, I think this enhancement would be very interesting for the library, is someone working on this?
 
 
----- Original Message -----
Sent: Wednesday, July 14, 2004 9:24 AM
Subject: Re: [dev-crypto] Signature Validation on Expired certificate?


If you use authenticated attributes with SigningTime attribute then the signature verification should not fail because the certificate was valid in the moment of signature.
Attachment (smime.p7s): application/x-pkcs7-signature, 3739 bytes
Permalink | Reply |

Gmane