Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Peter Gutmann via dev-security-policy
Matthew Hardeman via dev-security-policy writes: >I merely raise the point that IF the framers of the 20 bytes rule did, in >fact, simultaneously intend that arbitrary SHA-1 hash results should be able >to be stuffed into the serial number field AND

RE: Certificates with invalidly long serial numbers

2017-08-08 Thread Jeremy Rowley via dev-security-policy
24 hours is super short when it's a Saturday morning at 4 am and it’s a European government entity. I agree that is what the policy says now, but, for lower risk items, the policy should change, preferably to at least one business day. -Original Message- From: dev-security-policy

RE: High traffic on this list, and Mozilla root program involvement

2017-08-08 Thread Jeremy Rowley via dev-security-policy
Do you want that added as a new bug for all the issues listed? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham via dev-security-policy Sent: Tuesday, August 8, 2017 10:02 AM To:

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread identrust--- via dev-security-policy
On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote: > “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL > that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is > required to have the plaintext HTTP scheme according to Baseline

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread identrust--- via dev-security-policy
On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy > > wrote: > > > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote: > >> “IdenTrust ACES

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread identrust--- via dev-security-policy
On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy > > wrote: > > > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote: > >> “IdenTrust ACES

SSL.com root inclusion request

2017-08-08 Thread Aaron Wu via dev-security-policy
This request from SSL.com is to include the “SSL.com Root Certification Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV Root Certification Authority RSA”, and “SSL.com EV Root Certification Authority ECC” root certificates, turn on the Email and Websites trust bits for

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Ryan Sleevi via dev-security-policy
On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote: > On 08/08/2017 18:43, Ryan Sleevi wrote: > > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > >> I was not advocating "letting everyone decide". I was advocating that > >> Mozilla show some restraint,

Re: CA Problem Reporting Mechanisms

2017-08-08 Thread Jeremy Rowley via dev-security-policy
+1. CAs should be required to support certificate problem reports sent through a specified email address. It simplifies the process a lot if CAs use at least one common mechanism. > On Aug 8, 2017, at 12:22 PM, Jonathan Rudenberg via dev-security-policy >

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Alex Gaynor via dev-security-policy
It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. Alex On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Jakob Bohm via dev-security-policy
Some people seemed to require 24-hour revocation of these, which I also find possibly excessive. On 08/08/2017 20:28, Alex Gaynor wrote: I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads. The only CAs that have ever had _any_ penalty

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Jakob Bohm via dev-security-policy
On 08/08/2017 19:44, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote: On 08/08/2017 12:54, Nick Lamb wrote: On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: Since the CT made it possible, I have seen an increasing obsession with enforcing every

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Matthew Hardeman via dev-security-policy
It seems this thread has diverged a bit from its stated purpose, the determination of the question of mis-issuance of a set of certificates which have (possibly) longer than allowed serial numbers. I raised a question as to the history of the selection of the 20 bytes limit for serial numbers

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Alex Gaynor via dev-security-policy
I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads. The only CAs that have ever had _any_ penalty applied to them have been for grotesque abuse of the trust vested in them. Alex On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Jakob Bohm via dev-security-policy
On 08/08/2017 18:43, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Ryan Sleevi via dev-security-policy
On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote: > On 08/08/2017 12:54, Nick Lamb wrote: > > On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: > >> Since the CT made it possible, I have seen an increasing obsession with > >> enforcing every little detail of the BRs,

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

2017-08-08 Thread Jonathan Rudenberg via dev-security-policy
> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy > wrote: > > Dear Mozilla Security Policy Community, > > Thanks for the advice about the short serial numbers and apologies for the > delayed response. > > Since 2016, all D-TRUST TLS

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Ryan Sleevi via dev-security-policy
On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > I was not advocating "letting everyone decide". I was advocating that > Mozilla show some restraint, intelligence and common sense in wielding > the new weapons that certlint and crt.sh have given us. > > This shouldn't be race

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Jonathan Rudenberg via dev-security-policy
> On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy > wrote: > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote: >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder >> URL that has a HTTPS

RE: CA Problem Reporting Mechanisms

2017-08-08 Thread Tim Hollebeek via dev-security-policy
See BR 1.5.2. CAs are already required to have contact information in their CPS. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+thollebeek=trustwave@lists.mozilla.org] On Behalf Of David E. Ross via dev-security-policy Sent: Tuesday, August 8,

Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

2017-08-08 Thread Fiedler, Arno via dev-security-policy
Dear Mozilla Security Policy Community, Thanks for the advice about the short serial numbers and apologies for the delayed response. Since 2016, all D-TRUST TLS certificates based on electronic Certificate Requests have a certificate serial number which includes 64 bits of entropy. Between

Re: dNSName containing '/' / low serial number entropy

2017-08-08 Thread Arno Fiedler via dev-security-policy
Dear Mozilla Security Policy Community, Thanks for the advice about the short serial numbers and apologies for the delayed response. Since 2016, all D-TRUST TLS certificates based on electronic Certificate Requests have a certificate serial number which includes 64 bits of entropy. Between

Re: CA Problem Reporting Mechanisms

2017-08-08 Thread Jonathan Rudenberg via dev-security-policy
> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy > wrote: > > On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote: >> >>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy >>> wrote:

Re: CA Problem Reporting Mechanisms

2017-08-08 Thread David E. Ross via dev-security-policy
On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote: > >> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy >> wrote: >> >> On 16/05/17 02:26, userwithuid wrote: >>> After skimming the responses and checking a few CAs, I'm starting to >>>

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Jakob Bohm via dev-security-policy
I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have given us. This shouldn't be race as to who wields the weapon first, forgiving CAs only if they happen to

RE: StartCom cross-signs disclosed by Certinomis

2017-08-08 Thread Inigo Barreira via dev-security-policy
Can this be responded to more directly and comprehensively please? Are there any staff or personnel being shared between WoSign and Startcom? No This includes any staff from (or paid by) Qihoo 360 its subsidiaries, contractors, or affiliates--does anyone do any work (paid or unpaid) for both

Re: StartCom cross-signs disclosed by Certinomis

2017-08-08 Thread urijah--- via dev-security-policy
Can this be responded to more directly and comprehensively please? Are there any staff or personnel being shared between WoSign and Startcom? This includes any staff from (or paid by) Qihoo 360 its subsidiaries, contractors, or affiliates--does anyone do any work (paid or unpaid) for both

AC FNMT Usuarios and anyExtendedKeyUsage

2017-08-08 Thread Jonathan Rudenberg via dev-security-policy
The "AC FNMT Usuarios” intermediate operated by the Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) issues certificates that are not BR-compliant. This was acknowledged during the FNMT root inclusion request discussion and allowed as long as the intermediate "never issues

Re: Miss-issuance: URI in dNSName SAN

2017-08-08 Thread Alex Gaynor via dev-security-policy
Hi all, Following up on this thread, 8 days ago I emailed Camerfirma, I have not heard back from them, nor have they taken any action. What is the appropriate next step here? Alex On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor wrote: > I've been attempting to report a

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Alex Gaynor via dev-security-policy
Luckily we have tools like certlint, which can be run on certificates to catch this stuff! I'd feel very differently if CAs were starting these threads because they'd caught issues with certlint, than the fact that independent researchers are noticing. Alex On Tue, Aug 8, 2017 at 7:52 AM, Jakob

Re: Certificates with invalidly long serial numbers

2017-08-08 Thread Alex Gaynor via dev-security-policy
This methodology of "letting everyone decide which parts of the spec/BRs aren't important" doesn't make sense. If there's something wrong with the spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of the "fetch" specification). Giving each CA unilateral authority to ignore

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Jakob Bohm via dev-security-policy
On 08/08/2017 12:54, Nick Lamb wrote: On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: Since the CT made it possible, I have seen an increasing obsession with enforcing every little detail of the BRs, things that would not only have gone unnoticed, but also been considered

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-08 Thread Nick Lamb via dev-security-policy
On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: > Since the CT made it possible, I have seen an increasing obsession with > enforcing every little detail of the BRs, things that would not only > have gone unnoticed, but also been considered unremarkable before CT. Even if I had no

RE: StartCom cross-signs disclosed by Certinomis

2017-08-08 Thread Inigo Barreira via dev-security-policy
Hi Percy, StartCom Spain exists since september last year. And it was included in the remediation plan set in October last year, but at the time Gerv wrote that email it didn´t exist officially, it took a while to be registered officially in the "equivalent" spanish companies house. The process

RE: StartCom cross-signs disclosed by Certinomis

2017-08-08 Thread Inigo Barreira via dev-security-policy
Hi, In the remediation plan that was published in October there was a chart in which was indicate how the group was going to change, from WoSign management to be under 360 management. I can provide the information again if you wish. StartCom Spain is 100% owned by Startcom UK, which is also 100%

RE: StartCom cross-signs disclosed by Certinomis

2017-08-08 Thread Inigo Barreira via dev-security-policy
Hi, 1.- yes, I said many times that it was not a good decission and of course not the best way to start, but at all times these test certs were under control, lived only for some minutes. Everything was explained in bugzilla #1369359 2.- Those pre-certificates were related to these test