On Sat, Sep 20, 2014 at 1:10 AM, Anne van Kesteren <[email protected]> wrote:
>> My point is that UI indicators should reflect the reality of actual >> technical security boundaries. Unless we actually create a boundary, >> we shouldn't show that we have. > > So why do you show special UI for EV? For historical reasons, i.e. It Was Like That When I Got Here. (Similar to how getUserMedia does not (yet) require secure origins.) >> * What's a stable cryptographic identity in the web PKI? Is it the >> public key in the end-entity certificate, or the public key in any of >> the issuing certificates? >> * Or maybe the union of all keys? >> * Or maybe the presence of any 1 key in the set? >> * What about the sometimes weird and hard-to-predict certificate >> path-building behavior across platforms? >> * What about key rotation that happens legitimately? >> * Do we convince CAs to issue name-constrained issuing certificates to >> each site operator (with the constrained name being the origin's exact >> hostname), that cert's key becomes the origin's key, and site >> operators issue end entities from that? >> ** There'd still be a need to re-issue that key, from time to time. > > It seems for same-origin checks where the origin is derived from a > resource and not a URL, we could in fact do one or more of those, > today. E.g. if https://example.com/ fetches https://example.org/image > we'd check if they're same-origin and if their certificate matches. > Now as connections grow more persistent this will likely be the case > anyway, no? Perhaps an origin's cryptographic identity might be stable over the course of a page-load, or even over the course of a browsing session. But we'd need a stronger guarantee of lifetime than that. >> ** Could the TACK key be the origin key? > > Is TACK still going anywhere? The mailing list suggests it's dead. But one could imagine it being resuscitated, if it were a way to get a long-lived cryptographic identity for an origin. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
