Re: TunRootCA2 root inclusion request

For reference, I’ve added crt.sh links for the replacement certificates below. > On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy > wrote: > > https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; > notAfter March

Re: TunRootCA2 root inclusion request

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy > wrote: > > ==> The CA proceeded to notify the end entity of the certificate > https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new > certificate is issued by

Re: StartCom cross-signs disclosed by Certinomis

> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy > wrote: > > For those which are not revoked are due to use different curves (P-384, > P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB > Forum and there´s no

Re: StartCom cross-signs disclosed by Certinomis

> On Aug 3, 2017, at 12:26, Kathleen Wilson via dev-security-policy > wrote: > > All, > > I have conflicting opinions about this situation: > > On the one hand, I want to see better behavior, and am inclinded to add these > two intermediate certs to

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy > wrote: > > Feedback will be appreciated on the following draft for the Bugzilla Bugs > that I will be filing for the problems listed below. I think we should ask for the CAs to

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy > wrote: > > I would note that any CA which does not or has not promptly revoked these > within 24 hours of contact should, at a minimum, contact all root programs > that they participate in

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 15:37, Kathleen Wilson via dev-security-policy > wrote: > > ** Common Name not in SAN > https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ > It is not clear to me if I need to add this item to the

Re: Bugzilla Bugs re CA issuance of non-compliant certs

tificate. > Thank you for letting us know of this issue. > > Regards > Adriano Santoni > Actalis > > > > > Inviato dal mio dispositivo Samsung > > > ---- Messaggio originale > Da: Jonathan Rudenberg via dev-security-policy > <

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy > wrote: > > Feedback will be appreciated on the following draft for the Bugzilla Bugs > that I will be filing for the problems listed below. It would be useful to know when and

Re: Bad characters in dNSNames

> On Aug 16, 2017, at 11:37, Amus via dev-security-policy > wrote: > > What's wrong with the two Well's Fargo certs? I don't see any invalid > characters in them. https://crt.sh/?opt=cablint=19558707 https://crt.sh/?opt=cablint=11382596 Both have

New undisclosed Camerfirma intermediates

Two intermediates issued by AC Camerfirma that are not disclosed in the CCADB were logged today: - https://crt.sh/?sha256=201c0617cc3310c7f29fcbe46b57459bc6786a8ba2753018eb27c1e800168a2e=mozilladisclosure (issued on 2017-05-25) -

Re: Certificates with less than 64 bits of entropy

> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > QuoVadis (560) >Siemens Issuing CA Internet Server 2016 (560) > > D-TRUST (224) >D-TRUST SSL Class 3 CA 1 2009 (178) >D-T

Re: Certificates with common names not present in their SANs

> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy > wrote: > > Hi all, > > 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always > be an element from the SAN. > > Here are 62 certs, from a variety of CAs which

Certificates with improperly normalized IDNs

RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized Domain Names are normalized before encoding to punycode. Let’s Encrypt appears to have issued at least three certificates that have at least one dnsName without the proper Unicode normalization applied.

Re: Certificates with improperly normalized IDNs

> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy > wrote: > > On 10/08/2017 22:22, Jonathan Rudenberg wrote: >> RFC 5280 section 7.2 and the associated IDNA RFC requires that >> Internationalized Domain Names are normalized before encoding

Re: Misissued certificates

> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy > wrote: > > Can anyone point out a real world X.509 framework that gets confused by > a redundant pathlen:0 in a CA:FALSE certificate? (Merely to assess the > seriousness of the issue,

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

> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy > wrote: > > Hello Jonathan, > > the certificate has 64 bits of entropy in the "DNqualifier" field instead of > the serial number field. > > Since 2012 we used this way of adding

Certificates with less than 64 bits of entropy

Baseline Requirements section 7.1 says: > Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate > serial numbers greater than zero (0) containing at least 64 bits of output > from a CSPRNG. There are 1027 unexpired unrevoked certificates known to CT with a notBefore date

Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from containing IANA reserved IP addresses and any certificates containing them should have been revoked by 2016-10-01. There are seven unexpired unrevoked certificates that are known to CT and trusted by NSS containing reserved

More certificates with invalid dnsNames

I’ve found 54 additional unexpired unrevoked certificates that are known to CT and trusted by NSS containing dnsNames that are invalid. The errors include invalid characters, internal names, and wildcards in the wrong position. The full list is here: https://misissued.com/batch/8/ There are a

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

Hi Arno and Martin, > On Aug 14, 2017, at 11:44, Arno Fiedler wrote: > > Dear Forum, > > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at least > 64 bits of entropy in the serial number. > > Since 01-12-2016 D-TRUST TLS certificates requested

Certificate with invalid dnsName issued from Baltimore intermediate

This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which chains up to a Baltimore CyberTrust root, contains an invalid dnsName of “www.intesasanpaolovita..biz” (note the two dots):

Re: Certificate with invalid dnsName issued from Baltimore intermediate

> On Jul 17, 2017, at 15:27, Nick Lamb via dev-security-policy > wrote: > > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote: >> Thank you for bringing this to our attention. We have contacted Intesa >> Sanpaolo regarding this error and have

Re: WoSign new system passed Cure 53 system security audit

> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via dev-security-policy > wrote: > > On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote: >> >> Please note this email topic is just for releasing the news that WoSign new >> system passed the

More improperly disclosed intermediates

There are several intermediates on the dashboard (https://crt.sh/mozilla-disclosures) that have been incorrectly disclosed and have not been brought up on this list yet: a) One intermediate issued by SECOM is undisclosed: -

English translation for Certinomis root CP/CPS?

The Common CCADB Policy states: > CAs must provide English versions of any Certificate Policy, Certification > Practice Statement and Audit documents which are not originally in English, > with version numbers matching the document they are a translation of. The page at

Certificates with invalidly long serial numbers

RFC 5280 section 4.1.2.2 says: > Conforming CAs MUST NOT use serialNumber values longer than 20 octets. There are two CAs that appear to misissue certificates with serial numbers that are longer than 20 octets on an ongoing basis: - Certinomis - TI Trust Technologies (chains up to a

Re: Final Decision by Google on Symantec

> On Jul 28, 2017, at 09:34, Alex Gaynor via dev-security-policy > wrote: > > Frankly I was surprised to see Chromium reverse course on this -- they have > a history of aggressive leadership in their handling of CA failures, it's a > little disappointing

Re: CA Problem Reporting Mechanisms

> 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 >> wonder: Wouldn't it be easier to just add another mandatory

Re: Certificate with invalid CN and dnsName issued by certSIGN

> On Aug 2, 2017, at 12:28, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > This certificate, issued on July 27 by certSIGN, has an invalid common name > of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note

Re: Intermediates missing audit disclosures (Firmaprofesional)

> On Aug 2, 2017, at 12:02, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > There are still three intermediates (one issued by Firmaprofesional and two > issued by Swisscom) that are missing audit disclosures in the CCA

Undisclosed Taiwan GRCA intermediates

Two intermediates were issued by the Taiwan Government Root Certification Authority two weeks ago and have not been disclosed in CCADB: - https://crt.sh/?sha256=a423a33493b31953226df96477627dbd056756704211001b6161fb5f8299dc3a -

Intermediates missing audit disclosures (Firmaprofesional and Swisscom)

There are still three intermediates (one issued by Firmaprofesional and two issued by Swisscom) that are missing audit disclosures in the CCADB and do not have a pending OneCRL revocation: - https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b (see

Certificate with invalid CN and dnsName issued by certSIGN

This certificate, issued on July 27 by certSIGN, has an invalid common name of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading space): https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint

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

Certificates with metadata-only subject fields

Baseline Requirements section 7.1.4.2.2(j) says: > All other optional attributes, when present within the subject field, MUST > contain information that has been verified by the CA. Optional attributes > MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, > and/or any

Re: Certificates with metadata-only subject fields

> On Aug 9, 2017, at 17:50, Peter Bowen wrote: > > The point of certlint was to help identify issues. While I appreciate > it getting broad usage, I don't think pushing for revocation of every > certificate that trips any of the Error level checks is productive. I agree,

Re: Certificates with metadata-only subject fields

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy > wrote: > > On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote: >> >>> On Aug 9, 2017, at 17:50, Peter Bowen wrote: >>> >>> The point of certlint was to help identify

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

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

> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy > wrote: > > On 07/08/2017 22:47, 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,

Certificates issued with HTTPS OCSP responder URL (IdenTrust)

“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 Requirements section 7.1.2.2(c). Here’s the list of certificates:

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

> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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 respond

Re: Bugzilla Bugs re CA issuance of non-compliant certs

> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy > wrote: > > Bugs filed... Hi Kathleen, It looks like a bug was not created for GoDaddy about these certificates with invalid dnsNames, containing a space at the beginning of the

Re: O=U.S. Government for non-USG entity (IdenTrust)

> On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > After looking into this more, I’ve found that the majority of certificates > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA

Re: O=U.S. Government for non-USG entity (IdenTrust)

> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy > wrote: > > On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote: >> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote: >>> IdenTrust is fully

Re: O=U.S. Government for non-USG entity (IdenTrust)

> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > I looked through the CT logs and found 15 more unexpired unrevoked > certificates that are trusted by NSS and appear to have the same inaccurat

Misissuance response status update

For those who aren’t following Bugzilla closely, here’s a quick update on where things are with the large batch of misissuance bugs that was filed this week. Most CAs have provided an initial response, and many have finished their initial incident reviews and provided details. Only two CAs

Re: New undisclosed Camerfirma intermediates

> On Aug 16, 2017, at 23:35, Aaron Wu via dev-security-policy > wrote: > > Hi Jonathan, > > Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two > intermediate certs has been disclosed in CCADB now. One of these intermediates is

Re: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

+mdsp > On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote: > > Hi Jonathan > You are right, we are going to look into this, taken into account that the > same serial number should be in the real certificate. > > Regards > > El jueves, 17 de agosto de 2017, 19:54:31 (UTC+2), Jonathan

Re: Miss-issuance: URI in dNSName SAN

> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy > wrote: > > https://crt.sh/?id=112929021=cablint > is a precertificate. You can see the CT Precertificate Poison critical > extention. The serial number of this certificate should

Re: Symantec: Update

> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy > wrote: > > I would appreciate people's comments on the details of the current draft. I don’t think that this proposal goes far enough. Symantec has demonstrated that they have no

Re: New undisclosed intermediates

> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy > wrote: > > I don't believe that disclosure of root certificates is the responsibility > of a CA that has cross-certified a key. For instance, the CCADB interface > talks in terms of

Re: New undisclosed intermediates

> On Jun 8, 2017, at 05:17, Gervase Markham via dev-security-policy > wrote: > > On 08/06/17 00:42, Jonathan Rudenberg wrote: >> Yet another batch of undisclosed intermediates has shown up in CT: > > Like, seriously? Another one appeared this weekend:

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

> On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy > wrote: > > Apparently, in at least one case, the certificate was issued directly(!) to > localhost by Symantec. > > https://news.ycombinator.com/item?id=14598262 > >

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy > wrote: > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via >> dev-security-policy wrote: >>> If you should

Re: New undisclosed intermediates

> On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy > wrote: > > Happy Monday! > > Another week, another set of intermediate certs that have shown up in CT > without having been properly disclosed: >

Re: New undisclosed intermediates

> On Jun 7, 2017, at 21:56, Matthew Hardeman via dev-security-policy > wrote: > > On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote: > >> Yet another batch of undisclosed intermediates has shown up in CT: >> >> - >>

Re: Unknown Intermediates

> On Jun 16, 2017, at 05:00, Rob Stradling via dev-security-policy > wrote: > > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote: >> Hello, I was crawling the pkcs7 blobs in public pdf files and found some >> intermediate certificates that

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy > wrote: > > That seems like very poor logic and justification. > > Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for > literally years now, perhaps it's worth asking

Re: StartCom inclusion request: next steps

> On Sep 14, 2017, at 04:49, Gervase Markham via dev-security-policy > wrote: > > We should add the existing Certnomis cross-signs to OneCRL to revoke > all the existing certificates. As of 10th August (now a month ago) > StartCom said they have 5

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: CAA Certificate Problem Report

> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > wrote: > > In all three of these cases, the "domain's zone does not have a DNSSEC > validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS, > and CAA records types for each zone

Re: CAA Certificate Problem Report

For reference, here is the relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398428 > On Sep 9, 2017, at 05:21, Jeremy Rowley via dev-security-policy > wrote: > > big.basic.caatestsuite.com > > [JR] We only check CAA records with UDP to keep

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy > wrote: > > For a little more context, the idea is that we can speed up the CAA check for > all customers while working with those who have DNSSEC to make sure they > aren't killing

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >&g

Re: O=U.S. Government for non-USG entity (IdenTrust)

> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy > wrote: > > Hello, In reference to 3)"Certificates that appear to be intended as client > certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for > the Mozilla Root

Re: On the value of EV

> On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy > wrote: > > A lot of people have posed suggestions for countermeasures so extreme > they should not be taken seriously. This includes discontinuing EV, I don’t think that removing the EV

Re: On the value of EV

> On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy > wrote: > > > It turns out that the CA/Browser Validation working group is currently > looking into how to address these issues, in order to tighten up validation > in these cases.

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote: > 2. Performing a scan of current CAA records for the domain names we have > issued for in the past 90 days, specifically looking for tags in CAA > records with non-lowercase characters. We’ll examine such instances on a >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Oops, I missed item 1, disregard :) On Fri, May 18, 2018, at 13:45, Jonathan Rudenberg via dev-security-policy wrote: > On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote: > > 2. Performing a scan of current CAA records for the domain names we have > > issued

Re: DYMO Root CA installed by Label Printing Software

> On Jan 9, 2018, at 18:42, Peter Gutmann via dev-security-policy > wrote: > > Ryan Sleevi writes: > >> Of course, if that doesn’t tickle your fancy, there are other ways that are >> supported that you may not have heard about - for

Re: DYMO Root CA installed by Label Printing Software

> On Jan 9, 2018, at 19:31, Peter Gutmann via dev-security-policy > wrote: > > Jonathan Rudenberg writes: > >> For communicating with other machines, the correct thing to do is to issue a >> unique certificate for each device from

Re: Updating Root Inclusion Criteria

> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy > wrote: > > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the right > rules for inclusion were. > > So I decided to approach this from a different

Re: Updating Root Inclusion Criteria

> On Jan 18, 2018, at 08:53, Ryan Sleevi wrote: > > If Mozilla was committed to an equitable set of criteria for both incumbents > and newcomers, then one natural consequence of this is that all incumbents > should be required to rotate their keys to new roots, created under

Re: DRAFT January 2018 CA Communication

> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy > wrote: > > 2. On 19-December, significant concerns were raised about the reliability > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > [3] Since then,

Re: DRAFT January 2018 CA Communication

> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy > wrote: > > We could still choose to set that date in our own policy if the ballot were > to fail. The reasoning behind that date has been discussed on the > CA/Browser Forum lists. I

Re: Updating Root Inclusion Criteria

> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy > wrote: > > On 17/01/2018 16:13, Jonathan Rudenberg wrote: >>> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy >>> wrote: >>> >>> Hi

Re: Updating Root Inclusion Criteria

> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy > wrote: > > On 17/01/2018 21:14, Jonathan Rudenberg wrote: >>> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy >>> wrote: >>> >>> On

Re: DRAFT January 2018 CA Communication

> On Jan 25, 2018, at 13:09, Wayne Thayer via dev-security-policy > wrote: > > Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an > explanation of the new method 12 is too much detail for this message, and > it can be found in the

Re: ccadb.org

> On Jan 29, 2018, at 19:48, James Burton via dev-security-policy > wrote: > > I was doing research on the ccadb.org site and was surprised to find that > the site is running only in HTTP and is not using HTTPS. There is already a bug about this:

Re: ccadb.org

Hrm, I didn’t realize it had been restricted. The gist is that bug is closed as incomplete as of three months ago and there is a new bug that I don’t have access to: https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 > On Jan 29, 2018, at 20:02, James Burton wrote: > > Hi

Re: Public trust of VISA's CA

> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy > wrote: > > In the light of this, I believe it is reasonable to discuss the question > of whether Visa's PKI (and, specifically, the VISA eCommerce Root, > https://crt.sh/?id=896972 ,

Re: Public trust of VISA's CA

> On Feb 13, 2018, at 19:16, Wayne Thayer via dev-security-policy > wrote: > > On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg > wrote: > >> >>> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy < >>

GlobalSign certificate with far-future notBefore

A certificate issued by GlobalSign showed up in CT today with a notBefore date of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of ~1129 days (more than three years). https://crt.sh/?id=311477948=zlint CA/B Forum ballot 193 modified the Baseline Requirements to set a

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Wed, Apr 11, 2018, at 14:48, Matthew Hardeman via dev-security-policy wrote: > Additionally, I think it's fair to say that I'm aghast that another CA > (who by their inclusion in the Mozilla root program has agreed to stay > abreast of developments on this list) has issued for the exact same

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy wrote: > It was injudicious of a CA to issue another certificate in this name for > this entity after the already well documented controversy. Did they just > not care that it would invite trouble or did they not know that

Re: TunRootCA2 root inclusion request

> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy > wrote: > > This request has been in public discussion for more than 6 months, so I > would like to make a decision soon. If you have comments or concerns with > this request, please post

Re: TunRootCA2 root inclusion request

> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >

Re: TunRootCA2 root inclusion request

> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com> > wrote: > >> >>> On Feb 27, 2018, at 16:35, Jonath

Re: P-521 Certificates

On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > (Posting in a personal capacity as I am no longer employed by Trustwave) > > Mozilla Root Store Policy section 5.1 > (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > >

Re: DarkMatter Concerns

On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote: > G’day Folks, > > DarkMatter CEO (Karim Sabbagh), has provided an official response to > Mozilla on the recent media article about the UAE that referenced > security and intelligence matters. Per Wayne’s request to

Re: DarkMatter Concerns

On Fri, Feb 22, 2019, at 16:21, Wayne Thayer via dev-security-policy wrote: > Despite the lack of > direct evidence of misissuance by DarkMatter, this may be a time when we > should use our discretion to act in the interest of individuals who rely on > our root store. It's worth noting that

Re: DarkMatter Concerns

Hi Scott, On Tue, Mar 5, 2019, at 09:02, Scott Rea via dev-security-policy wrote: > > • DM has resolved all technical and policy issues raised in the UAE and > DM Roots submission process on Mozilla list: see > https://bugzilla.mozilla.org/show_bug.cgi?id=1427262 > > • Since the

Re: CFCA certificate with invalid domain

On Fri, Mar 15, 2019, at 10:58, bstephens822--- via dev-security-policy wrote: > On Wednesday, February 27, 2019 at 10:28:00 AM UTC-5, > michel.le...@gmail.com wrote: > > Hello, > > > > I noticed this certificate > > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an > > invalid

Re: Certinomis Issues

On Tue, May 7, 2019, at 19:48, Wayne Thayer via dev-security-policy wrote: >2. > >Constrain it to use for gouv.fr domains in an upcoming Firefox release. > > > While there are only a few thousand unexpired TLS certificates (the root is > not trusted for email) known to chain to this

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

On Fri, Aug 16, 2019, at 07:56, Doug Beattie via dev-security-policy wrote: > Peter, > > I'm not claiming that EV reduces phishing globally, just for those sites > that use them. Do you have a chart that breaks down phishing attacks by SSL > certificate type? > > Here is some research that

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote: > and > both took advantage of weaknesses in two > government registries to create actual dummy companies with misleading > names, then trying to get

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

On Mon, Aug 26, 2019, at 20:44, Jakob Bohm via dev-security-policy wrote: > On 26/08/2019 21:49, Jonathan Rudenberg wrote: > > On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote: > >> and > >> both

  1   2   >