On Fri, Mar 8, 2019 at 7:22 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Pursuant to the plain language of 7.1 as written, that circumstance -- > regardless of how it would occur -- would appear to be a misissuance. > I've already addressed this line of reasoning several times now as to what the expectations are. Indeed, the very message you're replying to has already addressed the scenario and the expectations, so I'm not sure repeating it is furthering much new insight. The rule as written requires that the output bits have come from a CSPRNG. > But it doesn't say that they have to come from a single invocation of a > CSPRNG or that they have to be collected as a contiguous bit stream from > the CSPRNG with no bits of output from the CSPRNG discarded and replaced by > further invocation of the CSPRNG. Clearly a technicality, but shouldn't > the rules be engineered with the assumption that implementers (or their > software vendors) might take a different interpretation? > We can only do so much to defend against the jackass genie [1]. Likewise, there is no defensible interpretation that an algorithm that, say, takes bits from a CSPRNG and either keeps or discards them based on some non-CSPRNG algorithm, and then outputs them, still represents a CSPRNG, just as we cannot say that we sample bits from RFC 3514 [2] and only keep the good ones, and thus ensuring we never corrupt our machine with evil. The substance of this argument is quite literally haggling over what "output" and "contains" is, and that, frankly, is obnoxious. I appreciate the attention to detail, but I find it difficult to feel that it is a good faith effort that is designed to produce results consistent with the goals that many of this community have and share, and thus don't think it would be a particularly valuable thing to continue discussing. While there is certainly novelty in the approach, which is not at all unfamiliar in the legal profession [3], care should be taken to make sure that we are making forward progress, rather than beating dead horses. I'm not going to tell you to stop talking about this, as I think it'd be improper to police such a thread given my involvement in it. However, I want to highlight that nothing productive has emerged from it, and the creative interpretations being advocated. We are no further in understanding any of the questions being proposed by those applying creative interpretations, because the principles have not changed. Every time a CA has tried to apply such problematic logic, it has worked out poorly for them in this community. whether arguing it was "ambiguous" that MITM was prohibited, even though there was a requirement to validate (and ensure validation of) all domain names in a certificate or that it's not "misissuance", even though no evidence can be provided that the requirements were followed, nothing good has come of that. Indeed, I think advocating this line of reasoning is doing more active harm, to this community and to CAs, and I hope it's abundantly clear as to why that is. [1] https://tvtropes.org/pmwiki/pmwiki.php/Main/JackassGenie [2] https://www.ietf.org/rfc/rfc3514.txt [3] https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
