[gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expirations

[Rupert Kittinger]

On Fri, 3 Jun 2005, Simon Josefsson wrote:

> Rupert Kittinger <rkit at mur.at> writes:
> 
> > Hi everybody,
> >
> > I think the x509 certificate check performed by 
> > gnutls_certificate_verify_peers2() is not sufficient, because it does not 
> > validate the various time constraints (activation/expiration of 
> > certificates, CAs, CRLs).
> 
> Right.  That is intentional, even if it is unfortunate.
> 
> Did you see the example in section 7.3.4 of the manual?  It try to do
> a bit more.  Full verification of a certificate is application and
> purpose dependent, so it is difficult to generalize.
> 

I am quite aware of this. However, a lot of users of a library like 
this will not have detailed knowledge of X509 (and all its incarnations, 
sigh) and would profit from a "better safe than sorry" approach. Also, a 
detailed description of the algorithm used in the manual would be a great, 
if only for its educational value :-)  

> > I propose adding the following function:
> >
> > int gnutls_certificate_verify_peers3 (gnutls_session session, unsigned int 
> > * status, time_t then) 
> >
> > that has the following semantics:
> > - perform the same checks as gnutls_certificate_verify_peers2()
> > - for every certificate in the chain, check for activation and expiration
> > - if a crl is available for a CA and the nextUpdate field is available,
> >   check for expiration. 
> >
> > add validation flags for the new error conditions.
> >
> > with the current API, these checks can only be performed by duplicating 
> > some of the code to get to the certificates, resp. crls.
> 
> In general I think it is a good idea to provide this.  I agree
> duplicating the code from the example is sub-optimal and prone to
> errors.  Checking activation/expiration dates should probably almost
> always be used.
> 
> If you want to work on this, that would be good.  I do dislike the *2
> and *3 names, though, but can't come up with a better name right now.
> 

I hope I find the time to do this. Maybe some other people reading this
 list care to provide feedback on an improved certificate validation 
algorithm?   
 
Rupert

-- 
Rupert Kittinger <rkit at mur.at>