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
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
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
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
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,
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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??
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,
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
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
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
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-
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
> -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:
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
> -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
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
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
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
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
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
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
> -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
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
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
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
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
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>&
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
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
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
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
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
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-
>
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
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
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
> -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 ;
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-
>
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
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
> -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
>
> -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
> >
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
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
> -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
>
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
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
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
> -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:
> -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 ;
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
1 - 100 of 105 matches
Mail list logo