On 4/13/11 11:09 AM, Gervase Markham wrote:
Would it allow third parties to maintain and distribute such
blocklists?
Hmm. Not unless you also want to maintain blocklists for addons and
graphics drivers as well, or for your users to lose that functionality.
(I guess you could download the Mozilla one and merge in your own list.)
I don't totally understand your point about addons and graphics drivers.
I guess I'm just not familiar enough with the codebase there.
In any case, the idea for user-maintained block lists would be to enable
something for CA (and Sub-CA) blocking akin to Adblock lists.
Knowledgeable super-users can make lists for security-conscious people
to subscribe to.
- CA locking functionality in HSTS or via CAA
I am not aware of a spec (yet) for HSTS to do this.
Indeed not. However, one would not be too tricky to write.
CAA (do-not-issue) is experimental track, and the draft is still pretty
rough.
DANE is standards track, and it anticipates this functionality in the
current draft section 2.3 -- cert type 2.
DANE does the same thing? I had not noticed that. What does Phil
Hallam-Baker say about the overlap?
The primary purpose of CAA is a communication from the domain owner to a
potentially issuing CA. PHB forked CAA when we told him that was out of
scope for DANE.
In addition to that core purpose, he has also included references to the
fact that "Relying Party Applications MAY enforce CAA issue restrictions
at their option, provided that the Relying Party Authorization set is
not empty." but admitted that, "The consequences of determining that a
certificate is not compatible with the specified CAA relying party
restrictions are outside the scope of this document." he hasn't
described any of the anticipated semantics for these records other than
reserving a bit for them. All of this, plus the fact that it is an
experimental draft, make me believe that it is not optimal for building
current functionality on top of.
http://tools.ietf.org/html/draft-hallambaker-donotissue
Members of DANE have told PHB and Ben that they support his core goal
but that the client validation stuff is overlapping with the DANE work
and probably best pursued there.
http://www.ietf.org/mail-archive/web/dane/current/msg01316.html
DANE, on the other hand, is intended primarily for communication from
domain owners to relying party applications, and the group is working
through many of the relevant issues. The difference between delivering
an EE cert and a CA cert is minimal.
Steve
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
