On Thursday, July 20, 2017 at 3:32:29 PM UTC-5, Ryan Sleevi wrote: > Broadly, yes, but there's unfortunately a shade of IP issues that make it > more difficult to contribute as directly as Gerv proposed. Gerv may accept > any changes to the Mozilla side, but if the goal is to modify the Baseline > Requirements, you'd need to sign the IPR policy of the CA/B Forum and join > as an Interested Party before changes.
I think at this phase that it makes sense to better flesh out within the Mozilla dev security community what kinds of mitigations might be economically feasible, provide measurable benefit of sufficient counterbalancing value, and practical details for implementation before trying to bring a ballot before the CAB forum. Having said that, I did read over the IPR policy agreement and at first blush saw nothing that would prevent myself or my company from becoming signatories should the idea take off. > > And realize that the changes have to be comprehensible by those with > limited to know background in technology :) Certainly. I would expect that the target audience is more compliance / audit / accounting than it is network engineering. Even still, I have to believe it is possible to describe the specific modes of risk and counterbalancing mitigations in a framework that those of that skillset can evaluate. > The question about the validity/reuse of this information is near and dear > to Googles' heart (hence Ballots 185 and 186) and the desire to reduce this > time substantially exists. That said, the Forum as a whole has mixed > feelings on this, and so it's still an active - and separate - point of > discussion. I mentioned it mostly as I was curious if the argument that time-of-issuance (or thereabout) DNS queries of an issuance blocking nature pertaining to CAA had been utilized as yet as an argument that more revalidation might now be appropriate because the revalidation is merely a minor extra burden to the queries already being run for CAA. (There's already a blocking DNS query on records of the subject domain holding up issuance, so what's a few more records on the same domain?) > That said, I think it's worthwhile to make sure the threat model, more than > anything, is defined and articulated. If the threat model results in us > introducing substantive process, but without objective security gain, then > it may not be as worthwhile. Enumerating the threats both addressed and > unaddressible are thus useful in that scope. Can you provide any good reference or point to an example of what you would regard an exceptionally well described definition and articulation of a thread model within the certificate issuance space generally? I feel I have a quite solid grasp of the various weak points in the network infrastructure and network operations aspects that underpin the technological measures involved in domain validation. I am interested in taking that knowledge and molding that into a view which might best permit this community to assess my thoughts on the matter, weigh pros and cons, and help guide proposals for mitigation. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
