Hi Ian, Thanks, we're looking into this.
Doug -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of i...--- via dev-security-policy Sent: Friday, August 7, 2020 11:37 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Concerns with GlobalSign IP address validation Hi there, When purchasing a GlobalSign OV IP address certificate, I was presented with several options to validate the certificate using email addresses that had an incorrectly truncated IP address, treating it similarly to a DNS name, which is not correct. As an example, GlobalSign would provide "admin@2.3.4" and "admin@3.4" as options for the IPv4 address "admin@1.2.3.4" -- which are (because of IPv4 notation) really 2.3.0.4 and 3.0.0.4, respectively, and not even under the same CIDR (not that it would make that valid anyway). To test this, I obtained an IP address with a zero from Google Cloud (34.94.0.97) and then requested a certificate for 44.34.94.97 (part of 44net, which seems largely unused), which becomes 34.94.97 after truncation and thus my server's IP. GlobalSign returned an error message when I chose the plainly invalid address "admin@34.94.97", which is why I'm not worried about posting this here, but it seems worthy of a further investigation into why GlobalSign presents these email addresses as options, if validation agents are trained to manually accept emails from these addresses (such as being shown them in internal systems), if they have issued any past certificates using invalid verification methods, etc. Thanks, Ian Carroll _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
