Re: Why BR 7.1 allows any serial number except 0
On Fri, Mar 8, 2019 at 9:27 PM Peter Gutmann wrote: > Ryan Sleevi writes: > > >I'm not sure this will be a very productive or valuable line of > discussion. > > What I'm pointing out is that beating up CAs over an interpretation of the > requirements that didn't exist until about a week ago I'm not sure if there's any value in continuing to highlight that you're factually misrepresenting things, rather significantly, and thus undermining much of your contribution. Several times now, multiple people have pointed out the discussions related to this that happened prior to, during, and following the introduction of this requirement. Your choice to ignore or deny such evidence is extremely counter-productive. > If you're going to impose a > specific interpretation on them then get it added to the BRs at a future > date > and enforce it then, don't retroactively punish CAs for something that > didn't > exist until a week or two ago. This framing is factually and materially false. There is no retroactive punishment occurring, just as the guidance was long-existing. I don't see there being any opportunity to productively engage, given the good-faith effort to correct your misunderstanding, which you still persist in advocating. Similarly, I do not think it at all helpful that you continue to ignore the objectives and goals of the incident response process, the value and importance it serves the community, and the expectations of the CAs. Perhaps there's an argument to be made that we should litigate what "the" means. It would be a fantastic spectacle, but it would be both thoroughly unproductive and fail to achieve any of the goals or objectives of a healthy Web PKI. Such exercises can and should be conducted elsewhere, while the rest of us try to make progress on improving how CAs respond to incidents caused by behaviours long-documented as incompatible with the requirements. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Why BR 7.1 allows any serial number except 0
Ryan Sleevi writes: >I'm not sure this will be a very productive or valuable line of discussion. What I'm pointing out is that beating up CAs over an interpretation of the requirements that didn't exist until about a week ago when it was pointed out in relation to DarkMatter is unfair on the CAs. If you're going to impose a specific interpretation on them then get it added to the BRs at a future date and enforce it then, don't retroactively punish CAs for something that didn't exist until a week or two ago. >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. Again, it's your definition of "reasonable". A number of CAs, who applied their own reasonable reading of the same requirements, seem to think otherwise. They're now being punished for the fact that their reasonable reading differs from Mozilla's reasonable reading. >I would strongly caution CAs against adopting any of these interpretations, >and suggest it would be best for CAs to wholly ignore the message referenced. "Pay no attention to the message behind the curtain". Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Why BR 7.1 allows any serial number except 0
I wrote: >So the immediate application of this observation is to make any 64-bit value >comply with the ASN.1 encoding rules: If the first bit is 1 (so the sign bit >is set), swap it with any convenient zero bit elsewhere in the value. >Similarly, if the first 9 bits are zero, swap one of them with a one bit from >somewhere else. Fully compliant with BR 7.1, and now also fully compliant >with ASN.1 DER. Oops, need to clarify that: Note the specific use of "swap one of them". You can't just drop in a zero bit you made up yourself, you have to use one of the original zero bits that came from the CSPRNG or you won't be compliant with BR 7.1 any more. So you need to swap in a genuine zero bit from elsewhere in the value, not just replace it with your own made-up zero bit. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Why BR 7.1 allows any serial number except 0
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: > > 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
Why BR 7.1 allows any serial number except 0
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: CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG Note the comment I made yesterday: That's the problem with rules-lawyering, if you're going to insist on your own very specific interpretation of a loosely-worded requirement then it's open season for anyone else to find dozens of other fully compatible but very different interpretations. So lets look at the most pathologically silly but still fully compliant with BR 7.1 serial number you can come up with. Most importantly, 7.1 it never says what form those bits should be in, merely that it needs to contain "at least 64 bits of output from a CSPRNG". In particular, it doesn't specify which order those bits should be in, or which bits should be used, as long as there's at least 64. So the immediate application of this observation is to make any 64-bit value comply with the ASN.1 encoding rules: If the first bit is 1 (so the sign bit is set), swap it with any convenient zero bit elsewhere in the value. Similarly, if the first 9 bits are zero, swap one of them with a one bit from somewhere else. Fully compliant with BR 7.1, and now also fully compliant with ASN.1 DER. Let's take it further. Note that there's no requirement for the order to be preserved. So let's define the serial number as: serialNumber = sortbits( CSPRNG64() ); On average you're going to get a 50:50 mix of ones and zeroes, so your serial numbers are all going to be: 0x plus/minus a few bits around the middle. When encoded, this will actually be 0x00, with the remaining zero bits implicit - feel free to debate whether the presence of implict zero bits is compliant with BR 7.1 or not. Anyway, continuing, you can also choose to alternate the bits so you still get a fixed-length value: 0x (plus/minus a bit or two at the LSB, as before). Or you could sort the bits into patterns, for example to display as rude messages in ASCII: "BR7SILLY" Or, given that you've got eight virtual pixels to play with, create ASCII art in a series of certificates, e.g. encode one line of an emoji in each serial number. Getting back to the claim that "BR 7.1 allows any serial number except 0", here's how you get this: At one end of the range, your bit-selection rule is "discard every one bit except the 64th one", so your serial number is: 0x0001 or, when DER encoded: 0x01 At the other end of the scale, "discard every zero bit except the first one": 0x7FFF or INT_MAX. 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 should note in passing that this also allows all the certificates you issue to have the same serial number, 1, since they're non-sequential and greater than zero. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
