After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676210 - Extended Validation support for certificates
Extended Validation support for certificates
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: network
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks: 721179
 
 
Reported: 2012-05-17 07:54 UTC by Xan Lopez
Modified: 2018-05-29 06:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Xan Lopez 2012-05-17 07:54:43 UTC
Supporting EV for certificates would be useful for browsers or other applications willing to show the usual extra-green UI stuff in the UI (see https://github.com/gnome-design-team/gnome-mockups/raw/master/web/url-entry.png, last entry).

I assume this would go in GtlsCertificate, perhaps an 'extended-validation' property. What I've been able to figure out so far is:

- Step 1 is to check that the certificationPolicies extension has an OID that matches the one assigned by each CA for their EV certificates. See http://en.wikipedia.org/wiki/Extended_Validation_Certificate. It seems browsers just dump that table statically, for instance Chrome has it in net/base/ev_root_ca_metadata.cc.

- Step 2 is to verify that the certificate has not been revoke at runtime using something like OCSP. This seems to be optional (?), but done by the major browsers. 

I suppose we could do a simple first patch that does step 1, and then add step 2 on top of it. GnuTLS supports OCSP since 3.0.12, so I guess we would need to bump the dependency if we want to use that.

If all this sounds reasonable I might start to implement it soon, but at the very least the bug will be useful as reference.
Comment 1 Dan Winship 2012-05-17 14:52:24 UTC
(In reply to comment #0)
> It seems browsers
> just dump that table statically, for instance Chrome has it in
> net/base/ev_root_ca_metadata.cc.

Yeah, Firefox has it in a big array too... I guess they don't want to store it in the NSS db because then a stupid sysadmin could change it...

It would be nice though if we could get someone else to extract the information for us and put it in the same package as the system CA list, so we get updates automatically without having to worry about re-checking upstream every release. Or failing that, at least have a script to extract-from-moz/chrome-and-dump-into-glib for us.
Comment 2 GNOME Infrastructure Team 2018-05-24 14:13:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/547.
Comment 3 Michael Catanzaro 2018-05-25 16:36:08 UTC
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
Comment 4 Christoph Reiter (lazka) 2018-05-29 06:43:36 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-networking/issues/25.