[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expi
[gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expirations
Fri, 3 Jun 2005 17:16:16 +0200 (CEST)
On Fri, 3 Jun 2005, Simon Josefsson wrote:
> Rupert Kittinger <address@hidden> 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
Rupert Kittinger <address@hidden>