"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
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
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
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)
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
5 matches
Mail list logo