On Wed, Nov 20, 2019 at 9:48 PM Peter Gutmann <pgut...@cs.auckland.ac.nz>

> 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

Reply via email to