Re: Sectigo-issued certificates with concerningly mismatched subject information
On Sun, 26 Jan 2020 11:16:24 +0100 Hanno Böck via dev-security-policy wrote: > I guess this is the most relevant part here. Noone has noticed. > > I see that a lot of people are having fun pointing out these issues > again and again to show how sloppy CAs work. Which is fine I guess, > but it leads to the question what the point of all this is. Unlike minor typographical errors which I don't think have a larger significance, this type of mistake might realistically have grave impact depending on how it happens, for which we will need Sectigo's honest response to the incident. For example suppose Sectigo has a bug in which under some circumstances Customer A is treated as though they were Customer B instead, and of course certificates like these are one possible result of the bug that we can see in the CT logs. But other symptoms of that same bug might include Customer B has proved to Sectigo that they control example.com, so Customer B can order new certificates for example.com, but with the bug now Customer A can get such certificates too which they are not entitled to. > Maybe it's time to change the WebPKI rules to reflect that - either say > "any information in a certificate that is not the CN/SAN is yolo and > can be whatever and web clients should make sure they never display > that informaiton" or "any useless extra information should be > skipped". I definitely can't support the former. The purpose of X.509 certificates is to bind a public key to an identity. If we decide that something isn't part of the identity then it shouldn't be included. I think the latter isn't a good idea, beyond the extent to which it's already present in the BRs but I don't feel strongly about it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sectigo-issued certificates with concerningly mismatched subject information
On Sun, 26 Jan 2020 01:59:33 -0800 (PST) Ian Carroll via dev-security-policy wrote: > These certificates expired in 2019 and are thus no longer a problem, > but they were actively used by the customer (e.infinityspeakers.com > still serves one of them) and it does not appear anyone has noticed. I guess this is the most relevant part here. Noone has noticed. I see that a lot of people are having fun pointing out these issues again and again to show how sloppy CAs work. Which is fine I guess, but it leads to the question what the point of all this is. Maybe it's time to change the WebPKI rules to reflect that - either say "any information in a certificate that is not the CN/SAN is yolo and can be whatever and web clients should make sure they never display that informaiton" or "any useless extra information should be skipped". Let's be honest: There are two reasons these extra fields exist in the first place, and no good one. One reason is they are legacy baggage from the X.509 standard. If we'd rewrite the webpki today we wouldn't have such fields. The other is that they are upselling features where CAs can create the illusion that there are more or less valuable certificates. -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Sectigo-issued certificates with concerningly mismatched subject information
Hi, I was recently sent https://crt.sh/?id=380678631 by Nathanial Lattimer (https://twitter.com/d0nutptr), when he noticed it appeared to contain subject information for a completely different entity (Harman International's domain, Twitter's organizational information). It appears Sectigo made this mistake several times, in https://crt.sh/?id=380583413 and https://crt.sh/?id=369796283 as well. These certificates expired in 2019 and are thus no longer a problem, but they were actively used by the customer (e.infinityspeakers.com still serves one of them) and it does not appear anyone has noticed. Harman is owned by Samsung and so it is very unlikely these were properly issued. I wanted to highlight this mis-issuance since it seems like a concerning failure case that is different from a simple typo, and may have a more systemic root cause. If there is a bug that is repeatedly causing i.e. the swapping of identity information in certificate requests, it would be pretty concerning. These certificates have been reported to sslab...@sectigo.com as well. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
