On Thu, Mar 9, 2017 at 12:26 PM, tugba onder via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Here, the part that needs to be taken care is "validate using at least one > of the methods listed". Although we mentioned it in our previous response, > I guess you missed it; we do not make verification just with respect to > 3.2.2.4.6. For the further satisfaction of 3.2.2.4, we first apply > 3.2.2.4.1, then 3.2.2.4.3 or 3.2.2.4.4 and then 3.2.2.4.5. Therefore, even > if we do not implement 3.2.2.4.6 at all, we satisfy the condition "validate > using at least one of the methods listed" in 3.2.2.4. > You're right, I did miss it / misunderstand. It's the first case I've heard of CAs applying multiple checks in an additive fashion; I've only ever heard of multiple layers being applied :) > While we are implementing 3.2.2.4.6, we generate the "Required Website > Content" concept described in ballot 169, including only the information > that uniquely identifies the subscriber without a random value or request > token. This practice comes from item 6 of section 3.2.2.4 of BR v1.3.7. The > important thing that should be noted here is, the use of random value or > request token is coming with ballot 169. The effective date for ballot 169 > was 1 March 2017, and the date on which we have received our audit report > was December 2016, before the effective date. > Right, this was less a concern for misissuance, and more a concern for what we've seen a number of CAs do - which is fail to stay up to date relative to the changes. Your description of your validation after March 1 was inconsistent with 3.2.2.4.6, which is why I flagged it. If you've already validated the domain using a different form permitted, and 3.2.2.4.6 is just a secondary layer of validation, then I agree, it's no concern. It's only if you use the process you describe as the primary validation - if so, it must conform to 3.2.2.4.6, or you must use some other form of primary validation. > If you consider any other inconsistencies, please inform us, we will > appreciate it. My request was one of just taking a few days / a week to re-examine what the current BRs are, using your knowledge of your policies and practices, and make sure that all methods are consistent. For example, the 64-bits of entropy, the aligned-with-3.2.2.4.6 method of domain validation, etc. That your auditor did not flag these implies that your auditor did not do that level of analysis, but that's also not surprising given the role/function of auditors (some auditors do this as part of their engagements, some auditors do not, and generally both are seen as complying with the necessary level of professional duty; just the ones that do are better auditors, and the ones that don't may miss stuff that finds them removed as trusted auditors in the future) Because we've seen some CAs argue that "You didn't explicitly say we had to follow X in the BRs", I wanted to avoid that situation, by just making sure Kamu SM warrants that "We've read the BRs 1.4.2, we've examined our policies and practices, we believe they're consistent and apply" (or "We identified items X, Y, Z that we are fixing by doing A, B, C") _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
