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

Am Mittwoch, 19. Juli 2017 00:26:16 UTC+2 schrieb Charles Reiss: > https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL > Class 3 CA 1 2009 containing the DNS SAN > 'www.lbv-gis.brandenburg.de/lbvagszit' (containing a '/') with a > notBefore in April 2017. > Regarding this

Re: PROCERT issues

I believe it's important to consider more than just the issues themselves, and to look at a CA's response to the issues. In the past weeks, we've done a lot of really fantastic work to push CAs on publishing more comprehensive post-mortems, and several CAs have distinguished themselves with timely

Re: Violations of Baseline Requirements 4.9.10

I'm going to file the Bugzilla Bugs for each of these CAs, as follows. == Bug Summary: : Non-BR-Compliant OCSP Responders Bug Description: Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here:

Re: PROCERT issues

On 07/09/17 22:27, Ryan Sleevi wrote: > Do you have an anticipated time period for discussion? That is, what > represents a time for which PROCERT may submit feedback to have it > considered, and at what point you will consider discussion closed? I don't want to place a hard limit on it because

Re: Certigna Root Renewal Request

> This request from the Dhimyotis/Certigna is to include the > SHA-256 ‘Certigna Root CA’ certificate and turn on the > Websites and Email trust bits. This root certificate will > eventually replace the SHA-1 ‘Certigna’ root certificate > that was included via Bugzilla #393166. > ... > The

RE: StartCom communication

Andrew et al, Just to inform that we have upgraded the EJBCA release to 6.9.0 in production this early morning and the CAA checking is working fine, as showed in the EJBCA´s logs. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy

Re: PROCERT issues

On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 17:17, Gervase Markham wrote: > >> Mozilla has decided that there is sufficient concern about the >> activities and operations of the CA "PROCERT" to collect together

Re: TunRootCA2 root inclusion request

Hello, I started reading your CP/CPS and I noticed that you do not use the standard CA/B Forum terminology. Is this on purpose? Is it just a translation issue? Furthermore, I believe that the English Root CA CP/CPS should be added to the bug, I can only find the translation of the SSL SubCA

Re: Violations of Baseline Requirements 4.9.10

Bugs filed… > > AS Sertifitseerimiskeskuse (SK) > Bug #1398233 > > Autoridad de Certificacion Firmaprofesional > Bug #1398240 > > CA Disig a.s. (Fixed as of 2017-08-31) > Bug #1398242 > > certSIGN (partially resolved) > Bug #1398243 > > Consorci Administració Oberta de Catalunya

Re: SHA-1 OCSP responder certificates

On 07/09/17 00:41, Ben Wilson wrote: > We immediately contacted the operators of the issuing CAs and > requested that they replace their OCSP responder certificates with > ones signed with SHA2, and most have done so. However, in drafting > this post I reviewed the Baseline Requirements, section

Re: PROCERT issues

On 07/09/2017 17:17, Gervase Markham wrote: Mozilla has decided that there is sufficient concern about the activities and operations of the CA "PROCERT" to collect together our list of current concerns. That list can be found here: https://wiki.mozilla.org/CA:PROCERT_Issues Note that this list

Re: Violations of Baseline Requirements 4.9.10

> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy > wrote: > >> I have updated the list again to note the additional responders fixed (in >> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly >> less enormous I've

Re: CAs not compliant with CAA CP/CPS requirement

Hey Andrew, we are checking CAA records at time of issuance. The CPS update should publish today. > On Sep 8, 2017, at 1:25 PM, Andrew Ayer via dev-security-policy > wrote: > > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's

CAs not compliant with CAA CP/CPS requirement

Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not resolve, Japan tends to use the .NE.jp suffix, not .net.jp . Therefore shouldn't these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do indeed resolve. On this subject, I am curious as to why it appears a lot of CA's do not

Re: CAs not compliant with CAA CP/CPS requirement

On Fri, Sep 8, 2017 at 12:24 PM, Andrew Ayer via dev-security-policy wrote: > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's Certificate > Policy and/or Certification Practice Statement (section 4.1 for CAs > still conforming to

RE: CAs not compliant with CAA CP/CPS requirement

Hi Andrew, I'm not certain how to update the previous Mozilla response with respect to CAA, but we added the following as authorized CAA records: Digicert.com *.digicert Digicert.net.jp Cybertrust.net.jp I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't seem anything

Re: Certigna Root Renewal Request

Thanks Kathleen, I have briefly inspected this BR Self Assessment document. Nothing terrifying leaped out at me that would lead me to ask that Mozilla deny the renewal, however I did find things worth mentioning here. The only listed 3.2.2.4 method is 3.2.2.4.5, Domain Authorization Document.

Re: Violations of Baseline Requirements 4.9.10

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy (dev-security-policy@lists.mozilla.org) wrote: Bugs filed… ~ Thanks, Kathleen Thank you very much Kathleen! If I receive additional responses I will update the bugs directly. -Paul

RE: CAs not compliant with CAA CP/CPS requirement

Those are typos. See section 4.2.1 of our CPS posted here: https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Samuel Pinder via

RE: Violations of Baseline Requirements 4.9.10

Hi Paul, In case you're not on the distribution for the DigiCert bug for this, here is my recent post. https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c2 Cheers, Ben -Original Message- From: dev-security-policy

RE: CAs not compliant with CAA CP/CPS requirement

Responding from my personal account but I can confirm that Google Trust Services does check CAA and our policy was updated earlier today to reflect that. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org