Name issues in public certificates

[Peter Bowen]

Inspired by Rob Stradling's work
(https://cabforum.org/pipermail/public/2015-November/006269.html), I
wrote a quick tool to check that commonNames and Subject Alternative
Names in server auth certificates issued by public CAs were following
the CA/Browser Forum baseline requirements.

The resulting report of anomalies is available at
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing

The rules are a rather strict interpretation of RFC 5280 and the
Baseline Requirements. Notably, it will complain if FQDNs are not
converted to ASCII (as defined in 7.2 and 7.3 of RFC 5280) and will
complain if there is an IP address flaged as a dNSName in a
Generalized Name.

There are a couple of rules that may create false positives, so please
don't assume every certificate on the sheet is problematic.

Thanks,
Peter

[Peter Gutmann]

Peter Bowen <pzb...@gmail.com> writes:

>There are a couple of rules that may create false positives, so please don't
>assume every certificate on the sheet is problematic.

That's still pretty scary, nearly 50,000 names from a who's-who of commercial
CAs. Yet more evidence that, like the output from the EFF SSL Observatory, we
need independent assessment of browser PKI rather than self-certification ("we
define ourselves to be in full compliance with everything we need to be
compliant with, as far as we can tell").

Peter.

[Rob Stradling]

Peter (G),

I fully agree that independent assessment is useful, but independent
assessments need to be assessed too (preferably before the press start
quoting soundbites! :-) )

Peter (B),

Thanks for doing this report. There are definitely some interesting
findings. However, I would like to discuss several classes of (what I
think are) false positives that cover a significant number of the
"anomalies" you've found:

- RFC5280 sections 7.2 and 7.3 do indeed talk about the need for
dNSNames, domainComponents, etc, to only contain ASCII data. However,
your report also flags Subject CNs with non-ASCII data - AFAICT, this is
permitted by both RFC5280 and the BRs. It is common practice to put the
"xn--" ASCII string in a dNSName and the UTF-8 string in the Subject CN.

- You wanted to check that "public CAs were following the CA/Browser
Forum baseline requirements" when issuing certs. However, some of the
certs in your report were issued before any of the browsers / audit
regimes demanded that public CAs be compliant with the BRs.
Furthermore, some of the certs in your report were issued before the BRs
even existed.

- You wanted to check "server auth certificates issued by public
CAs". However, I see some Code Signing Certificates in your report.

I'm pretty optimistic that all of the "anomalies" issued by Comodo's CA
system (except for the 8 mentioned in our recent incident report) will
be found to fall into these categories, although I haven't done an
exhaustive analysis yet. If there are any other "anomalies", they're a
bit lost in the noise at present!

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

On 17/11/15 14:12, Richard Wang wrote:
> I also found some mistakes for the list:
> 1. I see some client certificate in the report that it say the email as common
> name is wrong;
> 2. IP address is allowed by BR;

Reserved IP Addresses are no longer permitted by the BRs. This is what
Peter's "_special_ipv4" rule refers to, IIUC.

Encoding an IP Address in a dNSName is not permitted by the BRs. This
is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.

Public IP Addresses, encoded in the iPAddress field, are indeed
permitted. I think Peter's report correctly avoided flagging these as
"anomalies" though.

> 3. IDN is allowed, but also in the report

IDN is allowed, as long as it's encoded correctly.

See the previous comments about RFC5280 sections 7.2 and 7.3.

> Regards,
>
> Richard

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Peter Bowen]

On Tue, Nov 17, 2015 at 5:31 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> On 17/11/15 08:25, Peter Gutmann wrote:
>>
>> Peter Bowen <pzb...@gmail.com> writes:
>>
>>> There are a couple of rules that may create false positives, so please
>>> don't
>>> assume every certificate on the sheet is problematic.
>>
>>
>> That's still pretty scary, nearly 50,000 names from a who's-who of
>> commercial
>> CAs. Yet more evidence that, like the output from the EFF SSL
>> Observatory, we
>> need independent assessment of browser PKI rather than self-certification
>> ("we
>> define ourselves to be in full compliance with everything we need to be
>> compliant with, as far as we can tell").
>>
>> Peter.
>
>

> Peter (B),
>
> Thanks for doing this report. There are definitely some interesting
> findings. However, I would like to discuss several classes of (what I think
> are) false positives that cover a significant number of the "anomalies"
> you've found:
>
> - RFC5280 sections 7.2 and 7.3 do indeed talk about the need for dNSNames,
> domainComponents, etc, to only contain ASCII data. However, your report
> also flags Subject CNs with non-ASCII data - AFAICT, this is permitted by
> both RFC5280 and the BRs. It is common practice to put the "xn--" ASCII
> string in a dNSName and the UTF-8 string in the Subject CN.

I read 7.2 again and it clearly calls out as only applying to
domainComponent attributes. I'll rerun with allowance for hostnames
with u-labels in CNs.

> - You wanted to check that "public CAs were following the CA/Browser Forum
> baseline requirements" when issuing certs. However, some of the certs in
> your report were issued before any of the browsers / audit regimes demanded
> that public CAs be compliant with the BRs. Furthermore, some of the certs in
> your report were issued before the BRs even existed.

Yes, I should have been clearer here. The correct description should
be "determining if the names in unexpired certificates follow the
current BRs". As you point out, the BRs have changed over time and
didn't even exist when some of these were issued. That is why I
included the not before date; those examining the list should
determine their cutoff date.

> - You wanted to check "server auth certificates issued by public CAs".
> However, I see some Code Signing Certificates in your report.

I included all certificates that included the serverAuth EKU and all
those that had no EKU. Can you provide an example of a code signing
cert in the list so I can figure out why this test failed?

> I'm pretty optimistic that all of the "anomalies" issued by Comodo's CA
> system (except for the 8 mentioned in our recent incident report) will be
> found to fall into these categories, although I haven't done an exhaustive
> analysis yet. If there are any other "anomalies", they're a bit lost in the
> noise at present!

I'll rerun the data in a few hours. I also will fix the encoding
issues; somehow the character encoding got messed up on import to
Google Sheets. I will also add a field column to help identify where
in the certificates the issues are occurring. Hopefully these changes
will help remove the noise.

Thanks,
Peter

[Peter Bowen]

On Tue, Nov 17, 2015 at 6:12 AM, Richard Wang <ric...@wosign.com> wrote:
> I also found some mistakes for the list:
> 1. I see some client certificate in the report that it say the email as common
> name is wrong;

I filtered for certificates that includes the serverAuth EKU or do not
include any EKUs. Can you provide an example of a clientAuth
certificate that was incorrectly included?

> 2. IP address is allowed by BR;

IP addresses are only allowed in the commonName or as IPAddress type
in the SAN extension. If the rule is _ipv4_not_allowed_here, then
that means that an IP address was included in a SAN as a DNS Name,
which is disallowed. I will also fix the IP check to differentiate
between reserved IPs (as defined in the BRs) and special purpose IPs
(which are allowed if not reserved). The BRs do not clearly state
that 192.168.0.0/24, 172.16.0.0/12, and other special purpose IPs are
disallowed.

> 3. IDN is allowed, but also in the report

See my note to Rob; I'm fixing that. I misread RFC 5280 section 7.2.

Thanks,
Peter

[Rob Stradling]

On 17/11/15 16:25, Peter Bowen wrote:
<snip>

>> - RFC5280 sections 7.2 and 7.3 do indeed talk about the need for dNSNames,
>> domainComponents, etc, to only contain ASCII data. However, your report
>> also flags Subject CNs with non-ASCII data - AFAICT, this is permitted by
>> both RFC5280 and the BRs. It is common practice to put the "xn--" ASCII
>> string in a dNSName and the UTF-8 string in the Subject CN.
>
> I read 7.2 again and it clearly calls out as only applying to
> domainComponent attributes. I'll rerun with allowance for hostnames
> with u-labels in CNs.

Thanks.

>> - You wanted to check that "public CAs were following the CA/Browser Forum
>> baseline requirements" when issuing certs. However, some of the certs in
>> your report were issued before any of the browsers / audit regimes demanded
>> that public CAs be compliant with the BRs. Furthermore, some of the certs in
>> your report were issued before the BRs even existed.
>
> Yes, I should have been clearer here. The correct description should
> be "determining if the names in unexpired certificates follow the
> current BRs". As you point out, the BRs have changed over time and
> didn't even exist when some of these were issued. That is why I
> included the not before date; those examining the list should
> determine their cutoff date.

My concern is that many folks won't take the step of determining a
sensible cutoff date. (Incidentally, this is why we deliberately only
looked back at the past 1 year's worth of certs in the research we
published last week).

See how quickly even the esteemed Dr Gutmann seemed to be willing to
take your report at face value - "That's still pretty scary, nearly
50,000 names from a who's-who of commercial CAs". ;-)

>> - You wanted to check "server auth certificates issued by public CAs".
>> However, I see some Code Signing Certificates in your report.
>
> I included all certificates that included the serverAuth EKU and all
> those that had no EKU. Can you provide an example of a code signing
> cert in the list so I can figure out why this test failed?

CT knows about 2 certs issued by "COMODO RSA Code Signing CA", and your
report flagged both of them, even though both certs contain the EKU
extension with just the Code Signing OID.

https://crt.sh/?Identity=%25&iCAID=2035

>> I'm pretty optimistic that all of the "anomalies" issued by Comodo's CA
>> system (except for the 8 mentioned in our recent incident report) will be
>> found to fall into these categories, although I haven't done an exhaustive
>> analysis yet. If there are any other "anomalies", they're a bit lost in the
>> noise at present!
>
> I'll rerun the data in a few hours. I also will fix the encoding
> issues; somehow the character encoding got messed up on import to
> Google Sheets.

Great. I tried importing the list into postgres but I couldn't persuade
it to accept the invalid character encodings, so I gave up.

> I will also add a field column to help identify where
> in the certificates the issues are occurring. Hopefully these changes
> will help remove the noise.

Definitely. Thanks!

> Thanks,
> Peter

[Kurt Roeckx]

On Tue, Nov 17, 2015 at 05:40:28PM +0000, Rob Stradling wrote:
>
> Great. I tried importing the list into postgres but I couldn't persuade it
> to accept the invalid character encodings, so I gave up.

When importing data in my postgres database I leave the fields
NULL in case I really can't do anything sensable with it
currently.


Kurt

[Jeremy Rowley]

While interesting, this report is probably going to be used for a lot of misleading statements. There's lots to consider in this:

1) Considering that the 3-year validity cap was a recent requirement, I'm surprised your search only resulted in 50,000 certificates with all of the 5-10 year certificates that were issued.
2) Remember that the BRs were not binding on any CA until adopted by a browser. Mozilla was the first CA to adopt on ~Feb 15 2013. Despite the effective date of the BRs in July 2012, it's hard to say those certificates were not compliant at the time of issuance when the policies weren't required. Although I understand that this data shows compliance of with the current version of the BRs, I won't be too surprised to see the info taken out of context and say the certs were not issued properly.
3) No EKU was a recent CAB Forum debate that didn't have a resolution. They aren't technically covered by the BRs according to some CAs as they aren't intended for use in authenticating servers accessible through the Internet. I tried to fix this issue in the CAB Forum but the discussions and proposed solutions didn't go anywhere because of the RFCs and various jurisdictional requirements. I'd still love to see this remedied in the BRs at some point.
4) Can you explain where in the BRs it prohibits Ipv4 name in the dnsName? It shouldn't go there but there is a good reason for including it in the dnsName. One of the browsers used to choke if you use ipAddress instead of dnsName. (http://www.michaelm.info/blog/?p=1281)

I'm sure there are more concerns, but that's just a few of the initial thoughts I had when looking through the info.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 10:40 AM
To: Peter Bowen
Cc: mozilla-dev-s...@lists.mozilla.org; Peter Gutmann
Subject: Re: [FORGED] Name issues in public certificates

Great. I tried importing the list into postgres but I couldn't persuade it to accept the invalid character encodings, so I gave up.

> I will also add a field column to help identify where in the
> certificates the issues are occurring. Hopefully these changes will
> help remove the noise.

Definitely. Thanks!

> Thanks,
> Peter

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Jeremy Rowley]

Encoding an IP Address in a dNSName is not permitted by the BRs. This is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.

[JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers to work back then? Chrome and IE did not process ipAddress properly.

Jeremy

> Regards,
>
> Richard

>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.o
> rg] On Behalf Of Rob Stradling

> Sent: Tuesday, November 17, 2015 9:32 PM
> To: Peter Gutmann <pgu...@cs.auckland.ac.nz>; Peter Bowen
> <pzb...@gmail.com>; mozilla-dev-s...@lists.mozilla.org

> Subject: Re: [FORGED] Name issues in public certificates
>

> On 17/11/15 08:25, Peter Gutmann wrote:
>> Peter Bowen <pzb...@gmail.com> writes:
>>
>>> There are a couple of rules that may create false positives, so
>>> please don't assume every certificate on the sheet is problematic.
>>

>> That's still pretty scary, nearly 50,000 names from a who's-who of

>> commercial CAs. Yet more evidence that, like the output from the EFF
>> SSL Observatory, we need independent assessment of browser PKI rather
>> than self-certification ("we define ourselves to be in full
>> compliance with everything we need to be compliant with, as far as we can tell").
>>
>> Peter.
>

> Peter (G),
>
> I fully agree that independent assessment is useful, but independent
> assessments need to be assessed too (preferably before the press start
> quoting soundbites! :-) )
>

> Peter (B),
>
> Thanks for doing this report. There are definitely some interesting findings.
> However, I would like to discuss several classes of (what I think are)
> false positives that cover a significant number of the "anomalies" you've found:
>

> - RFC5280 sections 7.2 and 7.3 do indeed talk about the need for
> dNSNames, domainComponents, etc, to only contain ASCII data. However,
> your report also flags Subject CNs with non-ASCII data - AFAICT, this
> is permitted by both
> RFC5280 and the BRs. It is common practice to put the "xn--" ASCII
> string in a dNSName and the UTF-8 string in the Subject CN.
>

> - You wanted to check that "public CAs were following the
> CA/Browser Forum baseline requirements" when issuing certs. However,
> some of the certs in your report were issued before any of the
> browsers / audit regimes demanded that public CAs be compliant with the BRs.
> Furthermore, some of the certs in your report were issued before the
> BRs even existed.
>

> - You wanted to check "server auth certificates issued by public CAs".
> However, I see some Code Signing Certificates in your report.
>

> I'm pretty optimistic that all of the "anomalies" issued by Comodo's
> CA system (except for the 8 mentioned in our recent incident report)
> will be found to fall into these categories, although I haven't done
> an exhaustive analysis yet. If there are any other "anomalies",
> they're a bit lost in the noise at present!
>
>
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.

[Peter Bowen]

On Tue, Nov 17, 2015 at 12:04 AM, Peter Bowen <pzb...@gmail.com> wrote:
> Inspired by Rob Stradling's work
> (https://cabforum.org/pipermail/public/2015-November/006269.html), I
> wrote a quick tool to check that commonNames and Subject Alternative
> Names in server auth certificates issued by public CAs were following
> the CA/Browser Forum baseline requirements.
>
> The resulting report of anomalies is available at
> https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing
>
> The rules are a rather strict interpretation of RFC 5280 and the
> Baseline Requirements. Notably, it will complain if FQDNs are not
> converted to ASCII (as defined in 7.2 and 7.3 of RFC 5280) and will
> complain if there is an IP address flaged as a dNSName in a
> Generalized Name.
>

> There are a couple of rules that may create false positives, so please
> don't assume every certificate on the sheet is problematic.

I've updated the sheet based on the initial feedback. It is now
properly encoded in UTF-8 and allows domain names with u-labels in CN
attributes. It also properly excludes certificates which have an EKU
list that does not include serverAuth.

Please note the following important items:
1) The set of certificates checked includes certificates that were
issued before the Baseline Requirements existed. Some specific
requirements in the Baseline Requirements have effective dates well
after the initial approval of the BRs. Readers need to determine the
appropriate cut off date(s) for their usage of the data.

2) Several rules are not errors but are things that I flagged. These
include the "_onion" and "_special_ipv4" rules.

3) Currently IPv4 addresses in DNS name SAN entries are considered to be errors.

4) The largest issue by far is inclusion of SAN types not allowed by
the Baseline Requirements. According to section 7.1.4.2.1, only
dNSName and iPAddress types of GeneralNames are allowed.

I hope that this is useful data.

Thanks,
Peter

[Rob Stradling]

On 17/11/15 18:27, Jeremy Rowley wrote:
> Encoding an IP Address in a dNSName is not permitted by the BRs. This is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.
> [JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers to work back then? Chrome and IE did not process ipAddress properly.

Jeremy, I don't recall any clause in the BRs that permits CAs to ignore
requirements that they or their customers don't like.

They are not Baseline Suggestions! ;-)

If (whilst the BRs have been in force) there's been a perceived need to
encode IP addresses in dNSName fields, then don't you think that the
correct thing to do would've been to take the matter to CABForum and
seek to update the BRs so that this practice is permitted?

> Jeremy
>
>> Regards,
>>
>> Richard
>>
>> -----Original Message-----
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.o
>> rg] On Behalf Of Rob Stradling
>> Sent: Tuesday, November 17, 2015 9:32 PM
>> To: Peter Gutmann <pgu...@cs.auckland.ac.nz>; Peter Bowen
>> <pzb...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
>> Subject: Re: [FORGED] Name issues in public certificates
>>
>> On 17/11/15 08:25, Peter Gutmann wrote:
>>> Peter Bowen <pzb...@gmail.com> writes:
>>>

>>>> There are a couple of rules that may create false positives, so
>>>> please don't assume every certificate on the sheet is problematic.
>>>

[Jeremy Rowley]

They were until Feb 2013 :)

Sure - let's discuss these issues at the CAB Forum. Based on the spreadsheet, I'm pretty sure lots of CAs would like to re-address the elimination of all SANs except iPAddress and dNSANames.

[Rob Stradling]

On 17/11/15 17:54, Kurt Roeckx wrote:
> On Tue, Nov 17, 2015 at 05:40:28PM +0000, Rob Stradling wrote:
>>

>> Great. I tried importing the list into postgres but I couldn't persuade it
>> to accept the invalid character encodings, so I gave up.
>

> When importing data in my postgres database I leave the fields
> NULL in case I really can't do anything sensable with it
> currently.

I had the same trouble with Peter's updated report, but I've just
figured out how to resolve it. There are ~1000 instances of "\x" in the
.tsv file I exported. After replacing each one with "\\x", postgres
happily imported the data.

[Peter Bowen]

On Tue, Nov 17, 2015 at 2:40 PM, Rob Stradling <rob.st...@comodo.com> wrote:
> On 17/11/15 17:54, Kurt Roeckx wrote:
>>
>> On Tue, Nov 17, 2015 at 05:40:28PM +0000, Rob Stradling wrote:
>>>
>>>
>>> Great. I tried importing the list into postgres but I couldn't persuade
>>> it
>>> to accept the invalid character encodings, so I gave up.
>>
>>
>> When importing data in my postgres database I leave the fields
>> NULL in case I really can't do anything sensable with it
>> currently.
>
>
> I had the same trouble with Peter's updated report, but I've just figured
> out how to resolve it. There are ~1000 instances of "\x" in the .tsv file I
> exported. After replacing each one with "\\x", postgres happily imported
> the data.

I've uploaded the original CSV file to
https://s3-us-west-2.amazonaws.com/pzb-public-files/invalid-dnsname.csv

I suspect it might work better than the CSV -> Google Sheets -> TSV path.

Thanks,
Peter

[Rob Stradling]

On 17/11/15 22:47, Peter Bowen wrote:
<snip>

> I've uploaded the original CSV file to
> https://s3-us-west-2.amazonaws.com/pzb-public-files/invalid-dnsname.csv
>
> I suspect it might work better than the CSV -> Google Sheets -> TSV path.
>
> Thanks,
> Peter

Thanks Peter.

[Peter Bowen]

Based on writing the code to these checks, I think it would be good
for the CAB Forum to consider the following clarifications/changes:

1) for dNSname type GeneralNames, make sure implementers are aware
that the "preferred name synatx" in RFC1034 does not allow a trailing
period on a Domain Name (example.com. is not valid) and are aware that
leading and trailing whitespace is not allowed.

2) For commonName attributes in subject DNs, clarify that they can only contain:
- IPv4 address in dotted-decimal notation (specified as IPv4address
from section 3.2.2 of RFC 3986)
- IPv6 address in coloned-hexadecimal notation (specified as
IPv6address from section 3.2.2 of RFC 3986)
- Fully Qualified Domain Name or Wildcard Domain Name in the
"preferred name syntax" (specified by Section 3.5 of RFC1034 and as
modified by Section 2.1 of RFC1123)
- Fully Qualified Domain Name or Wildcard Domain Name in containing
u-labels (as specified in RFC 5890)

3) Forbid commonName attributes in subject DNs from containing a Fully
Qualified Domain Name or Wildcard Domain Name that contains both one
or more u-labels and one or more a-labels (as specified in RFC 5890).

4) Forbid all IP addresses that are listed in
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
or in http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
except those with global = true.

If the Forum decides to allow an exception to RFC 5280 to permit IP
address strings in dNSName general names, then require the same format
as allowed for common names.

Thanks,
Peter

[Peter Bowen]

Richard,

Please check the updated file I posted. My check to exclude certain
certificates was broken in the first pass but the revised version
properly excludes them.

The content is still at
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing,
but has been updated.

Thanks,
Peter

On Tue, Nov 17, 2015 at 6:07 PM, Richard Wang <ric...@wosign.com> wrote:
> I checked your list that the excel list number are: 6653 -- 6662, 29830 --
> 29841, 30434 -- 30437, they are all Client certificates without serverAuth
> EKU, but listed, please check it, thanks.
>
> The attached certificate is No. 6653, please check its EKU, thanks.
>
>
> Best Regards,

>
> Richard
>
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To: Richard Wang <ric...@wosign.com>
> Cc: Rob Stradling <rob.st...@comodo.com>; Peter Gutmann
> <pgu...@cs.auckland.ac.nz>; mozilla-dev-s...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>

[Rob Stradling]

Peter, yes, let's discuss that list at CABForum.

I would also like to get clarification on if/when the underscore
character may be used in each of the name types. Your report seems to
flag underscores as always prohibited (I think), but I expect that some
CAs would be surprised by that.

> Thanks,
> Peter
>

> On Tue, Nov 17, 2015 at 1:17 PM, Jeremy Rowley
> <jeremy...@digicert.com> wrote:
>> They were until Feb 2013 :)
>>
>> Sure - let's discuss these issues at the CAB Forum. Based on the spreadsheet, I'm pretty sure lots of CAs would like to re-address the elimination of all SANs except iPAddress and dNSANames.
>>
>> -----Original Message-----
>> From: Rob Stradling [mailto:rob.st...@comodo.com]
>> Sent: Tuesday, November 17, 2015 2:12 PM
>> To: Jeremy Rowley
>> Cc: Richard Wang; mozilla-dev-s...@lists.mozilla.org; Peter Bowen; Peter Gutmann

>> Subject: Re: [FORGED] Name issues in public certificates
>>

>> On 17/11/15 18:27, Jeremy Rowley wrote:
>>> Encoding an IP Address in a dNSName is not permitted by the BRs. This is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.
>>> [JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers to work back then? Chrome and IE did not process ipAddress properly.
>>
>> Jeremy, I don't recall any clause in the BRs that permits CAs to ignore requirements that they or their customers don't like.
>>
>> They are not Baseline Suggestions! ;-)
>>
>> If (whilst the BRs have been in force) there's been a perceived need to encode IP addresses in dNSName fields, then don't you think that the correct thing to do would've been to take the matter to CABForum and seek to update the BRs so that this practice is permitted?
>>
>>> Jeremy
>>>

>>>> Regards,
>>>>
>>>> Richard

>>>>
>>>> -----Original Message-----
>>>> From: dev-security-policy
>>>> [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.
>>>> o
>>>> rg] On Behalf Of Rob Stradling
>>>> Sent: Tuesday, November 17, 2015 9:32 PM
>>>> To: Peter Gutmann <pgu...@cs.auckland.ac.nz>; Peter Bowen

>>>> <pzb...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
>>>> Subject: Re: [FORGED] Name issues in public certificates
>>>>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Bowen]

On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> I would also like to get clarification on if/when the underscore character
> may be used in each of the name types. Your report seems to flag
> underscores as always prohibited (I think), but I expect that some CAs would
> be surprised by that.

Here is a set of rules that are functionally equivalent to the ones
I'm using to check dNSNames in GeneralNames:

LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?<!-))"
FQDN = "(#{LABEL}\.)*#{LABEL}"
WILDCARD_DN = "\\*\\.#{FQDN}"
DNSNAME = "(#{FQDN}|#{WILDCARD_DN})"

dNSName =~ /\A#{DNSNAME}\z/

The FQDN rule is based on RFC 5280 section 4.2.1.6, which in turn
references RFCs 1123 and 1034. There is no allowance for underscores
in domain names in these RFCs.

Thanks,
Peter

[Ryan Sleevi]

You've entered a special hell. It is dark and scary. You are likely to be
eaten by a grue.

The world is an awful place. Hostnames, doubly so. A big part of this is
due to how MSFT originally implemented their resolver code, although
arguably it can affect non-MSFT platforms as well, depending on the name
server setup.

Recall that DNS labels are full 8-bit, however, for practical purposes
(read: compatability), it's best to treat them as 7-bit ASCII. This is
somewhat touched upon in 1034 ("By convention, domain names can be stored
with arbitrary case ...") and in 1123 ("The DNS defines domain name syntax
very generally -- a string of labels each containing up to 63 8-bit
octets")

Terminology wise, let's call those "labels". A series of labels,
terminated by the empty label, make up a domain name. One type of domain
name is the host name (c.f. 1034, "For hosts, the mapping depends on the
existing syntax for host names which is a subset of the usual text
representation for domain names"), which corresponds to the A domain
record type (or AAAA, as later modified by the IPv6 specs)

OK, so we're clear so far? Recap is:
label = 0-63 octets
domain name = a series of labels, terminated by an empty label, not to
exceed 255 octets (counting label lengths as well)
host name = a subset of types of domain names, that in DNS corresponds to
the A/AAAA record

Now let's get messier yet still. 1034 introduces the "Preferred Name
Syntax", which is a recommendation for how to encode names. For example,
one part is that it suggests that all labels start with at least one
letter. This is to avoid ambiguity when parsing IPs, since if labels could
be all numeric (10.0.0.1), then it could be ambiguous as to how to parse
as a host name versus an IP address. However, 1123, Section 2.1, relaxed
this to allow the first character to be a digit, on the presumption that
all TLDs would be alpha-numeric.

This latter point wasn't enshrined anywhere, as far as I've been able to
tell, but was practiced by the set of gTLDs at the time and continues to
be practiced by ICANN (thus far).

So, now, the question is, where do the '_' come from?

Two places:
1) The URI spec (RFC 2396) permitted them because it didn't couple a URL
to the underlying name resolution system (DNS), but instead permitted a
variety of name and name resolution schemes. The ABNF from this spec
diverged from 1123, and 3986 tried to bring alignment again, but the
'damage' of permissiveness was done.
2) Microsoft's host resolution API, which supported a variety of name
types (DNS, NetBios, WINS, etc), in which the incoming string was looked
up against a variety of name resolution services. Their DNS resolver
adhered to the '8 bit is good bit' and '7 bit ASCII is good', and thus let
it through.

Further, it's important to consider that _ are valid (domain) names, and
ARE valid (URL host) names, even if they're not valid (DNS host) names.
Consider, for example, SRV names.

You hate everything yet? Because I sure do.

I captured some of these thoughts in
https://code.google.com/p/chromium/issues/detail?id=496472 and
https://code.google.com/p/chromium/issues/detail?id=496468 just because no
browser I've looked at 'does the right thing' and rejects underscores.

I mention all of this to say that I actually find it 'not clear cut' as to
what's expected, and have spent several day long dives into specs and
other implementations to see if there's any common consistency, especially
for https://url.spec.whatwg.org/ . On a pragmatic level, I'd like to be a
hard liner, with being one clear interpretation, but in the real world, I
can't find anyone who consistently followed or implemented that guidance.

[Peter Bowen]

On Wed, Nov 18, 2015 at 10:25 AM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> On Wed, November 18, 2015 8:56 am, Peter Bowen wrote:
>> On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling <rob.st...@comodo.com>
>> wrote:
>> > I would also like to get clarification on if/when the underscore
>> > character
>> > may be used in each of the name types. Your report seems to flag
>> > underscores as always prohibited (I think), but I expect that some CAs
>> > would
>> > be surprised by that.
>>
>> Here is a set of rules that are functionally equivalent to the ones
>> I'm using to check dNSNames in GeneralNames:
>>
>> LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?<!-))"
>> FQDN = "(#{LABEL}\.)*#{LABEL}"
>> WILDCARD_DN = "\\*\\.#{FQDN}"
>> DNSNAME = "(#{FQDN}|#{WILDCARD_DN})"
>>
>> dNSName =~ /\A#{DNSNAME}\z/
>>
>> The FQDN rule is based on RFC 5280 section 4.2.1.6, which in turn
>> references RFCs 1123 and 1034. There is no allowance for underscores
>> in domain names in these RFCs.
>

> You've entered a special hell. It is dark and scary. You are likely to be
> eaten by a grue.
>
> The world is an awful place. Hostnames, doubly so.

[...]

> Now let's get messier yet still. 1034 introduces the "Preferred Name
> Syntax", which is a recommendation for how to encode names. For example,
> one part is that it suggests that all labels start with at least one
> letter. This is to avoid ambiguity when parsing IPs, since if labels could
> be all numeric (10.0.0.1), then it could be ambiguous as to how to parse
> as a host name versus an IP address. However, 1123, Section 2.1, relaxed
> this to allow the first character to be a digit, on the presumption that
> all TLDs would be alpha-numeric.

[...]

> I mention all of this to say that I actually find it 'not clear cut' as to
> what's expected, and have spent several day long dives into specs and
> other implementations to see if there's any common consistency

While I realize that it is not clear cut in many contexts, RFC 5280 is
rather clear cut. The authors clearly wanted to avoid stumbling and
being eaten by a grue, so they wrote:

When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax", as specified by

Section 3.5 of [RFC1034] and as modified by Section 2.1 of

[RFC1123]. Note that while uppercase and lowercase letters are
allowed in domain names, no significance is attached to the case. In
addition, while the string " " is a legal domain name, subjectAltName
extensions with a dNSName of " " MUST NOT be used. Finally, the use
of the DNS representation for Internet mail addresses
(subscriber.example.com instead of subsc...@example.com) MUST NOT
be used; such identities are to be encoded as rfc822Name.

This makes it clear that the "preferred name syntax" is not a
recommendation when it comes to certificates. It is mandatory.

The CA/Browser Forum already has changed the rules for the CAB Forum
X.509 profile to allow dNSName entries to contain "*" which is
contrary to RFC 5280, so maybe the forum should consider other
variations of the rules of 5280.

Thanks,
Peter

[Brian Smith]

On Tue, Nov 17, 2015 at 4:40 PM, Richard Wang <ric...@wosign.com> wrote:

> So WoSign only left IP address issue that we added both IP address and DNS
> Name since some browser have warning for IP address only in SAN.
>

Put the IP addresses in the SAN as an iPAddress and then also put them in
the Subject CN, one CN per IP address. Then all browsers will accept the
certs and they will conform to the baseline requirements (IIUC).

Note that this is Ryan Sleevi's good idea.

Cheers,
Brian

[Brian Smith]

Peter Bowen <pzb...@gmail.com> wrote:

> 2) For commonName attributes in subject DNs, clarify that they can only
> contain:
>
- IPv4 address in dotted-decimal notation (specified as IPv4address
> from section 3.2.2 of RFC 3986)
> - IPv6 address in coloned-hexadecimal notation (specified as
> IPv6address from section 3.2.2 of RFC 3986)
> - Fully Qualified Domain Name or Wildcard Domain Name in the
> "preferred name syntax" (specified by Section 3.5 of RFC1034 and as
> modified by Section 2.1 of RFC1123)
> - Fully Qualified Domain Name or Wildcard Domain Name in containing
> u-labels (as specified in RFC 5890)


> 3) Forbid commonName attributes in subject DNs from containing a Fully
> Qualified Domain Name or Wildcard Domain Name that contains both one
> or more u-labels and one or more a-labels (as specified in RFC 5890).
>

I don't think these rules are necessary, because CAs are already required
to encode all this information in the SAN, and if there is a SAN with a
dNSName and/or iPAddress the browser is required to ignore the subject CNs.
That is, if the certificate a SAN with a dNSName and/or iPAddress entry,
then it doesn't really matter how the CN is encoded as long as it isn't
misleading.

> If the Forum decides to allow an exception to RFC 5280 to permit IP
> address strings in dNSName general names, then require the same format
> as allowed for common names.
>

That should not be done. As I mentioned in my other reply in this thread,
Ryan Sleevi already described a workaround that seems to work very well:
Encode the IP addresses in the SubjectAltName as iPAddress entries, and
then also encode them as (normalized) ASCII dotted/colon-separated text in
the subject CN, using more than one subject CN if there is more than one IP
address.

By the way, I believe that mozilla::pkix will reject all the invalid names
that you found, except it accepts "_" in dNSNames. If you found some names
that mozilla::pkix accepts that you think are invalid, I would love to hear
about that.

Cheers,
Brian
--
https://briansmith.org/

[Peter Bowen]

On Wed, Nov 18, 2015 at 5:43 PM, Brian Smith <br...@briansmith.org> wrote:
> Peter Bowen <pzb...@gmail.com> wrote:
>>
>> 2) For commonName attributes in subject DNs, clarify that they can only
>> contain:
>>
>> - IPv4 address in dotted-decimal notation (specified as IPv4address
>> from section 3.2.2 of RFC 3986)
>> - IPv6 address in coloned-hexadecimal notation (specified as
>> IPv6address from section 3.2.2 of RFC 3986)
>> - Fully Qualified Domain Name or Wildcard Domain Name in the
>> "preferred name syntax" (specified by Section 3.5 of RFC1034 and as
>> modified by Section 2.1 of RFC1123)
>> - Fully Qualified Domain Name or Wildcard Domain Name in containing
>> u-labels (as specified in RFC 5890)
>>
>>
>> 3) Forbid commonName attributes in subject DNs from containing a Fully
>> Qualified Domain Name or Wildcard Domain Name that contains both one
>> or more u-labels and one or more a-labels (as specified in RFC 5890).
>
>
> I don't think these rules are necessary, because CAs are already required to
> encode all this information in the SAN, and if there is a SAN with a dNSName
> and/or iPAddress the browser is required to ignore the subject CNs. That is,
> if the certificate a SAN with a dNSName and/or iPAddress entry, then it
> doesn't really matter how the CN is encoded as long as it isn't misleading.

I'll leave that up to the Forum. I would prefer that we not have
common names with arbitrary data, but if so, so be it.

[Patrick T]

I've found one of the certificates here (*.gov.bn, Symantec issued) seems to contain some NULL characters in the SAN.

https://crt.sh/?serial=331C896050CE23EFAB5CF53237AF093F
and
https://crt.sh/?id=7335256

Wasn't there an issue with spoofing using NULs in certificates several years ago?
Verisign back then claimed this couldn't be done, but the cert is recent.

http://www.symantec.com/connect/blogs/busy-day-black-hat

[Peter Bowen]

On Thu, Nov 19, 2015 at 11:57 AM, Robin Alden <ro...@comodo.com> wrote:
> Peter said..

>> While I realize that it is not clear cut in many contexts, RFC 5280 is
>> rather clear cut. The authors clearly wanted to avoid stumbling and
>> being eaten by a grue, so they wrote:
>>
>> When the subjectAltName extension contains a domain name system
>> label, the domain name MUST be stored in the
>> dNSName (an IA5String).

>> The name MUST be in the "preferred name syntax", as specified by

>> Section 3.5 of [RFC1034] and as modified by Section 2.1 of

>> [RFC1123]. <snip>

>>
>> This makes it clear that the "preferred name syntax" is not a
>> recommendation when it comes to certificates. It is mandatory.
>

> Ah, but the lead-in there is

> "When the subjectAltName extension
> contains a domain name system label,"
>

> weird_place.example.com is not a domain name system label. It is not
> expected to (and likely does not, and maybe could not) resolve to an IP
> address on the public internet.

Yes, reading again I agree that the language there leaves it open that
the dNSName type might not contain a domain name system label. If the
authors truly wanted to avoid the grue, they should have said:

"When the subjectAltName extension contains a dNSName, the dNSName
must contain a domain name." (or domain name system label).

Given that it doesn't, but that that the BRs say "MUST be either a
dNSName containing the Fully‐Qualified Domain Name or an iPAddress
containing the IP address", it is clear we still need to have a valid
FQDN. I'll update my scanner to allow "_" in the labels that are not
registry controlled or in the label that is immediately to the left of
the registry controlled labels. Give me a little while and I'll
upload a revised data set with this fix.

> In practice, the people to whom weird_place.example.com is a useful name
> will be running Microsoft kit which is very happy with an underscore in
> a name. All that matters to them is that weird_place.example.com
> resolves within their environment.
> The CAB Forum BRs can be met in the validation of such a certificate
> providing that ownership or control of example.com is shown in the
> approved methods. The BRs place no requirement on the full name
> weird_place.example.com appearing on the internet or being accessible by
> the CA.

Thanks,
Peter

[Brian Smith]

Peter Bowen <pzb...@gmail.com> wrote:

> Robin Alden <ro...@comodo.com> wrote:
> Given that it doesn't, but that that the BRs say "MUST be either a
> dNSName containing the Fully‐Qualified Domain Name or an iPAddress
> containing the IP address", it is clear we still need to have a valid
> FQDN. I'll update my scanner to allow "_" in the labels that are not
> registry controlled or in the label that is immediately to the left of
> the registry controlled labels. Give me a little while and I'll
> upload a revised data set with this fix.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1136616. In mozilla::pkix,
we had to allow the underscore because of AWS.

[Peter Bowen]

Touche :) It looks like S3 allows underscores but calls out that they
are not DNS compliant
(http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html).
People accessing these buckets should be using the
https://s3.amazonaws.com/$BUCKET/$KEY URL format, not the
https://$BUCKET.s3.amazonaws.com/$KEY URL format. I will talk to the
S3 team about ensuring that all names published in DNS are compliant
with RFC 1123.

That being said, I updated the spreadsheet to allow underscores in
both the CN and dNSName generalName. Please note that the updated
sheet has a slightly different column order. I also added rules to
check for nulls in dNSNames (one hit), unparsable ASN.1 in the
subjectAltName extension (23 hits), and basic validation for
RFC822Names in SANs (even though they are not allowed in by the BRs).

The sheet is available at:
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing

As always, I welcome feedback.

Thanks,
Peter

[Peter Gutmann]

Patrick T <p...@eishundo.com> writes:

>I've found one of the certificates here (*.gov.bn, Symantec issued) seems to
>contain some NULL characters in the SAN.

Wow, you're right:

673 359: SEQUENCE {
677 33: SEQUENCE {
679 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
684 26: OCTET STRING, encapsulates {
686 24: SEQUENCE {
688 8: [2] '*.gov.bn'
698 12: [2] 00 5A 37 00 2A 2E 67 6F 76 2E 62 6E
: }
: }
: }

The tail end of that is *.gov.bn, no idea what the four bytes before that are.

Peter.

[douglas...@gmail.com]

I realize I'm a little late to the game, but I had a question on the maximum length. If I'm reading this correctly, it looks like you applied the max length of 63 to the LABEL. Should it actually be to FQDN and WILDCARD? Is it 63 or 64?

[Kurt Roeckx]

On 2015-11-19 22:19, douglas...@gmail.com wrote:
> I realize I'm a little late to the game, but I had a question on the maximum length. If I'm reading this correctly, it looks like you applied the max length of 63 to the LABEL. Should it actually be to FQDN and WILDCARD? Is it 63 or 64?

The label is limited to 63. I don't think there is an RFC that limits
the total FQDN, but rfc1123 says:

Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.


Kurt

[Peter Bowen]

On Fri, Nov 20, 2015 at 7:32 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On 2015-11-19 22:19, douglas...@gmail.com wrote:
>>

>> I realize I'm a little late to the game, but I had a question on the
>> maximum length. If I'm reading this correctly, it looks like you applied
>> the max length of 63 to the LABEL. Should it actually be to FQDN and
>> WILDCARD? Is it 63 or 64?
>
>

> The label is limited to 63. I don't think there is an RFC that limits the
> total FQDN, but rfc1123 says:
>
> Host software MUST handle host names of up to 63 characters and
> SHOULD handle host names of up to 255 characters.

http://blogs.msdn.com/b/oldnewthing/archive/2012/04/12/10292868.aspx
covers it is more detail. 253 is the length you want to check
according to RFC 1034.

[Kurt Roeckx]

For some reason I missed this earlier in RFC 1034:
labels 63 octets or less

names 255 octets or less

[...]

To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.



Kurt

[douglas...@gmail.com]

Yes, thanks. I had CommonName field in mind and that is limited to 64 characters but SubjectAltName is completely different when it comes to max length (even though they both hold a FQDN).

[Peter Bowen]

On Fri, Nov 20, 2015 at 9:28 AM, <douglas...@gmail.com> wrote:
> Yes, thanks. I had CommonName field in mind and that is limited to 64 characters but SubjectAltName is completely different when it comes to max length (even though they both hold a FQDN).

I had missed that limitation on commonName. I have added a check for
commonName length and updated the spreadsheet. No new GlobalSign
issues :)

[Rick Andrews]

On Wednesday, November 18, 2015 at 5:43:57 PM UTC-8, Brian Smith wrote:

Multiple common names were flagged as an attack vector in Kaminsky's PKI Layer Cake paper at https://securewww.esat.kuleuven.be/cosic/publications/article-1432.pdf. Specifically, the paper said that Firefox respected only the last CN in the DN. We need to be sure that all browsers (mobile too) respect all CNs. And this solution may be risky too because CN is being deprecated.

[Matthias Hunstock]

Am 17.11.2015 um 09:04 schrieb Peter Bowen:

> There are a couple of rules that may create false positives, so please
> don't assume every certificate on the sheet is problematic.

Is it possible that your script doesn't handle IPv6 addresses properly?


Regards

[Matthias Hunstock]

Am 09.12.2015 um 18:46 schrieb Peter Bowen:

> Do you have an example where you think IPv6 addresses are not being
> handled correctly?

Serial 19D70E1B381579 in your document is the example I stumbled upon.

I managed to get the complete cert from the server and cannot see any
issues there.

It is flagged as "_unqualified" though it has a global unicast IPv6
address, beside other SubjectAlternativeNames.


Regards
Matthias

[Peter Bowen]

You are correct. There is a logic bug and it is flagging properly
encoded ipv6 addresses in the SAN as unqualified. There are 9
certificates in CT that have IPv6 addresses.

Apologies for this. I will get the tool updated to ensure that IPv6
addresses do not cause a flag. For now, however, please ignore any
"unqualified" result for a SAN:IP row. This rule should be impossible
to hit for that data type.

Thanks,
Peter

[Matthias Hunstock]

Am 10.12.2015 um 15:47 schrieb Peter Bowen:
> Apologies for this. I will get the tool updated to ensure that IPv6
> addresses do not cause a flag.

Thank you for fixing this!

Matthias

[Richard Wang]

Hi all,

There are still some problems in IP address in certificate.
Yes, we tested it that have the conclusion that all browser support IP address, see below email.

But the test is not full covered all situation, if the certificate common name is a domain and the SAN have IP address like this way:
DNS Name=ims.cn
IP Address=101.199.99.157
IP Address=104.192.110.133
Then only IE11 in Win 10 support, other version IE browser (IE6/7/8/9/10) in Win XP/7/8 don’t support, need to add DNS name.

How to solve this problem? Any suggestion is welcome, thanks.


Best Regards,

Richard


-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Richard Wang
Sent: Wednesday, November 18, 2015 7:55 PM
To: Peter Bowen <pzb...@gmail.com>
Cc: Rob Stradling <rob.st...@comodo.com>; mozilla-dev-s...@lists.mozilla.org; jeremy...@digicert.com; Peter Gutmann <pgu...@cs.auckland.ac.nz>
Subject: RE: [FORGED] Name issues in public certificates

We tested IE6/IE7/IE8 on XP sp3, and IE10/IE11 on Windows 8, all support.
Firefox 3.6.3, 38 - 42, all support.
Chrome 11/45/46 support.
Safari 5.1.7 support.
Android 4.0-5.1 support,
IOS 9.1 support.

It seem no need to modify the BR, CA need to update the PKI system to delete the DNS Name.

Regards,

Richard


-----Original Message-----
From: dev-security-policy

[mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Richard Wang
Sent: Wednesday, November 18, 2015 6:49 PM
To: Peter Bowen <pzb...@gmail.com>
Cc: Rob Stradling <rob.st...@comodo.com>; mozilla-dev-s...@lists.mozilla.org; Peter Gutmann <pgu...@cs.auckland.ac.nz>
Subject: RE: [FORGED] Name issues in public certificates

We tested IE11, Firefox 42, Chrome 45 on Windows 10, all support IP address only now.
So we need to test the old version browsers. I will update soon.

Regards,

Richard

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On

Behalf Of Richard Wang
Sent: Wednesday, November 18, 2015 10:41 AM
To: Peter Bowen <pzb...@gmail.com>
Cc: Rob Stradling <rob.st...@comodo.com>;
mozilla-dev-s...@lists.mozilla.org; Peter Gutmann
<pgu...@cs.auckland.ac.nz>
Subject: RE: [FORGED] Name issues in public certificates

Yes, all Client certificates are removed, thanks.

So WoSign only left IP address issue that we added both IP address and DNS
Name since some browser have warning for IP address only in SAN.

Best Regards,

Richard

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Wednesday, November 18, 2015 10:28 AM
To: Richard Wang <ric...@wosign.com>
Cc: Rob Stradling <rob.st...@comodo.com>;

mozilla-dev-s...@lists.mozilla.org; Peter Gutmann
<pgu...@cs.auckland.ac.nz>
Subject: Re: [FORGED] Name issues in public certificates

Richard,

Please check the updated file I posted. My check to exclude certain
certificates was broken in the first pass but the revised version properly
excludes them.

The content is still at
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing,
but has been updated.

Thanks,
Peter

On Tue, Nov 17, 2015 at 6:07 PM, Richard Wang <ric...@wosign.com> wrote:
> I checked your list that the excel list number are: 6653 -- 6662,
> 29830 -- 29841, 30434 -- 30437, they are all Client certificates
> without serverAuth EKU, but listed, please check it, thanks.
>
> The attached certificate is No. 6653, please check its EKU, thanks.
>
>

> Best Regards,
>
> Richard

>
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To: Richard Wang <ric...@wosign.com>
> Cc: Rob Stradling <rob.st...@comodo.com>; Peter Gutmann
> <pgu...@cs.auckland.ac.nz>;

> mozilla-dev-s...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>

> On Tue, Nov 17, 2015 at 6:12 AM, Richard Wang <ric...@wosign.com> wrote:
>> I also found some mistakes for the list:
>> 1. I see some client certificate in the report that it say the email
>> as common name is wrong;
>
> I filtered for certificates that includes the serverAuth EKU or do not
> include any EKUs. Can you provide an example of a clientAuth
> certificate that was incorrectly included?
>
>> 2. IP address is allowed by BR;
>
> IP addresses are only allowed in the commonName or as IPAddress type
> in the SAN extension. If the rule is _ipv4_not_allowed_here, then
> that means that an IP address was included in a SAN as a DNS Name,
> which is disallowed. I will also fix the IP check to differentiate
> between reserved IPs (as defined in the
> BRs) and special purpose IPs (which are allowed if not reserved). The
> BRs do not clearly state that 192.168.0.0/24, 172.16.0.0/12, and other
> special purpose IPs are disallowed.
>
>> 3. IDN is allowed, but also in the report
>
> See my note to Rob; I'm fixing that. I misread RFC 5280 section 7.2.
>
> Thanks,
> Peter
>