On Fri, Mar 8, 2019 at 8:11 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I didn't post this as part of yesterday's message because I didn't want to > muddy the waters even further, but let's look at the exact wording of BR > 7.1: > <snip> > All fully compliant with the requirement that: > > CAs SHALL generate non-sequential Certificate serial numbers greater than > zero (0) containing at least 64 bits of output from a CSPRNG > I'm not sure this will be a very productive or valuable line of discussion. As best I can tell, you're discussing pathological interpretations, implicitly, it seems, with a critique of the current language. Complaining about things "as they are" doesn't really help anyone, other than perhaps the speaker, but if there is a positive suggestion that you believe addresses the concerns you see, it may be useful to just make that argument and make it clearly. It may be that you don't know what the proposed language should be, in which case, you should clearly state that. Alternatively, you're attempting to explore "What would happen if I was a CA and I gave these answers". As you seem to acknowledge, silly answers get silly results. It's well known in this community that attempting to hem and haw through creative interpretations of language, rather than trying to operate beyond reproach (and thus actively try to avoid silly answers), tend to be less likely to gain or retain trust. The world is fully of silly answers from silly people, and while that's great, it doesn't seem very worthwhile or productive to discuss - all that really matters is whether expected-to-be-smart people, CAs, are the ones giving silly answers. Of course, there are quite glaring flaws in the argument, particularly that "all" of these are compliant. None of them are compliant under any reasonable reading. None of those are defensible outputs of a CSPRNG, they are outputs of Peter's Silly Algorithm, a non-cryptographically strong non-pseudo-random-number-generator. The reason we can see these arguments as silly as the burden of proof rests on demonstrating how it complies. Language lawyering as whether "contains" allows "As input to my Silly Algorithm" is a tactic we can take as a thought experiment, but it's not productive, because all that matters is whether or not a CA is silly enough to make such a silly argument. And if they are that silly, they are unlikely to find such a silly answer well-received. Of course, all of this is understandable, when you consider that the 'how' you respond to an incident is just as important as the 'what' of the incident response. A CA that responds to incidents using silly examples is not doing themselves favors. Focusing on the fact that someone "could" give silly answers is to simply ignore whether or not it would be wise or defensible to do so, or whether there are alternatives that avoid silliness entirely. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
