From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Tue, 18 Nov 2014 21:33:43 +0100 Message-ID: <87k32s6yfs.fsf@alrua-karlstad.karlstad.toke.dk> References: <85a93pj1n5.fsf@stephe-leake.org> <87sihg7r73.fsf@alrua-karlstad.karlstad.toke.dk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1416342851 1710 80.91.229.3 (18 Nov 2014 20:34:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 20:34:11 +0000 (UTC) Cc: Emacs development discussions To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 21:34:07 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqpTR-0003qb-VJ for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 21:34:06 +0100 Original-Received: from localhost ([::1]:55231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqpTR-0003PK-JE for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 15:34:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqpTJ-0003PF-Ev for emacs-devel@gnu.org; Tue, 18 Nov 2014 15:34:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqpTE-0004oZ-Rq for emacs-devel@gnu.org; Tue, 18 Nov 2014 15:33:57 -0500 Original-Received: from mail2.tohojo.dk ([77.235.48.147]:37897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqpTE-0004oI-Ju for emacs-devel@gnu.org; Tue, 18 Nov 2014 15:33:52 -0500 X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Original-Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 1AF171E4739; Tue, 18 Nov 2014 21:33:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1416342449; bh=SOqxipDzMY2rT45/fBe/vNa2OZwPoiIfeuo2cqdNXvA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=TxzQcdeT32RBknO9X4ZcokZLqKrs76RhvA8KVB3wDgHuNmAO/JEtz0+RH1qc0LPOo x1RP82G8JbxN7VI4cItPJ8cnyVgMmDUVlR2yOeJmhoeO4uCOwTeNgK5SPdDjOSUc/V 9g5/p0jUnEn6wy0rfqKMhownfqLvB07PYPdudSSc= In-Reply-To: (Lars Magne Ingebrigtsen's message of "Tue, 18 Nov 2014 20:45:17 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.235.48.147 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177650 Archived-At: Lars Magne Ingebrigtsen writes: > Ah, right, so it's a general catch-all that's set in addition to other > flags? Yeah, seems to be: http://www.gnutls.org/manual/html_node/Verifying-a-certi= ficate.html > I don't see why we shouldn't ask. The user should be able to decide > without setting variables. Sure. I just mean that it would probably be nice to have some sort of distinction for severeness (perhaps coupled to the configured paranoia level), so that, for instance, an expired certificate that is replaced with a new one raises less of a warning than a revoked certificate, or one that doesn't match the trust store. >> Not sure which of these would indicate the common self-signed case? >> Could probably be both... > > Yeah, that's what I'm mainly wondering about. Well, according to the documentation: http://www.gnutls.org/manual/html_node/Verifying-X_002e509-certificate-path= s.html GNUTLS_CERT_SIGNER_NOT_CA means: "The certificate=E2=80=99s signer was not a CA. This may happen if this= was a version 1 certificate, which is common with some CAs, or a version 3 certificate without the basic constrains extension." Whereas GNUTLS_CERT_SIGNER_NOT_FOUND is the common "we don't trust whoever signed this". So I'd think that GNUTLS_CERT_SIGNER_NOT_FOUND would be returned for all self-signed certificates, and possibly GNUTLS_CERT_SIGNER_NOT_CA in addition. If GNUTLS_CERT_SIGNER_NOT_CA is returned for a legitimately signed certificate (from the trust store), the CA is probably doing something wrong. > Interesting. It does this even if the new certificate is valid? To > mitigate against rogue CAs? Yep, that's basically the whole reason for the extension. > The NSM will also warn about new certificates if the user has switched > to `paranoid', but it doesn't compare old and new CAs and stuff. Right, cool. Will give it a spin and see if I can break it as soon as I've compiled your branch :) -Toke