RE: Suspicious test.com Cert Issued By GlobalSign

Company Foo was a GlobalSign "test" account which we set up to verify proper issuance. > -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Monday, February 13, 2017 8:57 AM > To: Doug Beattie ; mozilla-dev-security- >

RE: GlobalSign BR violation

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Nick > Lamb via dev-security-policy > > I have a question: These certificates appear to be not only forbidden by the > BRs > but also

RE: Next CA Communication

Kathleen, Can you explain how policy 2.4 applies to existing CAs with respect to being Technically Constrained? This is my understanding: - Under policy 2.3 a CA that is technically constrained with EKU set to only secure email but without name constraints was considered out of scope of the

RE: GlobalSign BR violation

Hi Gerv, Here is the incident report for this reported issue. Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Sent: Thursday, March 16,

RE: DigiCert-Symantec Announcement

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Jeremy Rowley via dev-security-policy > Sent: Wednesday, August 2, 2017 10:54 PM > To: Peter Kurrasch ;

Validation of Domains for secure email certificates

Gerv, Mozilla Policy 2.5 states this: For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in

RE: Validation of Domains for secure email certificates

Hi Gerv, OK, I see your point. We'll come up with what we think are reasonable methods and document that in the CPS. That should work better than Gerv's vacation thoughts! Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

Gerv, Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the

RE: Responding to a misissuance

> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Friday, August 18, 2017 9:42 AM > To: Doug Beattie ; richmoor...@gmail.com; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Responding to a misissuance > > On

RE: Responding to a misissuance

And if there is any guidance on processing misissuance reports for Name constrained sub-CA vs. not name constrained, that would be helpful also. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On

RE: April CA Communication: Results

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Monday, May 15, 2017 9:16 AM > To: Jakob Bohm ;

RE: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

Gerv, I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by 21st July 2017. I'm assuming this is the latest official draft: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Specifically, does this mean all new domain validations must conform to

RE: Email sub-CAs

on how new policy requirements apply to this existing customer. Your guidance is appreciated. Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Doug > Beattie via dev-security

RE: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Ryan, If you look at the wide range of user agents accessing google.com today you'd see many legacy applications and older versions of browsers and custom browsers built from variants of the commercial browsers. By the time all/most users upgraded to new browsers, it would be time to change

RE: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Most (all?) non-browsers do not implement AIA chasing. This isn't an objection, just a flag and a potential action item on the "non-browser" side of this. Alex On Tue, May 16, 2017 at 10:27 AM, Rob Stradling <rob.stradl...@comodo.com<mailto:rob.stradl...@comodo.com>> wrot

RE: April CA Communication: Results

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Kurt > Roeckx via dev-security-policy > Sent: Monday, May 15, 2017 9:41 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re:

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Tuesday, June 20, 2017 9:12 PM > To: Doug Beattie ; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods > >

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Wednesday, June 21, 2017 4:16 PM > To: mozilla-dev-security-pol...@lists.mozilla.org >

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

H Gerv, I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates. We have 2 customers that can issue Secure Email certificates that are not technically constrained with name Constraints (the EKU is constrained to Secure Email and

RE: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Sent: Wednesday, May 31, 2017 7:24 AM > To: mozilla-dev-security-pol...@lists.mozilla.org >

RE: Email sub-CAs

Hi Gerv, I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs based on the discussion we started last month. I understand the BR requirement if the CA can issue server auth certificates, this was discussed here:

RE: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, June 1, 2017 8:46 AM To: Gervase Markham Cc: Doug Beattie ; mozilla-dev-security-policy Subject: Re: Policy 2.5 Proposal: Clarify

Issuing and using SHA-1 OCSP signing certificates

Hello Gerv, The BRs are clear on the use of SHA-1, but I have a question about the Mozilla policy and how it relates to the use of SHA-1 OCSP signing certificates. In December 2016 the Mozilla policy 2.3 was published and it didn't address the use of SHA-1 on OCSP signing certificates (see

RE: SHA-1 Usage in OCSP Responder

Hi Harshal, Yes, we took the option of pre-generating some OCSP signing certificates in 2016 for use in 2017 and 2018 vs. creating long validity OCSP signing certificates or moving to SHA-256. Since the not-before dates are in 2017 when this would have been prohibited, so we posted them to CT

Forbidden Practices: Subscriber key generation

Hi Gerv and Kathleen, We're working on the Mozilla CA self-assessment checklist and referenced requirements you have placed on CAs. On your page of Forbidden or Problematic Practices [1], you state that CAs must not generate private keys for signer certificates. CAs must never generate the

RE: ComSign Root Renewal Request

Hi Wayne, I noticed your comment on IDN validation. Is there a requirement that CAs establish an effective safeguard against homograph spoofing? The reason I ask is that Let's Encrypt's CPS says this: "Regarding Internationalized Domain Names, ISRG will have no objection so long as the

RE: Proposed policy change: require private pre-notification of 3rd party subCAs

Gerv, I assume this applies equally to cross signing, but not to "Vanity" CAs that are set up and run by the CA on behalf of a customer. Is that accurate? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Hey Wayne, This should be a really easy thing, but it's not. First comments on this: "MUST be encrypted and signed; or, MUST have a password that..." - Isn't the password the key used for encryption? I'm not sure if the "or" makes sense since in both cases the password is the key for

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least that is Tim's proposal, Wayne may not agree yet but he will when he reads this email) - We can’t distribute both the password and PKCS#12 over the same channel,

FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

ing (AW: Policy 2.6 Proposal: Add prohibition on CA key >generation to policy) > >Doug, > >On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy ><mailto:dev-security->pol...@lists.mozilla.org> wrote: >> -Original Message- >> From: dev-sec

RE: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Hi Wayne, I’m OK with this as long as this permits the password (fully or partially generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS (a single channel). Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 9, 2018 11:43 PM To: Doug Beattie

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

bition on CA key generation to policy) On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

I agree we need to tighten up Wayne's initial proposal a little. - Initial proposal (Wayne): CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

policy, and while it's confusing I believe it just means 'tamper evident'. -Tim > -Original Message- > From: dev-security-policy [mailto:mailto:dev-security-policy- > bounces+tim.hollebeek=mailto:digicert@lists.mozilla.org] On Behalf Of Doug > Beattie via dev-

RE: Changes to CA Program - Q1 2018

Thanks Kathleen. I only asked because you are trying to reduce the manpower for processing applications, and if a CA was already in the program there might not be a need to do as much. But on the other hand, this forces us to all comply with those pesky set of questions in "CA/Forbidden or

RE: Changes to CA Program - Q1 2018

Hi Kathleen, Is the same process used for existing CAs that need to add a new root and new CAs applying for the first time? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Ryan, Here is some more information to continue the discussion. - We will continue to post all certificates to CT logs so issuance can be monitored. - We will reduce validity period of OneClick certificates to 6 months. - We will work with the hosting providers (on

TLS-SNI-01 and compliance with BRs

Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10. The BRs say: 3.2.2.4.10. TLS Using a Random Number Confirming the Applicant's

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Ryan, I’m not sure where we go from here. We have customers that need certificates and they have demonstrated they can comply with not permitting the creation and use of certificates for domains other than those that the hosting company is hosting for that customer. All certificates will

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Friday, January 12, 2018 5:53 PM To: Doug Beattie Cc: Wayne Thayer ; Gervase Markham ; r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

> -Original Message- > From: Nick Lamb [mailto:n...@tlrmx.org] > Sent: Monday, January 15, 2018 2:39 PM > > > - Total number of active OneClick customers: < 10 > > What constitutes a OneClick customer in this sense? These are web hosting companies that receive certificates for

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment On Mon, Jan 15, 2018 at 3:36 PM, Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Ryan, I’m not sure where we g

RE: TLS-SNI-01 and compliance with BRs

pearing within the TLS handshake for .10. On Thu, Jan 18, 2018 at 4:46 PM, Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: The point is, you don’t really connect to the Certificate on the Autho

RE: TLS-SNI-01 and compliance with BRs

Matthew, That’s a good summary. It seems we have 2 methods that can be used only if the CAs using the methods have the design and risk mitigation factors reviewed and approved. It’s basically the old “any other method”, except before you can use it, the Root programs must review the

RE: GlobalSign certificate with far-future notBefore

Can we consider this case closed with the action that the VWG will propose a ballot that addresses pre and postdating certificates? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

la-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment On Thu, Jan 11, 2018 at 4:50 PM, Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>&

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Wayne and Gerv, I’ll try to answer both of your questions here. From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Friday, January 12, 2018 11:03 AM To: Doug Beattie Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible Issue

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Wayne, We didn’t really investigate wildcard issuance yet, but we can. Given the discuss so far, we’re planning to proceed with a whitelisting approach tomorrow and we will plan to end the use of Method 9 (schedule TBD) which follows Let’s Encrypt handling of Method 10. If there are any

Possible Issue with Domain Validation Method 9 in a shared hosting environment

Based on reported issues with TLS-SNI-01, we started investigation of our systems late yesterday regarding the use of "Test Certificate" validation, BR section 3.2.2.4.9. We found that this method may be vulnerable to the some of the same underlying issue as the ACME TLS-SNI-01 so we

RE: GlobalSign certificate with far-future notBefore

I'll try to respond to the few questions on the topic in this one email. In the case below, the customer ordered a 39 month certificate and set the notBefore date for 2 months into the future. The notAfter is within the allowed 39 month validity as measured from time of issuance. Posting the

RE: GlobalSign certificate with far-future notBefore

> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Wednesday, January 24, 2018 7:00 AM > To: Doug Beattie ; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: GlobalSign certificate with far-future notBefore > > Hi

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Wayne: I agree with your latest proposal. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Monday, April 9, 2018 7:10 PM > To:

RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Wayne Thayer via dev-security-policy > Sent: Tuesday, April 17, 2018 2:24 PM > To: mozilla-dev-security-policy pol...@lists.mozilla.org>

RE: Mozilla’s Plan for Symantec Roots

Hi Wayne, Is the Firefox 60 update in May the same as the combination of the April and October Chrome updates, in that all Symantec certificates will be untrusted on this date (5 months before Chrome)? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy-

RE: Increasing number of Errors found in crt.sh

his page: > https://crt.sh/?cablint=1+week > > Next, click on the link in the "Issuer CN, OU or O" column that > corresponds to the issuing CA you're interested in. > >> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto: >>> Hi Wa

Increasing number of Errors found in crt.sh

Hi Wayne and all, I've been noticing an increasing number of CA errors, https://crt.sh/?cablint=issues Is anyone monitoring this list and asking for misissuance reports for those that are not compliant? There are 15 different errors and around 300 individual errors (excluding the SHA-1

RE: Increasing number of Errors found in crt.sh

Increasing number of Errors found in crt.sh > > I also agree. > > As I said before, that's a non-trusted certificate. It was issued by a > test CA that does /not/ chain to a public root. > > > Il 01/10/2018 16:04, Rob Stradling ha scritto: >> On 01/10/2018 15:02, Doug Beat

RE: Maximal validity of the test TLS certificate issued by a private PKI system

Option 1 is the intended interpretation. We specified 30 days because the tokens used for domain validation (Random Number) need to have a useful life of 30 days. The 30-day usage period needed to be put into the definition of the Test Certificate, or into Method 3.2.2.4.9, and we selected the

RE: SSL private key for *.alipcsec.com embedded in PC client executables

As a follow-up, The certificate was revoked about 2 hours ago: https://crt.sh/?id=300288180=ocsp -Original Message- From: Doug Beattie Sent: Tuesday, December 11, 2018 8:09 AM To: 'dev-security-policy@lists.mozilla.org' Cc: 'Xiaoyin Liu' ; Mark Steward Subject: RE: SSL private

RE: SSL private key for *.alipcsec.com embedded in PC client executables

Thank you for this report. We've verified disclosure of the private key for this certificate and have notified the customer that their certificate will be revoked. Due to the large customer impact, we're provided them 24 hours to get new client executables prepared and ready for download by

RE: P-521 Certificates

Jason - where did you see this requirement? -Original Message- From: dev-security-policy On Behalf Of Jason via dev-security-policy Sent: Thursday, January 10, 2019 9:38 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: P-521 Certificates I would say that the problem

usareally.com and OFAC lists

A few of us have been discussing the usareally.com "issue" recently. In case you didn't know, the US Treasure put out a notice that US companies must not do business with USA Really: https://home.treasury.gov/news/press-releases/sm577 Let's Encrypt mapped that release to

RE: Survey of (potentially noncompliant) Serial Number Lengths

Rob, I'm sure you provided this info somewhere, but I can't figure our where the new summary table (named serial_number_entropy_20190325) is located. Is it somewhere on your Google Doc, or somewhere else? https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjC

Pre-Incident Report - AT GlobalSign customer CA Serial Number Entropy

When the serial number issue was first disclosed we reviewed all GlobalSign certificates issued from our systems and found no issues wrt serial number length. While all GlobalSign systems are compliant, one of our customers running an on-premise CA that chains to a GlobalSign root, AT, uses EJBCA

RE: Virginia Tech misissuance report for 63 bit serial numbers

A Mozilla incident report has been crated to track this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1536760 Doug From: Doug Beattie Sent: Tuesday, March 19, 2019 1:53 PM To: mozilla-dev-security-pol...@lists.mozilla.org Cc: Kathleen Wilson ; Wayne Thayer ; Arvid Vermote

Virginia Tech misissuance report for 63 bit serial numbers

Hi Wayne, Can you open a Mozilla ticket for one of our older customers, Virginia Tech (VT)? Thanks. === 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in

RE: Applicability of SHA-1 Policy to Timestamping CAs

GlobalSign concurs. -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, March 22, 2019 2:51 PM To: mozilla-dev-security-policy Subject: Applicability of SHA-1 Policy to Timestamping CAs I've been asked if the section 5.1.1

RE: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

The ETSI requirements for QWAC are complicated and not all that clear to me, but is it possible to use OV certificate and Policy OIDs as the base instead of EV? Since OV permits additional Subject Attributes, then that approach would not be noncompliant. Certainly issuing a QWAC needs to

GlobalSign misissuance: 4 certificates with invalid CN

Today our post issuance checker notified us of 4 certificates were issued with invalid CN values this afternoon. We posted our incident report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1552586 In summary, 4 certificate were issued from an API that had been depreciated, but not

RE: GlobalSign misissuance: 4 certificates with invalid CN

al Message- From: Nick Lamb Sent: Saturday, May 18, 2019 3:02 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie Subject: Re: GlobalSign misissuance: 4 certificates with invalid CN On Fri, 17 May 2019 21:11:41 + Doug Beattie via dev-security-policy wrote: > Today our post iss

RE: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

Wayne recommended that we open up a Mozilla incident ticket to track the 8 GlobalSign certificates of that do not contain the required null a parameter and thus violate the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1. https://bugzilla.mozilla.org/show_bug.cgi?id=1554259

RE: AT SSL certificates without the AIA extension

our termination date in about 4 months. Doug -Original Message- From: Nick Lamb Sent: Tuesday, April 30, 2019 3:51 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie Subject: Re: AT SSL certificates without the AIA extension On Mon, 29 Apr 2019 12:41:07 + Doug Beattie via

AT SSL certificates without the AIA extension

In the course of normal communications with AT, we came across an SSL certificate that did not have the required AIA extension in it on Friday April 16th. We had a conference call shortly thereafter and they verified that one of their current EJBCA certificate profiles is missing this

RE: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

Hi Sandor, You can follow the ballot status in the Server Certificate Working Group mail archives here: https://cabforum.org/pipermail/servercert-wg/ and specifically in this thread: https://cabforum.org/pipermail/servercert-wg/2019-April/000723.html Voting will start at least a week after the

RE: Logotype extensions

We've beaten the stuffing out of Logotype, imho. - CAs want to add it - Root stores don't - The BRs permit it (probably). - I'll report you to the DoJ, - I'll revoke our Roots, - bla bla bla My personal view is that CAs should be able to include data in extensions as long as they document how

RE: Entrust Root Certification Authority - G4 Inclusion Request

Ryan, GlobalSign has been thinking along these lines, but it's not clear how browsers build their path when a cross certificate is presented to them in the TLS handshake. Can you explain how chrome (windows and Android) builds a path when a cross certificate is delivered? What about the case

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

Beattie via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: DB: Yes, that's true. I was saying that phishing sites don't use EV, not that EV sites don't get phished Surely this shows that EV is not needed to make phishing work, not that EV reduces phishing?

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

From: Jonathan Rudenberg Sent: Friday, August 16, 2019 9:04 AM To: Doug Beattie ; Peter Gutmann ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar On Fri, Aug 16, 2019, at 07:56, Doug Beattie via dev

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

Peter, I'm not claiming that EV reduces phishing globally, just for those sites that use them. Do you have a chart that breaks down phishing attacks by SSL certificate type? Here is some research that indicates EV sites have a reduced phishing percentage, so customers accessing EV protected

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

Peter, Do you have any empirical data to backup the claims that there is no benefit from EV certificates? From the reports I've seen, the percentage of phishing and malware sites that use EV is drastically lower than DV (which are used to protect the cesspool of websites). Doug -Original

GlobalSign: SSL Certificates with US country code and invalid State/Prov

Today we opened a bug disclosing misissuance of some certificates that have invalid State/Prov values: https://bugzilla.mozilla.org/show_bug.cgi?id=1575880 On Tuesday August 20th 2019, GlobalSign was notified by a third party through the report abuse email address that two certificates

GlobalSign: OCSP Responder Returns invalid values for some Precertificates

Based on announcements by DigiCert and Let's Encrypt, GlobalSign has found that our Precertificates without corresponding certificates also return Unauthorized or Unknown. We're working with PrimeKey on a patch and are also updating our own OCSP services to return the proper values. Here are 2

RE: How to use Cross Certificates to support Root rollover

Ryan, Note: I changed the name of the thread because this is a great discussion about root roll-over and isn’t really related to the Entrust Root inclusion request. In theory Cross certificates are simple, but I’ve found that in practice they are difficult to manage and use.

How to use Cross Certificates to support Root rollover

Ryan, Note: I changed the name of the thread because this is a great discussion about root roll-over and isn’t really related to the Entrust Root inclusion request. In theory Cross certificates are simple, but I’ve found that in practice they are difficult to manage and use. First,

RE: DNS records and delegation

Ryan, Are you recommending that: a) we need a new domain validation method that describes this, or b) those CAs that want to play with fire can go ahead and do that based on their own individual security analysis, or c) we need a clear policy/guideline in the BRs or root program that MUST be

RE: About upcoming limits on trusted certificates

Hi Clint, The content of your email, the blog post and the Apple root policy all say something a little different and may leave some room for interpretation by the CAs. As it stands, things are a bit confused. Here's why: Your mail is a little light on the details. While you say this is an

Which fields containing email addresses need to be validated?

The Mozilla policy section 2.2 says: * . the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate. Since the Mozilla policy only applies to certificates with the EKU of

RE: Which fields containing email addresses need to be validated?

to be validated? On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy wrote: > It's not against Mozilla policy to > issue certificates with unvalidated email addresses in any field as > long as the Secure Mail EKU is not included, so the intent should be > to validat

RE: About upcoming limits on trusted certificates

Kathleen, Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. This would be a sudden and large

RE: About upcoming limits on trusted certificates

Hi Kathleen, I think a clear description of why the change is needed is a great first step and will help explain why this change is needed and justify the timeline (and Ryan's ballot SC22 had a number of suggestions, some good and some weak, imo). When we moved to SHA2 knew of security risks

RE: About upcoming limits on trusted certificates

Wilson ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: About upcoming limits on trusted certificates On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: When we moved to SHA2 knew of security ri

RE: About upcoming limits on trusted certificates

Are we to assume that the maximum certificate validity remains at 398 days? From: Ryan Sleevi Sent: Monday, March 16, 2020 10:02 AM To: Doug Beattie Cc: r...@sleevi.com; Kathleen Wilson ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: About upcoming limits on trusted

RE: About upcoming limits on trusted certificates

For clarity, I think we need to discuss all the knobs along with proposed effective dates and usage periods so we get the whole picture. The max validity period of the certificate has been the one receiving the most discussion recently, yet that’s missing from your counter proposal. Don’t you

RE: 7.1.6.1 Reserved Certificate Policy Identifiers

Yes, I should have asked this on the CABF list, and you answered my question with the links below. Thanks! From: Ryan Sleevi Sent: Thursday, May 14, 2020 8:57 AM To: Doug Beattie Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: 7.1.6.1 Reserved Certificate Policy Identifiers

7.1.6.1 Reserved Certificate Policy Identifiers

I have a question about section, 7.1.6.1. It says: This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates, as they relate to the identification of Certificate Policy. For Subscriber certificates I totally understand and agree with section

RE: Is issuing a certificate for a previously-reported compromised private key misissuance?

Has anyone worked with a site/service like this that could help convey compromised keys between CAs? https://pwnedkeys.com/submit.html -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, March 19, 2020 7:05 AM To:

RE: Policy 2.7.1 Issues to be Considered

Ben, When, approximately, do you think this proposed updates would become effective, and specifically this item: https://github.com/mozilla/pkipolicy/issues/206 Doug -Original Message- From: dev-security-policy On Behalf Of Ben Wilson via dev-security-policy Sent: Thursday,

RE: Mandatory reasonCode analysis

Hi Rob, I'm not sure you filtered this report by "thisUpdate", maybe you did it by nextUpdate by mistake? The GlobalSign CRL on this report was created in 2016, thus the question. Doug -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-policy

RE: Concerns with GlobalSign IP address validation

Hi Ian, Thanks, we're looking into this. Doug -Original Message- From: dev-security-policy On Behalf Of i...--- via dev-security-policy Sent: Friday, August 7, 2020 11:37 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Concerns with GlobalSign IP address validation Hi

RE: Concerns with GlobalSign IP address validation

of that email would fail. We'll update the page shortly to address this UI bug to avoid customer confusion. Regards, Doug -Original Message- From: dev-security-policy On Behalf Of Doug Beattie via dev-security-policy Sent: Monday, August 10, 2020 6:30 AM To: i...@ian.sh ; mozilla-dev-security-pol

  1   2   >