StartCom cross-signs disclosed by Certinomis
+1 Support revocation! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with common names not present in their SANs
"simply" how? If it's your belief that the Python code actually does work for IDN SANs I think you're going to need to do better than just asserting that it's "simply" so in the face of subject experts saying it's broken. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with common names not present in their SANs
On Sunday, August 6, 2017 at 3:08:32 PM UTC-4, Nick Lamb wrote: > On Sunday, 6 August 2017 14:10:36 UTC+1, alex@gmail.com wrote: > > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding > > the SAN > > Note https://bugs.python.org/issue28414 I've followed up on this bug, but it seems like a red herring to me -- if the value is in the SAN (as it is required to be!) the value will simply be matched from there. Further, a quick search of crt.sh's DB shows that quite a lot of certs are issued with IDNA-encoded CNs: certwatch=> select count(*) from certificate_identity where name_type = 'commonName' and lower(name_value) LIKE 'xn--%'; count 242943 Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with common names not present in their SANs
On Sat, Aug 05, 2017 at 02:36:14PM -0700, alex.gaynor--- via dev-security-policy wrote: > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the > SAN I think that's actually correrct? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with common names not present in their SANs
On Sunday, 6 August 2017 14:10:36 UTC+1, alex@gmail.com wrote: > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the > SAN Note https://bugs.python.org/issue28414 At least one popular implementation of TLS in a non-browser client (the Python SSL implementation) requires that non-ASCII FQDNs are written out as U-labels in the Common Name in order to correctly match them It can't work with A-labels because it (erroneously) transforms Punycoded names into U-labels before matching and as a result it can't match IDNs in SANs at all since these will be presented as A-labels Christian considers the current situation "sane" but it will so far as I can see encourage CAs to issue these bogus certificates _and_ weaken the support for SANs, and we should encourage Python to get their act together and fix this. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Certificates with common names not present in their SANs
Hi all, 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always be an element from the SAN. Here are 62 certs, from a variety of CAs which do not meet that requirement: https://misissued.com/batch/1/ These appear to be for a variety of reasons: - just plain wrongness :-) - leading/trailing spaces in either the CN or the SAN - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the SAN - My personal favorite, the presence of zero-width-space unicode characters in the CN There's probably some other reasons, there's a lot to sort through. I've notified several of the CAs already, but not all. (I notably haven't yet notified Symantec, who appear to have the plurality of these because of the IDNA issue). Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
