On Wed, Nov 20, 2019 at 9:48 PM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> > writes: > > >In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling, > >Jeremy Rowley, and I started discussing possible steps that might be > taken to > >prevent misencoding strings in certificates > > Is there any official position on strings that have completely invalid > encodings like embedded NULL characters in them (presumably in memoriam of > the > Kaminsky/Marlinspike certificate-spoofing bug) as one of Microsoft's CA > certificates among numerous others do? I’m not sure I understand the link to the discussion and why you’re bringing it up? Do you believe it’s still applicable in the Web PKI of the past decade? I ask, because this is already addressed rather extensively, and has been for some time, within linters, and since at least 2012 with respect to the Baseline Requirements, through the incorporation of RFC 5280, and thus transitively the incorporation of DNS preferred name syntax. I’m not sure which of Microsoft’s CAs you’re referring to, so you’d have to be more precise. Do you mean the publicly trusted certificates? Or something only trusted on Windows? If you could link to the crt.sh entry, that might be easier. It could be that you’re referencing the use of BMPString, which systems like Active Directory Certificate Services used. Those, being 16-bit code points, certainly “seemed” like they had embedded NULs, but only if misinterpreted as 8-bit. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
