[Bug 29018] Allow interactive TLS certificate verification

[bugzilla-daemon at freedesktop.org]

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

--- Comment #13 from Cosimo Cecchi <cosimoc at gnome.org> 2010-07-30 07:00:00 PDT ---
(In reply to comment #9)
> I forgot to mention before: in the crypto libraries we'll be using, is it more
> convenient for CertificateChainData to be an aay, or would it be more
> conventional to have the entire certificate chain as a single blob of bytes?

At least OpenSSL and GnuTLS deal with both single certificates and certificate
lists, so it's probably more useful to have it here as a list.

> Also, should we be specifying an order for the certificate chain, at least for
> the X.509 case? I think there's some convention that the cert being verified
> should be at one end, intermediate CAs should be in the middle, and the root CA
> cert (if present) should be at the other, but I can never remember which
> direction the chain goes in.

Yeah, good point. I find the usual order is the peer's certificate first, with
the root CA on the other end. I added some notes about this in
478315b4c70a4085e9329c6b6f338a3ac6067565

(In reply to comment #11)
> Why would the Telepathy spec be the thing choosing those limits? It's an
> implementation detail of the connection manager (and/or the cert-verifying UI),
> surely?
> 
> Or, do you mean that the CM and/or UI should advertise their limits on D-Bus? I
> don't see any need for that - the certificate came from the server, so either
> we're willing to accept it, or we're not, and capability discovery isn't
> useful.

Agreed. I originally meant that those limits could be advertised on the bus,
but it probably doesn't make much sense.

(In reply to comment #12)
> I think it's useful to tell the user why a cert was rejected: They may 
> not understand the reason themselves, or be able to do anything about 
> it, but it's handy for whoever the user runs to to be able to see what 
> happened, otherwise they're left with a frustrating "cause of death: 
> it died" situation.

Fair enough; I went ahead and added Limit_Exceeded as a possible value in
17df3f31a5c5b3d1cd4e5493728a47854b72345c

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