On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > I consider that only a single CA has represented any ambiguity as being > > their explanation as to why the non-compliance existed, and even then, > > clarifications to resolve that ambiguity already existed, had they simply > > been sought. > > > > Please contemplate this question, which is intended as rhetorical, in the > most generous and non-judgmental light possible. Have you contemplated the > possibility that only one CA attempted to do so because you've stated your > interpretation and because they're subject to your judgement and mercy, > rather than because the text as written reflects a single objective > mechanism which matches your own position? > Matthew, I honestly doubt so. It seems that one CA software vendor had a buggy implementation but we know this is not universal. For example, see https://github.com/r509/r509/blob/05aaeb1b0314d68d2fcfd2a0502f31659f0de906/lib/r509/certificate_authority/signer.rb#L132 and https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L511 are open source CA software packages that clearly do not have the issue. Further at least one CA has publicly stated their in-house written CA software does not have the issue. I know, as the author of cablint, that the main reason I didn't have any confusion. I didn't add more checks because of the false positive rate issue; if I checked for 64 or more bits, it would be wrong 50% of the time. The rate is still unacceptable with even looser rules; in 1/256 cases the top 8 bits will all be zero, leading to a whole the serial being a whole byte shorter. I do personally think that the CAs using EJBCA should not be faulted here; their vendor added an option to be compliant with the BRs and it was very non-obvious that it had a bug in the implementation. Based on my experience with software development, we should be encouraging CAs to use well tested software rather than inventing their own, when possible. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
