[Bug 29018] Allow interactive TLS certificate verification

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29018

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-30 04:21:13 PDT ---
In RejectError:
> is not meaningful, ans SHOULD

"and"

In RejectDetails:
> +           <pre>
> +             { 'expected-hostname': 'gmail.com' }
> +             { 'certificate-hostname': 'evil.example.org' }
> +           </pre>

The conventional pseudocode for dictionaries is to use Python/JSON syntax, in
which the whole dictionary is wrapped in {}, and items are separated by commas:

    { 'expected-hostname': 'gmail.com',
      'certificate-hostname': 'evil.example.org' }

or 

    {
      'expected-hostname': 'gmail.com',
      'certificate-hostname': 'evil.example.org',
    }

or however you want to indent it.

In Connection:
>                that indicates the hostname that could not be found.</p>
>            </tp:rationale>
> +
> +         <dl>
> +           <dt>expected-hostname (s), certificate-hostname (s)</dt>

Instead of making a new <dl>, I'd prefer including these in the existing <dl>,
above the <tp:rationale>. Indeed, now that we have a practical use for
ConnectionErrorDetails, you could delete the "maybe we'll use this in future"
rationale :-)

(In reply to comment #7)
> I already added Insecure_Algorithm to the D-Bus errors in a previous commit
> (e243001481350703aec717fcea57c7c40412ad4b); we could probably add it to the
> enum in Connection too, I think it's worth.

Please do keep all three places in sync. Also, Bug #23931 tries to add Revoked,
which I hadn't spotted; is that available in all three lists too?

I believe Vivek called it Insecure rather than Insecure_Algorithm in Bug #23931
because the algorithm isn't necessarily the part that's insecure: consider
256-bit RSA, for instance :-)

> I think Limit_Exceeded only makes sense if we also document limits for the
> number of bits for an acceptable certificate and the depth of the certificate
> chain, and I don't think it's something worth doing for now.

As I understand it, Limit_Exceeded was intended to represent limits hard-coded
into GNUTLS, to stop people performing denial of service attacks by providing
massive certificates that will take hours of computation to verify? It's
probably more useful as a Connection_Error than here, but we should keep the
TLS-related things in sync.

> After having looked at the documentation of the TLS libraries we will use, and
> having talked at GUADEC with some crypto people, I got convinced we should just
> use DER here instead of PEM, not because it's poorly specified (see RFC 1421
> [1]), but because PEM is just DER encoded in a different way, and DER is the
> most simple and widely supported format anyway.

Sounds good to me.

(The reason I thought PEM-for-certificates was poorly specified is that RFC
1421 seems to be the reference document for PEM, but it makes no mention of the
text "BEGIN CERTIFICATE" that in practice everyone uses, or indeed (AFAICS) how
to encode a standalone certificate!)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.