does mean something more than that, can you update to
make it more clear?
From: Ben Wilson
Sent: Thursday, March 18, 2021 2:53 PM
To: Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
verification to 398 days
I&#x
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 of
mprovement on the existing policy.
>>
>> -Original Message-
>> From: dev-security-policy
>>
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Wednesday, December 2, 2020 2:22 PM
>> To: Ryan Sleevi
>> Cc: Doug Beattie ; Mozilla <
&g
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 domain
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, Octobe
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
Sent
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-securit
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 the
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 Li
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
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
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: mozilla
16, 2020 10:27 AM
To: Doug Beattie
Cc: r...@sleevi.com; Kathleen Wilson ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates
No, I don't think we should assume anything, since it doesn't say anything
about lifetime :)
Th
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
address and that
typically involves a direct exchange with a person at the organization via a
Reliable Method of Communication. It’s not clear how we address that if we
move to anything below a year.
From: Ryan Sleevi
Sent: Friday, March 13, 2020 9:23 PM
To: Doug Beattie
Cc: Kathleen
: Thursday, March 12, 2020 4:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted certificates
On 3/12/20 5:52 AM, Doug Beattie wrote:
> Changing the domain validation re-user period is a substantial change from
> the Apple proposed max validity
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 de
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
"up
ich is the
active directly account, but I thought I'd start a discussion to see what
people thought.
Doug
-Original Message-
From: Kurt Roeckx
Sent: Thursday, February 6, 2020 4:06 PM
To: Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Which fields containing email addre
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 Sec
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
fol
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
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 were
From: Ben Laurie
Sent: Friday, August 16, 2019 9:33 AM
To: Doug Beattie
Cc: Jonathan Rudenberg ; 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, 16 Aug 2019 at 14:31, Doug
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
ected sites are safer:
https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf
-Original Message-
From: Peter Gutmann
Sent: Thursday, August 15, 2019 10:03 PM
To: Doug Beattie ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Fwd: Intent to Ship: Move Ext
/uploads/23.-Update-on-London-Protocol.pdf
Baffled…
From: Tom Ritter
Sent: Thursday, August 15, 2019 1:13 PM
To: Doug Beattie
Cc: Peter Gutmann ; MozPol
Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out of
the URL bar
On Thu, Aug 15, 2019, 7:46 AM Doug
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
signed CAs which I haven’t considered yet. What
definition/approach were you assuming?
See responses in-line below
From: Doug Beattie
Sent: Monday, August 5, 2019 7:29 AM
To: Doug Beattie
Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion Request
On Mon, Aug 5
signed CAs which I haven’t considered yet. What
definition/approach were you assuming?
See responses in-line below
From: Doug Beattie
Sent: Monday, August 5, 2019 7:29 AM
To: Doug Beattie
Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion Request
On Mon, Aug 5, 2019
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 wh
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 they
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
Hop
.
Doug
-Original 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 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 func
ake longer than 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&T SSL certificates without the AIA extension
On Mon, 29 Apr 2019 12:41:07
In the course of normal communications with AT&T, 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
extensio
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 f
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 have
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 certifica
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
Fn6lKoc/edit#g
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 restri
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
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
mozilla.dev.security.polic
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&T, uses EJBC
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 certi
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 here
As a follow-up, The certificate was revoked about 2 hours ago:
https://crt.sh/?id=300288180&opt=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 S
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 v
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 their
://misissued.com and use that as a better, more
filtered report once it returns to life.
Doug
From: Wayne Thayer
Sent: Monday, October 1, 2018 2:58 PM
To: Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh
Doug,
Responding to
First, visit this 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
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 of
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
"false
need to be?
Doug
From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Monday, May 14, 2018 4:54 PM
To: Doug Beattie ; mozilla-dev-security-policy
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
generation to policy)
On Mon, May 14, 2018 at 11:50 AM Doug Beattie
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, even
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
Cc
>From: Wayne Thayer [mailto:wtha...@mozilla.com]
>Sent: Monday, May 7, 2018 8:43 PM
>To: Doug Beattie
>Cc: Ryan Hurst ; mozilla-dev-security-policy
>pol...@lists.mozilla.org>
>Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
>generation t
.org
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
>
> On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
> > First comments on this: "MUST be encrypted and signed; or, MUST have a
> password that..
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 encryptio
Thayer
Cc: Doug Beattie ; Buschart, Rufus
; mozilla-dev-security-policy
; Wichmann, Markus Peter
; Enrico Entschew ; Grotz,
Florian ; Heusler, Juergen
Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
OOB passwords are generally tough to integrate into
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 transf
> -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>
>
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: mozilla-dev-secur
> -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: Wednesday, April 4, 2018 5:26 PM
> To: mozilla-dev-security-policy
>
> Subject: Policy 2.6 P
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-
>
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 Tim
> -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 Doug,
&
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
only root program
representative that has expressed strong views on what is permitted and what is
not (else you have your CA revoked or root pulled from the program).
Doug
From: Matthew Hardeman [mailto:mharde...@gmail.com]
Sent: Friday, January 19, 2018 1:45 PM
To: Doug Beattie
Cc: r
: Thursday, January 18, 2018 7:25 PM
To: Doug Beattie
Cc: Alex Gaynor ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs
I think others have already responded, but I do want to highlight one other
problem with the reasoning being offered here: SNI is not
IP address). It
seems like misissuance to me.
From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, January 18, 2018 3:47 PM
To: Doug Beattie
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: TLS-SNI-01 and compliance with BRs
I guess it depends how you define
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 contro
...@sleevi.com]
Sent: Monday, January 15, 2018 4:56 PM
To: Doug Beattie
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase
Markham ; Wayne Thayer
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting
environment
As suggested, we encourage you to
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Monday, January 15, 2018 4:14 PM
To: Doug Beattie
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase
Markham ; Wayne Thayer
Subject: 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 t
, January 15, 2018 2:31 PM
To: Doug Beattie
Cc: r...@sleevi.com; Wayne Thayer ; Gervase Markham
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting
environment
On Mon, Jan 15, 2018 at 1:18 PM, Doug Beattie
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 with Domain Validation Method 9 in a shared hosting
environment
additional
security concerns that we need to be made aware of, please let me know and we
can adjust the plan accordingly.
Doug
From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Friday, January 12, 2018 3:43 PM
To: Doug Beattie
Cc: Gervase Markham ; r...@sleevi.com;
mozilla-dev-security-pol
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 with Domain Validation Method 9
certificates outside
of their permitted domains and then whitelist them.
If this is acceptable, we’d like to resume issuance today if possible.
Doug
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, January 11, 2018 5:19 PM
To: Doug Beattie
Cc: mozilla-dev-security-pol...@lists.mozilla.org
#x27;re continuing to research this and will let you know what we find.
Doug
Doug Beattie
Vice President of Product Management
GlobalSign
Two International Drive | Suite 150 | Portsmouth, NH 03801
Email: doug.beat...@globalsign.com<mailto:doug.beat...@globalsign.com>
www.globalsign.com<htt
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 Pro
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 Kathleen
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
domain
security-pol...@lists.mozilla.org
> Subject: Re: Forbidden Practices: Subscriber key generation
>
> On 14/11/17 21:53, Doug Beattie wrote
> > The question is, if we issue Code Signing certificates via P12 files
> > in compliance with the Code Signing standard, are we out of c
iki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf
Doug Beattie
Product Mangement
GMO GlobalSign, Inc.
Portsmouth, NH USA
_
I wanted to send out a status of where we are on the ROCA vulnerable
certificates issued by GlobalSign. A full report will be coming later this
week once we've completed the revocations, but here is a summary of the scope
and status as it stands right now.
Here's the Timeline:
10/16: Became a
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-
> bounces+doug.beattie=globalsign@lists.mozi
Hi Gerv and Jacob,
Thanks for the assistance and recommendations.
Since I sent this initial email I found out we have a couple of CAs without
EKUs that are issuing SHA-1 Client certificates, so I'm afraid the scope of the
question has just expanded beyond just OCSP signing certificates. We've
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 any
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
> -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 18/08/17 1
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 Behalf
> -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 ; mozilla-dev-security-policy
>
> Su
ounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, July 20, 2017 10:58 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Validation of Domains for secure email certificates
>
> Hi Doug,
>
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 the
Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 22, 2017 8:50 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
>
> On 21/06/17 16:58, Doug Beattie wrote:
> >> It's wo
> -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
> Subj
> -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
> > We h
1 - 100 of 121 matches
Mail list logo
