RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

2021-03-19 Thread Doug Beattie via dev-security-policy
Thanks Ben. What’s the purpose of this statement: 5. verify that all of the information that is included in server certificates remains current and correct at intervals of 825 days or less; The BRs limit data reuse to 825 days since March 2018 so I don’t think this adds anything. If it

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

2021-03-16 Thread Doug Beattie via dev-security-policy
Hi Ben, Regarding the redlined spec: https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6 Is this a meaningful statement given max validity is 398 days now? 5. verify that all

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

2021-02-25 Thread Doug Beattie via dev-security-policy
Ben, I'd prefer that we tie this to a date related to when the domain validations are done, or perhaps 2 statements. As it stands (and as others have commented), on July 1 all customers will immediately need to validate all domains that were done between 825 and 397 days ago, so a huge number

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

2020-12-01 Thread Doug Beattie via dev-security-policy
Hi Ben, For now I won’t comment on the 398 day limit or the date which you propose this to take effect (July 1, 2021), but on the ability of CAs to re-use domain validations completed prior to 1 July for their full 825 re-use period. I'm assuming that the 398 day limit is only for those

RE: Policy 2.7.1 Issues to be Considered

2020-10-06 Thread Doug Beattie via dev-security-policy
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

2020-09-30 Thread Doug Beattie via dev-security-policy
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

2020-08-10 Thread Doug Beattie via dev-security-policy
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

RE: Concerns with GlobalSign IP address validation

2020-08-10 Thread Doug Beattie via dev-security-policy
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: New Blog Post on 398-Day Certificate Lifetimes

2020-07-10 Thread Doug Beattie via dev-security-policy
Ben, For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC. -Original Message- From: dev-security-policy On Behalf Of Ben Wilson via dev-security-policy Sent: Friday, July 10, 2020 12:49 PM To: mozilla-dev-security-policy Subject: Re: New Blog Post on 398-Day Certificate

RE: 7.1.6.1 Reserved Certificate Policy Identifiers

2020-05-14 Thread Doug Beattie via dev-security-policy
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

2020-05-14 Thread Doug Beattie via dev-security-policy
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?

2020-03-19 Thread Doug Beattie via dev-security-policy
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: About upcoming limits on trusted certificates

2020-03-16 Thread Doug Beattie via dev-security-policy
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: About upcoming limits on trusted certificates

2020-03-16 Thread Doug Beattie via dev-security-policy
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

2020-03-16 Thread Doug Beattie via dev-security-policy
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

2020-03-13 Thread Doug Beattie via dev-security-policy
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

2020-03-12 Thread Doug Beattie via dev-security-policy
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

2020-03-04 Thread Doug Beattie via dev-security-policy
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

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

2020-02-06 Thread Doug Beattie via dev-security-policy
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

Which fields containing email addresses need to be validated?

2020-02-06 Thread Doug Beattie via dev-security-policy
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: DNS records and delegation

2019-10-11 Thread Doug Beattie via dev-security-policy
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

GlobalSign: OCSP Responder Returns invalid values for some Precertificates

2019-09-06 Thread Doug Beattie via dev-security-policy
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

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

2019-08-22 Thread Doug Beattie via dev-security-policy
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

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

2019-08-16 Thread Doug Beattie via dev-security-policy
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

2019-08-16 Thread Doug Beattie via dev-security-policy
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

2019-08-16 Thread Doug Beattie via dev-security-policy
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

2019-08-15 Thread Doug Beattie via dev-security-policy
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

RE: How to use Cross Certificates to support Root rollover

2019-08-05 Thread Doug Beattie via dev-security-policy
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

2019-08-05 Thread Doug Beattie via dev-security-policy
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: Entrust Root Certification Authority - G4 Inclusion Request

2019-08-02 Thread Doug Beattie via dev-security-policy
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: Logotype extensions

2019-07-12 Thread Doug Beattie via dev-security-policy
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: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

2019-05-24 Thread Doug Beattie via dev-security-policy
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: GlobalSign misissuance: 4 certificates with invalid CN

2019-05-23 Thread Doug Beattie via dev-security-policy
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

GlobalSign misissuance: 4 certificates with invalid CN

2019-05-17 Thread Doug Beattie via dev-security-policy
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: AT SSL certificates without the AIA extension

2019-04-30 Thread Doug Beattie via dev-security-policy
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

2019-04-29 Thread Doug Beattie via dev-security-policy
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

2019-04-18 Thread Doug Beattie via dev-security-policy
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: Organization Identifier field in the Extended Validation certificates accordinf to the EVG ver. 1.6.9

2019-04-17 Thread Doug Beattie via dev-security-policy
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

RE: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-04-03 Thread Doug Beattie via dev-security-policy
Wayne, The Microsoft policy already requires that CAs include EKUs in all EE certificates that chain up to roots in their program. See 4.A.18 in http://aka.ms/RootCert Effective February 1, 2017, all end-entity certificates must contain the EKU for the purpose that the CA issued the

RE: Survey of (potentially noncompliant) Serial Number Lengths

2019-03-26 Thread Doug Beattie via dev-security-policy
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

RE: Applicability of SHA-1 Policy to Timestamping CAs

2019-03-22 Thread Doug Beattie via dev-security-policy
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: Virginia Tech misissuance report for 63 bit serial numbers

2019-03-20 Thread Doug Beattie via dev-security-policy
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

2019-03-19 Thread Doug Beattie via dev-security-policy
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

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

2019-03-13 Thread Doug Beattie via dev-security-policy
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

usareally.com and OFAC lists

2019-01-11 Thread Doug Beattie via dev-security-policy
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: P-521 Certificates

2019-01-10 Thread Doug Beattie via dev-security-policy
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

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

2018-12-12 Thread Doug Beattie via dev-security-policy
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: Maximal validity of the test TLS certificate issued by a private PKI system

2018-12-11 Thread Doug Beattie via dev-security-policy
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

2018-12-11 Thread Doug Beattie via dev-security-policy
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: Increasing number of Errors found in crt.sh

2018-10-01 Thread Doug Beattie via dev-security-policy
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: Increasing number of Errors found in crt.sh

2018-10-01 Thread Doug Beattie via dev-security-policy
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

RE: Increasing number of Errors found in crt.sh

2018-10-01 Thread Doug Beattie via dev-security-policy
That last email got away from me before I finished compiling the list, but you get the idea. -Original Message- From: dev-security-policy On Behalf Of Doug Beattie via dev-security-policy Sent: Monday, October 1, 2018 9:27 AM To: mozilla-dev-security-policy Subject: Increasing number

Increasing number of Errors found in crt.sh

2018-10-01 Thread Doug Beattie via dev-security-policy
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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-15 Thread Doug Beattie via dev-security-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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-14 Thread Doug Beattie via dev-security-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,

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

2018-05-10 Thread Doug Beattie via dev-security-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

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

2018-05-09 Thread Doug Beattie via dev-security-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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-04 Thread Doug Beattie via dev-security-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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-30 Thread Doug Beattie via dev-security-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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-30 Thread Doug Beattie via dev-security-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: Require separate intermediates for different usages (e.g. server auth, S/MIME)

2018-04-17 Thread Doug Beattie via dev-security-policy
> -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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-10 Thread Doug Beattie via dev-security-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: Mozilla’s Plan for Symantec Roots

2018-03-02 Thread Doug Beattie via dev-security-policy
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: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
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: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
> -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: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Doug Beattie via dev-security-policy
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: TLS-SNI-01 and compliance with BRs

2018-01-19 Thread Doug Beattie via dev-security-policy
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: TLS-SNI-01 and compliance with BRs

2018-01-19 Thread Doug Beattie via dev-security-policy
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

TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Doug Beattie via dev-security-policy
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

2018-01-16 Thread Doug Beattie via dev-security-policy
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

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

2018-01-15 Thread Doug Beattie via dev-security-policy
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: Possible Issue with Domain Validation Method 9 in a shared hosting environment

2018-01-15 Thread Doug Beattie via dev-security-policy
> -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

2018-01-15 Thread Doug Beattie via dev-security-policy
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

2018-01-15 Thread Doug Beattie via dev-security-policy
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

2018-01-12 Thread Doug Beattie via dev-security-policy
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

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

2018-01-12 Thread Doug Beattie via dev-security-policy
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

2018-01-12 Thread Doug Beattie via dev-security-policy
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>&

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

2018-01-11 Thread Doug Beattie via dev-security-policy
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: Changes to CA Program - Q1 2018

2018-01-10 Thread Doug Beattie via dev-security-policy
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

2018-01-10 Thread Doug Beattie via dev-security-policy
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: ComSign Root Renewal Request

2017-12-19 Thread Doug Beattie via dev-security-policy
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

Forbidden Practices: Subscriber key generation

2017-11-14 Thread Doug Beattie via dev-security-policy
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: Proposed policy change: require private pre-notification of 3rd party subCAs

2017-10-24 Thread Doug Beattie via dev-security-policy
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- >

Issuing and using SHA-1 OCSP signing certificates

2017-10-03 Thread Doug Beattie via dev-security-policy
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

2017-08-29 Thread Doug Beattie via dev-security-policy
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

RE: Responding to a misissuance

2017-08-18 Thread Doug Beattie via dev-security-policy
> -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

2017-08-18 Thread Doug Beattie via dev-security-policy
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: DigiCert-Symantec Announcement

2017-08-03 Thread Doug Beattie via dev-security-policy
> -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 ;

RE: Validation of Domains for secure email certificates

2017-07-20 Thread Doug Beattie via dev-security-policy
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- >

Validation of Domains for secure email certificates

2017-07-20 Thread Doug Beattie via dev-security-policy
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: Root Store Policy 2.5: Call For Review and Phase-In Periods

2017-07-06 Thread Doug Beattie via dev-security-policy
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: Root Store Policy 2.5: Call For Review and Phase-In Periods

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

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

2017-06-20 Thread Doug Beattie via dev-security-policy
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

2017-06-01 Thread Doug Beattie via dev-security-policy
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

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

2017-06-01 Thread Doug Beattie via dev-security-policy
> -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

2017-05-18 Thread Doug Beattie via dev-security-policy
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

2017-05-16 Thread Doug Beattie via dev-security-policy
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Doug Beattie via dev-security-policy
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: April CA Communication: Results

2017-05-15 Thread Doug Beattie via dev-security-policy
> -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:

  1   2   >