Re: [FORGED] Name issues in public certificates

[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

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 9:32 PM
To: Peter Gutmann ; Peter Bowen
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [FORGED] Name issues in public certificates

On 17/11/15 08:25, Peter Gutmann wrote:

Peter Bowen  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-security-policy@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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Name issues in public certificates

[Richard Wang]

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;
3. IDN is allowed, but also in the report

Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 9:32 PM
To: Peter Gutmann ; Peter Bowen 
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [FORGED] Name issues in public certificates

On 17/11/15 08:25, Peter Gutmann wrote:
> Peter Bowen  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!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Name issues in public certificates

[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=digicert@lists.mozilla.org]
 On Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 10:40 AM
To: Peter Bowen
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Peter Gutmann
Subject: Re: [FORGED] Name issues in public certificates

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

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

RE: [FORGED] Name issues in public certificates

[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=wosign.com@lists.mozilla.o
> rg] On Behalf Of Rob Stradling
> Sent: Tuesday, November 17, 2015 9:32 PM
> To: Peter Gutmann ; Peter Bowen 
> ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>
> On 17/11/15 08:25, Peter Gutmann wrote:
>> Peter Bowen  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-security-policy@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.
___
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: [FORGED] Name issues in public certificates

[Rob Stradling]

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


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


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Kurt Roeckx]

On Tue, Nov 17, 2015 at 05:40:28PM +, 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Peter Bowen]

On Tue, Nov 17, 2015 at 2:40 PM, Rob Stradling  wrote:
> On 17/11/15 17:54, Kurt Roeckx wrote:
>>
>> On Tue, Nov 17, 2015 at 05:40:28PM +, 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Rob Stradling]

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


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.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Rob Stradling]

On 17/11/15 17:54, Kurt Roeckx wrote:

On Tue, Nov 17, 2015 at 05:40:28PM +, 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.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Removed Certs Spreadsheet

[Kathleen Wilson]

All,

We've added a new report, that is automatically generated from Salesforce:

https://wiki.mozilla.org/CA:RemovedCAcerts

Please note the caveat: The Removed Certs Spreadsheet currently only 
lists the cert removals that have happened since September 2014, which 
is when we began using Salesforce to maintain the root store data.


I have an action item to add the data for the certs that were removed 
before we started using Salesforce, so they will show up in the report. 
But I don't know when I'll be able to get to it.


Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[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

On Tue, Nov 17, 2015 at 1:17 PM, Jeremy Rowley
 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.stradl...@comodo.com]
> Sent: Tuesday, November 17, 2015 2:12 PM
> To: Jeremy Rowley
> Cc: Richard Wang; mozilla-dev-security-pol...@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=wosign.com@lists.mozilla.
>>> o
>>> rg] On Behalf Of Rob Stradling
>>> Sent: Tuesday, November 17, 2015 9:32 PM
>>> To: Peter Gutmann ; Peter Bowen
>>> ; mozilla-dev-security-pol...@lists.mozilla.org
>>> Subject: Re: [FORGED] Name issues in public certificates
>>>
>>> On 17/11/15 08:25, Peter Gutmann wrote:
 Peter Bowen  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 

RE: [FORGED] Name issues in public certificates

[Richard Wang]

I think we should update BR for IP address as dNSANames since the browser 
don't support IP address only, but many communication servers need the IP SSL 
certificate.
We will test which browser don't support it.


Best Regards,

Richard

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Wednesday, November 18, 2015 5:17 AM
To: Rob Stradling 
Cc: Richard Wang ;
mozilla-dev-security-pol...@lists.mozilla.org; Peter Bowen
; Peter Gutmann 
Subject: RE: [FORGED] Name issues in public certificates

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.stradl...@comodo.com]
Sent: Tuesday, November 17, 2015 2:12 PM
To: Jeremy Rowley
Cc: Richard Wang; mozilla-dev-security-pol...@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=wosign.com@lists.mozilla.
>> o
>> rg] On Behalf Of Rob Stradling
>> Sent: Tuesday, November 17, 2015 9:32 PM
>> To: Peter Gutmann ; Peter Bowen
>> ; mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: [FORGED] Name issues in public certificates
>>
>> On 17/11/15 08:25, Peter Gutmann wrote:
>>> Peter Bowen  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!

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: [FORGED] Name issues in public certificates

[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  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:pzbo...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To: Richard Wang 
> Cc: Rob Stradling ; Peter Gutmann
> ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>
> On Tue, Nov 17, 2015 at 6:12 AM, 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;
>
> 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
>
> ___
> 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: [FORGED] Name issues in public certificates

[Richard Wang]

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:pzbo...@gmail.com]
Sent: Wednesday, November 18, 2015 12:33 AM
To: Richard Wang 
Cc: Rob Stradling ; Peter Gutmann 
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [FORGED] Name issues in public certificates

On Tue, Nov 17, 2015 at 6:12 AM, 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;

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Name issues in public certificates

[Richard Wang]

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:pzbo...@gmail.com]
Sent: Wednesday, November 18, 2015 10:28 AM
To: Richard Wang 
Cc: Rob Stradling ; 
mozilla-dev-security-pol...@lists.mozilla.org; Peter Gutmann 

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  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:pzbo...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To: Richard Wang 
> Cc: Rob Stradling ; Peter Gutmann
> ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>
> On Tue, Nov 17, 2015 at 6:12 AM, 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;
>
> 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
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Name issues in public certificates

[Peter Gutmann]

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

RE: [FORGED] Name issues in public certificates

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

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Tuesday, November 17, 2015 2:12 PM
To: Jeremy Rowley
Cc: Richard Wang; mozilla-dev-security-pol...@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=wosign.com@lists.mozilla.
>> o
>> rg] On Behalf Of Rob Stradling
>> Sent: Tuesday, November 17, 2015 9:32 PM
>> To: Peter Gutmann ; Peter Bowen 
>> ; mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: [FORGED] Name issues in public certificates
>>
>> On 17/11/15 08:25, Peter Gutmann wrote:
>>> Peter Bowen  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!

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy