Re: Certificates with common names not present in their SANs

[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
more restrained in claiming local law, although made similarly problematic
claims :)

On Thu, Aug 10, 2017 at 2:20 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
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

[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
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with common names not present in their SANs

[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 do not meet that requirement: 
> https://misissued.com/batch/1/

I sent a problem report to Symantec about these certificates via their web form 
on 2017-08-07 and received this response from them a few minutes ago:

> Thank you for reporting the issue for Symantec, Thawte and RapidSSL 
> certificates; however, we feel that the certificates we have issued are 
> compliant.  We consider the puny-coded SAN to match the native-coded CN and 
> to best cover both human consumers and machine consumers that need to be able 
> to read the name. Therefore, the certificates should not be revoked.
___
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

[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 <
dev-security-policy@lists.mozilla.org> wrote:

> "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
>
___
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

[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 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

[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 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

[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 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

[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) 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