On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy < [email protected]> wrote:
> On Thu, 5 Mar 2020 14:15:17 +0000 > Nick Lamb via dev-security-policy > <[email protected]> wrote: > > > There is some value in policy alone but there's also substantial > > independent value in writing the policy into the code. Would Mozilla > > accept third party work to implement something like #908125 ? I > > appreciate you don't work for them any more Wayne, perhaps Kathleen or > > somebody else who does can answer? > > I never saw any reply on this topic and so my assumption is that at > best such a patch would be in the big pile of volunteer stuff maybe > nobody has time to look at. Writing code is usually the last step, and can be premature during the discussion phase, because it tends to unnecessary anchor the conversation. As I understand it Apple's intent is that Safari will not accept a > certificate with a lifetime of (let's say for this example) 500 days, > but this would not necessarily become a violation of their root store > policy. Such a certificate could exist and (absent decisions here) it > would work in Firefox but not Safari. More practically, it would work > in some TLS-based internal system that trusts public roots, but not in > Safari, which would be just fine for a backend system that was never > actually intended to be used by web browsers. That understanding does not seem consistent with past messaging. This would make it like SCT enforcement in Safari or Chrome. Google > doesn't propose to distrust a CA which issues certificates without > logging them - it just ensures the Chrome browser doesn't trust those > certificates until it is shown proof they were logged, which might be > hours or weeks later. Correct, in that like Apple, Chrome offers folks who own and administer the device to configure exceptions regarding logging. I think it’s important to highlight that these are meaningfully different, however, in that lifetime (and reuse) can be objectively qualified independent of policy, while policies like CT or “publicly trusted” are semi-dependent upon policy (e.g. the set of trusted logs or CAs). Root stores have fairly consistently treated violations of objectively quantifiable criteria as root store program violations/incidents. A more apt example is Mozilla policy with respect to signature algorithms. As I understand it Google's own CA deliberately > does this in fact. No, that’s not correct. If that understanding is correct (again the poor communication from > Apple which I already disapproved of doesn't help me) then in having an > unenforced root store policy about this, rather than enforcement but no > policy change, Mozilla would be standing alone. As an aside, the asides don’t help. Let’s at least recognize this is Apple engaging more than they have in the past two decades, and appreciate that they’ve been willing to discuss to the limits they have. Baby steps, and positive changes should be recognized as such. I do disagree the suggestion of “standing alone”. Policy and enforcement are complementary yet independent actions. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
