COVID-19 and CA Operational Status

CAs, Please can you give a brief statement regarding these questions below: a) What’s your operational status at this time? b) Do you expect in the next six months to maintain an adequate operational status? c) If the worst case scenario does happen, what have you planned to maintain

Re: COVID-19 and CA Operational Status

23, 2020 at 3:13 PM Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> CAs, >> >> Please can you give a brief statement regarding these questions below: >> >> a) What’s your operational status at this time? >> >>

Re: Terms and Conditions that use technical measures to make it difficult to change CAs

A customer should able have the choice to change their CA provider without threats of revocation by the CA. It’s definitely an abuse of the revocation function. I do understand terms and conditions are in normal circumstances legally binding once signed by a customer but this practice is abuse of

Re: EJBCA performs incorrect calculation of validities

Mike, How do you plan to stop similar issues from occurring in future? Thank you Burton On Wed, 28 Oct 2020, 10:55 Mike Kushner via dev-security-policy, < dev-security-policy@lists.mozilla.org> wrote: > Hi all, > > We were alerted to the fact that EJBCA does not calculate certificate and >

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

Let's Encrypt hasn't done anything wrong here. Let's Encrypt has issued the certificate according to the BR requirements and their own policies. Every domain should be allowed to have a certificate regardless of intent. CAs must not be allowed to act as judges. Remember, all server certificates

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

I stand by the comments I made earlier and it's the correct terminology. A domain should have a certificate regardless of intent by the user. CAs are not the police and shouldn't act as one. CAs do have to follow policies if the certificate is used in illegal activities, misissued, etc but no CA

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

I'm not going to answer the question because it's not relevant to discussion. On Thu, Aug 13, 2020 at 6:57 PM Paul Walsh wrote: > Let me try this. Let’s say a report of child abuse is put forward to a > hosting provider, should they ignore it because they “are not the police”? > Should

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

Please don't speculate on my opinion just because I won't answer the question. That's unprofessional. So act professional! You know it makes sense! On Thu, Aug 13, 2020 at 8:04 PM Paul Walsh wrote: > Exactly what I thought - you’re either unable to answer the question > honestly, or you simply

Intermediate common name ambiguous naming

The common name of the Let's Encrypt R3 intermediate certificate ( https://crt.sh/?id=3479778542) is in my opinion short and ambiguous. It doesn't have any information in common name that can identify the operator of the CA "Let's Encrypt" which can cause confusion who is running the CA. The

Re: Intermediate common name ambiguous naming

r me is the lack of uniqueness of the intermediate with the "R3" naming on it's own. Burton On Fri, 11 Dec 2020, 13:51 Ryan Sleevi, wrote: > > > On Fri, Dec 11, 2020 at 5:51 AM Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> The comm

Re: Summary of Camerfirma's Compliance Issues

It doesn't look great to the community when a CA that is under investigation for serious compliance issues asks for more time to provide detailed answers. Also you said 'accurate answers' ? Were the answers you were going to post today inaccurate in some way? Burton On Tue, Dec 15, 2020 at 6:13

Re: Intermediate common name ambiguous naming

Ryan, Please could you expand a little more on this? "*Ideally, users would most benefit from simply having a random value in the DN (no details, period) for both roots *and* intermediates, as this metadata both can and should be addressed by CCADB"* Burton On Fri, 11 Dec 2020, 16:49 Ryan

Root Store Policy Suggestion

Hello, The Mozilla root store policy should include a section that sets out time limit periods in numbered stages for non-compliance CA discussions. That way everything is fair, can't be disputed and everyone knows when the discussion of the non-compliance CA will conclude. Then the decision from

Re: Root Store Policy Suggestion

On Thu, Jan 28, 2021 at 7:33 PM Ryan Sleevi wrote: > > > On Thu, Jan 28, 2021 at 1:32 PM Burton wrote: > >> Hi Ryan, >> >> The answer to your questions. >> >> A remediation plan is only useful in cases of slight CA non-compliance to >> the rules set forth by the root store policy. >> >> A

Re: Root Store Policy Suggestion

Hi Ryan, I included the remediation plan in the proposal because a CA will mostly always include a remediation plan when they reach the stage of serious non-compliance investigation by root store policy owners. The first remediation plan is always a draft version as it's updated as the discussion

Re: Root Store Policy Suggestion

Hi Ryan, These are good questions! I'll get back to you tomorrow with the answers to your questions. I want to research and give you the right information. Thank you Burton On Wed, Jan 27, 2021 at 7:54 PM Ryan Sleevi wrote: > > > On Wed, Jan 27, 2021 at 2:45 PM Burton wrote: > >> I included

Re: Mozilla's Response to Camerfirma's Compliance Issues

Hi Ben, The CA has been given chance after chance to improve after incident after incident but failed to do so. The remediation plan is a doorstop plan for the CA to wedge the door open to remain in the Mozilla root store but it's time to face the inevitable conclusion and the door must close on

Patch immediately LPE vulnerability in sudo

If you haven't heard already there is a LPE vulnerability in sudo and must be patched immediately. Details here: https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit Thank you Burton

Re: Root Store Policy Suggestion

Hi Ryan, The answer to your questions. A remediation plan is only useful in cases of slight CA non-compliance to the rules set forth by the root store policy. A remediation plans in cases of slight CA non-compliance provides assurance of CA commitment to compliance. A CA under investigation of

CloudFlare Issuing SHA-1 SSL Certificates

CloudFlare has been issuing SHA-1 SSL Certificates from CloudFlare Inc Compatibility CA-3 which is BR violation. See: https://crt.sh/?CN=%25=34007 Thank you James Burton ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: FW: StartCom inclusion request: next steps

On Friday, September 15, 2017 at 12:30:00 PM UTC+1, James Burton wrote: > On Friday, September 15, 2017 at 10:56:11 AM UTC+1, Inigo Barreira wrote: > > > > > > > Those tests were done to check the CT behaviour, there was any other > > > testing of the new systems, just for the CT. Those certs

Re: FW: StartCom inclusion request: next steps

On Friday, September 15, 2017 at 10:56:11 AM UTC+1, Inigo Barreira wrote: > > > > > Those tests were done to check the CT behaviour, there was any other > > testing of the new systems, just for the CT. Those certs were under control > > all > > the time and were lived for some minutes because

Re: FW: StartCom inclusion request: next steps

> Those tests were done to check the CT behaviour, there was any other testing > of the new systems, just for the CT. Those certs were under control all the > time and were lived for some minutes because were revoked inmediately after > checking the certs were logged correctly in the CTs. It´s

Re: StartCom inclusion request: next steps

On Monday, September 18, 2017 at 11:38:57 AM UTC+1, Inigo Barreira wrote: > > > > I want to give you some words from one of the "community side" (this is a > > personal opinion and may vary from other opinions inside the community). > > > > Trust is not something that you get, it is something

Re: DigiCert-Symantec Announcement

Hi Jeremy, Is DigiCert planning on continuing selling DV certificates after the transition? As DigiCert has previously been vocal on the fact that the drawbacks of issuing DV certificates outweigh the benefits as stated here: https://www.digicert.com/dv-ssl-certificate.htm. If DigiCert is

Re: On the value of EV

EV is on borrowed time and deprecating EV is the most logical viable solution right now and brings us one step forward in vanishing the old broken web security frameworks of the past. Now that both me and Ian have demonstrated the fundamental issues with EV and the way its displayed in the UI,

Re: Disallowed company name

This company only cost £10. £6 for the incorporation. £4 for sending in NE01 form to Companies House. On Mon, 4 Jun 2018 at 08:58, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Punctuation differences are not enough to register a name in the us, or at >

Disallowed company name

I posted this also on the CAB Forum validation mailing list but I think it's worthy of discussion on both lists. I recently incorporated the company named ";", see: https://beta.companieshouse.gov.uk/company/11363219. This company compiles with the both the "Companies Act 2006" and "The Company,

Re: Disallowed company name

Hi Jeremy, In the UK it would be class as “same as” and therefore wouldn’t be allowed to be incorporated. You can see this in the links: Companies Act 2006: https://www.legislation.gov.uk/ukpga/2006/46/part/5/chapter/3 The Company, Limited Liability Partnership and Business (Names and Trading

Re: Disallowed company name

I've spoke with a few UK banks about a opening bank account for ";" and they are happy to proceed. James Burton On Fri, Jun 1, 2018 at 11:58 PM Matthew Hardeman wrote: > > > On Thu, May 31, 2018 at 8:38 PM, Peter Gutmann > wrote: > >> >> >Banks, trade vendors, etc, tend to reject accounts

Retirement of RSA-2048

Approximate date of retirement of RSA-2048? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

You really should set up a emergency conference call with all members of the CAB Forums and talk about these issues with chair. If you and other members feel that the answers are not satisfactory then you can vote to remove the Chair for dereliction of duty and place the sub-Chair in charge of the

Re: ccadb.org

Hi Jonathan, I haven't got the required permission to access bug 1376996. Thank you, James On Tue, Jan 30, 2018 at 12:57 AM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > > > On Jan 29, 2018, at 19:48, James Burton via dev-security-policy < > dev-security-pol

ccadb.org

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. Now, I understand that GitHub pages don't support HTTPS for custom domains but you could always use CloudFlare for HTTPS support in the meantime until GitHub enables

RE: Misissuance/non-compliance remediation timelines

The idea of a grading system being used to judge CAs compliance will be a total disaster. We should instead be focusing our efforts on more transparency. James -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jb=0.me...@lists.mozilla.org] On Behalf Of

Re: CA Program for security researchers

They tried charging the card the amount the day after the certificate was issued but the bank fraud department called me about the transaction and I refused it because it was invalid as it was within the trial period and it was clearly stipulated that I was only going to get charged after the 30

Re: CA Program for security researchers

I didn't put this in the article because it's not relevant as an attacker wouldn't care nonetheless. James On Thu, Feb 22, 2018 at 9:29 PM, James Burton wrote: > They tried charging the card the amount the day after the certificate was > issued but the bank fraud department

CA Program for security researchers

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 ___ dev-security-policy mailing list

Re: CA Program for security researchers

It doesn't take that long for a CAs to do vetting checks for OV and EV certificates when everything is handed to them on a plate. Breaking CAs vetting procedures is not too hard. The key here is that security research shouldn't cost the researcher thousands to prove a valid point. They should be

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

Here is another example of cross-country company name collision. Recently, I incorporated to the company named "X Corporation" in the United Kingdom. If someone incorporated the exactly same name in the US. The only difference between mine and the other persons company in the EV indicator is the 2

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

Both mine and Ian's demonstrations never harmed or deceived anyone as they were proof of concept. The EV certs were properly validated to the EV guidelines. Both companies are legitimate. So what's the issue? None. On Thu, Apr 12, 2018 at 8:05 PM, Eric Mill via dev-security-policy <

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

Judges must follow the law to the letter and must not let personal feelings influence their decision. The same rules apply to CAs. Every company who passes the EV guidelines has the right to have an EV cert and CAs must be impartial even if that cert might cause harm. If the CA doesn't like it

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

We both work in the security space and yes, usually blocking a proof of concept is good practice but in this situation I feel that revoking this cert was heavy handed and unnecessary. The probability of Ian using the EV certs for deceptive purposes was extremely low. There are tons more ways of

Re: Following up on Trustico: reseller practices and accountability

Currently, resellers are allowed to submit CSRs on behalf of their customers and as we've seen this is open to abuse. Maybe it's time to stop this practice and restrict submission of CSRs to CA portals only. On Mon, Mar 5, 2018 at 12:51 PM, okaphone.elektronika--- via dev-security-policy

Re: Following up on Trustico: reseller practices and accountability

which they > generate CSRs for users, and then users take that generated CSR to the CA? > What role are you suggesting that the CA has to play in policing 'how' the > CSR was generated - since a CSR is-a CSR is-a CSR? > > On Mon, Mar 5, 2018 at 8:26 AM, James Burton via dev-security-pol

Re: Google Trust Services Root Inclusion Request

Richard, Your conduct is totally unacceptable and won’t be tolerated. You must read the forum rules regarding etiquette. Also I suggest you apologise to Ryan. James On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Richard,

Re: Underscore characters

On Thu, Dec 27, 2018 at 9:00 PM Ryan Sleevi wrote: > I'm not really sure I understand this response at all. I'm hoping you can > clarify. > > On Thu, Dec 27, 2018 at 3:45 PM James Burton wrote: > >> For a CA to intentionally state that they are going to violate the BR >> requirements means that

Re: Underscore characters

For a CA to intentionally state that they are going to violate the BR requirements means that that CA is under immense pressure to comply with demands or face retribution. The severity inflicted on a CA by intentionally violating the BR requirements can be severe. Rolling a dice of chance. Why

Re: Use cases of publicly-trusted certificates

The main reason that publicly trusted certificates are used by organizations for all infrastructure (internal and external) is that it's far cheaper than building and maintaining an internal PKI. On Thu, Dec 27, 2018 at 4:14 PM Jakob Bohm via dev-security-policy <

Re: Initial Incident Report: Issuance of certificates with 63 bit serial number

Hi Fotis, You need to file this as a bugzilla bug. Thank you, Burton On Sun, 10 Mar 2019 at 18:34, Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > SSL.com has been following the recent discussions at > mozilla.dev.security.policy regarding the behavior

Re: DarkMatter Concerns

Benjamin, There is one theme in all of your responses and it's perfectly clear that you feel strongly that this discussion as a whole is an attack not only on DarkMatter's operations but on the United Arab Emirates sovereignty right to able to have a root included in the Mozilla root store and

Re: DarkMatter Concerns

Benjamin, There is one theme in all of your responses and it's perfectly clear that you feel strongly that this discussion as a whole is an attack not only on DarkMatter's operations but on the United Arab Emirates sovereignty right to able to have a root included in the Mozilla root store and

Re: DarkMatter Concerns

I mean country location of the individual doesn't matter. They could be for example be using a VPN to connect to Google Cloud instance and get a certificate that way. Thank you, Burton On Thu, Mar 7, 2019 at 4:53 PM James Burton wrote: > Let's Encrypt issues domain validation certificates and

Re: DarkMatter Concerns

I'm talking about someone from a restricted country using a undocumented domain name to obtain a Let's Encrypt certificate and there is nothing that can be done about it. We can't predict the future. Thank you, Burton On Thu, Mar 7, 2019 at 5:23 PM Matthew Hardeman wrote: > > On Thu, Mar 7,

Re: DarkMatter Concerns

Let's Encrypt issues domain validation certificates and anyone with a suitable domain name (e.g. .com, .net, .org ) can get one of these certificates just by proving control over the domain by using the DNS or " /.well-known/pki-validation" directory as stated in the CAB Forum baseline

Re: DarkMatter Concerns

Let's be realistic, anyone can obtain a domain validated certificate from Let's Encrypt and there is nothing really we can do to prevent this from happening. Methods exist. Thank you, Burton On Thu, Mar 7, 2019 at 4:59 PM Matthew Hardeman wrote: > > On Thu, Mar 7, 2019 at 10:54 AM James

Re: A modest proposal for a better BR 7.1

Matt's right, you need to discussion this on the CAB Forum. Burton On Sat, Mar 9, 2019 at 9:10 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Mar 08, 2019 at 08:43:49PM -0600, Matthew Hardeman via > dev-security-policy wrote: > > I know this

Open Source CA Software

Let's Encrypt CA software 'Boulder' is open source for everyone to browse and check for issues. All other CAs should follow the Let's Encrypt lead and open source their own CA software for everyone to browse and check for issues. We might have found the serial number issue sooner. Thank you,

Re: Open Source CA Software

in the future. Thank you, Burton On Thu, Mar 14, 2019 at 10:57 PM Ryan Sleevi wrote: > > > On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Let's Encrypt CA software 'Boulder' is open source for ever

Re: EJBCA defaulting to 63 bit serial numbers

What concerns me overall in this discussion is the fact that some CAs thought it was completely acceptable to barely scrape through to meet the most basic minimum of requirements. I hope these CAs have a better security posture and are not operating at the minimum. Thank you, Burton On Sat, Mar

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

My understanding of the days before EV was that the CAs themselves made up the validation requirements for DV and because of this there was an uneven validation requirements across the industry. EV was the first document created to solve this and standardise validation requirements for a

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

If one compares the first EV specification with the current EV specification one will notice that the EV specification hasn't changed that much during its lifetime. The issues presented during the last years though research have been known about since the first adoption of the EV specification. If

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

Jakob, Before I touch on your comments, I wanted to point out that I am fairly well known in the CA industry even back then and that fact might have tainted the results sightly because I am treated some what differently to other orders as the validation staff look more carefully at the

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

Companies House ( http://resources.companieshouse.gov.uk/serviceInformation.shtml#compInfo) says "We carry out basic checks on documents received to make sure that they have been fully completed and signed, but we do not have the statutory power or capability to verify the accuracy of the

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

Resend again to fix spelling errors and add extra details The correct way to vet a UK company would be to: 1. The CA checks Companies House to check if the company is incorporated. 2. The CA sends a letter with verification code to the company address listed on Companies House. 3. The CA requests

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

Kirk, I know you are really passionate about extended validation and it does come across in your correspondences on this forum and the CAB Forum but sometimes our passion or frustration leads us to divulge private information which shouldn't have been released into the public domain. Before you

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

These so called "extended" validation vetting checks on companies for extended validation certificates are supposed to provide the consumer on the website with an high level of assurance that the company has been properly validated but the fact is that these so called "extended" validation vetting

Re: [FORGED] Re: Firefox removes UI for site identity

Extended validation was introduced at a time when mostly everyone browsed the internet using low/medium resolution large screen devices that provided the room for an extended validation style visual security indicator . Everything has moved on and purchases are made on small screen devices that

Re: [FORGED] Firefox removes UI for site identity

> > [PW] Phil knows more about the intent so I’ll defer to his response at the > end of this thread. I would like to add that computer screens bigger than > mobile devices aren’t going away. So focusing only on mobile isn’t a good > idea. > > Thanks for the constructive conversation James, finally

Re: [FORGED] Firefox removes UI for site identity

Hi Paul, I take the view that the articles on the CA Security Council website are a form of marketing gimmick with no value whatsoever. Thank you Burton On Tue, Oct 29, 2019 at 5:55 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Nick, > > > On Oct