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 via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 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

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

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > > I think we have settled on the following resolution to this issue: > > > > Add the following to section 5.2

Re: question about DNS CAA and S/MIME certificates

I created a new issue suggesting that we add this requirement to Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via

Re: Root Store Policy 2.6

We're concluding discussions on all of the issues identified for version 2.6 of the policy [1]. You can find a complete set of changes here: https://github.com/mozilla/pkipolicy/compare/master...2.6 Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs the current practice

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

31941101v010202p.pdf > > > > ETSI EN 319 411-2 <3194112> V2.2.2 adopted on April 23, 2018 > > http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60 > > /en_31941102v020202p.pdf > > > > Peter > > > > -Original Message- > > From: dev

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

Doug, On Thu, May 10, 2018 at 10:57 AM Doug Beattie wrote: > 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). > > > This

Policy 2.6 Proposal: Update Minimum Audit Versions

After consulting with representatives from WebTrust and ETSI, I propose that we update the minimum required versions of audit criteria in section 3.1.1 as follows: - WebTrust "Principles and Criteria for Certification Authorities - Extended Validation SSL" from 1.4.5 to 1.6.0 or later - “Trust

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

I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or >

Re: Bit encoding (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 < dev-security-policy@lists.mozilla.org> wrote: > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan > >

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

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey Doug, > > On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > > Hey Wayne, > > > > This should be a really easy thing, but it's not. > > > > First comments on

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

The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST

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

Unless there is further discussion, I will consider this issue closed with the following change to section 5.3, meaning that it applies to both unconstrained and technically constrained intermediates: Subordinate CA certificates created after January 1, 2019: * MUST contain an EKU extension; and,

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

Ryan - thanks for raising these issues again. I still have concerns about getting this specific in the policy, but since we're now headed down that road... On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A few problems I see

OISTE WISeKey Global Root GC CA Root Inclusion Request

This request is for inclusion of the OISTE WISeKey Global Root GC CA as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8912732 * Summary of Information Gathered and Verified:

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

Jakob, On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote > > However maybe an additional (clarifying or new) requirement set: > > I think the existing language in section 5.3.1 covers all of this. If not, can you point out the gaps

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

24, 2018 at 9:21 AM, Ryan Sleevi <r...@sleevi.com> wrote: > >> >> >> On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> I'm re-sending this with the subject tagged as

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

ear, what defines a 'sufficiently secure password' as the original > > > wording lets a lot of room for 'interpretation'. > > > > > > What do you think? > > > > > > /Rufus > > > > > > > > > Siemens AG > > > Information Tec

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

On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi wrote: > > > On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: > >> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: >> >>> I'm not sure I underestand the use case. I'm hoping that they

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Thu, Apr 26, 2018 at 6:59 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote: > > > > which is why in the near future we can hopefully use RDAP over TLS > > > > (RFC > > > > 7481) instead

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

On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I suggest to make the requirement „* The PKCS#12 file must have a > sufficiently secure password, and the password must be transferred via a > separate channel than the

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

On Fri, Apr 20, 2018 at 12:33 PM, Wayne Thayer wrote: > At this point we have a few choices: > > 1. Do nothing about requiring email as a problem reporting mechanism. > Instead, take on the related issues of disclosure of the reporting > mechanism and receipt confirmation in

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

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 20/04/2018 21:59, Wayne Thayer wrote: > >> On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> I

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

se? Is it just that now all of the S/MIME certificates issued under the intermediate must also expire or be replaced so that the old intermediate (without a constraint on srvName) can be revoked? On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy < > dev-security-po

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

On Tue, Apr 24, 2018 at 9:21 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I'm re-sending this with the subject tagged as a 'policy 2.6 p

Re: Regional BGP hijack of Amazon DNS infrastructure

Thanks Matthew, I appreciate you bringing this to everyone's attention. Unless I'm misunderstanding the scope of the attack, it would have been trivial for them to get a trusted cert from most any CA. However, according to the following article, "Victims had to click through a HTTPS error

Re: Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

Hearing no objections, I have made the proposed clarification in the version 2.6 branch: https://github.com/mozilla/pkipolicy/commit/def9c711163e0cae6a19866fb551e915e3bcef12 - Wayne On Tue, Apr 17, 2018 at 11:20 AM, Wayne Thayer wrote: > Section 5.3 of Mozilla policy

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

To close out discussion on this issue, I've updated the change by removing the requirement to list each subCA certificate in the CPS: https://github.com/mozilla/pkipolicy/commit/1bdcd53baf2e8b9006a5e13923ce3d66eeff927e - Wayne On Mon, Apr 16, 2018 at 4:51 PM, Wayne Thayer

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

On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think you should consider an an exception Issuing CAs including Name > Constraints. This would keep allowing root signing services for corporate > CAs without forcing

Re: Transforming a trade name into ASCII in the O field of an OV cert

Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. If this were an EV cert I would argue that it was misissued. On Mon, Apr 23, 2018 at 12:13 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Apr 23, 2018 at 1:11 PM, Henri

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

On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 20:24, Wayne Thayer wrote: > >> This proposal is to require intermediate certificates to be dedicated to >> specific purposes by EKU. Beginning at some future date,

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

On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I believe the wording "insecure electronic channels" leaves a lot of space > for interpretation. In corporate PKIs for email encryption it is quite > common to transfer

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

At this point we have a few choices: 1. Do nothing about requiring email as a problem reporting mechanism. Instead, take on the related issues of disclosure of the reporting mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or both. 2. Go ahead with the proposal to require

Re: CCADB disclosure of id-kp-emailProtection intermediates

Mozilla's April 15 deadline for disclosure of email intermediates that are not technically constrained has now passed. I have created the following bugs for the certificates listed at https://crt.sh/mozilla-disclos ures#undisclosed * Firmaprofesional:

Re: RAs and the BRs

On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There is a way to get zero-validation certs, totally legit, under the BRs. > Currently, the BRs permit pretty much free delegation of Registration > Authorities for everything

Define/clarify policy for transfer of intermediate CA certificates

This issue was brought up in the thread that kicked off the 2.6 root store policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose new unconstrained intermediate CA certificates within one week of creation. Section 8 covers [in my opinion] transfers of roots but not intermediates.

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

This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be required to contain only a single EKU.

Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

Section 5.3 of Mozilla policy states: All certificates that are capable of being used to issue new certificates, > and which directly or transitively chain to a certificate included in > Mozilla’s CA Certificate Program, MUST be operated in accordance with this > policy and MUST either be

Policy 2.6 Proposal: Require CAs to support problem reports via email

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud,

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer wrote: > As an alternative to requiring newly-issued subCA Certificates to be > listed in the relevant CP/CPS prior to issuing certificates, would it be > reasonable for Mozilla to require the Certificate Policies extension in >

Re: Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

I will consider this issue to be resolved by the change I made for issue 113: https://github.com/mozilla/pkipolicy/commit/55929f58da98a7af08fbf4bc2eb4537991de481b - Wayne On Wed, Apr 4, 2018 at 2:31 PM, Wayne Thayer wrote: > Last year we held a discussion on this topic

Re: Policy 2.6 Proposal: Require audits back to first issuance

The proposed language includes the requirement for compliance with both the BRs and Mozilla policy, so it's a better fit for the section of our policy titled "Inclusions" than the section titled "Baseline Requirements Conformance". To close out this discussion, I added the proposed language to

Re: Policy 2.6 Proposal: Require English Language Audit Reports

To close out this discussion, I've gone ahead with the proposed change, including the addition of the requirement that the English language version of the audit statement be an authoritative version: https://github.com/mozilla/pkipolicy/commit/e4cc785367350a46fc839639a28a92bd17d542e3 - Wayne On

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

Eric raised an issue distinct from 'the value of EV' that I think is important: Can certificate revocation be used as a form of censorship? As HTTPS becomes the default state of the web, it becomes more important to consider this issue and what should be done about it. I plan to discuss this with

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

On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman wrote: > > > On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi wrote: > >> >> So Apple Computer is misleading to customers of Apple Records, and Apple >> Records is misleading to customers of Apple Computer, is

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

On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi wrote: > > > On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer > wrote: > >> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> Indeed, I

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

On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Indeed, I find it concerning that several CAs were more than happy to take > Ian's money for the issuance, but then determined (without apparent cause > or evidence) to revoke

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

As an alternative to requiring newly-issued subCA Certificates to be listed in the relevant CP/CPS prior to issuing certificates, would it be reasonable for Mozilla to require the Certificate Policies extension in these certificates to contain a URL pointing to the relevant policy document(s)? I

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

I've gone ahead and removed references to ETSI TS 101 456 and TS 102 042 from the 2.6 branch of the policy: https://github.com/mozilla/pkipolicy/commit/49a07119a1fd5c887d4b506f60e210fad941b26a - Wayne On Tue, Mar 27, 2018 at 12:44 PM, Wayne Thayer wrote: > There has been

Re: Policy 2.6 Proposal: Require audits back to first issuance

Thank you for responding Matthias. On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Hi Wayne > > > Can anyone say if an equivalent public-facing > > report exists for ETSI audits? If so, I think we should require CAs

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

I've asked the Government of Korea to comment on this news article in their inclusion request (https://bugzilla.mozilla.org/show_bug.cgi?id=1377389). - Wayne On Wed, Apr 11, 2018 at 7:26 AM, jumping2gether--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > According to

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

Getting back to the earlier question about email certificates, I am now of the opinion that we should limit the scope of this policy update to TLS certificates. The current language for email certificates isn't clear and any attempt to fix it requires us to answer the bigger question of "under

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

On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/04/2018 18:55, Wayne Thayer wrote: > >> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos >> wrote: >> >> My proposal is "CAs MUST NOT distribute or

Re: Audits for new subCAs

On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen wrote: > > A CP is an optional document and may be maintained by an entity other > than the CA. For example there may be a common policy that applies to > all CAs that have a path to a certain anchor. So including the CA > list in

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

The Korea GPKI MOI CA certificates are in the inclusion process. As I noted in the bug, I've added information on the reported misissuance and OCSP errors to the inclusion request and I've noted the concerns raised about the auditor in their CCADB record. - Wayne On Thu, Apr 5, 2018 at 10:03 AM,

Re: Policy 2.6 Proposal: Require English Language Audit Reports

It has been pointed out to me that we should seek to create a policy that meets our needs without imposing a requirement for auditors to adopt the English language. For the CP/CPS, we address this concern by requiring a translation that "...must match the current version..." I am of the opinion

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

On Thu, Apr 5, 2018 at 4:58 AM, Doug Beattie wrote: > > I don’t think you should include #2 because it's a common practice to > issue one certificate for Secure Mail that is used to both sign and > encrypt, and this would preclude CA key generation for those types of

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

On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos wrote: > My proposal is "CAs MUST NOT distribute or transfer private keys and > associated certificates in PKCS#12 form through insecure physical or > electronic channels " and remove the rest. > > +1 - I support this

Re: FW: Complying with Mozilla policy on email validation

On Wed, Apr 4, 2018 at 3:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote: > > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < > > > My opinion on this method and on

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

On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Some thoughts: > > 1 - Should additional text be included to mandate strong cipher suites ( > http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to > find

Re: Policy 2.6 Proposal: Require English Language Audit Reports

On Wed, Apr 4, 2018 at 2:46 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote: > > Mozilla needs to be able to read audit reports in the English language > > without relying on machine

Re: FW: Complying with Mozilla policy on email validation

On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > > I agree that name constraints would be difficult to implement in this > > scenario, but I'm less convinced

Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

Last year we held a discussion on this topic [1] that concluded as follows: It is true that in the case of a legacy root, creating a new root with a > cross-sign is not technically all that complex (although it may take > some time organizationally) and then we could embed that new one. > > Given

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

This issue is titled “Make sure Forbidden practices are forbidden” - in other words, make sure they are banned in our policy. The only forbidden practice on our list [1] that’s not already covered by our policy is “Distributing Generated Private Keys in PKCS#12 Files”. It reads: CAs must never

Policy 2.6 Proposal: Audit requirements for new subCA certificates

In a recent discussion [1] we decided to clarify the audit requirements for new subordinate CA certificates. I’ve drafted a change that requires the new certificate to appear in the next periodic audits and in the CP/CPS prior to issuance:

Policy 2.6 Proposal: Require English Language Audit Reports

Mozilla needs to be able to read audit reports in the English language without relying on machine translations that may be inaccurate or misleading. I suggest adding the following sentence to the end of policy section 3.1.4 “Public Audit Information”: An English language version of the

Re: Policy 2.6 Proposal: Require audits back to first issuance

On Mon, Apr 2, 2018 at 9:28 PM, tom.prince--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, April 2, 2018 at 7:12:19 PM UTC-6, Wayne Thayer wrote: > > In section 2.3 (Baseline Requirements Conformance), add a new bullet that > > states "Before being

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

Thanks everyone for your input. This discussion has reached the conclusion that Mozilla should deny the inclusion request for the AC Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 As suggested, AC Camerfirma is welcome to submit a new inclusion request

Re: FW: Complying with Mozilla policy on email validation

On Tue, Apr 3, 2018 at 11:42 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Apr 3, 2018 at 12:19 PM, Ryan Hurst via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > For example, if we consider a CA

Re: FW: Complying with Mozilla policy on email validation

On Tue, Apr 3, 2018 at 10:19 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Reading this thread and thinking the current text, based on the > interpretation discussed, does not accommodate a few cases that I think are > useful. > > For example, if we

Re: Policy 2.6 Proposal: Require audits back to first issuance

i wrote: > > On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Mozilla began requiring BR audits for roots in our program in 2013 > [1], but > > > we have a vague policy s

Re: Audits for new subCAs

On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > While Entrust happens to do this, as a relying party, I dislike frequent > updates to CP/CPS documents just for such formal changes. > > This creates a huge loophole. The CP/CPS

Fwd: FW: Complying with Mozilla policy on email validation

I'm forwarding this for Tim because the list rejected it as SPAM. *From:* Tim Hollebeek *Sent:* Monday, April 2, 2018 2:22 PM *To:* 'mozilla-dev-security-policy' *Subject:* Complying with Mozilla policy on email validation Mozilla policy

Re: Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

ces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne > > Thayer via dev-security-policy > > Sent: Monday, March 26, 2018 2:50 PM > > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > > Subject: Policy 2.6 Proposal: Require

Re: Audits for new subCAs

On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi wrote: > > I think, for new CAs, the KGC report and the stated CP/CPS, combined with > ensuring that the next audit that covers the period of time stated on the > KGC report includes that certificate, seems like a reasonable balance.

Re: Audits for new subCAs

Tim, On Fri, Mar 30, 2018 at 7:00 AM, crawfordtimj--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote: > > On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy < >

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

On Thu, Mar 29, 2018 at 2:12 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer <wtha...@mozilla.com> wrote: > >> On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote: >> >>> >&g

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote: > > Hi Ramiro, > > > > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via > dev-security-policy < >

Re: Policy 2.6 Proposal: Require audits back to first issuance

On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote: > > I'm not fully sure I understand the proposal here. > > I would think that, for all roots created since 2012, the expectation > is that there is an unbroken series of audits, going from a Point in Time > audit (of the

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> When the Francisco Partners acquisition of Comodo was annou

Re: AC Camerfirma misissued certificates automated analysis results

Thank you for sharing this information. On Mon, Mar 26, 2018 at 9:24 AM, juanangel.martingomez--- via dev-security-policy wrote: > > > We've done an automated analysis on 2018-03-13 of TSL/SSL certificates > that have been issued by our CAs: > - Camerfirma

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

Hi Ramiro, On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > > Thanks again for your remarks. > In the end I am going to learn something of PKI :-). > Surely I do not get a full understanding of you solution, but

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

There has been a lot of confusion about the transition to the new standards, and I believe that this change makes it clearer that Mozilla no longer accepts audits based on the older ETSI standards. On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <

Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

Mozilla policy section 3.1.2.2 states: ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods > ending in July 2017 or earlier. > Now that we are past this deadline, I propose that we remove all references to ETSI TS 102 042 and 101 456 from the policy. This is:

Policy 2.6 Proposal: Permit issuance during change in ownership

When the Francisco Partners acquisition of Comodo was announced, it was pointed out [1] that a strict reading of the current policy section 8.1 would have forced Comodo to stop issuing certificates for some period of time: If the receiving or acquiring company is new to the Mozilla root program,

Policy 2.6 Proposal: Require audits back to first issuance

Mozilla began requiring BR audits for roots in our program in 2013 [1], but we have a vague policy statement in section 3.1 regarding audit requirements prior to inclusion: Before being included and periodically thereafter, CAs MUST obtain certain > audits… > BR section 8.1 contains the

Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

Mozilla policy section 2.2(2) requires validation of email addresses for S/MIME certificates, but doesn't require disclosure of these practices as it does for TLS certificates. I propose adding the following language from 2.2 (3) (TLS) to 2.2(2) (S/MIME): The CA's CP/CPS must clearly specify the

Re: Audits for new subCAs

at 6:18 PM, Peter Bowen <pzbo...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Recently I've received a few questions about audit requirements for > > subordinate CAs

Re: Audits for new subCAs

Apologies. By choosing to use the term TSP when referring to an organization operating a PKI, I thought I had made my meaning clear. I now realize I inferred "certificate" when I used the term "subordinate CA". I meant "subordinate CA certificate" in all cases where I wrote "subordinate CA" or

Re: Policy 2.6 Proposal: Update domain validation requirements

I've drafted these changes: https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8 On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek wrote: > > > * Add a new bullet on IP Address validation that forbids the use of BR > > 3.2.2.5(4) (“any

Re: TURKTRUST Non-compliance

Given that TURKTRUST has stated that the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" root is no longer being audited or complying with new policies, I believe there is consensus that it should be removed from the Mozilla root store. Kathleen will file a bug for that action. Ryan

Audits for new subCAs

Recently I've received a few questions about audit requirements for subordinate CAs newly issued from roots in our program. Mozilla policy section 5.3.2 requires these to be disclosed "within a week of certificate creation, and before any such subCA is allowed to issue certificates.", but says

Re: Policy 2.6 Proposal: Move Compliance Date into policy

ity-policy@lists.mozilla.org> wrote: > On 21/03/2018 10:43, Ryan Sleevi wrote: > >> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> I think it's reasonable - especial

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

le change. > > On Tue, Mar 20, 2018 at 2:45 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi <r...@sleevi.com> wrote: >> >> > >> > So, one aspect of this is th

Re: Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

Hearing no objections, I've added this change to the 2.6 branch: https://github.com/mozilla/pkipolicy/commit/5490d165f0d9b55cb75e5851303a21f9a250e199 ​ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Logius PKIoverheid response to Action #2 in the January 2018 CA Communication

Thank you for the response Jochem. I am glad to hear that Logius has evaluated the risk and, given the passage of ballot 218, is moving to other methods of domain validation. - Wayne On Fri, Mar 16, 2018 at 5:55 AM, Berge, J. van den (Jochem) - Logius via dev-security-policy

Re: DigiCert .onion certificates without Tor Service Descriptor Hash extension

Jeremy filed the following incident report at https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 : 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug),

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Wed, Mar 21, 2018 at 2:43 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> >> > I am specifically thinking of CP/CPS updat

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi <r...@sle

Re: TURKTRUST Non-compliance

On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think it's not going to be productive to spend a lot of time on the list > debating whether or not a CA can opt out of full BR compliance by simply > saying "we're winding

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote: > > Looking through [1], it seems like the Compliance Date has only differed > from the Publication Date once (with 2.0). > It's not clear to me that the 2.5 failure to adoption was related to > ambiguity around compliance

<    1   2   3   4   5   6   7   >