Re: Certificates with common names not present in their SANs

2017-08-10 Thread Ryan Sleevi via dev-security-policy
CFCA stated this, in https://cabforum.org/pipermail/public/2017-July/011733.html Since then, no further evidence of this claim has been provided. SHECA ( https://cabforum.org/pipermail/public/2017-July/011737.html ) and GDCA ( https://cabforum.org/pipermail/public/2017-July/011736.html ) are

Re: Certificates with common names not present in their SANs

2017-08-10 Thread Matthew Hardeman via dev-security-policy
Didn't someone recently float the argument that the native u-label was required by local regulation / custom (in China) to be included and so they stuffed it into the CN? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Certificates with common names not present in their SANs

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy > wrote: > > 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

Re: Certificates with common names not present in their SANs

2017-08-07 Thread Alex Gaynor via dev-security-policy
Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm one of the maintainers of the Python ssl module, and I anticipate us having a fix for IDNs by the next release). Alex On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <

Re: Certificates with common names not present in their SANs

2017-08-06 Thread Nick Lamb via dev-security-policy
"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

Re: Certificates with common names not present in their SANs

2017-08-06 Thread alex.gaynor--- via dev-security-policy
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

Re: Certificates with common names not present in their SANs

2017-08-06 Thread Kurt Roeckx via dev-security-policy
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

Re: Certificates with common names not present in their SANs

2017-08-06 Thread Nick Lamb via dev-security-policy
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)

Certificates with common names not present in their SANs

2017-08-06 Thread alex.gaynor--- via dev-security-policy
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