On 29/03/2017 20:52, Alex Gaynor wrote:
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expect!), their users would all
get cert warnings with the Mozilla trust DB!
Even as someone pretty well versed in the WebPKI, I don't think my
expectations about who the CA for a given site should be really are
actionable.
It seems to be that certs are for computers to consume, and only
incidentally for humans to read (*hit tip* to SICP).
Alex
PS: To expand a bit on this thought experiment, if I were to enumerate all
CAs over a bunch of websites, the only cases I can think of where human
intuition has a defensible conclusion, is that certain CAs _shouldn't_ sign
things, notably CAs intended only for limited usage (e.g. a Government CA
designed for signing government website certs). These cases are, I think,
much better handled by Name Constraints (or some other technical
constraint), and that's an entirely different subject altogether.
Which was precisely my point, except that to date, the few implemented
forms of name constraints seem unable to capture the real world
considerations that should exclude most CAs from a considerable part of
the Web name space:
- Country-specific CAs want to sign certificates for GTLD sites (.com,
.net, .org, .name etc.) that are actually under that country
jurisdiction.
- Cloud-hosting provider CAs (Microsoft, Google, Amazon) want to sign
certificates for anything they host, regardless of TLD or country.
- Neither are appropriate CAs for any sites not under their
administration/jurisdiction.
The special case of the old US Gov CA getting thrown out of Mozilla and
some other browsers is something of an outlier, but even then, it would
be odd if a US Gov site had a certificate from the Taiwan GRCA or the
Spanish guild of public notaries.
So until relevant technical constraints are actually ubiquitous in the
WebPKI, manual checking remains relevant.
On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 29/03/2017 16:47, Gervase Markham wrote:
On 29/03/17 15:35, Peter Kurrasch wrote:
In other words, what used to be a trust anchor is now no better at
establishing trust than the end-entity cert one is trying to validate or
investigate (for example, in a forensic context) in the first place. I
hardly think this redefinition of trust anchor improves the state of the
global PKI and I sincerely hope it does not become a trend.
The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+
years.
That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.
Problem is that whenever viewing a full cert chain in a typical browser
etc. that has reference "trusted" copies of all the incumbents,
disassociating the names in root CA and SubCA certificates from reality
creates misinformation in a context displayed as being "fully
validated" to known traceable roots by the Browser/etc.
For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good". Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist). Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).
With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations. One would expect a blogger/blogblog domain to
have a Google-issued certificate while one would expect the opposite of
anything hosted outside the Alphabet group.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
