The problem might be a security issue because it gives an attacker more opportunities to craft a malicious certificate with a signature collision.

Other issues may include applications that convert serial number to an actual integer. Some systems and languages interpret a trailing zero as indication for octal representation. Other applications may use int(serial_number) + issuer DN as unique identifier for a certificate. Leading zeros may break assumptions and cause conflicts.

I don't think this is a vulnerability because installing a root certificate requires privilege, but will let the BoringSSL people decide.

I'm pretty sure that the issue also applies to intermediate and EE certs. It's a bit tricky to create a cert with bad integers and I haven't had time to craft a bad certificate manually.

Much as I would love for that parser to be strict, I believe there are enough misissuing Enterprise CAs that we're stuck here. Ryan is more authoritative here though.

Correct. This is one area of acknowledged incompatibility that we'd like to tighten over time. Publicly trusted CAs are being supervised and prohibited from this, and we'll be working to tighten that further, but Enterprise CAs remain a compatibility concern and have thus not prioritized deprecation.

I don't believe there's any need to restrict this. The concerns expressed in Comment #1 do not apply.

I'm actually marking this Feature, because this would be a change to the Web Platform as such invalid serials are, unfortunately, widely accepted on the Web Platform (Chrome, Firefox, Edge, Safari depending on macOS release)

>  While the encoding is valid BER, it's not valid DER. 

The BER rules are the same as the DER rules: "If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets." - https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

So it isn't valid BER either.

> I'm pretty sure that the issue also applies to intermediate and EE certs. It's a bit tricky to create a cert with bad integers and I haven't had time to craft a bad certificate manually.

If intermediate or end-entity certificates with this kind of bad encoding are accepted then that's a separate bug. 

> Such invalid serials are, unfortunately, widely accepted on the Web Platform (Chrome, Firefox, Edge, Safari depending on macOS release)

I would be surprised if Firefox accepts such encodings in end-entity and intermediate certificates. See https://hg.mozilla.org/projects/nss/annotate/b81ef75ef4e8/lib/mozpkix/lib/pkixder.cpp#l581, which implements the check from the BER spec. I would even be surprised if Firefox accepted such encoding in root certificates since, IIRC, it uses the same parser to parse root certificates.

As per comment# 5, issue seems to be a Feature request, hence marking it as Untriaged.

Thanks!