Re: CFCA certificate with invalid domain

2019-03-15 Thread Jonathan Rudenberg via dev-security-policy
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: DarkMatter Concerns

2019-03-05 Thread Jonathan Rudenberg via dev-security-policy
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: DarkMatter Concerns

2019-02-26 Thread Jonathan Rudenberg via dev-security-policy
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

2019-02-22 Thread Jonathan Rudenberg via dev-security-policy
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: P-521 Certificates

2019-01-08 Thread Jonathan Rudenberg via dev-security-policy
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: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-18 Thread Jonathan Rudenberg via dev-security-policy
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: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-18 Thread Jonathan Rudenberg via dev-security-policy
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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

2018-04-11 Thread Jonathan Rudenberg via dev-security-policy
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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

2018-04-11 Thread Jonathan Rudenberg via dev-security-policy
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: TunRootCA2 root inclusion request

2018-02-27 Thread Jonathan Rudenberg via dev-security-policy
> 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: TunRootCA2 root inclusion request

2018-02-27 Thread Jonathan Rudenberg via dev-security-policy
> 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

2018-02-27 Thread Jonathan Rudenberg via dev-security-policy
> 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: Public trust of VISA's CA

2018-02-13 Thread Jonathan Rudenberg via dev-security-policy
> 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 < >>

Re: Public trust of VISA's CA

2018-02-13 Thread Jonathan Rudenberg via dev-security-policy
> 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: ccadb.org

2018-01-29 Thread Jonathan Rudenberg via dev-security-policy
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: ccadb.org

2018-01-29 Thread Jonathan Rudenberg via dev-security-policy
> 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: DRAFT January 2018 CA Communication

2018-01-25 Thread Jonathan Rudenberg via dev-security-policy
> On Jan 25, 2018, at 15:34, Wayne Thayer via dev-security-policy > wrote: > > On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg > wrote: > >> This is a great improvement. I think we should also ask that any CAs using >> these

Re: DRAFT January 2018 CA Communication

2018-01-25 Thread Jonathan Rudenberg via dev-security-policy
> 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: DRAFT January 2018 CA Communication

2018-01-24 Thread Jonathan Rudenberg via dev-security-policy
> 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: DRAFT January 2018 CA Communication

2018-01-24 Thread Jonathan Rudenberg via dev-security-policy
> 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,

GlobalSign certificate with far-future notBefore

2018-01-23 Thread Jonathan Rudenberg via dev-security-policy
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: Updating Root Inclusion Criteria

2018-01-18 Thread Jonathan Rudenberg via dev-security-policy
> 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: Updating Root Inclusion Criteria

2018-01-17 Thread Jonathan Rudenberg via dev-security-policy
> 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: Updating Root Inclusion Criteria

2018-01-17 Thread Jonathan Rudenberg via dev-security-policy
> 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

2018-01-17 Thread Jonathan Rudenberg via dev-security-policy
> 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: DYMO Root CA installed by Label Printing Software

2018-01-09 Thread Jonathan Rudenberg via dev-security-policy
> 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: DYMO Root CA installed by Label Printing Software

2018-01-09 Thread Jonathan Rudenberg via dev-security-policy
> 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: On the value of EV

2017-12-12 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-12-11 Thread Jonathan Rudenberg via dev-security-policy
> 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: StartCom inclusion request: next steps

2017-09-14 Thread Jonathan Rudenberg via dev-security-policy
> 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: CAA Certificate Problem Report

2017-09-11 Thread Jonathan Rudenberg via dev-security-policy
> 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: CAA Certificate Problem Report

2017-09-11 Thread Jonathan Rudenberg via dev-security-policy
> 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: CAA Certificate Problem Report

2017-09-11 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-09-09 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-09-09 Thread Jonathan Rudenberg via dev-security-policy
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: Violations of Baseline Requirements 4.9.10

2017-09-08 Thread Jonathan Rudenberg via dev-security-policy
> 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

Misissuance response status update

2017-08-18 Thread Jonathan Rudenberg via dev-security-policy
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: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

2017-08-18 Thread Jonathan Rudenberg via dev-security-policy
+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: Bugzilla Bugs re CA issuance of non-compliant certs

2017-08-17 Thread Jonathan Rudenberg via dev-security-policy
> 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)

2017-08-17 Thread Jonathan Rudenberg via dev-security-policy
> 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: Miss-issuance: URI in dNSName SAN

2017-08-17 Thread Jonathan Rudenberg via dev-security-policy
> 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: New undisclosed Camerfirma intermediates

2017-08-17 Thread Jonathan Rudenberg via dev-security-policy
> 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: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-16 Thread Jonathan Rudenberg via dev-security-policy
> 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)

2017-08-16 Thread Jonathan Rudenberg via dev-security-policy
> 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

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

2017-08-16 Thread Jonathan Rudenberg via dev-security-policy
> 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: Bad characters in dNSNames

2017-08-16 Thread Jonathan Rudenberg via dev-security-policy
> 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

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

2017-08-15 Thread Jonathan Rudenberg via dev-security-policy
> 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: Bugzilla Bugs re CA issuance of non-compliant certs

2017-08-15 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-08-15 Thread Jonathan Rudenberg via dev-security-policy
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

2017-08-15 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-08-15 Thread Jonathan Rudenberg via dev-security-policy
> 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

New undisclosed Camerfirma intermediates

2017-08-14 Thread Jonathan Rudenberg via dev-security-policy
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: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

2017-08-14 Thread Jonathan Rudenberg via dev-security-policy
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

More certificates with invalid dnsNames

2017-08-12 Thread Jonathan Rudenberg via dev-security-policy
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

Certificates with reserved IP addresses

2017-08-12 Thread Jonathan Rudenberg via dev-security-policy
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

Re: Misissued certificates

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> 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: Certificates with improperly normalized IDNs

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> 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

Certificates with improperly normalized IDNs

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
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 common names not present in their SANs

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> 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

Re: Certificates with less than 64 bits of entropy

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> 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

Certificates with less than 64 bits of entropy

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
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

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

2017-08-10 Thread Jonathan Rudenberg via dev-security-policy
> 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

Re: Certificates with metadata-only subject fields

2017-08-09 Thread Jonathan Rudenberg via dev-security-policy
> 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: Certificates with metadata-only subject fields

2017-08-09 Thread Jonathan Rudenberg via dev-security-policy
> 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,

Certificates with metadata-only subject fields

2017-08-09 Thread Jonathan Rudenberg via dev-security-policy
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: 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 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 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:

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

2017-08-07 Thread Jonathan Rudenberg via dev-security-policy
> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-07 Thread Jonathan Rudenberg via dev-security-policy
> 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,

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

2017-08-07 Thread Jonathan Rudenberg via dev-security-policy
> 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

Certificates issued with HTTPS OCSP responder URL (IdenTrust)

2017-08-07 Thread Jonathan Rudenberg via dev-security-policy
“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:

Certificates with invalidly long serial numbers

2017-08-05 Thread Jonathan Rudenberg via dev-security-policy
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

English translation for Certinomis root CP/CPS?

2017-08-04 Thread Jonathan Rudenberg via dev-security-policy
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

Re: StartCom cross-signs disclosed by Certinomis

2017-08-03 Thread Jonathan Rudenberg via dev-security-policy
> 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: StartCom cross-signs disclosed by Certinomis

2017-08-03 Thread Jonathan Rudenberg via dev-security-policy
> 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: Certificate with invalid CN and dnsName issued by certSIGN

2017-08-02 Thread Jonathan Rudenberg via dev-security-policy
> 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

Certificate with invalid CN and dnsName issued by certSIGN

2017-08-02 Thread Jonathan Rudenberg via dev-security-policy
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

Re: Intermediates missing audit disclosures (Firmaprofesional)

2017-08-02 Thread Jonathan Rudenberg via dev-security-policy
> 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

Intermediates missing audit disclosures (Firmaprofesional and Swisscom)

2017-08-02 Thread Jonathan Rudenberg via dev-security-policy
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

Undisclosed Taiwan GRCA intermediates

2017-08-02 Thread Jonathan Rudenberg via dev-security-policy
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 -

Re: TunRootCA2 root inclusion request

2017-07-29 Thread Jonathan Rudenberg via dev-security-policy
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

2017-07-29 Thread Jonathan Rudenberg via dev-security-policy
> 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: Final Decision by Google on Symantec

2017-07-28 Thread Jonathan Rudenberg via dev-security-policy
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-17 Thread Jonathan Rudenberg via dev-security-policy
> 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

Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-17 Thread Jonathan Rudenberg via dev-security-policy
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):

More improperly disclosed intermediates

2017-07-16 Thread Jonathan Rudenberg via dev-security-policy
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: -

Re: WoSign new system passed Cure 53 system security audit

2017-07-11 Thread Jonathan Rudenberg via dev-security-policy
> 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

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

2017-06-21 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-06-20 Thread Jonathan Rudenberg via dev-security-policy
> 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: Unknown Intermediates

2017-06-16 Thread Jonathan Rudenberg via dev-security-policy
> 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: New undisclosed intermediates

2017-06-12 Thread Jonathan Rudenberg via dev-security-policy
> 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: New undisclosed intermediates

2017-06-08 Thread Jonathan Rudenberg via dev-security-policy
> 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

2017-06-07 Thread Jonathan Rudenberg via dev-security-policy
> 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: New undisclosed intermediates

2017-06-07 Thread Jonathan Rudenberg via dev-security-policy
> 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: Symantec: Update

2017-05-11 Thread Jonathan Rudenberg via dev-security-policy
> 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