Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 04 Nov 2013 23:38:50 +0100 Vincent Bernat <bernat@luffy.cx> wrote: 

VB>  ❦  4 novembre 2013 22:10 CET, Ted Zlatanov <tzz@lifelogs.com> :
VB> So, for me, there should be only one verification algorithm. We are not
VB> in the ideal case for this because we only have one algorithm but its
VB> name does not exactly describe it.
>> 
VB> Maybe you could just alias verify-error and verify-hostname-error and
VB> say in the documentation that they do the same and that
VB> verify-hostname-error will be removed at some point?
>> 
>> I think :verify-error should be a list; when it contains 'x509-hostname
>> then we behave like :verify-hostname-error does now, for backwards
>> compatibility.  But otherwise we'll add extra checks to the list, not as
>> top-level options to `gnutls-boot'.  It's easy to put a Customize
>> interface on top of that.

VB> When you say x509-hostname, do you mean "by default"? If yes, I
VB> agree.

Yes.  I think.  How would you like it to look?

VB> But I suppose you would have to implement a "confirm on error"
VB> option. I cannot propose myself to implement that since I have
VB> absolutely no clue on how Emacs Lisp interface with C.

I'm interested in your opinion.  How would you expect Emacs (on the
GnuTLS C level or on the Gnus level) to handle these cases, and how
would you control them with customizable variables?

- expired cert
- hostname mismatch
- self-signed cert, first time seen
- cert mismatch

In general we have the problem of asking questions in the middle of
establishing a network connection.  This is not easy with Emacs, whose
interactive ELisp layer is too complicated to be reliably called from
the C layer.  So all of the above have to work without user interaction.

Ted