SSL.com root inclusion request

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

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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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)

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: High traffic on this list, and Mozilla root program involvement

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)

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: StartCom cross-signs disclosed by Certinomis

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

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

RE: StartCom cross-signs disclosed by Certinomis

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: Certificates with invalidly long serial numbers

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

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 with invalidly long serial numbers

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: CA Problem Reporting Mechanisms

+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

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 issued with HTTPS OCSP responder URL (IdenTrust)

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

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 with invalidly long serial numbers

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 issued with HTTPS OCSP responder URL (IdenTrust)

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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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)

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: Miss-issuance: URI in dNSName SAN

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 with invalidly long serial numbers

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

AC FNMT Usuarios and anyExtendedKeyUsage

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: StartCom cross-signs disclosed by Certinomis

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: Certificates with invalidly long serial numbers

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

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

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

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

> 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

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 with invalidly long serial numbers

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

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,

Re: CA Problem Reporting Mechanisms

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: CA Problem Reporting Mechanisms

> 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: dNSName containing '/' / low serial number entropy

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

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

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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

> 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