gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] add gnutls_certificate_find_issuer


From: Joe Orton
Subject: Re: [PATCH] add gnutls_certificate_find_issuer
Date: Tue, 19 Feb 2008 21:33:05 +0000
User-agent: Mutt/1.5.17 (2007-11-01)

Hi Nikos,

On Tue, Feb 19, 2008 at 11:14:39PM +0200, Nikos Mavrogiannopoulos wrote:
> Joe Orton wrote:
>> On Fri, Feb 15, 2008 at 10:21:50AM +0000, Joe Orton wrote:
>>> This patch adds a function which finds the issuer of a given certificate 
>>> within a credentials structure.  This is useful so that clients can 
>>> easily recreate the complete server cert chain given only the single cert 
>>> returned by the peer.
...
>  In which case is a function like this needed? I'm thinking maybe exporting 
> the included structures that would need, would better than having functions 
> to perform operations on them.

neon uses a gnutls_certificate_credentials structure and exposes 
functions which allow applications based on neon to configure specific 
CA certs as trusted using gnutls_certificate_set_x509_trust* in various 
ways.  neon doesn't otherwise examine or store those certs; indeed, when 
using gnutls_certificate_set_x509_trust_file() to load a CA root bundle 
in PEM format, there is not really any way to do so.

When an SSL handshake takes place and a server cert cannot be verified 
for some reason (commonName mismatch, for example), the neon API then 
needs to expose the whole server cert chain to the application, so that 
it can be presented to a user for manual verification.

gnutls_certificate_get_peers() will not necessarily return that whole 
chain, so neon needs some way to recreate the chain based on the 
configured set of trusted certs.  That is what 
gnutls_certificate_find_issuer() is for.

Does that make sense?  

With respect to exposing structure contents directly, I would generally 
advocate exposing functions instead where possible, since structures 
bring restrictive ABI constraints.

Regards,

joe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]