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