Re: Audits for new subCAs

On 23/03/2018 19:34, Wayne Thayer wrote: Recently I've received a few questions about audit requirements for subordinate CAs newly issued from roots in our program. Mozilla policy section 5.3.2 requires these to be disclosed "within a week of certificate creation, and before any such subCA is

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On 21/03/2018 10:43, Ryan Sleevi wrote: On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I think it's reasonable - especially in light of the discussion being had regarding 2.6 and 3.2.2.4/3.2.2.5 - that when there are

Re: TURKTRUST Non-compliance

On 20/03/2018 20:55, Tim Hollebeek wrote: The BRs already cover this. The point is that once a CA stops auditing, there's an issue about ensuring conformance. Actually, they don't. They have an empty placeholder section for wind down procedures. Surely one could blindly apply the full BRs

Re: TURKTRUST Non-compliance

On 20/03/2018 18:49, Ryan Sleevi wrote: On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Are you suggesting that the BRs be modified so a CA that has ceased issuance can obtain a clean audit report without meeting all c

Re: TURKTRUST Non-compliance

On 20/03/2018 17:39, Wayne Thayer wrote: Jakob, On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 17/03/2018 01:23, Wayne Thayer wrote: Note, that if it is reasonably certain/validated that the only activity is maint

Re: TURKTRUST Non-compliance

On 17/03/2018 01:23, Wayne Thayer wrote: TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" root included in the Mozilla program with the 'websites' trust bit enabled (not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1], and 13 unexpired end-entity

Re: Mis-issuance of certificate with https in CN/SAN

On 16/03/2018 05:28, Ben Wilson wrote: This mis-issuance incident was reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857) Here's the incident report: 1.How your CA first became aware of the problem (e.g. via a

Re: Process of including ca root in mozilla

On 09/03/2018 05:28, westmai...@gmail.com wrote: It's bad that 70% of the root certificates in the discussion thread are certificates of governments that are not needed to anyone except these governments. Andrew And the citizens under those governments. And anyone elsewhere checking out

Re: Following up on Trustico: reseller practices and accountability

How about something simple like: (Rephrase terminology etc. as necessary) If a CA has any arrangements with any 3rd parties to act as intermediaries between the subscriber and the CA, while not being the party that operates the normal uses of the private key on the subscribers behalf, the CA

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On 27/02/2018 17:20, Wayne Thayer wrote: I am seeking input on this proposal: Work is underway to allow Firefox add-ons to read certificate information via WebExtensions APIs [1]. It has also been proposed [2] that the WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to

Re: Code signing and malware

On 26/02/2018 21:28, Ryan Sleevi wrote: On Mon, Feb 26, 2018 at 3:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Mon, Feb 26, 2018 at 12:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 2

Re: Code signing and malware

On 26/02/2018 10:27, Kurt Roeckx wrote: I just came across this: https://www.recordedfuture.com/code-signing-certificates/ I think the most important part of it is: "we confirmed with a high degree of certainty that the certificates are created for a specific buyer per request only and are

Re: CA Program for security researchers

On Thu, Feb 22, 2018 at 10:10 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 22/02/2018 22:17, James Burton wrote: There needs to be a program that helps security researchers like myself get free or low cost certificates for research purposes. T

Re: CA Program for security researchers

On 22/02/2018 22:17, James Burton wrote: There needs to be a program that helps security researchers like myself get free or low cost certificates for research purposes. That EV research I did a while ago nearly set me back personally $4,297. James I think there are three main cases and an

Re: DRAFT January 2018 CA Communication

On 26/01/2018 18:11, Wayne Thayer wrote: Based on the feedback we've received, but sticking with the original intent of this communication, I have converted it into a survey. You can find a draft at: https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate

Re: GlobalSign certificate with far-future notBefore

On 24/01/2018 13:54, Ryan Sleevi wrote: On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Wednesday, January 24, 2018 7:00 AM To: Doug Beattie

Re: Updating Root Inclusion Criteria (organizations)

On 22/01/2018 10:47, Gervase Markham wrote: On 19/01/18 13:20, Jakob Bohm wrote: My suggestions are only meant to inspire formal rules written / chosen by module leaders such as you. But the entire point of this discussion is that we are pointing out it's hard to make such rules in the way

Re: TLS-SNI-01 and compliance with BRs

The following discussion is only a sketched out idea and thus does not classify all the 10 blessed methods: One rule that could reasonably be added to the BR or Mozilla requirements for the various methods could be this general safety rule: - Validation methods that check control over a

Re: Updating Root Inclusion Criteria (organizations)

On 19/01/2018 11:09, Gervase Markham wrote: On 19/01/18 01:05, Jakob Bohm wrote: On 18/01/2018 11:01, Gervase Markham wrote: On 17/01/18 19:49, Jakob Bohm wrote: 3. Major vertical CAs for high value business categories that issue    publicly trusted certificates at better than EV level

Re: Updating Root Inclusion Criteria (organizations)

On 18/01/2018 11:01, Gervase Markham wrote: On 17/01/18 19:49, Jakob Bohm wrote: 3. Major vertical CAs for high value business categories that issue   publicly trusted certificates at better than EV level integrity.  For How do you define "major"? And "high value business category"? Major

Re: Updating Root Inclusion Criteria (organizations)

On 17/01/2018 22:51, Peter Bowen wrote: On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: 4. Selected company CAs for a handful of too-bit-to-ignore companies that refuse to use a true public CA. This would currently pr

Re: Updating Root Inclusion Criteria

On 17/01/2018 23:03, Jonathan Rudenberg wrote: On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 17/01/2018 21:14, Jonathan Rudenberg wrote: On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy <dev-securi

Re: Updating Root Inclusion Criteria

On 17/01/2018 21:14, Jonathan Rudenberg wrote: On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 17/01/2018 16:13, Jonathan Rudenberg wrote: On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy <dev-securi

Re: Updating Root Inclusion Criteria (organizations)

As for what CA organizations to include in a future iteration of the Mozilla root store, I would say that there are 4 groups that I (as a browser user) would like to get included and 2 which I would not: 1. Global public CAs that provide certificates to subscribers from all over the world

Re: Updating Root Inclusion Criteria

On 17/01/2018 16:13, Jonathan Rudenberg wrote: 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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

When I wrote my previous reply, I had not yet received Let's encrypt's post in which they announced they would not reenable TLS-SNI-01 globally. So this was written based on Let's encrypt only *temporarily* disabling TLS-SNI-01 as stated in their original post and *allegedly* (according to 3rd

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 11/01/2018 05:38, Ryan Sleevi wrote: On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 11/01/2018 01:08, Ryan Sleevi wrote: On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < dev-securi

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 11/01/2018 01:08, Ryan Sleevi wrote: On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Agree. Hence my suggestion that TLS-SNI-0next use a name under the customer's domain (such as the name used for DNS-01), not a name

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 10/01/2018 18:39, Matthew Hardeman wrote: Here again, I think we have a problem. It's regarded as normal and acceptable at many web host infrastructures to pre-stage sites for domain-labels not yet in use to allow for development and test deployment. Split horizon DNS or other in-browser or

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 10/01/2018 23:53, Matthew Hardeman wrote: On Wed, Jan 10, 2018 at 3:57 PM, Ryan Sleevi wrote: Note that the presumptive discussion re: .well-known has ignored that the Host header requirements are underspecified, thus the fundamental issue still exists for that too. That

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 10/01/2018 16:38, ssimon.g...@gmail.com wrote: On Wednesday, January 10, 2018 at 3:34:51 PM UTC+1, Jakob Bohm wrote: Depending on exactly how the shared web server is misconfigured I don't think the web server is misconfigured: serving a self signed cert for any domain - even one that I

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On 10/01/2018 14:15, Kurt Roeckx wrote: On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote: * Users have the ability to upload certificates for arbitrary names without proving domain control. So a user can always take over the domain of an other user on those

Re: Serial number length

017 18:48, Ryan Sleevi wrote: Or just generate longer serials with random. Which is much simpler. On Fri, Dec 29, 2017 at 11:57 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 29/12/2017 13:55, Nick Lamb wrote: On Fri, 29 Dec 2017 07:24:31 +010

Re: Serial number length

On 29/12/2017 13:55, Nick Lamb wrote: On Fri, 29 Dec 2017 07:24:31 +0100 Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: 3. Or would the elimination in #2 reduce the entropy of such serial numbers to slightly less than 64 bits (since there are less

Serial number length

After looking at some real certificates both in the browser and on crt.sh, I have some followup questions on certificate serial numbers: 1. Do all recently issued certificates have to contain at least 64 bits of randomness in their serial numbers? 2. Is it acceptable for a CA to satisfy this

Re: CA generated keys

On 15/12/2017 22:33, Ryan Hurst wrote: On Tuesday, December 12, 2017 at 1:08:24 PM UTC-8, Jakob Bohm wrote: On 12/12/2017 21:39, Wayne Thayer wrote: On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/12/2017 19:39,

Re: On the value of EV

On 15/12/2017 02:30, Ryan Sleevi wrote: On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 14/12/2017 00:23, Peter Gutmann wrote: Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.or

Re: On the value of EV

On 14/12/2017 00:23, Peter Gutmann wrote: Tim Shirley via dev-security-policy writes: But regardless of which (or neither) is true, the very fact that EV certs are rarely (never?) used on phishing sites There's no need:

Re: On the value of EV

On 13/12/2017 22:40, Matthew Hardeman wrote: On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: Yes. This is the foundation and limit of Web Security. https://en.wikipedia.org/wiki/Same-origin_policy This is what is programatically enforced. Anything else either requires

Re: On the value of EV

On 13/12/2017 20:55, Gervase Markham wrote: On 11/12/17 17:00, Ryan Sleevi wrote: Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my

Re: On the value of EV

On 14/12/2017 17:51, Peter Bachman wrote: @Jakob I was referring to the classical namespaces which have evolved since the 1980s. The NSF pilot project was based on a now obsolete version of X.500, Quipu, that world rooted with participating county directories. While I managed that part of

Re: On the value of EV

On 13/12/2017 18:38, Nick Lamb wrote: On Wed, 13 Dec 2017 12:29:40 +0100 Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: What is *programmatically* enforced is too little for human safety. believing that computers can replace human judgement is a big m

Re: On the value of EV

conducted behavioral experiments (not to be confused with A/B experiments on unwilling participants). On 13/12/2017 13:39, Ryan Sleevi wrote: On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Yes. This is the foundation

Re: On the value of EV

On 12/12/2017 22:51, Ryan Sleevi wrote: On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: What you are writing below, with far too many words is that you think that URLs are the only identities that matter in this

Re: CA generated keys

On 12/12/2017 21:39, Wayne Thayer wrote: On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/12/2017 19:39, Wayne Thayer wrote: The outcome to be avoided is a CA that holds in escrow thousands of private keys used f

Re: On the value of EV

On 12/12/2017 20:04, Ryan Sleevi wrote: On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The overall thing is that the current thread seems to be a major case of throwing the baby out with the bathwater. That is

Re: CA generated keys

On 12/12/2017 19:39, Wayne Thayer wrote: On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I don't know but it's worth talking about. I think the discussion should be "when should this be allowed, and how can it be done

Re: On the value of EV

On 12/12/2017 18:31, Jonathan Rudenberg wrote: On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: A lot of people have posed suggestions for countermeasures so extreme they should not be taken seriously. This includes discont

Re: On the value of EV

On 12/12/2017 18:19, Ryan Sleevi wrote: On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/12/2017 01:08, Adam Caudill wrote: Even if it is, someone filed the paperwork. Court houses have clerks, guards, video c

Re: On the value of EV

On 12/12/2017 01:08, Adam Caudill wrote: Even if it is, someone filed the paperwork. Court houses have clerks, guards, video cameras, etc... It still may present a real physical point from which to bootstrap an investigation. Court houses also have online systems. I think if you read both

Re: Mozilla RSA-PSS policy

On 01/12/2017 17:06, Ryan Sleevi wrote: On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Depending on the prevalence of non-public CAs (not listed in public indexes) based on openssl (this would be a smallish company thin

Re: Mozilla RSA-PSS policy

On 01/12/2017 16:23, Hubert Kario wrote: On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote: On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario wrote: It does feel like again the argument is The CA/EE should say 'I won't do X' so that a client won't accept a signature

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On 28/11/2017 15:53, Nick Lamb wrote: On Tue, 28 Nov 2017 04:26:30 +0100 Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: Nick Lamb, in the message I replied to, clearly suggested as much, and provided a contrived scenario to "prove" that poin

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On 28/11/2017 04:16, Ryan Sleevi wrote: On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 27/11/2017 19:37, Nick Lamb wrote: On Fri, 24 Nov 2017 12:25:40 + Gervase Markham via dev-security-policy <dev-securi

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On 28/11/2017 02:29, Jakob Bohm wrote: On 27/11/2017 19:37, Nick Lamb wrote: On Fri, 24 Nov 2017 12:25:40 + Gervase Markham via dev-security-policy wrote: ... While your scenario below sounds compelling, it is very much a contrived scenario of the

Re: Possible future re-application from WoSign (now WoTrus)

On 27/11/2017 09:38, Danny 吴熠 wrote: Dear Gerv, Kethleen, other community friends, First, thanks for Gerv and Kathleen’s so kind consideration and so great arrangement for this pre-discussion. Second, thanks for the community participants to help us know our problem clearly in the past year,

Re: Possible future re-application from WoSign (now WoTrus)

On 22/11/2017 16:38, Gervase Markham wrote: On 22/11/17 10:54, Jakob Bohm wrote: Some notes about previously discussed items: Mozilla is not suggesting that WoSign has completed all of the steps. The entire point is that we want to have this pre-discussion before they make the effort to do

Re: Possible future re-application from WoSign (now WoTrus)

On 22/11/2017 10:05, Gervase Markham wrote: We understand that WoTrus (WoSign changed their name some months ago) are working towards a re-application to join the Mozilla Root Program. Richard Wang recently asked us to approve a particular auditor as being suitable to audit their operations. In

Re: .tg Certificates Issued by Let's Encrypt

On 14/11/2017 02:23, Kathleen Wilson wrote: On 11/6/17 3:40 AM, Ben Laurie wrote: Since CT is not (yet) compulsory, it seems you probably have to contact all CAs, doesn't it? To close the loop on this... I have added the following to the draft of the November 2017 CA Communication. ~~

Re: ETSI audits not listing audit periods

On 06/11/2017 17:05, m.wiedenho...@tuvit.de wrote: TÜViT as a conformity assessment body would like to add some explanations to clear up some misunderstandings about ETSI auditing. First of all, we would like to give one preliminary remark. ETSI has separated the TSP technical requirements

Re: Incident report: Certificates with error in subject: postalCode

On 02/11/2017 13:27, Nick Lamb wrote: My understanding is that postal codes written in this form are understood (even if not always specifically permitted) by many postal authorities and so this deviation would not be likely to impact deliverability of a snail mail letter sent (for whatever

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

On 16/10/2017 21:01, Matthew Hardeman wrote: The authors of the paper on the weak RSA keys generated by Infineon TPMs and smart cards have published code in multiple languages / platforms that provide for an efficient test for weakness by way of the Infineon TPM bug. Perhaps this should be a

Re: Incident Report format

On 28/09/2017 18:11, Gervase Markham wrote: On 22/09/17 00:12, Ryan Sleevi wrote: Based on the number of reports reviewed recently, I suspect we've got opportunities for improvement, but I'm not quite sure yet what the concrete suggestions on that should look like. A few thoughts below:

Re: Public trust of VISA's CA

On 20/09/2017 09:37, Martin Rublik wrote: On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: https://crt.sh/mozilla-certvalidations?group=version=896972 is a very informative graph for me -- this is the number of validations

Re: FW: StartCom inclusion request: next steps

On 14/09/2017 17:05, Inigo Barreira wrote: All, ... 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 outstanding SSL certs which are valid due to the Certnomis cross- sign.

Re: CAA Certificate Problem Report

On 14/09/2017 01:13, Matthew Hardeman wrote: On Tuesday, September 12, 2017 at 5:36:56 AM UTC-5, Gervase Markham wrote: As the drafter of the section :-), my intent was to make it so that if a site owner were concerned about the possibility that their CAA record or DNS could be spoofed, they

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: Idea for a stricter name constraint interpretation

On 07/09/2017 21:00, Ryan Sleevi wrote: On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: All but one of your suggestions would require the revocation of existing SubCA certificates, essentially invalidating all existin

Re: Idea for a stricter name constraint interpretation

On 01/09/2017 20:07, Ryan Sleevi wrote: On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: ... So, from the get-go with the standards, it was possible to name constrain DNS. Unless you were referencing certificates prior t

Re: Idea for a stricter name constraint interpretation

On 01/09/2017 02:14, Ryan Sleevi wrote: On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 31/08/2017 22:26, Ryan Sleevi wrote: Agreed. But in general, in order to maintain interoperability, there's a process for bu

Re: Idea for a stricter name constraint interpretation

On 31/08/2017 22:26, Ryan Sleevi wrote: On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I am aware that this was the original specification. However like many other parts of PKIX it may not be as good in 20/20 hin

Re: Idea for a stricter name constraint interpretation

On 31/08/2017 21:49, Ryan Sleevi wrote: On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Would it be beneficial to Mozilla in particular and the larger PKI community in general if the following was added to implement

Idea for a stricter name constraint interpretation

Over the past many months, a few situations have arisen where SubCAs intended to be constrained were not constrained according to the rules, because they lacked "exclude all" name constraints for name types they were not supposed to issue at all. Would it be beneficial to Mozilla in particular

Re: Violations of Baseline Requirements 4.9.10

On 31/08/2017 07:24, Peter Miškovič wrote: Hi Paul, we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed it yesterday afternoon. Problem with OCSP response for RootCA will be fixed to the end of next week. They are offline and there is no real possibility to issue a

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 28/08/2017 10:15, Nick Lamb wrote: I think that instead Ryan H is suggesting that (some) CAs are taking advantage of multiple geographically distinct nodes to run the tests from one of the Blessed Methods against an applicant's systems from several places on the Internet at once. This

Re: Certificates with less than 64 bits of entropy

Since QuoVadis has not yet responded, let me point to a few (partial) answers already known from previous messages from QuoVadis or others: On 15/08/2017 14:53, Ryan Sleevi wrote: On Tue, Aug 15, 2017 at 4:53 AM, Stephen Davidson via dev-security-policy < dev-security-policy@lists.mozilla.org>

Re: TrustCor root inclusion request

On 14/08/2017 21:48, Andrew Ayer wrote: On Mon, 14 Aug 2017 20:27:05 +0100 Neil Dunbar via dev-security-policy wrote: Note that TrustCor is capable of removing SHA-1 as a signature hash on OCSP responses, if the community determines it presents risk to

Re: Symantec Update on SubCA Proposal

Your below description raises two questions of general interest (though not of interest to the Mozilla root program): 1. Will DigiCert establish cross-signatures from the old/historic Symantec roots to continuing DigiCert roots and subCAs? 2. Will DigiCert continue those Symantec services

Re: Certificates with invalidly long serial numbers

ship with the customer, perhaps only an email address that can be used to let them know their website is about to go down. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley= digicert.com@lists.mozilla .org] On Behalf Of Jakob Bohm via dev-security-po

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:14, Ryan Sleevi wrote: On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This raises the question if CAs should be responsible for misissued domain names, or if they should be allowed to issue certif

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:00, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: On 10/08/2017 22:22, Jonathan Rudenberg wrote: RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized

Re: Misissued certificates

On 11/08/2017 00:29, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: Can anyone point out a real world X.509 framework that gets confused by a redundant pathlen:0 in a CA:FALSE certificate? (

Re: Certificates with invalidly long serial numbers

r the cost. On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like 36 hours, which is m

Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like 36 hours, which is much shorter than the normal time taken to do proper OV and/or EV validation. I have previously suggested 14 days for live certificates

Re: Certificates with improperly normalized IDNs

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 to punycode. Let’s Encrypt appears to have issued at least three certificates that have at least one dnsName without the

Re: Misissued certificates

On 10/08/2017 20:14, Matthew Hardeman wrote: Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of ev-valid.identrustssl.com It has a normal 2 year validity period. Which again sounds like a certificate administratively created to serve as a test point certificate for the

Re: Certificates with invalidly long serial numbers

(Note: Top posting because Alex did so) FYI: Last night, I posted a proposed very very rough draft overall graduation of revocation periods for various kinds of issues in mailman.1730.1502216764.14894.dev-security-pol...@lists.mozilla.org (Part of this thread). This only received a meaningless

Re: Certificates with invalidly long serial numbers

which are expected to get a longer deadline if the proposed changes go through. For such, maybe post public descriptions, but delay on the formal filing that would start the 24 hour clock. On Aug 8, 2017, at 1:02 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.

Re: Certificates with invalidly long serial numbers

bad for interoperability to have certificates randomly disappear due to someone filing mass-bugs for violations of formalities. Alex On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Some people seemed to require 2

Re: Certificates with invalidly long serial numbers

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 dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 08/08/2017 18:43, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jako

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

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

On 07/08/2017 23:05, Vincent Lynch wrote: Jakob, I don't see what is wrong with Jonathan reporting these issues. The authors and ratifiers of the BRs made the choice to specify these small details. While a minor encoding error is certainly not as alarming as say, issuing an md5 signed

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

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, the OCSP responder URI is required to have the plaintext HTTP scheme according to Baseline Requirements section

Re: Certificates with invalidly long serial numbers

. These practices represent the same fundamental speed/quality trade-off. On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 07/08/2017 18:07, Hanno Böck wrote: On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-se

Re: Certificates with invalidly long serial numbers

On 07/08/2017 16:54, Peter Bowen wrote: On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy wrote: Hello I checked only one but I think they are all the same. The integer value of the serial number is 20 octets, but when encoded into

Re: Certificates with invalidly long serial numbers

On 07/08/2017 18:07, Hanno Böck wrote: On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-security-policy wrote: FWIW - In the case of Telecom Italia, they have a commercial CA product has a bug in it that occasionally causes this issue. They may need

Re: StartCom cross-signs disclosed by Certinomis

On 07/08/2017 11:21, Franck Leroy wrote: Hello I see many reactions that are not in line with the reality because you don’t have all the history on the subject. I’ll try to summarize. Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) and he left this company in

<    1   2   3   4   5   >