[gnutls-devel] Unable to trust server certificate instead of issueing CA

[Daniel Kahn Gillmor]

On 12/03/2014 02:01 PM, Andreas Metzler wrote:
> Hello,
> 
> This came up on d-d
> <http://article.gmane.org/gmane.linux.debian.devel.general/199833>:
> 
> With gnutls 3.3.* it seems to be impossible to trust server
> certificate instead of the signing authority:

> ametzler at argenau:~$ gnutls-cli --x509cafile=/tmp/GNUTLS/buildd.debian.org.pem  buildd.debian.org

> This used to work in 2.x. Is this an intentional change?

This seems like it might be a slight shift in semantics of --x509cafile
(and probably of gnutls_certificate_set_x509_trust_file() behind it).

Old semantics:

 * If any cert in the peer's chain is found in x509cafile, the chain is
valid

New semantics:

 * If any CA cert in the peer's chain is found in the x509cafile, the
chain is valid.

Arguably, these are different goals, and you might want to separate out
the "I think my peer has one of these keys" scenario from the "i think
my peer's id is certified by one of these keys" scenario for better
conceptual clarity.

The --tofu and --strict-tofu option to gnutls-cli can be used to help
answer "i think my peer has one of these keys".

But if this is going to be a deliberate behavior shift, it probably
needs explicit documentation.  We might also want a runtime warning if
any of the loaded certs had CA:False or were otherwise incapable of
acting as a CA.

But ultimately, i'm not sure that we should break the API semantics in
this way even if the explicitly-split semantics would be cleaner; the
non-split semantics are a fairly well-established use pattern.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141203/57d2aaed/attachment.sig>