Re: Network security manager

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Lars Magne Ingebrigtsen <larsi@gnus.org> 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-certificate.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-paths.html

GNUTLS_CERT_SIGNER_NOT_CA means:

    "The certificate’s 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