[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] CertPath validation using TimeStamp times failes
From:       Hubert Kario <hka () qbs ! com ! pl>
Date:       2010-05-12 12:13:51
Message-ID: 201005121413.51672.hka () qbs ! com ! pl
[Download RAW message or body]

On Tuesday 11 May 2010 22:43:46 Hubert Kario wrote:
> On Tuesday 11 May 2010 19:58:57 Marcin Waldowski wrote:
> > Hello Hubert.
> >
> > Please check if http://www.bouncycastle.org/jira/browse/BJA-249
> > (resolved!) is related to your issue.
> >
> > Please also check if you can find any answer in discussion:
> > http://www.bouncycastle.org/devmailarchive/msg10835.html
> >
> > Regards,
> > Marcin Waldowski
> 
> That looks like it, I'll test it tommorow and report the results.

The 1.57beta06 works the way it should.

Has this bug in the Java crypto API been reported upstream?

Hubert

> 
> I should probably start a new thread, but is there a way to specify grace
> period for CertPathValidator?
> I mean, when I'm checking past signatures I need to have CRLs not at least
> newer than the signature but newer by the grace period to be sure that the
> certificate was valid at the time (provided by a timestamp token) it was
> used.
> 
> > 2010/5/11 Hubert Kario <hka@qbs.com.pl>
> >
> > > Hi all!
> > >
> > > I'm currently implementing a XAdES library and as such have a need to
> > > validate
> > > signatures and timestamps. Or rather need to validate signatures and
> > > timestamps in the past (whatever they were valid at specific time, not
> > > whatever they are valid now)
> > >
> > > Background:
> > > - the documents I'm validating don't have embedded CRLs (because they
> > > are XAdES-T files)
> > > - polish cryptography laws practically require the use of either CRLs
> > > published at least one hour after signing and timestamping, or use of
> > > double
> > > timestamps spaced between by at least an hour
> > > (that's because CRLs can invalidate CRLs one hour back at the time of
> > > their public distribution)
> > > - all qualified certificates I got my hands on don't have specified
> > > distribution points
> > >
> > > Problem:
> > > Java X509CRLSelector specifes[1] that if the setDateAndTime(Date
> > > dateAndTime)
> > > is used then the CRL returned by use of it must be published _before_
> > > the time
> > > specifed, but must have its invalidation time _after_ it:
> > >
> > > -|-----------------|----------------|--------> (time)
> > > CRL publication    validation time  CRL next update
> > >
> > > it can't return a CRL like this:
> > > -|-----------------|----------------|--------> (time)
> > > validation time    CRL publication  CRL next update
> > >
> > >
> > > What I tried to do (after I got my hands on this piece of information,
> > > it obviously could't work) while validating timestamped signatures is
> > > to: - check if time stamp token is valid (using current time)
> > > - use the time embedded in the token to validate the signature
> > > - get locations of CRLs from user or cache by showing him the DN the
> > > CRLs have
> > > to match
> > > - download current CRLs from cache or distribution point
> > > - create CertStore for CRLs with
> > > CertStore.getInstance("Collection",
> > >                new CollectionCertStoreParameters(crlList), "BC");
> > > - pass the certStore with CRLs, assembled CertPath and trustedCAs to
> > > the validator along with the time from the token
> > > - if all's OK, the validator doesn't throw an exception and I return an
> > > OK to
> > > the user
> > >
> > > and that's the problem, because the CRLs I have now are published
> > > today, and
> > > the timestamp was made a week ago, the CRLSelector can't find old CRLs
> > > and whole process fails.
> > >
> > > Question:
> > > Am I doing something with the CertPath I shouldn't do (IMO unlikely as
> > > the ExtendedPKIXParameters have a public setDate() method just for this
> > > use) or is
> > > there a Class/Object that is specifically used for validating
> > > timestamped certificate chains (google was unhelpful with locating it)
> > > or is the specification bogus and should require only the nextUpdate
> > > date to be later than the specifed one and allow returning CRLs from
> > > the future?
> > >
> > > IMHO that's a bug in the Java interfaces (or rather specification of
> > > it). Once a certificate was revoked it can't be made valid again and
> > > each and every
> > > CRL has to have all the revoked certificates so it's best to have the
> > > most current CRL that's possible even if it looks like it came from the
> > > future.
> > >
> > > [1] -
> > >
> > > http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/Ce
> > >rt PathProgGuide.html#X509CRLSelector --
> > > Hubert Kario
> > > QBS - Quality Business Software
> > > 02-656 Warszawa, ul. Ksawerów 30/85
> > > tel. +48 (22) 646-61-51, 646-74-24
> > > www.qbs.com.pl
> > >
> > > System Zarządzania Jakością
> > > zgodny z normą ISO 9001:2000
> 

-- 
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

System Zarządzania Jakością
zgodny z normą ISO 9001:2000


[prev in list] [next in list] [prev in thread] [next in thread]