Re: Mozilla's Response to Camerfirma's Compliance Issues

[Wayne Thayer via dev-security-policy]

Ben,

Here are my thoughts:

- First off, we have given Camerfirma the benefit of the doubt for too long
and Mozilla can't continue to trust Camerfirma while they remediate these
problems. With all the documented issues and Camerfirma's response, that
would represent an unacceptable ongoing risk to Mozilla's users. Distrust
is the first step.
- While most documented incidents are related to TLS certificates, I see
nothing to indicate that Camerfirma manages S/MIME any better. It's more
likely that we simply don't know about many of the email certificate issues
due to the lack of CT enforcement. Mozilla should act to protect
Thunderbird users as well.
- Given the number of issues that have been documented with Camerfirma's
delegated SubCAs, any remediation plan that has them keeping control of CA
certificates is a non-starter for me. Having said that, I don't think
Mozilla should forbid future delegated SubCAs, but rather require
Camerfirma to gain approval for each one (as is currently required by
section 8.1 of the Mozilla Root Store Policy).
- Camerfirma's current certificate hierarchies are quite outdated and
represent a significant risk independent of their operator. They must be
replaced as part of any remediation plan.
- To regain trust, Camerfirma will need to take adequate time to complete
the remediations they have outlined and present evidence of the
improvements from their auditor as part of a new root inclusion request.

Thanks,

Wayne

On Tue, Jan 26, 2021 at 4:01 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> So far there have been several good comments.  Please keep them coming.
>
> I want to take this opportunity just to clarify a few of things.
>
> First, it has been Mozilla's long-standing position that, "We believe that
> the best approach to safeguarding secure browsing is to work with CAs as
> partners, to foster open and frank communication, and to be diligent in
> looking for ways to keep our users safe."  So, expect that we will take a
> well-thought and deliberate approach to this issue with Camerfirma.
>
> Second, many of the compliance issues have dealt with requirements
> applicable to server certificates, yet only two roots of the four trusted
> by Mozilla have the websites bit enabled.
>
> Chambers of Commerce Root – 2008 (Email and Websites)
>
> 063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0
>
> Global Chambersign Root – 2008  (Email and Websites)
>
> 136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA
>
> Chambers of Commerce Root  (Email only)
>
> 0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3
>
> Global Chambersign Root (Email only)
>
> EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED
> So there is another issue that needs to be considered, if distrust is
> chosen, whether to remove just the websites trust bit or to take action
> against all 4 roots, and if so, on what basis?
>
> (Also, note that Camerfirma has two other roots that are not included in
> the Mozilla trust store. They are the CHAMBERS OF COMMERCE ROOT – 2016 and
> the GLOBAL CHAMBERSIGN ROOT - 2016.)
>
> Thanks,
>
> Ben
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Camerfirma's Compliance Issues

[Wayne Thayer via dev-security-policy]

On Sat, Dec 19, 2020 at 1:03 AM Ramiro Muñoz via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ben, Ryan, Burton and all:
>
> Camerfirma will present its claims based on a description of the problems
> found by associating the references to the specific bugs.
> After making a complete analysis of the bugs as presented by Ben, always
> considering that bugs are the main source of truth, we see that the
> explanations offered by Camerfirma could generally be better developed. We
> hope to make up for these deficiencies with this report.
>
>
It's worth pointing out that in April 2018, the Camerfirma '2016 roots'
inclusion request [1] was denied [2] after a host of issues were
documented. At that time it was made clear that ongoing trust in the older
roots was in jeopardy [3]. While some progress was made, the number,
severity, and duration of new and ongoing bugs since then remains quite
high. In this context, I don't find these new disclosures and commitments
from Camerfirma to form a convincing case for their trustworthiness.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=986854
[2]
https://groups.google.com/g/mozilla.dev.security.policy/c/skev4gp_bY4/m/snIuP2JLAgAJ
[3]
https://groups.google.com/g/mozilla.dev.security.policy/c/skev4gp_bY4/m/ZbqPhO5FBQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

[Wayne Thayer via dev-security-policy]

On Thu, Dec 17, 2020 at 10:32 AM Aaron Gable via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> One potential option (5) would be to go even further than (2), and remove
> the OCSP paragraph from the MRSP§6 entirely. Given that MRSP§2.3 says "CA
> operations relating to issuance of certificates capable of being used for
> SSL-enabled servers MUST also conform to the latest version of the [BRs]",
> it seems clear that BR§4.9.10 is already included in its entirety. You
> could update MRSP§2.3 to say "...relating to issuance and revocation..." if
> you wanted to be even more explicit.
>
>
This all makes sense when applied to TLS certificates, but as Ben mentioned
the current language also applies to S/MIME. My instinct would be to either
do nothing to the current MRSP language, or to explicitly have it apply to
S/MIME and reference the BRs for TLS. If there is a desire to have the BR
4.9.10 language apply to S/MIME, I'd suggest we make that very clear.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sectigo to Be Acquired by GI Partners

[Wayne Thayer via dev-security-policy]

Rob: what, if any, changes will be made to the Sectigo CP/CPS as a result
of this change of control?

Thanks,

Wayne

On Thu, Oct 1, 2020 at 1:55 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  As announced previously by Rob Stradling, there is an agreement for
> private investment firm GI Partners, out of San Francisco, CA, to acquire
> Sectigo. Press release:
> https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners
> .
>
>
> I am treating this as a change of legal ownership covered by section 8.1
> <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
> >
> of the Mozilla Root Store Policy, which states:
>
> > If the receiving or acquiring company is new to the Mozilla root program,
> > it must demonstrate compliance with the entirety of this policy and there
> > MUST be a public discussion regarding their admittance to the root
> program,
> > which Mozilla must resolve with a positive conclusion in order for the
> > affected certificate(s) to remain in the root program.
>
> In order to comply with policy, I hereby formally announce the commencement
> of a 3-week discussion period for this change in legal ownership of Sectigo
> by requesting thoughtful and constructive feedback from the community.
>
> Sectigo has already stated that it foresees no effect on its operations due
> to this ownership change, and I believe that the acquisition announced by
> Sectigo and GI Partners is compliant with Mozilla policy.
>
> Thanks,
>
> Ben
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Change of Root ownership structure

[Wayne Thayer via dev-security-policy]

Given that no other concerns have been raised, I consider this request to
have been "resolved with a positive conclusion" as required by Mozilla
policy section 8.1.

Arnold: please update the information in CCADB (or ask Kathleen if you are
unable) when this change takes effect.

- Wayne

On Wed, Apr 29, 2020 at 11:56 AM Wayne Thayer  wrote:

> Thank you for making this announcement Arnold. This change of legal
> ownership is covered by section 8.1 of the Mozilla Root Store Policy,
> including the following statement:
>
> If the receiving or acquiring company is new to the Mozilla root program,
>> it must demonstrate compliance with the entirety of this policy and there
>> MUST be a public discussion regarding their admittance to the root program,
>> which Mozilla must resolve with a positive conclusion in order for the
>> affected certificate(s) to remain in the root program.
>>
>
> Technically I believe the statement above applies to this situation, so I
> would like to formally begin the discussion period for this change in legal
> ownership of the T-Systems CA by requesting additional thoughtful and
> constructive feedback from the community. I will plan to keep the
> discussion period open for a minimum of 3 weeks.
>
> T-Systems has already indicated that no changes to their CP/CPS are
> planned aside from the company name.
>
> On Tue, Apr 28, 2020 at 7:18 AM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Thanks, Arnold.
>>
>> Our change was more complex, so we had to go to a more cumbersome
>> process, including audits of the ownership receiving party.
>>
>> What I guess it's required now is an explicit confirmation from Mozilla
>> to say if such a direct transfer to an entity not member of the program is
>> compliant with section 8.1 of the policy.
>>
>>
> I believe that the plan described by T-Systems is compliant with Mozilla
> policy.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Status of the bugzilla bug list

[Wayne Thayer via dev-security-policy]

I'd just like to add or reinforce a few points based on my approach to
managing open incident bugs:

* I have leaned heavily to the side of leaving bugs open if there is the
potential for additional questions, and always if there are any incomplete
remediations. This means that bugs do tend to stay open longer than may be
considered ideal, but it ensures that the follow-up is as complete as
possible.
* This has a somewhat natural result, given that closing bugs is not the #1
priority, of bugs being left open when they really are ready to be closed.
Thus any metric based on if/when a bug is closed is not a good
representation of the CA's diligence.
* I am happy to review any bug that a CA feels is stuck in that state -
just set the needs-info flag for me in the bug. I suspect the same goes for
Ryan and Ben.
* I agree that the attention paid to incident bugs by CAs is a meaningful
indicator of their professionalism, if not their trustworthiness. Bug
hygiene should matter to CAs.

- Wayne

On Tue, May 19, 2020 at 11:40 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, May 19, 2020 at 2:22 PM Matthias van de Meent
>  wrote:
> > I agree that for any one bug, this metadata is not anything to make
> > decisions over, but when looking over e.g. the last 3 years, you can
> > start making more informed guesses on the metadata only. E.g. when you
> > find that a CA has consistently had 4-8 compliance issues open with
> > only sporadic updates, although this doesn't tell anything about this
> > CA in and of itself, it does give a (basic) sense of concern. But, as
> > I've heard, the metadata is even less precise than I'd previously
> > expected, and thus this road to knowledge is yet to be built.
>
> Exactly, for better or worse.
>
> I'm not sure, even in our idealized world, we'd necessarily /want/
> Bugzilla to be this. Historically, the approach has been to
> systematize patterns (e.g. https://wiki.mozilla.org/CA:Symantec_Issues
> , https://wiki.mozilla.org/CA:PROCERT_Issues ,
> https://wiki.mozilla.org/CA:WoSign_Issues ), to try and provide that
> information distilled in a way that's useful to decision making and
> policy stakeholders.
>
> It's difficult to see that purely encapsulated in the bug metadata,
> because there's issues where something seemingly small can be quite
> eye opening, and something seemingly major can be actually quite
> benign. The dimension of severity is subjective across a number of
> dimensions, and so there's no quick and pert way of summarizing that.
>
> I'm not trying to defend the status quo, to be sure. There's a lot I
> would love to see improved here, it's just not the highest priority in
> the overall set of issues. For example, I'd rather see things like ALV
> for intermediates, improvements to auditor qualifications,
> improvements to audits themselves, structural improvements to the BRs
> (for which I have many in-flight pull requests), etc. Similarly, I'm
> concerned about patterns of CAs simply not responding in a timely
> fashion ( e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1563579 ),
> and would love to improve the tooling to detect and alert on this. Or,
> for that matter, better tooling to help us digest and correlate
> responses across CAs, or identify when an issue is a duplicate (e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1638898 ) or not yet
> revoked (e.g. http://misissued.com ). I have a long list of things
> that could be improved, for sure, but alas, time and resource limited
> :)
>
> > To continue on your metaphor: I do not expect Tier 1, but maybe more
> > like somewhere between Tier 2 en Tier 3? A biweekly, monthly or any
> > regular check for open compliance issues waiting for a reply from
> > Mozilla would already improve the (observed) situation tremendously.
>
> I don't disagree on room for improvements, for sure, but I'm still
> going to push back on a Mozilla obligation here, because I don't think
> that's reasonable. The interesting thing about this particular
> situation is that if CAs consistently adhered to their existing
> expectations, it does tend to end up resolved quicker. The ball is
> placed consistently in the CA's court to drive this to resolution, and
> they're expected to be continually doing that. This is, in part, due
> to how Bugzilla searching, filtering, and alerting works. This again
> goes back to where there's room for improvement here, if you're
> passionate, and help is welcome :)
>
> This goes back to workflow. If CAs followed the defined workflow, "it
> works". You're right that CAs aren't following the defined workflow,
> and so it's not working as ideally as possible, and that makes some of
> the data you want more difficult. Should Mozilla start removing CAs
> that don't adhere to that work flow? In some extreme cases (e.g. see
> above), it's probably justified, if not outright necessary. In other
> cases, that may be seen as extreme. The important thing here, 

Re: Request to Include certSIGN Root CA G2 certificate

[Wayne Thayer via dev-security-policy]

The ETSI audit attestation statement referenced by Ben [1] lists 6
non-conformities that were to be corrected within 3 months of the onsite
audit that occurred on 2020-02-10 until 2020-02-14:

Findings with regard to ETSI EN 319 401:
-REQ-7.8-06–Documentation shall be improved

Findings with regard to ETSI EN 319 411-1:
-REG-6.3.1-01–Implementation shall be improved
-GEN-6.5.1-04-Implementation shall be improved

Findings with regard to ETSI EN 319 411-2:
-SDP-6.5.1-02 -Implementation shall be improved
-GEN-6.6.1-05–Documentation shall be improved
-CSS-6.3.10-13–Documentation shall be improved

I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
signing certificates shall be created under, at least, dual control.

I'd like to see an explanation of these non-conformities and the
remediation from certSIGN, and confirmation from LSTI that they have been
fixed.

- Wayne

[1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635

On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This request is for inclusion of the certSIGN Root CA G2 certificate and to
> turn on the Websites trust bit and for EV treatment.
>
>
> The request is documented in Bugzilla and in the CCADB as follows:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
>
> (Summary of info gathered and verified, URLs for test websites, etc.)
>
>
>
> * certSIGN’s BR Self Assessment is here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9052673
>
> The Certsign document repository can be found here:
>
> https://www.certsign.ro/en/certsign-documents/policies-procedures
>
> * Root Certificate Locations:
>
> http://crl.certsign.ro/certsign-rootg2.crt
>
> http://registru.certsign.ro/certcrl/certsign-rootg2.crt
>
> http://www.certsign.ro/certcrl/certsign-rootg2.crt
>
>
> https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305
>
>
> https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem
>
>
> * EV Policy OID:   2.23.140.1.1
>
> * CRL URL: http://crl.certsign.ro/certsign-rootg2.crl
>
> * OCSP URL: http://ocsp.certsign.ro
>
>
>
> * Audit: See https://bugzilla.mozilla.org/attachment.cgi?id=9142635 (
>
> http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1612-163_V10_Certsign_S.pdf
> )
> which shows that a recent annual audit was performed on the certSIGN Root
> CA G2 by LSTI Group according to ETSI EN 319 411-2, V2.2.2 (2018-04)”,
> “ETSI EN 319 411-1, V1.2.2 (2018-04)” and “ETSI EN 319 401, V2.2.1
> (2018-04)” as well as the CA/Browser Forum’s “EV SSL Certificate
> Guidelines, version 1.7.1” and “Baseline Requirements, version 1.6.7”
> considering the requirements of the “ETSI EN 319 403, V2.2.2 (2015-08)” for
> the Trust Service Provider Conformity Assessment.
>
>
> * CP/CPS Review
>
> Ryan Sleevi conducted a preliminary review the PKI Disclosure Statement and
> CPS - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13
>
> I followed up, and now Comment #24 in Bugzilla shows the latest responses
> from Certsign - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c24
>
>
>
> This begins the 3-week comment period for this request.
>
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
>
> Thanks,
> Ben
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla's Expectations for OCSP Incident Reporting

[Wayne Thayer via dev-security-policy]

It was recently reported [1] that IdenTrust experienced a multi-day OCSP
outage about two weeks ago. Other recent OCSP issues have resulted in
incident reports [3][4], so I am concerned that IdenTrust didn't report
this, and I created a bug [5] to ensure that we track the issue (assuming
the report of an extended outage is accurate).

I also created an issue [6] suggesting that Mozilla clarify expectations
for reporting CRL and OCSP outages. These services are notoriously
unreliable and I doubt that a constant barrage of reports for brief outages
would be manageable. I believe that Mozilla does expect CAs to report
"significant" outages, but there is currently no guidance to help CAs
determine when they should file a report.

- Wayne

[1]
https://www.feistyduck.com/bulletproof-tls-newsletter/issue_64_gcc_code_analyzer_finds_bug_in_openssl
[2]
https://community.letsencrypt.org/t/identrust-ocsp-producing-errors/120677
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1622505
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1630040
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1636544
[6] https://github.com/mozilla/pkipolicy/issues/214
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Change of Root ownership structure

[Wayne Thayer via dev-security-policy]

Thank you for making this announcement Arnold. This change of legal
ownership is covered by section 8.1 of the Mozilla Root Store Policy,
including the following statement:

If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program.
>

Technically I believe the statement above applies to this situation, so I
would like to formally begin the discussion period for this change in legal
ownership of the T-Systems CA by requesting additional thoughtful and
constructive feedback from the community. I will plan to keep the
discussion period open for a minimum of 3 weeks.

T-Systems has already indicated that no changes to their CP/CPS are planned
aside from the company name.

On Tue, Apr 28, 2020 at 7:18 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks, Arnold.
>
> Our change was more complex, so we had to go to a more cumbersome process,
> including audits of the ownership receiving party.
>
> What I guess it's required now is an explicit confirmation from Mozilla to
> say if such a direct transfer to an entity not member of the program is
> compliant with section 8.1 of the policy.
>
>
I believe that the plan described by T-Systems is compliant with Mozilla
policy.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal for New CA Certificate Policy Module Owner

[Wayne Thayer via dev-security-policy]

This change has been made and Kathleen Wilson is now the CA Certificate
Policy Module Owner.

On Fri, Mar 20, 2020 at 1:34 PM Wayne Thayer  wrote:

> I posted the following message in the mozilla.governance forum.
>
> If you would like, please feel free to comment here in m.d.s.p.
>
> - Wayne
>
> -- Forwarded message -
> From: Wayne Thayer 
> Date: Fri, Mar 13, 2020 at 11:11 AM
> Subject: Proposal for New CA Certificate Policy Module Owner
> To: 
>
>
> I’d like to propose making Kathleen Wilson the new owner of the “CA
> Certificate Policy” module. Since leaving my job at Mozilla in January I
> have continued to provide oversight for this module, and I intend to remain
> involved in the future. However, given my diminished focus on this
> important work, I believe now is a good time to transition the
> responsibility for this module back to Kathleen.
>
> As an emeritus owner of this module, owner of the CA Certificates module,
> and long-time member of this community, Kathleen's qualifications speak for
> themselves. For reference, Kathleen became CA Certificates Module owner and
> CA Certificate Policy peer in August 2010 [1] and CA Certificate Policy
> Module owner in January 2012 [2]. She led the updates to the following
> versions of Mozilla Root Store Policy [3]: 2.0, 2.1, 2.2. Kathleen has been
> writing and maintaining CA program wiki pages since 2010. [4]
>
> There are two modules related to Mozilla’s CA Program which govern the
> default set of certificates in Network Security Services (NSS) and
> distributed in Mozilla’s software products. They are:
>
> 1) Mozilla CA Certificate Policy [5]
> Description: Definition and enforcement of policies governing
> Certification Authorities, their root certificates included in Mozilla
> software products, and intermediate and end-entity certificates within
> those CA hierarchies.
> Current Owner: Wayne Thayer -- Proposed Owner: Kathleen Wilson
> Current Peer(s): Kathleen Wilson -- Proposed Peer: Wayne Thayer
>
> 2) CA Certificates [6]
> Description: Determine which root certificates should be included in
> Mozilla software products, which trust bits should be set on them, and
> which of them should be enabled for EV treatment. Evaluate requests from
> Certification Authorities (CAs) for inclusion or removal of root
> certificates, and for updating trust bit settings or enabling EV treatment
> for already included root certificates.
> Owner: Kathleen Wilson  -- no change
> Peer(s): Ryan Sleevi, Wayne Thayer -- no change
>
> Thanks,
>
> Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.governance/doYvOMfMuJc/aSt4aTEj4HMJ
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/euJzuS737-Q/hX94NnNF5xUJ
> [3] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/qiSIaQ6ZvyU/fY7JD4EUd9QJ
> [5] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
> [6] https://wiki.mozilla.org/Modules/All#CA_Certificates
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root

[Wayne Thayer via dev-security-policy]

This issue is now documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=1625767

On Tue, Mar 24, 2020 at 12:29 PM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Investigation of the situation:
>
> 2009-03-06
> Microsec Ltd. issued the following root certificate:
> - Microsec e-Szigno Root CA 2009
> Expiry date: 2038-01-18
>
> 2009-03-09
> Microsec Ltd. issued the following subordinate CA certificates:
> - Advanced Class 2 e-Szigno CA 2009
> - Advanced Class 3 e-Szigno CA 2009
> - Advanced Pseudonymous e-Szigno CA 2009
> - Qualified Pseudonymous e-Szigno CA 2009
> - Qualified e-Szigno CA 2009
>
> Expiry date of each of these certificates: ‎2038-01-17
>
>
> 2009-06-16
> Microsec reissued the following root certificate:
> - Microsec e-Szigno Root CA 2009
> Expiry date: 2029-12-30
> In the certificate the following fields were changed: validity
> notBefore and notAfter dates, and the certificatePolicies extension.
>
> Microsec reissued the following subordinate CA certificates:
> - Advanced Class 2 e-Szigno CA 2009
> - Advanced Class 3 e-Szigno CA 2009
> - Advanced Pseudonymous e-Szigno CA 2009
> - Qualified Pseudonymous e-Szigno CA 2009
> - Qualified e-Szigno CA 2009
>
> Expiry date of each of these certificates (aligned with the new
> root): ‎2029-12-29
> In the certificates the following fields were changed: validity
> notBefore and notAfter dates, and the certificatePolicies extension.
>
>
> 2009-12-02
> Microsec reissued the following root certificate:
> - Microsec e-Szigno Root CA 2009
> Expiry date was unchanged: 2029-12-30
> The certificatePolicies extension was dropped from the
> certificate, and the place of the keyUsage extension changed within the
> ASN.1 structure.
>
> Microsec reissued the following subordinate CA certificates:
> - Advanced Class 2 e-Szigno CA 2009
> - Advanced Class 3 e-Szigno CA 2009
> - Advanced Pseudonymous e-Szigno CA 2009
> - Qualified Pseudonymous e-Szigno CA 2009
> - Qualified e-Szigno CA 2009
>
> In the certificates the validity notBefore date changed to the
> issuance date, the certificatePolicies extension changed to anyPolicy, and
> the URL pointing to the location of CPS documents changed to a uniform
> value for qualified and non-qualified certificates.
>
>
> In summary, all above certificates were reissued by Microsec two
> times during 2009. In these two cases each certificate was reissued with an
> unchanged public key and unchanged Subject DN as compared to the previous
> corresponding certificate, while some other fields were changed. The CA
> certificates were published (apart from the website) through the Microsec
> e-Szigno signature creation and validation application, and were (may have
> been) also published in the trusted certificate stores of other software.
>
> The CA certificates were primarily intended for electronic
> signatures. It is necessary to be able to validate digital signatures
> chaining up to these CAs in the long term (50 years). Since electronic
> signature (end user) certificates only contain the Subject DN of the issuer
> CA, the reissued (doppelganger) subordinate CA certificates with the same
> Subject DN and key are equally suitable for certificate chain building. As
> a consequence, revocation of some subordinate CA certificates might cause
> validation errors (false negatives) in some signature validation
> applications, therefore, Microsec maintained all versions of the CA
> certificates as valid.
> This solution worked without problems in the creation and
> validation of signatures, and Microsec has not received any error reports
> in relation to this throughout the years.
> Microsec has always published and promoted the use of the latest
> version of the CA certificates, but could not prevent the use of the
> earlier versions.
>
>
> 2016-11
> Having set up the CCADB, Mozilla introduced more and more
> stringent checks, and earlier versions of some of the CA certificates were
> added to the database.
> Upon the notification from Mozilla, Microsec investigated the
> situation, and requested to maintain the validity of the affected CA
> certificates due to reasons explained above. Mozilla temporarily approved
> to keep all CA certificate verions valid.
>
>
> 2019-11
> In relation to the improvement of the CCADB system Mozilla
> launched automated tools for audit letter validation (ALV). These controls
> require each subordinate CA certificate in CCADB to be included in one of
> the audit letters. The automatic checking is based on the SHA-256
> fingerprint of the certificate.
>
> During the validation of the Microsec audit letters the ALV tool
> found 9 

Re: Sectigo: Failure to revoke certificate with previously-compromised key within 24 hours

[Wayne Thayer via dev-security-policy]

I've created a bug to track this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1625715

- Wayne

On Thu, Mar 26, 2020 at 11:33 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> At 2020-03-20 03:02:43 UTC, I sent a notification to sslab...@sectigo.com
> that certificate https://crt.sh/?id=1659219230 was using a private key
> with
> SPKI fingerprint
> 4c67cc2eb491585488bab29a89899e4e997648c7047c59e99a67c6123434f1eb, which was
> compromised due to being publicly disclosed.  My e-mail included a link to
> a
> PKCS#10 attestation of compromise, signed by the key at issue.  An MX
> server
> for sectigo.com accepted this e-mail at 2020-03-20 03:02:50 UTC.
>
> This certificate was revoked by Sectigo, with a revocation timestamp of
> 2020-03-20 19:37:48 UTC.
>
> Subsequently, certificate https://crt.sh/?id=2614798141 was issued by
> Sectigo, and uses a private key with the same SPKI as that previously
> reported.  This certificate has a notBefore of Mar 23 00:00:00 2020 GMT,
> and
> embeds two SCTs issued at 2020-03-23 05:55:53 UTC.  At the time of writing,
> the crt.sh revocation table does not show this certificate as revoked
> either
> via CRL or OCSP:
>
> Mechanism   ProviderStatus  Revocation Date Last
> Observed in CRLLast Checked (Error)
> OCSPThe CA  Goodn/a n/a
>  2020-03-27  06:27:23 UTC
> CRL The CA  Not Revoked n/a n/a
>  2020-03-27  04:44:26 UTC
>
> Based on previous discussions on m.d.s.p, I believe Sectigo's failure to
> revoke this certificate within 24 hours of its issuance is a violation of
> the BRs, and hence Mozilla policy.
>
> - Matt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Musings on mass key-compromise revocations

[Wayne Thayer via dev-security-policy]

Thank you Matt. I really appreciate the detailed summary and look forward
to your specific improvement proposals.

- Wayne

On Sat, Mar 28, 2020 at 1:12 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I've been asked to provide some "big-picture" thoughts on how the process
> for key compromise revocations works, doesn't work, and could be improved.
> This is based on the work that I've done over the past month or so,
> requesting revocation of certificates which have had their private keys
> disclosed by being posted to some public location.
>
> This e-mail is intended to provide a summary of what I did and how it all
> went, with a summary of the things that I came across which I feel could
> stand to be improved.  Most of these improvements will likely come through
> changes to the Mozilla or CCADB policies, or via changes to the BRs.  A
> couple are things that CAs themselves need to take on board, as they aren't
> "policy" matters as such, but are still issues of concern.
>
> As the exact nature of how a problem may be solved will, no doubt, engender
> no small amount of debate, I intend (unless someone tells me I'm once again
> being a goose), to provide separate e-mail thread-starters on the details
> of the issues I found, along with my proposals for how the issues might be
> solved.  I will be providing a summary of the issues I found, but all the
> gory minutiae will be provided in later e-mail threads.
>
> One final thing before I get started: I'd like to give a big shout-out to
> Rob Stradling and anyone else who is involved in making crt.sh happen, and
> Sectigo for sponsoring its existence.  Everything I've done here would have
> been a zillion times harder if there wasn't already a database of every
> CT-logged certificate available for me to hammer on.  It is an Internet
> Treasure.
>
> So to kick things off, let's have some stats.
>
> In the past month, I've requested revocation of over 2,800 certificates and
> pre-certs[1], across 11 different "CA organisations" (I'm counting one "CA
> organisation" as any number of issuing CAs that share a common problem
> reporting address).  These certificates were using a total of 1,217
> distinct
> private keys.  These keys come from multiple sources, but based on an
> analysis of a sample of around 3% of those keys, the overwhelming majority
> come from GitHub repositories which were at one time -- and in many cases
> still are -- publicly available.
>
> As a bit of an aside, at the time of writing, there are a further 52 SPKIs,
> representing an unknown number of certificates, for which I have yet to
> request revocation from the relevant CAs.  These are keys which have
> entered
> the pwnedkeys database since around the 23rd March.  In addition, since the
> 23rd, I've automatically requested revocation of 17 certificates (from 16
> SPKIs) through Let's Encrypt's automated ACME-based revocation API (and
> also
> deactivated about eight Let's Encrypt accounts whose private keys were
> posted
> publicly...)
>
> An interesting thing to do is to compare "issuance volume" against
> "disclosed keys".  This isn't a reflection of the CAs themselves, because a
> CA can't control what their customers do with their keys.  Given the
> differences in issuance methodologies, target markets, and business
> practices between CAs, it's worth taking a look at different CAs'
> "disclosure rate", I guess you'd call it, and consider what impact, if any,
> tho differences between CAs' operations might have on the likelihood of
> their customers disclosing their keys.
>
> I've taken issuance volume as being the total number of unexpired
> certificates (as of a few days ago) issued by a "CA organisation" (again,
> all the issuing CAs that share a common problem reporting address).
> Pre-certs get in the way, unfortunately, but it's not trivial to say "only
> count a pre-cert if there isn't a corresponding cert" in crt.sh, so we have
> what we have.
>
> Of the 11 CA orgs that I sent at least one revocation request to, here are
> their numbers:
>
> CA org  SPKIs   Issued  Issued / SPKI
>
> Digicert832 3402992040901
> QuoVadis23  73184   3181
> GlobalSign  47  1650873 35124
> DFN-Verein  3   52945   17648
> GoDaddy 38  4264928 112234
> Sectigo 128 41718165325923
> Entrust 6   576093  96015
> SECOM   1   118748  118748
> Certum  5   329047  65809
> Let's Encrypt   133 122438321   920588
>
> I took the opportunity, also, to look at a couple of larger CAs (by
> issuance
> volume) which have had zero certificates with keys I found: pki.goog
> (issued
> 1284676), and Amazon (issued 2308004).  Clearly, the best approach to
> avoiding key disclosure is never 

Fwd: Proposal for New CA Certificate Policy Module Owner

[Wayne Thayer via dev-security-policy]

I posted the following message in the mozilla.governance forum.

If you would like, please feel free to comment here in m.d.s.p.

- Wayne

-- Forwarded message -
From: Wayne Thayer 
Date: Fri, Mar 13, 2020 at 11:11 AM
Subject: Proposal for New CA Certificate Policy Module Owner
To: 


I’d like to propose making Kathleen Wilson the new owner of the “CA
Certificate Policy” module. Since leaving my job at Mozilla in January I
have continued to provide oversight for this module, and I intend to remain
involved in the future. However, given my diminished focus on this
important work, I believe now is a good time to transition the
responsibility for this module back to Kathleen.

As an emeritus owner of this module, owner of the CA Certificates module,
and long-time member of this community, Kathleen's qualifications speak for
themselves. For reference, Kathleen became CA Certificates Module owner and
CA Certificate Policy peer in August 2010 [1] and CA Certificate Policy
Module owner in January 2012 [2]. She led the updates to the following
versions of Mozilla Root Store Policy [3]: 2.0, 2.1, 2.2. Kathleen has been
writing and maintaining CA program wiki pages since 2010. [4]

There are two modules related to Mozilla’s CA Program which govern the
default set of certificates in Network Security Services (NSS) and
distributed in Mozilla’s software products. They are:

1) Mozilla CA Certificate Policy [5]
Description: Definition and enforcement of policies governing Certification
Authorities, their root certificates included in Mozilla software products,
and intermediate and end-entity certificates within those CA hierarchies.
Current Owner: Wayne Thayer -- Proposed Owner: Kathleen Wilson
Current Peer(s): Kathleen Wilson -- Proposed Peer: Wayne Thayer

2) CA Certificates [6]
Description: Determine which root certificates should be included in
Mozilla software products, which trust bits should be set on them, and
which of them should be enabled for EV treatment. Evaluate requests from
Certification Authorities (CAs) for inclusion or removal of root
certificates, and for updating trust bit settings or enabling EV treatment
for already included root certificates.
Owner: Kathleen Wilson  -- no change
Peer(s): Ryan Sleevi, Wayne Thayer -- no change

Thanks,

Wayne

[1]
https://groups.google.com/d/msg/mozilla.governance/doYvOMfMuJc/aSt4aTEj4HMJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/euJzuS737-Q/hX94NnNF5xUJ
[3] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/qiSIaQ6ZvyU/fY7JD4EUd9QJ
[5] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
[6] https://wiki.mozilla.org/Modules/All#CA_Certificates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Acceptable forms of evidence for key compromise

[Wayne Thayer via dev-security-policy]

I've created https://github.com/mozilla/pkipolicy/issues/205 to consider
adding a requirement to a future version of Mozilla policy for CAs to
either support a standardized mechanism for proving key compromise, or to
publish acceptable mechanism(s) in their CPS.

- Wayne

On Mon, Mar 2, 2020 at 2:38 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Using ACME as the revocation reporting mechanism moves the issue from
> using a bespoke proof-of-possession/revocation request protocol to a known
> address (i.e., the problem-reporting address disclosed in each CA’s
> CPS/CCADB) to an issue of using a known proof-of-possession/revocation
> protocol to a largely non-discoverable address (i.e., the “revoke-cert”
> endpoint of each CA’s ACME server).
>
>
>
> There is no central registry of ACME directory URLs, so still significant
> work would be required to make ACME’s “revoke-cert” endpoint useful across
> CAs.
>
>
>
> As an alternative, a standard “revocation request” format could be
> developed that leverages the relative discoverability of each CA’s
> problem-reporting mechanism.
>
>
>
> Thanks,
>
> Corey
>
>
>
> From: Rob Stradling 
> Sent: Monday, March 2, 2020 4:31 PM
> To: Nick Lamb ; mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>; Corey Bonnell <
> cbonn...@securetrust.com>
> Cc: Matt Palmer 
> Subject: Re: Acceptable forms of evidence for key compromise
>
>
>
> "I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key."
>
>
>
> Such as https://tools.ietf.org/html/rfc8555#section-7.6 <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4Mm7tnSoQ=5=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc8555%23section-7%2e6>
> ?
>
>
>
> ISTM that any CA could stand up a standalone "revokeCert" API that only
> accepts proofs signed by the private key associated with the certificate,
> without that CA having to implement the rest of RFC8555.  Would this count
> as a "standard mechanism" (given that it's a portion of a Standards Track
> RFC)?  If so, why don't we simply say that this is the "standard mechanism"?
>
>
>
> @Matt: I read your tweet (
> https://twitter.com/tobermatt/status/1232779464783695873 <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK9l05N2C8g=5=https%3a%2f%2ftwitter%2ecom%2ftobermatt%2fstatus%2f1232779464783695873>
> ) as proposing this idea, but ISTM that you've stopped slightly short of
> actually proposing it in this list thread.  
>
>
>
> @Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI
> is kinda stuck with it now (see RFC8555).
>
>
>
>   _
>
> From: dev-security-policy   > on behalf of
> Corey Bonnell via dev-security-policy <
> dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org> >
> Sent: 02 March 2020 19:48
> To: Nick Lamb mailto:n...@tlrmx.org> >;
> mozilla-dev-security-policy   >
> Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
> Subject: RE: Acceptable forms of evidence for key compromise
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> There was quite a bit of discussion on the development of a standard
> revocation request format on LAMPS WG mailing list two years ago in the
> wake
> of the Trustico mass revocation:
> https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/ <
> https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4xz54WB8A=5=https%3a%2f%2fmailarchive%2eietf%2eorg%2farch%2fmsg%2fspasm%2fqeVHLeG6-Q%5f47QKNdyOOxsAT3Zk%2f>
> .
> Nothing was developed in terms of a concrete proposal specifying a
> revocation
> request format/protocol, but the pros/cons of such were hashed out pretty
> thoroughly.
>
> I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key. The use of such a
> mechanism would reduce the burden of work for those reporting key
> compromises,
> as the reporter would not need to learn how to demonstrate possession the
> private key 15 different ways to 15 different CAs. And CAs would benefit
> from
> such a mechanism, as they wouldn't need to spend support cycles working
> with
> the reporter to arrive at a suitable means to demonstrate possession or
> have
> to learn some exoteric software tooling that the reporter is using to prove
> possession.
>
> Thanks,
> Corey
>
> -Original Message-
> From: dev-security-policy   > On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Monday, March 2, 2020 2:35 PM
> To: dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>
> Cc: Matt Palmer 

Re: About upcoming limits on trusted certificates

[Wayne Thayer via dev-security-policy]

On Wed, Mar 4, 2020 at 11:48 AM Nick Lamb  wrote:

> On Tue, 3 Mar 2020 13:27:59 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
>
> > I'd like to ask for input from the community: is this a requirement
> > that we should add to the Mozilla policy at this time (effective
> > September 1, 2020)?
>
> If Mozilla adds this as a policy requirement it should also land
> enforcement in Firefox that rejects certificates which violate this
> policy. I tried to investigate whether this currently happens for the
> 825 day rule in the BRs but failed to satisfy myself either way.
>
>
I'm fairly certain that there is no validity period enforcement in Firefox.
The request is https://bugzilla.mozilla.org/show_bug.cgi?id=908125 I'm also
not in a position to commit Mozilla to technical enforcement if we adopt a
policy of 398 days. However, I believe there is still value in the policy
alone - violations are easily detected via CT logs, and making them a
misissuance under our policy then obligates the CA to file a public
incident report.


> I read the SC22 discussion when it happened but I will re-read it all in
> the light of Apple's recent decision and your question and post again
> if that results in something I miss here.
>
>
> One thing Mozilla definitely shouldn't replicate is Apple's decision to
> present this to CA/B in person - resulting in tech news coverage based
> on hearsay and conjecture - then only follow up days later to the wider
> population with material that doesn't cover every obvious question a
> reasonable person would have. A few hours before Clint's post I actually
> had to explain to someone that their understanding of the issue was
> probably wrong† - but with nothing official from Apple it was
> impossible to say so definitively, which means they're left pointlessly
> confused, presumably not Apple's purpose here.
>
> If Mozilla does follow Apple's policy here (which I am minded to think
> is the wiser course) they should make sure to have materials on hand
> immediately to clarify exactly what that will mean to both specialists
> and lay people when that policy is announced.
>
>
As usual, I'll propose the policy language and we'll discuss it on the list.


> †They had imagined existing two year certificates would suddenly cease
> to work on iPhones after their first year, which of course would be a
> nightmare to manage and does not match Clint's confirmation here that
> notBefore will be used to decide which certificates the policy applies
> to.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Wayne Thayer via dev-security-policy]

Thank you for sharing this Clint.

I'd like to ask for input from the community: is this a requirement that we
should add to the Mozilla policy at this time (effective September 1, 2020)?

You may recall that a 398-day maximum validity for TLS certificates was
proposed to the CA/Browser Forum by Google last year. Mozilla voted in
favor, but ballot SC22 failed due to a lack of support from CAs. [1] Many
of the arguments for and against this change can be found in the emails
sent by CA/Browser Forum members during the discussion [2] and when casting
their votes.[3]

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/001080.html
[2] https://cabforum.org/pipermail/servercert-wg/2019-August/
[3] https://cabforum.org/pipermail/servercert-wg/2019-September/

On Tue, Mar 3, 2020 at 12:55 PM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello all,
>
> I wanted to inform this community of an upcoming change to the Apple Root
> Program.
> SSL/TLS certificates issued on or after September 1, 2020 will need to
> have a total lifetime of no more than 398 days. This change will be put in
> place in a future release of iOS, macOS, iPadOS, watchOS, and tvOS for
> default-trusted TLS certificates (i.e. the Roots that come preinstalled on
> the above OSes).
>
> For additional information, please see
> https://support.apple.com/en-us/HT211025.
>
> Thank you!
> -Clint
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When to accept/require revised audits for missing cert fingerprints

[Wayne Thayer via dev-security-policy]

On Thu, Feb 6, 2020 at 5:44 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:



My recommendation is that, for audit periods ending within the next 30 or
> so days (meaning, effectively, for reports provided over the next 4 months,
> given the three month window before reporting), such situations are
> accepted despite the limited assurance they provide. Following that - that
> is, for any audit afterwards, there is zero exception, and revocation is
> required.
>
>
I'd like to see Mozilla require an incident report from CAs that can't or
won't follow the existing guidance (by either supplying a revised audit
statement, revoking the certificate, or adding it to OneCRL). A number of
CAs have resolved these issues by following this guidance and I recommend
against adding a grace period at this time for those who have not.

This places the onus on the CA to ensure their audit reports will meet
> Mozilla’s requirements.
>
>
In the future, I expect ALV to catch these issues as soon as the audit
report is published. Mistakes do happen, and I don't think our policy
should go straight to revocation upon an ALV failure due to an audit
statement error.

2) Should we accept a revised audit statement to include the SHA256
> > fingerprint of a certificate that was not previously listed and does not
> > have the same Subject + SPKI as other cert(s) listed in the audit
> > statement?
>
>


I realize Mozilla uses OneCRL to address the gap there, but ostensibly this
> is a straight BR violation regarding providing continuous audits. The
> proposed revisions will make this unambiguously clearer, but either way,
> the best path to protect the most users is to require the CA to revoke such
> certificates.
>
> This also hopefully has the desired effect of forcing CAs to pay closer
> attention to the requirements placed on them, and ensure that the negotiate
> and scope their audits to ensure they’re actually meeting those
> requirements.
>
>
I agree, but I also think that ALV will cause these issues to be caught and
quickly corrected in the future (assuming the CA has properly disclosed all
CA certificates).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy Module Ownership

[Wayne Thayer via dev-security-policy]

I have decided to leave Mozilla, effective this Friday.

I expect Mozilla to hire a replacement, but that will of course take time.
In the interim, I will remain the CA Certificate Policy Module Owner and
contribute to the best of my ability in a volunteer capacity.

Please feel free to contact me or Kathleen with any questions or concerns.

I want to take this opportunity to once again thank everyone for your
support and contributions to this amazing community.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

The email has been sent to all CAs in the Mozilla program requesting that
they respond to the survey by the end of this month.

Responses will be published on the wiki [1] as they are received. Please
note that the responses for questions 2, 3, and 5 do not yet properly
display the date fields that were recently added.

- Wayne

[1] https://wiki.mozilla.org/CA/Communications#January_2020_CA_Communication

On Mon, Jan 6, 2020 at 12:41 PM Wayne Thayer  wrote:

> Thank you Malcolm, that is a good suggestion for consistency. I have
> updated the survey and am still planning to send it out tomorrow (Tuesday).
>
> - Wayne
>
> On Mon, Jan 6, 2020 at 1:14 AM Malcolm Doody via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote:
>> > I've made some additional improvements to the survey based on feedback
>> from
>> > Kathleen:
>> >
>> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
>>
>> Perhaps Action 2 should be split into Action 2 Date and Action 2
>> Comments, as per 3 & 5?
>>
>> //Malcolm
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

Thank you Malcolm, that is a good suggestion for consistency. I have
updated the survey and am still planning to send it out tomorrow (Tuesday).

- Wayne

On Mon, Jan 6, 2020 at 1:14 AM Malcolm Doody via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote:
> > I've made some additional improvements to the survey based on feedback
> from
> > Kathleen:
> >
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
>
> Perhaps Action 2 should be split into Action 2 Date and Action 2 Comments,
> as per 3 & 5?
>
> //Malcolm
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

On Fri, Jan 3, 2020 at 12:49 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote:
> > I've made some additional improvements to the survey based on feedback
> from
> > Kathleen:
> >
> >
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
> >
> > I'm planning to send this out to CAs on Tuesday.
> >
> > On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer 
> wrote:
> >
> > > On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley <
> jeremy.row...@digicert.com>
> > > wrote:
> > >
> > >> Should anything be mentioned about the allowed algorithms? That's the
> > >> largest change to the policy and  confirming the AlgorithmIdentifiers
> in
> > >> each case may take some time.
> > >>
> > >>
> > > I'd argue that this is a clarification rather than a change, and
> depending
> > > on the CA, confirming compliance with the updates in section 5.1 may
> not
> > > take as long as the CPS updates. I'm not strongly opposed to calling
> this
> > > out but I'd argue that it's hard to miss when reviewing all of the
> updates
> > > as required by question #1.
> > >
>
> Perhaps a minor question/nit, but it's better to raise it to remove all
> doubt: for Action Item 3, if there exists revoked (but still unexpired)
> end-entity certificates w/o a EKU but the CA has already switched to
> universally including the EKU in end-entity certificates, should the CA
> select "All unexpired end-entity certificates that we issue or have issued
> and are within the scope of Mozilla’s policy currently comply with this
> requirement" (which loosely interprets the meaning of "unexpired" to
> encompass "non-revoked" as well), or should the CA select one of the other
> options?
>
>
Thank you Corey. I have explicitly added "non-revoked" to the option that
you quoted above.

I believe the intent of the discussion in
> https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ
> indicates that Mozilla doesn't care about revoked certificates in this
> case, so perhaps the language for option 1 should be clarified to specify
> "unexpired, non-revoked" to better convey the intent.
>
> Thanks,
> Corey
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

I've made some additional improvements to the survey based on feedback from
Kathleen:

https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW

I'm planning to send this out to CAs on Tuesday.

On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer  wrote:

> On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley 
> wrote:
>
>> Should anything be mentioned about the allowed algorithms? That's the
>> largest change to the policy and  confirming the AlgorithmIdentifiers in
>> each case may take some time.
>>
>>
> I'd argue that this is a clarification rather than a change, and depending
> on the CA, confirming compliance with the updates in section 5.1 may not
> take as long as the CPS updates. I'm not strongly opposed to calling this
> out but I'd argue that it's hard to miss when reviewing all of the updates
> as required by question #1.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

[Wayne Thayer via dev-security-policy]

I've modified the first question of the survey and added a response option
for exceptions:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW

On Tue, Dec 24, 2019 at 5:55 AM Nick Lamb  wrote:

> On Mon, 23 Dec 2019 14:20:16 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
>
> > I suggest that we modify question #1 to require CAs
> > to attest that they intend to FULLY comply with version 2.7 of the
> > policy and if they won't fully comply, to list all non-conforrmities.
> > In other words, define an exception as anything that isn't compliant
> > with the current policy rather than something we granted in the past.
>
> Thanks Wayne, I believe this would achieve my broader goals without
> being too onerous for you/ Mozilla or the CAs.
>
> I look forward to any discussions prompted by the modified question or
> by non-comformities disclosed as a result.
>
>
> Nick.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

[Wayne Thayer via dev-security-policy]

On Sat, Dec 21, 2019 at 11:30 AM Nick Lamb  wrote:

> On Thu, 19 Dec 2019 10:23:19 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
>
> > We've included a question about complying with the intermediate audit
> > requirements in the January survey, but not a more general question
> > about exceptions. I feel that an open-ended question such as this
> > will be confusing for CAs to answer, and moreover I don't want to
> > create the impression that Mozilla grants exceptions for policy
> > violations because, as a general rule, we don't.
>
> As a general rule you don't grant exceptions, and so exceptions are
> let's say, an exception to that general rule? Hence the name.
>
>
Nope. The point is that we have no systematic process for handling
exceptions, and to the best of my knowledge no list of granted exceptions
exists. It's not even clear what constitutes an exception. Is any policy
violation an exception? Does a certificate that was misissued 23 months ago
but not revoked constitute an exception? Are the Symantec subordinates that
are allow-listed exceptions? Is an exception something that a Mozilla
representative interpreted for a CA as being permitted? Is an exception
narrowly defined as something that Mozilla agreed to in writing?

We may have been more liberal in making exceptions in the past, but I have
hopefully been consistent in stating that it is the CA's responsibility to
decide what to do and inform us rather than ask for permission.

So, to the same end as my original proposal, I recommend instead that
> Mozilla personalizes any CA survey sent out to a CA which they believe
> currently benefits from any such exceptions - setting out what those
> exceptions to its rules are for that CA. And in all communications the
> text should be clear that any exceptions the CA believed were in place
> are in fact spent as far as Mozilla is concerned unless they are
> enumerated in this communication.
>
>
This is challenging because no list of exceptions exists and because I'm
not aware of a way to perform this type of customization in our survey
system (I'll confirm with Kathleen).

In the event there are in fact NO exceptions, that's just one small
> tweak to the text.
>
>
But potentially a very confusing tweak, unless we define what we mean by an
exception. I suggest that we modify question #1 to require CAs to attest
that they intend to FULLY comply with version 2.7 of the policy and if they
won't fully comply, to list all non-conforrmities. In other words, define
an exception as anything that isn't compliant with the current policy
rather than something we granted in the past.

In the event that one or two CAs benefit from some minor exception
> which still has force, it's a little bit of work, and in the process a
> firm reminder to both Mozilla and the CA of the ongoing price of such
> exceptions.
>
>
Not to mention a good argument that exceptions are unfair.

And in the event that it's actually dozens of exceptions across many or
> most CAs I hope the realisation of the effort involved will cause Wayne
> to reconsider his previous claim that "as a general rule, we don't".
>
>
I agree that it would be valuable to know if this is the case.

One valuable opportunity from m.d.s.policy is for CAs to learn from
> each others mistakes and in doing so avoid making the same or similar
> mistakes themselves. But Mozilla has opportunities to learn from
> mistakes here too, and I feel as though the mismatch between Kathleen's
> expectation (that a situation should have "resolved" since 2016) and
> the CA's understanding (that this constituted an indefinite exception
> to Mozilla policy) is such a mistake.
>
>
I agree.


> Nick.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley 
wrote:

> Should anything be mentioned about the allowed algorithms? That's the
> largest change to the policy and  confirming the AlgorithmIdentifiers in
> each case may take some time.
>
>
I'd argue that this is a clarification rather than a change, and depending
on the CA, confirming compliance with the updates in section 5.1 may not
take as long as the CPS updates. I'm not strongly opposed to calling this
out but I'd argue that it's hard to miss when reviewing all of the updates
as required by question #1.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

On Thu, Dec 19, 2019 at 3:12 PM Ryan Sleevi  wrote:

>
> On Thu, Dec 19, 2019 at 12:10 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> All,
>>
>> I've drafted a new email and survey that I plan to send to all CAs in the
>> Mozilla program in early January. it focuses on compliance with the new
>> (2.7) version of our Root Store Policy. I will appreciate your review and
>> feedback on the draft:
>>
>> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
>
>
> ## ACTION 1 ##
> One thing that I think came up from the past CA communications is that CAs
> assert this, but then end up failing to actually implement.
>
> Perhaps it may be worthwhile to be more explicit here about the
> expectations:
>
> """
> Read version 2.7 of Mozilla's Root Store Policy.
>
> CAs are expected to review and abide by Version 2.7 of Mozilla's Root
> Store Policy. This includes a number of changes from previous versions. CAs
> MUST review this policy and ensure compliance, and CAs SHOULD carefully
> review the differences from previous versions of Mozilla's Policy. These
> changes have been discussed on mozilla.dev.security.policy and on GitHub.
> CAs that did not participate in these discussions or that have not yet
> reviewed these conversations should also review the discussions regarding
> these changes, to reduce the chance of confusion or misinterpretation.
>
> CAs are encouraged to raise any questions that they do not feel addressed
> in the Policy, or which the discussions and reasoning for the changes was
> not clear.
> """
>
> There's probably a better way to word all of this, but where I'm trying to
> emphasize
> - The policy is the policy, and the ideal goal is that the policy stands
> by itself
> - That said, CAs understandably can misinterpret new policies when they
> use the logic of past policies or interpretations, while someone reading
> the policy fresh or which participated in the discussions about the policy
> would not be confused by
> - Even though CAs are required to follow m.d.s.p., the length of time for
> Policy 2.7 may mean they have had turnover or knowledge drain or simply
> forgot, so it's good to remind them that they can find information about
> each and every change discussed here or on GitHub, and they're expected to
> be familiar with it
>
> I'm trying to flag the "We didn't follow the discussion and continued to
> use our old interpretation" scenario, and see if there's something that can
> be done to remind folks to pay attention.
>
>
I've incorporated these suggestions.

## ACTION 3 ##
> Would it make sense to add a third option, "All end-entity certificates
> that we issue or have issued after [date] and are within..." and let folks
> specify a date?
>
> I largely mention this because it's an existing Microsoft requirement as I
> understand it, and is somewhat enforced by Apple (at least for TLS) since
> July, so it may be that CAs are already compliant for new certificates, but
> also have unexpired old certificates that are not compliant. It may be that
> the answer is supposed to be "#1", but that wasn't immediately obvious to
> me when I first read.
>
> Alternatively, it might be clearer to reword that "Beginning on 1 July,
> 2020, *new* end-entity ...", to emphasize that it's not that
> Firefox/Mozilla will begin enforcing on 2020-07-01, but that certificates
> issued on/after that date will be required to be compliant (presumably,
> measured by notBefore)
>
>
I made both of these changes as well.

## ACTION 5 ##
> I'm not sure if Salesforce forms allow it, but is it possible to have
> Action 5 include both a date selector and a comment field? It might make it
> easier to have consistency for options 3 & 4. Like "ACTION 5 Date" and
> "ACTION 5 Comments"
>
> Of course, if it doesn't, no worries.
>

I added an optional date entry field to this question.

All of these changes are now published at link I shared.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy 2.7 Published

[Wayne Thayer via dev-security-policy]

You can find an explanation of Mozilla's enforcement mechanism on our wiki
[1]. When a CA fails to comply, the immediate action upon discovery is the
creation of an incident bug and the expectation that the CA will file an
incident report [2].

- Wayne

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement
[2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

On Mon, Dec 23, 2019 at 9:24 AM Tomas Hidalgo Salvador via
dev-security-policy  wrote:

> Hi Wayne,
>
> What could be the consequences of a given CA (Certification Authority) not
> complying with this new policy? Thanks!
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Reporting Guidance

[Wayne Thayer via dev-security-policy]

Having received no comments on this proposal, I went ahead and added it to
the wiki [1].

- Wayne

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

On Wed, Dec 11, 2019 at 4:45 PM Wayne Thayer  wrote:

> While thinking about different ways to solve the problem of disclosing
> missed revocation deadlines, we devised a solution for searching and
> reporting on delayed revocations separately from other incidents. We've
> begun to add a new Bugzilla "whiteboard" label to delayed revocation
> incident bugs. We can then display those incidents separately on our
> Incident Dashboard, as follows:
> https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays
>
> I've come to the conclusion that Mozilla should begin to require that CAs
> submit a separate bug when a revocation deadline is missed. I dislike the
> extra overhead of creating and managing more bugs, but doing so allows us
> to provide clearer guidance to CAs, and it helps to ensure that we are
> seeking out the root causes of revocation delays when they occur, rather
> than potentially missing those learnings amongst the issue(s) that
> triggered the revocation(s). To be clear, this proposal is not intended to
> create more work or somehow punish CAs for missing revocation deadlines.
>
> This results in the following new guidance:
>
> CAs should submit a separate incident report when:
> * Mozilla policy requires that the CA revoke one or more certificates by a
> certain deadline, such as those in BR section 4.9, but that deadline is not
> met by the CA
> * In the process of researching one incident, another incident with a
> distinct root cause and/or remediation is discovered
> * After an incident bug is marked resolved, the incident reoccurs
>
> I will appreciate everyone's feedback on these proposed improvements to
> the Incident Report section [1] of our Responding to an Incident wiki page.
> If no responses are received over the next few days, I'll go ahead and make
> these changes.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
>
> On Thu, Nov 21, 2019 at 10:48 AM Ryan Sleevi 
> wrote:
>
>>
>>
>> On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> During the recent CA/Browser Forum meeting, I was asked to provide better
>>> guidance on Mozilla's expectations for incident reporting. We're adding a
>>> requirement for incident reporting to the new version of our policy [1],
>>> but in this message I'm focused on the guidance provided on our wiki [2].
>>> The question was when to add information to an existing bug versus
>>> creating
>>> a new one. I'd like to propose adding the following guidance to the wiki
>>> to
>>> address this question:
>>>
>>> CAs should create a separate bug and file a new incident report when:
>>> * In the process of researching one incident another incident with a
>>> distinct root cause and/or remediation is discovered
>>> * After an incident bug is marked resolved, the incident reoccurs
>>>
>>> A third possible addition would be:
>>> * When a CA accidentally or intentionally misses a revocation deadline, a
>>> separate bug should/must be filed examining the root cause and
>>> remediation
>>> for missing the deadline
>>>
>>> I believe the argument for this is that tracking revocation issues
>>> separately will help us to focus on improving the agility of the web PKI.
>>> On the other hand, Mozilla has not generally required separate reports in
>>> the past, and doing so certainly creates more work for everyone involved.
>>> It's not clear to me that the benefit of this outweighs the cost.
>>
>>
>> Yeah, I've been thinking about this in light of the feedback Kathleen
>> offered on
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/jZft5ZH_AgAJ
>>
>> My primary objectives in treating it as two distinct issues are:
>> 1) Ensuring the timely remediation of the root causes of whatever
>> 'caused' the incident. In general, this should be 'sooner' than 'later'
>> 2) Ensuring transparency about when CAs are having repeat "delayed
>> revocation" issues; buried within issues themselves makes it difficult to
>> track when there are repeat offenders, but also limits visibility into
>> systemic issues that all CAs can/should be aware of when contemplating the
>> design and maintenance of their PKI
>> 3) Ensuring progress is made towards revocation, by not having bugs
>> prematurely closed when the 'root' incident is resolved but the CA has
>> taken no meaningful steps to bring their PKI back into compliance (yet)
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

[Wayne Thayer via dev-security-policy]

On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, 25 Nov 2019 14:12:46 -0800
> Kathleen Wilson via dev-security-policy
>  wrote:
>
> > CAs should have been keeping track of and resolving their own known
> > problems in regards to not fully following the BRs and Mozilla
> > policy. For example, I expect that a situation in which I responded
> > with an OK in 2016 would have been corrected in the 3 years since
> > that email was written.
>
> Perhaps to this end it would be useful for Mozilla's periodic survey
> letters to always ask each CA to list any exceptional circumstances they
> believe currently apply to them?
>
>
We've included a question about complying with the intermediate audit
requirements in the January survey, but not a more general question about
exceptions. I feel that an open-ended question such as this will be
confusing for CAs to answer, and moreover I don't want to create the
impression that Mozilla grants exceptions for policy violations because, as
a general rule, we don't.

This would act both as a reminder to Mozilla of any such exceptions
> which they granted but may have assumed meanwhile ceased to be
> relevant, AND to the CA of any such exceptions upon which they find
> themselves still relying.
>
> The publication of CA responses is an opportunity for Mozilla, Peers
> and the wider community to comment on any discrepancy.
>
>
> Nick.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DRAFT January 2020 CA Communication

[Wayne Thayer via dev-security-policy]

All,

I've drafted a new email and survey that I plan to send to all CAs in the
Mozilla program in early January. it focuses on compliance with the new
(2.7) version of our Root Store Policy. I will appreciate your review and
feedback on the draft:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW

Note that two deadlines have been added to the communication:
* Action 3 specifies that CAs must agree to update their CP/CPS, if needed
to comply, prior to April 1, 2020. This is intended to prevent responses
that we have found unacceptable in the past, e.g. waiting for an annual
audit before updating the CP/CPS.
* Action 5 requires CAs with failed Intermediate ALV results to publish a
plan to correct these problems no later than Feb 15, 2020. Kathleen
announced that we have begun validating audit letters for intermediate
certificates back in October [1], and the requirement for audit statements
to contain the SHA256 fingerprint of each root and intermediate certificate
that was in scope of the audit dates back to 2017. CAs should have already
taken action to resolve these issues, so this deadline is intended to
convey the need for an immediate response.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/ZPDMRvDzBQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy 2.7 Published

[Wayne Thayer via dev-security-policy]

On Thu, Dec 12, 2019 at 4:58 AM Malcolm Doody via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, 12 December 2019 11:07:24 UTC, Malcolm Doody  wrote:
> > On Wednesday, 11 December 2019 15:42:21 UTC, Wayne Thayer  wrote:
> > > The new version of the Mozilla Root Store Policy has been published
> [1].
> >
> > Looks like the level-4 headers (3.1.2.1 and 3.1.2.2) are in the wrong
> sized font
>
> Looking, it comes down to the CSS definition for h1 to h6 in [3]
> There are overriding definitions for h1 to h4 (not h5 or h6) in [4]
> so h5 takes the larger font-size:2rem definition from [3] whereas it ought
> to have a font-size:1rem definition in [4]
>
>
I reported the formatting issue at
https://github.com/mozilla/bedrock/issues/8323

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Reporting Guidance

[Wayne Thayer via dev-security-policy]

While thinking about different ways to solve the problem of disclosing
missed revocation deadlines, we devised a solution for searching and
reporting on delayed revocations separately from other incidents. We've
begun to add a new Bugzilla "whiteboard" label to delayed revocation
incident bugs. We can then display those incidents separately on our
Incident Dashboard, as follows:
https://wiki.mozilla.org/CA/Incident_Dashboard#Revocation_Delays

I've come to the conclusion that Mozilla should begin to require that CAs
submit a separate bug when a revocation deadline is missed. I dislike the
extra overhead of creating and managing more bugs, but doing so allows us
to provide clearer guidance to CAs, and it helps to ensure that we are
seeking out the root causes of revocation delays when they occur, rather
than potentially missing those learnings amongst the issue(s) that
triggered the revocation(s). To be clear, this proposal is not intended to
create more work or somehow punish CAs for missing revocation deadlines.

This results in the following new guidance:

CAs should submit a separate incident report when:
* Mozilla policy requires that the CA revoke one or more certificates by a
certain deadline, such as those in BR section 4.9, but that deadline is not
met by the CA
* In the process of researching one incident, another incident with a
distinct root cause and/or remediation is discovered
* After an incident bug is marked resolved, the incident reoccurs

I will appreciate everyone's feedback on these proposed improvements to the
Incident Report section [1] of our Responding to an Incident wiki page. If
no responses are received over the next few days, I'll go ahead and make
these changes.

- Wayne

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

On Thu, Nov 21, 2019 at 10:48 AM Ryan Sleevi  wrote:

>
>
> On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> During the recent CA/Browser Forum meeting, I was asked to provide better
>> guidance on Mozilla's expectations for incident reporting. We're adding a
>> requirement for incident reporting to the new version of our policy [1],
>> but in this message I'm focused on the guidance provided on our wiki [2].
>> The question was when to add information to an existing bug versus
>> creating
>> a new one. I'd like to propose adding the following guidance to the wiki
>> to
>> address this question:
>>
>> CAs should create a separate bug and file a new incident report when:
>> * In the process of researching one incident another incident with a
>> distinct root cause and/or remediation is discovered
>> * After an incident bug is marked resolved, the incident reoccurs
>>
>> A third possible addition would be:
>> * When a CA accidentally or intentionally misses a revocation deadline, a
>> separate bug should/must be filed examining the root cause and remediation
>> for missing the deadline
>>
>> I believe the argument for this is that tracking revocation issues
>> separately will help us to focus on improving the agility of the web PKI.
>> On the other hand, Mozilla has not generally required separate reports in
>> the past, and doing so certainly creates more work for everyone involved.
>> It's not clear to me that the benefit of this outweighs the cost.
>
>
> Yeah, I've been thinking about this in light of the feedback Kathleen
> offered on
> https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/jZft5ZH_AgAJ
>
> My primary objectives in treating it as two distinct issues are:
> 1) Ensuring the timely remediation of the root causes of whatever 'caused'
> the incident. In general, this should be 'sooner' than 'later'
> 2) Ensuring transparency about when CAs are having repeat "delayed
> revocation" issues; buried within issues themselves makes it difficult to
> track when there are repeat offenders, but also limits visibility into
> systemic issues that all CAs can/should be aware of when contemplating the
> design and maintenance of their PKI
> 3) Ensuring progress is made towards revocation, by not having bugs
> prematurely closed when the 'root' incident is resolved but the CA has
> taken no meaningful steps to bring their PKI back into compliance (yet)
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Root Store Policy 2.7 Published

[Wayne Thayer via dev-security-policy]

The new version of the Mozilla Root Store Policy has been published [1].
This version goes into effect on January 1, 2020. The prior version that is
in effect for the rest of 2019 is linked from the wiki [2].

I have also just posted an announcement [3] on the Mozilla Security Blog.

We will be sending out a CA Communication in January to ensure that all CAs
in the Mozilla program are aware of the policy update, and other recent
changes. I will share a draft for everyone's review soon.

I would like to sincerely thank everyone who participated in the
discussions that led to these policy changes.

- Wayne

[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[2] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
[3]
https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

[Wayne Thayer via dev-security-policy]

A concern [1] was raised about the required version of WebTrust audit
criteria. After discussing with the WebTrust folks, I have changed the
minimum requirement to the previous WebTrust versions instead of the
current versions [2].

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/197
[2]
https://github.com/mozilla/pkipolicy/commit/9c25ef32d43843597864d3fbb4d9f231feb07f95

On Mon, Nov 25, 2019 at 11:39 AM Wayne Thayer  wrote:

> I've given the new version [1] another review, updated a few links, and
> set the effective date to 1-January 2020.
>
> Unless there are new comments on this or any of the other changes [2], I
> will have the new version published in the next few weeks. I'll also be
> preparing a CA Communication to announce the new policy and specific
> compliance dates.
>
> - Wayne
>
> [1] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
> [2] https://github.com/mozilla/pkipolicy/compare/master...2.7?diff=split
>
> On Wed, Nov 20, 2019 at 3:21 PM Wayne Thayer  wrote:
>
>> The last change I am proposing for version 2.7 of the Mozilla Root Store
>> policy is an update to the minimum versions of audit criteria that we will
>> accept in audits. I have conferred with the WebTrust Task Force and was
>> informed that we can update the minimum version requirements for audit
>> statements received after December 2019 as follows:
>>
>> WebTrust for CA – instead of v2.0 use v2.2
>> WebTrust for BL+NSR – instead of v2.2 use v2.4.1
>> WebTrust for EVSSL – instead of v1.6.0 use v1.6.8
>>
>> I asked the same question to ETSI representatives and was told that the
>> following changes are appropriate:
>>
>> ETSI EN 319 411-1 - instead of v1.1.1 use v1.2.2
>> ETSI EN 319 411-2 - instead of v2.1.1 use v2.2.2
>>
>> I have made these changes at
>> https://github.com/mozilla/pkipolicy/commit/f605b39ccd9d1000ecebbfc028ab99aafae73d33
>> (I also update the links in a later commit)
>>
>> This is https://github.com/mozilla/pkipolicy/issues/197
>>
>> I will greatly appreciate everyone's feedback - especially from any CAs
>> or auditors for which these changes may cause problems.
>>
>> - Wayne
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Wayne Thayer via dev-security-policy]

Why not "AIA chasing considered harmful"? The current state of affairs is
that most browsers [other than Firefox] will go and fetch the intermediate
if it's not cached. This manifests itself as sites not working in Firefox,
and users switching to other browsers.

You may be further dismayed to learn that Firefox will soon implement
intermediate preloading [1] as a privacy-preserving alternative to AIA
chasing.

- Wayne

[1]
https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading#Intermediate_CA_Preloading

On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie  wrote:

>
>
> On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
> wrote:
>
>> Ben Laurie via dev-security-policy 
>> writes:
>>
>> >In short: caching considered harmful.
>>
>> Or "cacheing considered necessary to make things work"?
>
>
> If you happen to visit a bazillion sites a day.
>
>
>> In particular:
>>
>> >caching them and filling in missing ones means that failure to present
>> >correct cert chains is common behaviour.
>>
>> Which came first?  Was cacheing a response to broken chains or broken
>> chains a
>> response to cacheing?
>>
>> Just trying to sort out cause and effect.
>>
>
> Pretty sure if broken chains caused browsers to not show pages, then there
> wouldn't be broken chains.
>
> --
> I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
> #VerifyAllTheThings.
>
> https://g.co/u58vjr https://g.co/adjusu
> *(Google internal)*
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

[Wayne Thayer via dev-security-policy]

I've given the new version [1] another review, updated a few links, and set
the effective date to 1-January 2020.

Unless there are new comments on this or any of the other changes [2], I
will have the new version published in the next few weeks. I'll also be
preparing a CA Communication to announce the new policy and specific
compliance dates.

- Wayne

[1] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
[2] https://github.com/mozilla/pkipolicy/compare/master...2.7?diff=split

On Wed, Nov 20, 2019 at 3:21 PM Wayne Thayer  wrote:

> The last change I am proposing for version 2.7 of the Mozilla Root Store
> policy is an update to the minimum versions of audit criteria that we will
> accept in audits. I have conferred with the WebTrust Task Force and was
> informed that we can update the minimum version requirements for audit
> statements received after December 2019 as follows:
>
> WebTrust for CA – instead of v2.0 use v2.2
> WebTrust for BL+NSR – instead of v2.2 use v2.4.1
> WebTrust for EVSSL – instead of v1.6.0 use v1.6.8
>
> I asked the same question to ETSI representatives and was told that the
> following changes are appropriate:
>
> ETSI EN 319 411-1 - instead of v1.1.1 use v1.2.2
> ETSI EN 319 411-2 - instead of v2.1.1 use v2.2.2
>
> I have made these changes at
> https://github.com/mozilla/pkipolicy/commit/f605b39ccd9d1000ecebbfc028ab99aafae73d33
> (I also update the links in a later commit)
>
> This is https://github.com/mozilla/pkipolicy/issues/197
>
> I will greatly appreciate everyone's feedback - especially from any CAs or
> auditors for which these changes may cause problems.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trusted Recursive Resolver Policy in India

[Wayne Thayer via dev-security-policy]

The only update I can provide at this time is that we're working on it.

On Thu, Nov 21, 2019 at 10:08 AM rich.salz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, September 14, 2019 at 7:04:11 AM UTC+8, Wayne Thayer wrote:
> > Rich: I want to acknowledge your question, which I think is really "what
> is
> > the right forum for Mozilla TRR (DNS over HTTPS) policy [1]
> discussions?" I
> > don't currently have an answer for you, but will respond when I do.
>
> Any update?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident Reporting Guidance

[Wayne Thayer via dev-security-policy]

During the recent CA/Browser Forum meeting, I was asked to provide better
guidance on Mozilla's expectations for incident reporting. We're adding a
requirement for incident reporting to the new version of our policy [1],
but in this message I'm focused on the guidance provided on our wiki [2].
The question was when to add information to an existing bug versus creating
a new one. I'd like to propose adding the following guidance to the wiki to
address this question:

CAs should create a separate bug and file a new incident report when:
* In the process of researching one incident another incident with a
distinct root cause and/or remediation is discovered
* After an incident bug is marked resolved, the incident reoccurs

A third possible addition would be:
* When a CA accidentally or intentionally misses a revocation deadline, a
separate bug should/must be filed examining the root cause and remediation
for missing the deadline

I believe the argument for this is that tracking revocation issues
separately will help us to focus on improving the agility of the web PKI.
On the other hand, Mozilla has not generally required separate reports in
the past, and doing so certainly creates more work for everyone involved.
It's not clear to me that the benefit of this outweighs the cost.

Are there other examples that would provide helpful guidance to CAs?

I will appreciate everyone's input on this proposal.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md#24-incidents
[2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

[Wayne Thayer via dev-security-policy]

The last change I am proposing for version 2.7 of the Mozilla Root Store
policy is an update to the minimum versions of audit criteria that we will
accept in audits. I have conferred with the WebTrust Task Force and was
informed that we can update the minimum version requirements for audit
statements received after December 2019 as follows:

WebTrust for CA – instead of v2.0 use v2.2
WebTrust for BL+NSR – instead of v2.2 use v2.4.1
WebTrust for EVSSL – instead of v1.6.0 use v1.6.8

I asked the same question to ETSI representatives and was told that the
following changes are appropriate:

ETSI EN 319 411-1 - instead of v1.1.1 use v1.2.2
ETSI EN 319 411-2 - instead of v2.1.1 use v2.2.2

I have made these changes at
https://github.com/mozilla/pkipolicy/commit/f605b39ccd9d1000ecebbfc028ab99aafae73d33
(I also update the links in a later commit)

This is https://github.com/mozilla/pkipolicy/issues/197

I will greatly appreciate everyone's feedback - especially from any CAs or
auditors for which these changes may cause problems.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Thu, Nov 14, 2019 at 3:24 PM Wayne Thayer  wrote:

> On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi  wrote:
>
>>
>> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> A few more questions have come up about this change:
>>>
>>> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings,
>>> why
>>> would we include them in our policy?
>>>
>>
>> They were included for completeness sake, as neither Mozilla Policy nor
>> the BRs presently forbid them.
>>
>> I'm much in favor of not permitting them, but since the current
>> restriction on RSA keys does not restrict the signature algorithms used, we
>> wanted to make sure the combinations were suitable.
>>
>>
>
> I understand the point that including the RSA-PSS encodings does not
> change the literal meaning of the current policy, but it does imply that
> Mozilla supports these encodings when in fact NSS does not. We could
> resolve this by removing the RSA-PSS encodings or by adding a note stating
> that Firefox doesn't currently support them. I prefer adding the note,
> since Firefox could add support [1] for RSA-PSS much more quickly that this
> policy is typically updated. I propose the following:
>
> Note: as of version 70, RSASSA-PSS encodings are not supported by Firefox.
> (with a link to [1])
>
>
I've gone ahead and made this change in the 2.7 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/320d3a47c655c5b49f6465d9446ceea85be96d4b

- Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1088140
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

How Certificates are Verified by Firefox

[Wayne Thayer via dev-security-policy]

If you are one of the many people who have wondered how exactly Firefox
handles some aspect of certificate processing, you may be interested to
know that we have recently updated the information on our wiki:

https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification

I hope you find this helpful.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi  wrote:

>
> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> A few more questions have come up about this change:
>>
>> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
>> would we include them in our policy?
>>
>
> They were included for completeness sake, as neither Mozilla Policy nor
> the BRs presently forbid them.
>
> I'm much in favor of not permitting them, but since the current
> restriction on RSA keys does not restrict the signature algorithms used, we
> wanted to make sure the combinations were suitable.
>
>

I understand the point that including the RSA-PSS encodings does not change
the literal meaning of the current policy, but it does imply that Mozilla
supports these encodings when in fact NSS does not. We could resolve this
by removing the RSA-PSS encodings or by adding a note stating that Firefox
doesn't currently support them. I prefer adding the note, since Firefox
could add support [1] for RSA-PSS much more quickly that this policy is
typically updated. I propose the following:

Note: as of version 70, RSASSA-PSS encodings are not supported by Firefox.
(with a link to [1])

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1088140
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

A few more questions have come up about this change:

* Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
would we include them in our policy?
* Related: would this detailed enumeration of requirements be better to
place in the BRs than in Mozilla policy?
* In that case it wouldn't cover S/MIME certs
* We'd still need to exclude P-521 in Mozilla policy
* It would end up in audit criteria and perhaps engineers implementing
it would be more likely to be aware of it
* Presumably the RSA-PSS encoding would be included in the BRs and
would then potentially need to be excluded from Mozilla policy

As always, I'll appreciate everyone's input on these questions.

- Wayne

On Wed, Oct 2, 2019 at 5:59 PM Wayne Thayer  wrote:

> Thank you Ryan. Brian reviewed these changes back in May, so I've gone
> ahead and accepted them for the 2.7 policy update:
> https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27
>
> I'll consider this issue resolved unless there are further comments.
>
> - Wayne
>
> On Fri, May 24, 2019 at 1:38 AM Ryan Sleevi  wrote:
>
>>
>>
>> On Wed, May 22, 2019 at 7:43 PM Brian Smith  wrote:
>>
>>> Ryan Sleevi  wrote:
>>>


> It would be easier to understand if this is true if the proposed text
> cited the RFCs, like RFC 4055, that actually impose the requirements that
> result in the given encodings.
>

 Could you clarify, do you just mean adding references to each of the
 example encodings (such as the above example, for the SPKI encoding)?

>>>
>>> Exactly. That way, it is clear that the given encodings are not imposing
>>> a new requirement, and it would be clear which standard is being used to
>>> determine to correct encoding.
>>>
>>
>> Thanks, did that in
>> https://github.com/sleevi/pkipolicy/commit/80da8acded63618a058d26c73db1e2438a6df9ed
>>
>>
>>>
>>> I realize that determining the encoding from each of these cited specs
>>> would require understanding more specifications, including in particular
>>> how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
>>> calling out all of these details individually less people get confused by
>>> inevitable omissions.
>>>
>>
>> Hopefully struck the right balance. These changes are now reflected in
>> the PR at https://github.com/mozilla/pkipolicy/pull/183
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next Root Store Policy Update

[Wayne Thayer via dev-security-policy]

We've concluded discussions on the individual issues and can begin work to
finalize the version 2.7 Root Store Policy update.

Here is a redline of all the changes:
https://github.com/mozilla/pkipolicy/compare/master...2.7 (click on the
Files Changed tab)

As noted below, two of these changes include effective dates. Otherwise,
CAs are expected to comply on or soon after the effective date of this
version of the policy. I expect the effective date for this version to be
sometime in December or early January.

I will greatly appreciate everyone's review of and feedback on these
changes.

- Wayne

Here is the status of the original set of issues:
176 - Clarify revocation requirements for S/MIME certs: included in the 2.7
draft policy: included in the 2.7 draft policy
175 - Forbidden Practices wiki page says email validation cannot be
delegated to 3rd parties: included in the 2.7 draft policy
173 - Strengthen requirement for newly included roots to meet all current
requirements: I decided to gather more information on the impact before
proceeding with this change.
172 - Update section 5.3 to include Policy Certification Authorities as an
exception to the mandatory EKU inclusion requirement: decided not to
implement this.
171 - Require binding of CA certificates to CP/CPS: included in the 2.7
draft policy
170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair: included in
the 2.7 draft policy
169, 140 - Extend Section 8 to also encompass subordinate CAs: included in
the 2.7 draft policy
168, 161, 158  - Require Incident Reports, move practices into policy:
included in the 2.7 draft policy. Issue #158 may require CP/CPS updates and
thus has an effective date of April 1, 2020
163 - Require EKUs in end-entity certificates (S/MIME): included in the 2.7
draft policy with an effective date of July 1, 2020
162 - Require disclosure of CA software vendor/version in incident report:
decided not to implement this
159 - Clarify section 5.3.1 Technically Constrained: included in the 2.7
draft policy
152 - Add EV audit exception for policy constrained intermediates: I
decided to defer this to a future policy discussion
151 - Change PITRA to Point-in-Time assessment in section 8: included in
the 2.7 draft policy

The following issues are also resolved in the 2.7 draft:
167 - Add P-521 exclusion to Baseline Requirements exceptions in section 2.3
177 - Clarify revocation requirements for intermediate certificates in
regards to ca-compliance bugs
191 - Update section 1.2 to reflect creation of TLMC for appeals
193 - Require incident disclosure transitively for all sub-CAs

- Wayne

On Wed, Oct 2, 2019 at 3:17 PM Wayne Thayer  wrote:

> Over the past 3 months, a number of other projects distracted me from this
> work. Now I'd like to focus on finishing these updates to our Root Store
> policy. There are roughly 6 issues remaining to be discussed, and I will,
> as always, greatly appreciate everyone's input on them. I'll be sending out
> individual emails on each issue.
>
> Meanwhile, you can view a redline of the changes we previously agreed on:
> https://github.com/mozilla/pkipolicy/compare/master...2.7
>
> - Wayne
>
> On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:
>
>> I've added a few more issues that were recently created to the list for
>> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>>
>> 176 - Clarify revocation requirements for S/MIME certs
>> 175 - Forbidden Practices wiki page says email validation cannot be
>> delegated to 3rd parties
>>
>> I plan to begin posting issues for discussion shortly.
>>
>>
>> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>>
>>> Later this month, I would like to begin discussing a number of proposed
>>> changes to the Mozilla Root Store policy [1]. I have reviewed the list of
>>> issues on GitHub and labeled the ones that I recommend discussing:
>>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>>
>>> 173 - Strengthen requirement for newly included roots to meet all
>>> current requirements
>>> 172 - Update section 5.3 to include Policy Certification Authorities as
>>> an exception to the mandatory EKU inclusion requirement
>>> 171 - Require binding of CA certificates to CP/CPS
>>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair
>>> 169, 140 - Extend Section 8 to also encompass subordinate CAs
>>> 168, 161, 158  - Require Incident Reports, move practices into policy
>>> 163 - Require EKUs in end-entity certificates (S/MIME)
>>> 162 - Require disclosure of CA software vendor/version in incident report
>>> 159 - Clarify section 5.3.1 Technically Constrained
>>> 152 - Add EV audit exception for policy constrained intermediates
>>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>>
>>> I will appreciate any feedback on the proposed list of issues to discuss.
>>>
>>> I do recognize that the current DarkMatter discussions could result in
>>> the need to add some additional items to this list.
>>>
>>> I have created a new branch 

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

I've opened issue #196 [1] to track Rufus' suggested clarification for a
future policy update. I'll consider this issue (#175) resolved unless
further comments are received.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/196

On Mon, Oct 28, 2019 at 4:41 PM Wayne Thayer  wrote:

> On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus <
> rufus.busch...@siemens.com> wrote:
>
>> Maybe the following could be a reasonable rewording of the paragraph that
>> makes the intention of the discussion clear, but isn't to 'clunky':
>>
>> For a certificate capable of being used for digitally signing or
>> encrypting email messages, the CA SHALL validate that the Applicant
>> Representative (as defined in the BRGs) of the request controls the email
>> account associated with the email address referenced in the certificate,
>> except when the CA and the owner of the domain are Affiliates (as defined
>> in the BRGs). The CA SHALL NOT delegate the validation of an email address.
>> The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
>> to perform this validation.
>>
>>
> Thank you for the proposal. Proposals are always helpful! However, this
> seems significantly less clear to me.
>
> With this wording we would reach:
>>
>> 1) The request can be initiated by the Applicant or Applicant
>> Representative - due to the definition of Applicant Representative in the
>> BRGs
>>
>
> The existing language does the same without adding more BR references.
>
> 2) Every CA can continue to issue S/MIME certificates as long as they
>> perform a validation of the control of the email address
>> 3) The CA cannot delegate the validation process
>>
>
> Did you intentionally omit the language that allows the CA to delegate
> validation of the local portion of the email address?
>
> 4) If the operator of the mail server operates its own CA, he doesn't have
>> to perform error prone email address validations
>>
>
> The existing language already permits this via "*or* has been authorized
> by the email account holder to act on the account holder's behalf."
>
> Do you believe that this is forbidden by the current version of Mozilla
> policy?
>
>
>> 5) We don't mix the words validation and verification for the same
>> activity
>>
>>
> I have no issue with changing "verification" to "validation", but this is
> also unchanged from the current version of the policy.
>
> In other words, these proposed changes address what might be another
> potential issue with the existing policy, but don't appear to be essential
> to the issue being discussed in this thread.
>
> > As to which is it - is it the MX admin/domain admin or the individual
>> meat person - it seems that the answer is
>> > either/or/both, at least from the perspective of RFC 822. The
>> meat-person may control the account, or the admin
>> > of the account may themselves control the account, or the admin of the
>> domain may control the MX that controls
>> > the account. In all cases, they control the email account associated.
>>
>> In the upcoming S/MIME WG I see a lot of discussions around this topic
>> arising.
>>
>> With best regards,
>> Rufus Buschart
>>
>> Siemens AG
>> Siemens Operations
>> Information Technology
>> Value Center Core Services
>> SOP IT IN COR
>> Freyeslebenstr. 1
>> 91058 Erlangen, Germany
>> Tel.: +49 1522 2894134
>> mailto:rufus.busch...@siemens.com
>> http://www.twitter.com/siemens
>> https://siemens.com/ingenuityforlife
>>
>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
>> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
>> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
>> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
>> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
>> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, Oct 21, 2019 at 6:49 PM Wayne Thayer  wrote:

> Here are the proposed changes:
> * Reinstate Mozilla's revocation requirements for S/MIME certificates:
> https://github.com/mozilla/pkipolicy/commit/e6337bb76a4522da15aeb7c0862b6cc05d317814
> (replacing the original 2.7 proposal with the older Root Store policy
> requirements)
> * Require revocation when a certificate violates our Root Store policy:
> https://github.com/mozilla/pkipolicy/commit/fbe5c4f7b78bd4572632ce411a758eba1acf04ef
> (note: I've already fixed the typo)
>
>
I also fixed the list formatting here. Having received no further comments,
I will consider these proposals to be accepted.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 7:41 PM Ryan Sleevi  wrote:

>
> On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I have added this proposal to the 2.7 branch:
>>
>> https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc
>>
>> I will greatly appreciate everyone's feedback on these changes.
>
>
> This is almost entirely on the typographical side:
> items 1-4 use ; at the end of line. Item 5 uses "; and", and item 6 ends
> with "."
>
> If the desire is to keep that structure, then I think the following
> changes are needed:
> - item 5 has "; and" changed to ";"
> - item 6 has "." changed to "; and"
> - Item 7 has "Ensure" changed to "ensure"
>

Thanks for catching this Ryan. I've fixed these issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus 
wrote:

> Maybe the following could be a reasonable rewording of the paragraph that
> makes the intention of the discussion clear, but isn't to 'clunky':
>
> For a certificate capable of being used for digitally signing or
> encrypting email messages, the CA SHALL validate that the Applicant
> Representative (as defined in the BRGs) of the request controls the email
> account associated with the email address referenced in the certificate,
> except when the CA and the owner of the domain are Affiliates (as defined
> in the BRGs). The CA SHALL NOT delegate the validation of an email address.
> The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
> to perform this validation.
>
>
Thank you for the proposal. Proposals are always helpful! However, this
seems significantly less clear to me.

With this wording we would reach:
>
> 1) The request can be initiated by the Applicant or Applicant
> Representative - due to the definition of Applicant Representative in the
> BRGs
>

The existing language does the same without adding more BR references.

2) Every CA can continue to issue S/MIME certificates as long as they
> perform a validation of the control of the email address
> 3) The CA cannot delegate the validation process
>

Did you intentionally omit the language that allows the CA to delegate
validation of the local portion of the email address?

4) If the operator of the mail server operates its own CA, he doesn't have
> to perform error prone email address validations
>

The existing language already permits this via "*or* has been authorized by
the email account holder to act on the account holder's behalf."

Do you believe that this is forbidden by the current version of Mozilla
policy?


> 5) We don't mix the words validation and verification for the same activity
>
>
I have no issue with changing "verification" to "validation", but this is
also unchanged from the current version of the policy.

In other words, these proposed changes address what might be another
potential issue with the existing policy, but don't appear to be essential
to the issue being discussed in this thread.

> As to which is it - is it the MX admin/domain admin or the individual
> meat person - it seems that the answer is
> > either/or/both, at least from the perspective of RFC 822. The
> meat-person may control the account, or the admin
> > of the account may themselves control the account, or the admin of the
> domain may control the MX that controls
> > the account. In all cases, they control the email account associated.
>
> In the upcoming S/MIME WG I see a lot of discussions around this topic
> arising.
>
> With best regards,
> Rufus Buschart
>
> Siemens AG
> Siemens Operations
> Information Technology
> Value Center Core Services
> SOP IT IN COR
> Freyeslebenstr. 1
> 91058 Erlangen, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> http://www.twitter.com/siemens
> https://siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Firefox removes UI for site identity

[Wayne Thayer via dev-security-policy]

Hi Paul,

On Mon, Oct 28, 2019 at 2:41 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


> [PW] So you dislike Mozilla’s implementation for the tracker icon in the
> address bar? When you update to 70.0 you’re prompted with an
> educational-type pop-out to draw your attention to the visual indicator. Do
> you think that’s a bad idea? Do you think users should just know how to use
> browser software?
>
>
This repeated comparison of the EV indicator to the privacy shield is
apples to orangutans. The security and privacy of a Firefox user doesn't
depend on them interacting with the privacy shield. If a user never notices
the privacy shield, that user will be as secure as one who examines it on
every page load. It follows that there is no need for users to be properly
trained to interact with the privacy shield to protect themselves. This
gets to the root of the problem with the EV UI as a positive security
indicator.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Thu, Oct 24, 2019 at 10:33 AM Buschart, Rufus 
wrote:

> On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi <mailto:r...@sleevi.com>
> wrote:
> > On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy
> <mailto:dev-security-policy@lists.mozilla.org> wrote:
> >> Thanks Dimitris and Rufus. Would it satisfy your concern if the
> requirement
> >> was changed to:
> >>
> >> The CA SHALL NOT delegate validation of the Base Domain Name (as
> defined in
> >> the Baseline Requirements) portion of an email address.
>
> Thanks Wayne, I like the new wording.
>
> > If the CA has validated "mycompany.example", associated with account
> "mycompany", what is the expectation for 'localpart'?
> >
> > Interpretation 1) The CA MAY delegate validation of the localpart to
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> > Interpretation 2) By validating 'mycompany' as to have control over
> 'mycompany.example', the CA has taken reasonable measure. No further
> validation requirements
> > exist for the localpart, provided it is directed by the 'mycompany'
> account, as 'mycompany' is seen to implicitly have control over the MX
> records.
> >
> > I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
> trying to get at whether
> > (CA || mycompany) needs to perform some validation step for 'localpart'
> once the validation for the domain part is done.
>
> I simply want to avoid to come into the situation, that I as the operator
> of an internal Enterprise PKI have to do some additional email validation
> on our own mailboxes. We do have 350 k users, if the validation process
> fails only at 1% of them, we have 3500 help desk tickets.
>
> One last remark: I might be the only one, but I'm not 100% sure what the
> "this verification" at the end of the last sentence refers to. Is "this
> verification" (a) the verification of the Authorization Domain Name, (b)
> the verification of the email address or (c) both together? If it is (b),
> as I believe, I would move the whole sentence, starting from "The CA's
> CP/CPS...", after the first sentence (ending with "the account holder's
> behalf").
>
>
I would argue that (a) is a subset of (b) and there is no difference
between (b) and (c), but the intent is (c). If a CA issues both TLS and
S/MIME certificates, their CPS could simply state that the domain component
is validated using the same methods as used for TLS. For a CA that only
issues S/MIME certificates, I want to see the methods used to validate the
domain part documented - especially given that they aren't subject to the
BRs - along with the methods used to validate the local part or the entire
address.

Would changing "this" to "email address" but leaving that sentence after
the domain part requirements make it clear? That would read:

"The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
to perform email address verification."

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

Having received no comments, I did not add the proposed guidance on status
update frequency, but I did make the "marked as resolved" change that
Jeremy suggested:
https://github.com/mozilla/pkipolicy/commit/bad3fedc10e1fe9d5237760093ad235326e3bd62

An additional related change has been proposed in issue #193 [1]: require
incident disclosure transitively for all sub-CAs. In the issue, it was
pointed out that  the expectations for incident reporting by subordinate
CAs might not be clear, and a number of options were presented. I proposed
that the most important point to make in policy is that Mozilla holds the
program member (i.e. root CA) accountable.

Ryan suggested the following addition to the list of requirements in
section 2.1 to clarify this requirement:

The CA whose certificates are included in Mozilla's root program MUST
ensure that all certificates within the scope of this policy, as described
in Section 1.1, adhere to this policy.

I have added this proposal to the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc

I will greatly appreciate everyone's feedback on these changes.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/193

On Fri, Oct 4, 2019 at 4:22 PM Wayne Thayer  wrote:

> Jeremy Rowley posted the following comments in a separate thread:
>
> One suggestion on incident reports is to define "regularly update" as some
>> period of time as non-responses can result in additional incident reports.
>> Maybe something along the lines of "the greater of every 7 days, the time
>> period specified in the next update field by Mozilla, or the time period
>> for the next update as agreed upon with Mozilla". I'd also change "the
>> corresponding bug is resolved by a Mozilla representative" to "the
>> corresponding bug is marked as resolved in bugzilla by a Mozilla
>> representative" since the CA is resolving the actual bug, and Mozilla is
>> managing its perception on the bug's status.
>>
>
> While I agree with the intent, I do fear that something this strict in
> policy creates the wrong incentives (e.g. bots that auto-comment bugs with
> no real updates, and others that create new incidents after 7 days and one
> second). I'd be okay with adding something like "CAs SHOULD update status
> weekly and MUST provide status updates at least every 30 days unless
> otherwise agreed by a Mozilla representative."
>
> The addition of "marked as resolved" makes sense to me.
>
> On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:
>
>>
>> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer 
>> wrote:
>>
>>>
>>> I've drafted a specific proposal for everyone's consideration:
>>>
>>>
>>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>>
>>>
>> Having received no new comments on this proposal, I'll consider this
>> issue closed and plan to include it in policy version 2.7.
>>
>> - Wayne
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi  wrote:

>
> On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> > I'm also not sure if I understand the wording correctly. Let's assume,
>> an
>> > internal CA of company "mycompany" gets successfully validated for
>> > mycompany.example and receives a (possibly name constrained) certificate
>> > for its issuing CA from one of the root CAs. Can this internal CA issue
>> > certificates for every email address under @mycompany.example without
>> > further validation or is an internal validation process required? My
>> > opinion is, that such an internal validation process doesn't increase
>> > security, since mycompany controls the mailservers of mycompany and can
>> > anyhow validate everything.
>> >
>> >
>> Thanks Dimitris and Rufus. Would it satisfy your concern if the
>> requirement
>> was changed to:
>>
>> The CA SHALL NOT delegate validation of the Base Domain Name (as defined
>> in
>> the Baseline Requirements) portion of an email address.
>>
>
> I may be misunderstanding Rufus' concern, but it seemed slightly different?
>
> That is, taken in the whole of 2.2, the expectation is "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 *or* has been authorized by the email account holder to act
> on the account holder's behalf".
>
> If the CA has validated "mycompany.example", associated with account
> "mycompany", what is the expectation for 'localpart'?
>
> Interpretation 1) The CA MAY delegate validation of the localpart to
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> Interpretation 2) By validating 'mycompany' as to have control over
> 'mycompany.example', the CA has taken reasonable measure. No further
> validation requirements exist for the localpart, provided it is directed by
> the 'mycompany' account, as 'mycompany' is seen to implicitly have control
> over the MX records.
>
> I'm not sure Interpretation #2 fully holds (e.g. if the CA were using
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was
> trying to get at whether (CA || mycompany) needs to perform some validation
> step for 'localpart' once the validation for the domain part is done.
>
>
The "new" (it was already a Forbidden Practice) restriction on delegating
domain validation doesn't change the language that applies here, which is
that "...the CA takes reasonable measures..." and that "The CA's CP/CPS
must clearly specify the procedure(s)...". Until there are BRs for S/MIME,
CAs must define and document their email validation practices.

  As to Dimitris' case, I think you're spot on in understanding the problem.
>
>
>> Alternately, would this create an unacceptable loophole in the requirement
>> and if so, can you suggest a more secure alternative?
>
>
> My worry is that CAs will read this believing it permits more than
> intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain
> Name", and only validates at the FQDN (i.e. the entire @domain), they may
> see this as being permitted to delegate. After all, they are not delegating
> validation of a Base Domain Name, they're delegating validation of an FQDN.
>
> """The CA SHALL NOT delegate validation of the domain portion of an email
> address. The CA MAY rely on validation the CA has performed for an
> Authorization Domain Name (as specified in the Baseline Requirements) as
> being valid for subdomains of that Authorization Domain Name."""
>
>
This is much better, thanks. The proposed change is:
https://github.com/mozilla/pkipolicy/commit/0a63f457c059365103e48ad3eb409cd376903e51

The point here is to make it explicit SHALL NOT. The following sentence
> does not conflict or limit that scope, but gives the CA limited additional
> permission to address the case Dimitris raised.
>
> The choice of "Authorization Domain Name" versus "Base Domain Name" is
> that a given FQDN may have multiple "Base Domain Names", due to how the
> Public Suffix List works. The Authorization Domain Name process was
> designed to find the most specific Base Domain Name, by pruning labels
> left-to-right. Rather than recreate that algorithm, I reused it here.
>
> The downside is that such a definition picks up CNAME chasing, which
> (similar to the remarks to Rufus), can be distinct from MX validation in
> some situations. However, it's a trade-off, and seems strictly improved
> over the status quo, and regardless, the documentation requirement that 2.2
> places would cover those situations (hopefully).
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox removes UI for site identity

[Wayne Thayer via dev-security-policy]

The primary purpose of forwarding the Intent to Ship email to this list was
to inform the community of this planned change and the reasoning behind it.
Mozilla considered lots of information prior to announcing the change, and
during the vigorous debate that ensued, we continued to listen without
taking sides. In the end, the discussion and information presented did not
compel us to change our decision.

On Tue, Oct 22, 2019 at 4:49 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via
> dev-security-policy wrote:
> > I also have a question for Mozilla on the removal of the EV UI.
>
> This is a mischaracterisation.  The EV UI has not been removed, it has been
> moved to a new location.
>
> > So my question to Mozilla is, why did Mozilla post this as a subject on
> > the mozilla.dev.security.policy list if it didn't plan to interact with
> > members of the community who took the time to post responses?
>
> What leads you to believe that Mozilla didn't plan to interact with members
> of the community?  It is entirely plausible that if any useful responses
> that warranted interaction were made, interaction would have occurred.
>
> I don't believe that Mozilla is obliged to respond to people who have
> nothing useful to contribute, and who don't accurately describe the change
> being made.
>
> > This issue started with a posting by Mozilla on August 12, but despite
> 237
> > subsequent postings from many members of the Mozilla community, I don't
> > think Mozilla staff ever responded to anything or anyone - not to explain
> > or justify the decision, not to argue.  Just silence.
>
> I think the decision was explained and justified in the initial
> announcement.  No information that contradicted the provided justification
> was presented, so I don't see what argument was required.
>
> > In the future, if Mozilla has already made up its mind and is not
> > interested in hearing back from the community, it might be better NOT to
> > start a discussion on the list soliciting feedback.
>
> Soliciting feedback and hearing back from the community does not require
> response from Mozilla, merely reading.  Do you have any evidence that
> Mozilla staff did not, in fact, read the feedback that was given?
>
> - Matt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox removes UI for site identity

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 1:38 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Johann. Much appreciated. Would you be kind enough to email me a
> screen shot to save me the trouble of installing an older version and then
> waiting for an update? :)
>
>
You can find the (now updated) release notes at
https://www.mozilla.org/en-US/firefox/70.0/releasenotes/

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 10:59 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > > Sounds good. This was your proposed response to solving this issue
> > > back on May 13, so it's full circle :)
> > >
> > >
> > > I'm going to consider this issue resolved unless there are further
> > > comments.
> >
> > Just checking whether the following is acceptable.
> >
> > If a CA validates the domain mycompany.example being owned/controlled by
> "mycompany", can this company delegate the issuance of
> > S/MIME certificates for subsection1.mycompany.example to an internal
> department or a subsidiary? Does the proposed language allow
> > this?
>
> I'm also not sure if I understand the wording correctly. Let's assume, an
> internal CA of company "mycompany" gets successfully validated for
> mycompany.example and receives a (possibly name constrained) certificate
> for its issuing CA from one of the root CAs. Can this internal CA issue
> certificates for every email address under @mycompany.example without
> further validation or is an internal validation process required? My
> opinion is, that such an internal validation process doesn't increase
> security, since mycompany controls the mailservers of mycompany and can
> anyhow validate everything.
>
>
Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
was changed to:

The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
the Baseline Requirements) portion of an email address.

Alternately, would this create an unacceptable loophole in the requirement
and if so, can you suggest a more secure alternative?

By the way: How are CAA records to be treated in the scope of S/MIME? Since
> gmail.com has a CAA record that prevents every CA except of Google to
> issue certificates for gmail.com, does this also forbid every CA to issue
> certificates for rufus.busch...@gmail.com?
>
>
I'm not aware of any current policy that requires CAs to perform CAA checks
on S/MIME certificates.

With best regards,
> Rufus Buschart
>
> Siemens AG
> Siemens Operations
> Information Technology
> Value Center Core Services
> SOP IT IN COR
> Freyeslebenstr. 1
> 91058 Erlangen, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
>
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief
> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and
> Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300,
> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer via dev-security-policy]

> there are not that many organizations, does a grandfathering clause cause
> unnecessary complexity? I realize this is not in DigiCert's best interest,
> but the community may benefit the most by simply requiring a review of all
> Sub CAs instead of trying to grandfather in existing cross-signs.  Do you
> have an idea on the number that might entail? At worst, we waste a bunch of
> time discovering that all of these are perfectly operated and that they
> could have been grandfathered in the first place. At best, we identify some
> critical issues and resolve them as a community.
>
>
>
> It appears to be at least 2 dozen organizations, based on the "subordinate
> CA owner" field in CCADB. I say "at least" because, as Dimitris noted,
> we're just now identifying intermediates that are incorrectly labeled as
> falling under the parent certificate's audits.
>
>
>
> If there are a significant number of unconstrained on-prem CAs, then
> language that requires a review on re-signing would be helpful.  Perhaps
> say "As of X date, a CA MUST NOT sign a non-technically constrained
> certificate where cA=True for keys that are hosted external to the CA's
> infrastructure or that are not operated in accordance with the issuing CA's
> policies and procedures unless Mozilla has first granted permission for
> such certificate"? The wording needs work of course, but the idea is that
> they go through the discussion and Mozilla signs off. A process for
> unconstrained Sub CAs that is substantially similar to the root inclusion
> makes sense, but there is documentation on CCADB for the existing ones.
> Still, this documentation should probably made available, along with the
> previous incident reports, to the community for review and discussion.
> Afterall, anything not fully constrained is essentially operating the same
> as a fully embedded root.
>
>
>
> Grandfathering in organizations currently in control of an unconstrained
> subordinate CA, but requiring them to go through an approval process before
> obtaining a new subordinate CA certificate seems like a good approach. I do
> however have concerns about requiring a process similar to the root
> inclusion process. We expect the root CA to take responsibility for the
> organizations they certify, so a lighter process that acts as a
> verification of the decision made by the root CA is appropriate here. To
> put it another way, applying the full root inclusion process to externally
> operated unconstrained subordinate CA certificates is not much different
> than forbidding them. I do agree that policy docs and audits should be made
> available as part of this review.
>
>
>
> Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a
> bad idea, and I fully support more careful scrutiny on which entities are
> controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are
> responsible for over half of the incident reports, with issues ranging from
> missed audit dates to incorrect profile information. The long cycle in
> getting information,  being a middle-man information gathering, and trying
> to convey both Mozilla and CAB forum policy makes controlling compliance
> very difficult, and a practice I would not recommend to any CA. Once you've
> established a relationship as a signer CA (or acquired a relationship),
> extraditing yourself is... difficult.  The certificates end up embedded on
> smart cards, used by government institutions and pinned in weird places.
> And the unfortunate part is you don't have the direct relationship with the
> end-user to offer counsel against some of the practices. That extra
> abstraction layer between the CA and root store program ends up adding a
> lot more complexity than you'd initially think. Delegating the CA
> responsibility ends up being a bad idea and takes years to fix. DigiCert is
> finally down to the final few TLS sub CAs (5) and each are operating in
> OCSP signing mode only. They'll all be revoked in 2020.
>
>
>
> Unless I'm missing something, DigiCert is continuing to issue externally
> operated S/MIME sub CAs, e.g. https://crt.sh/?id=1652799594
>
>
>
> Jeremy
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Thursday, October 3, 2019 2:45 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate
> CAs
>
> I'd like to revisit this topic because I see it as a significant change
> and am surprised that it didn't generate any discussion.
>
> Taking a step back, a change [1] to notification requirements was made

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Mon, Oct 21, 2019 at 7:01 PM Ryan Sleevi  wrote:

>
> On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer  wrote:
>
>> The CA MUST verify all e-mail addresses using a process that is
>>> substantially similar to the process used to verify domain names, as
>>> described in the Baseline Requirements.
>>>
>>
>> This seems problematic because it could be interpreted as forbidding an
>> email challenge-response validation, not to mention that "substantially"
>> leaves a lot of room for interpretation.
>>
>
> Yeah, this was more about short-hand matching the existing 2.2
> requirements for validation, which leave "reasonable measures" as the
> validation requirement (i.e. even more room for interpretation ;D)
>
>
>> The CA SHALL NOT delegate validation of the domain part of an e-mail
>>> address.
>>>
>>
>> This is
>> https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a
>>
>
> Sounds good. This was your proposed response to solving this issue back on
> May 13, so it's full circle :)
>
>

I'm going to consider this issue resolved unless there are further comments.


>> The CA SHALL NOT delegate validation of the local part of an e-mail
>>> address
>>> except when delegating to an Enteprise RA, provided that the domain part
>>> of
>>> the e-mail address is within the Enteprise RA's verified Domain
>>> Namespace.
>>>
>>>
>> This seems to go beyond the original intent of this issue and the
>> discussion to-date, and Enterprise RAs are not defined in the context of
>> S/MIME certificates. Why is the existing language in section 2.2(2)
>> insufficient to cover this requirement?
>>
>
> Your original proposal seemed to entirely do away with this ("Delegating
> this function to 3rd parties is not permitted."). I was trying to capture
> the subset for the use case folks identified (including my initial reply to
> your proposal, back on May 13), while still being more prescriptive.
>
> The issue/concern would be a CA reads that they shall not delegate the
> domain portion, but don't realize it /also/ means they can't delegate
> 'total' validation, since the full e-mail also contains a domain part. i.e.
> that I can't delegate validating sleevi.example, but I can totally delegate
> validating ryan@sleevi.example since that's not delegating "just" a
> domain part, but delegating validation a "total" email.
>
> It's contrived, I agree, but it was trying to match your original, much
> more restrictive language, of not allowing any delegation of e-mail.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

Here are the proposed changes:
* Reinstate Mozilla's revocation requirements for S/MIME certificates:
https://github.com/mozilla/pkipolicy/commit/e6337bb76a4522da15aeb7c0862b6cc05d317814
(replacing the original 2.7 proposal with the older Root Store policy
requirements)
* Require revocation when a certificate violates our Root Store policy:
https://github.com/mozilla/pkipolicy/commit/fbe5c4f7b78bd4572632ce411a758eba1acf04ef
(note: I've already fixed the typo)

As always, I will appreciate everyone's review or and comments on this
proposal.

- Wayne

On Wed, Oct 2, 2019 at 4:00 PM Wayne Thayer  wrote:

> Thank you for the comments Dimitris. I think you make a valid point in
> general that S/MIME certificates are quite different from TLS certificates,
> and applying the BR rules to them might not be appropriate. I expect this
> to ultimately be sorted out by the CAB Forum's future S/MIME Working Group,
> but in the interim we still need some reasonable Mozilla policy. This leads
> me to conclude that the best solution might be to do as Kathleen suggested
> and reinstate the old Mozilla revocation requirements (prior to referencing
> the BRs) to apply to S/MIME certificates:
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation
> The biggest change here from my earlier proposal would be that no
> revocation timeline would be specified.
>
> I also suggest that we add a requirement for both TLS and S/MIME
> certificates that states the CA must revoke a certificate that "does not
> comply with the version of this policy that was in effect at the time it
> was issued.". Currently, there is no hard requirement for CAs to revoke
> certificates that comply with the BRs but not with our own policy (e.g. use
> of the P-521 algorithm [1]).
>
> How do these changes sound to everyone?
>
> - Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/_eJvekr1BgAJ
>
> On Fri, Jun 14, 2019 at 10:43 PM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
>
>>
>> Dear Wayne,
>>
>> Please consider the fact that S/MIME is focused on "signature"
>> Certificates which has different considerations than "authentication"
>> Certificates. The baseline requirements (and their revocation
>> requirements) are focused on "authentication" Certificates. I believe
>> the revocation policies, at least for the CA Certificates, do not align
>> well with S/MIME.
>>
>> When a piece of data is "signed" (such as an e-mail), Relying Parties
>> need to be able to verify the status of the signing Certificate _when
>> the signature was created_. If the Issuing CA is revoked, it is no
>> longer able to provide status information for that Certificate. If we
>> think about the serial number issue, if a CA had to be revoked, status
>> information for its issued Certificates would discontinue leading
>> Relying Parties to have difficulties validating the existing signed
>> e-mails that were valid when signed.
>>
>> This might be something to consider more carefully.
>>
>>
>> Thank you,
>> Dimitris.
>>
>>
>> On 15/5/2019 3:25 π.μ., Wayne Thayer via dev-security-policy wrote:
>> > On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via
>> dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> On 5/10/19 5:46 PM, Wayne Thayer wrote:
>> >>> I've attempted to update section 6 to incorporate revocation
>> requirements
>> >>> for S/MIME certificates:
>> >>>
>> >>>
>> >>
>> https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637
>> >>> Note: since much of this language is copied directly from the BRs, if
>> we
>> >>> decide to adopt it, the policy will also need to comply with the
>> Creative
>> >>> Commons Attribution 4.0 International license used by the BRs.
>> >>>
>> >>> I will greatly appreciate everyone's review and comments on this
>> proposed
>> >>> change.
>> >>
>> >> The proposed changes look OK to me.
>> >>
>> >> But I would also be fine with the new section 6.2 regarding revocation
>> >> of S/MIME certs just re-using the revocation text that we used to have
>> >> in our policy (which had been removed in an effort to remove redundancy
>> >> with the BRs).
>> >>
>> >>
>> >>
>> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

On Sat, Oct 5, 2019 at 6:32 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Jeremy, Dimitris,
>
> It does help clarify. I think we're all on the same page: namely, in all
> cases, the CA does the validation of (at minimum) the domain portion.
>
> I think it might be useful to think of this like the split between
> Authorization Domain Name and Fully Qualified Domain Name. A CA isn't
> /required/ to only use the ADN, they could validate just the FQDN and
> always at the FQDN level. But, in both cases, they have to at least
> validate (a portion of) the domain name.
>
> For S/MIME, the idea here is:
> - If the CA had validated the domain portion, they could delegate the
> validation of the local part to the RA. This is the same as the concept of
> Enterprise RA, which allows the RA to handle the O/OU and other attributes,
> as long as the CA validated the domain.
> - Alternatively, the CA could validate the entire e-mail address (e.g.
> using a random value)
>
> But in both cases, the CA is involved in any domain-part validation.
>
> Perhaps said differently:
>

It's not clear if you intended the following to be a concrete policy
proposal, but I'll treat it as such.

The CA MUST verify all e-mail addresses using a process that is
> substantially similar to the process used to verify domain names, as
> described in the Baseline Requirements.
>

This seems problematic because it could be interpreted as forbidding an
email challenge-response validation, not to mention that "substantially"
leaves a lot of room for interpretation.

The CA SHALL NOT delegate validation of the domain part of an e-mail
> address.
>

This is
https://github.com/mozilla/pkipolicy/commit/85ae5a1b37ca8e5138d56296963195c3c7dec85a

The CA SHALL NOT delegate validation of the local part of an e-mail address
> except when delegating to an Enteprise RA, provided that the domain part of
> the e-mail address is within the Enteprise RA's verified Domain Namespace.
>
>
This seems to go beyond the original intent of this issue and the
discussion to-date, and Enterprise RAs are not defined in the context of
S/MIME certificates. Why is the existing language in section 2.2(2)
insufficient to cover this requirement?

I tried a couple variations of this (e.g. MAY delegate), but that could be
> read as a loophole of allowing other forms of local-part delegation (i.e.
> the "MAY" reads as "MAY use an Enterprise RA, or MAY use whatever else you
> want", instead of "MAY" only if Enterprise RA)
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

I've gone ahead and moved the effective date of this policy back to July 1,
2020:
https://github.com/mozilla/pkipolicy/commit/7a879fe371844d265c484a8f0ce40fd255967c13

On Wed, Oct 2, 2019 at 6:04 PM Jeremy Rowley 
wrote:

> I'm surprised any CA has heartburn over the EKU changes. Microsoft has
> required them in end entity certificates for quite some time. From the MS
> policy: "Effective February 1, 2017, all end-entity certificates must
> contain the EKU for the purpose that the CA issued the certificate to the
> customer, and the end-entity certificate may not use “any EKU.”" There's a
> chance that the CA is not in Microsoft, but I thought Mozilla usually had
> fewer CAs than Microsoft included.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, October 2, 2019 6:05 PM
> To: horn...@gmail.com
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
>
> On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：
> > > The BRs require EKUs in leaf TLS certs, but there is no equivalent
> > > requirement for S/MIME certificates. This leads to confusion such as
> > > [1]
> > in
> > > which certificates that are not intended for TLS or S/MIME fall
> > > within
> > the
> > > scope of our policies.
> > >
> > > Simply requiring EKUs in S/MIME certificates won't solve the problem
> > unless
> > > we are willing to exempt certificates without an EKU from our
> > > policies,
> > and
> > > doing that would create a rather obvious loophole for issuing S/MIME
> > > certificates that don't adhere to our policies.
> > >
> > > The proposed solution is to require EKUs in all certificates that
> > > chain
> > up
> > > to roots in our program, starting on some future effective date (e.g.
> > April
> > > 1, 2020). This has the potential to cause some compatibility
> > > problems
> > that
> > > would be difficult to measure and assess. Before drafting language
> > > for
> > this
> > > proposal, I would like to gauge everyone's support for this proposal.
> > >
> > > Alternately, we could easily argue that section 1.1 of our existing
> > policy
> > > already makes it clear that CAs must include EKUs other than
> > > id-kp-serverAuth and id-kp-emailProtection in certificates that they
> > > wish to remain out of scope for our policies.
> > >
> > > This is https://github.com/mozilla/pkipolicy/issues/163
> > >
> > > I will greatly appreciate everyone's input on this topic.
> > >
> > > - Wayne
> > >
> > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
> >
> >
> > GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates
> > However, the influence range of implementation is very large.
> > We need to define our own Document Signing EKU and data encryption
> > EKU, and coordinate all subordinate Cas(Five CAs) and application
> > system’s owners(more than 2,000 application systems).
> > It needs a whole year to implement this. Therefore, after multiple
> > evaluations, it is decided to officially add the EKU to the user
> > certificate on January 1, 2021.
> > It is difficult for us to complete ahead of April 2020.
> > Can we get more buffer?
> >
> >
> I had expected to have this policy update completed sooner when I proposed
> April 2020 as the date for requiring EKUs in end-entity certificates. Given
> that, I think it's reasonable to push the date back to July 2020, but not
> to January 2021. 2021 seems particularly unreasonable in light of the
> Microsoft requirement [1] that went into effect in January 2017 and appears
> to apply to GPKI.
>
> Will any other CAs find it impossible to meet this requirement for
> certificates issued after June 2020? Also, are there any concerns with this
> applying to certificates issued from technically constrained intermediate
> CA certificates? As-proposed, this applies to those certificates (and it
> appears to me that Microsoft's policy does as well).
>
> - Wayne
>
> [1]
>
> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Wayne Thayer via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1480510.

- Wayne

On Tue, Oct 8, 2019 at 4:23 PM Wayne Thayer  wrote:

> On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
>>
>> > We will update section 4.2 and 9.12.3 in the next release of the CPS.
>>
>> The CPS Has been updated to address the above issues, see
>> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf
>> .
>>
>> I've verified these updates.
>
> This request has been in discussion for quite a while now. Please post any
> further comments by next Tuesday 15-October, and I will plan to end the
> discussion period at that time.
>
> - Wayne
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Entrust Root Certification Authority - G4 Inclusion Request

[Wayne Thayer via dev-security-policy]

On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
>
> > We will update section 4.2 and 9.12.3 in the next release of the CPS.
>
> The CPS Has been updated to address the above issues, see
> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf
> .
>
> I've verified these updates.

This request has been in discussion for quite a while now. Please post any
further comments by next Tuesday 15-October, and I will plan to end the
discussion period at that time.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

Jeremy Rowley posted the following comments in a separate thread:

One suggestion on incident reports is to define "regularly update" as some
> period of time as non-responses can result in additional incident reports.
> Maybe something along the lines of "the greater of every 7 days, the time
> period specified in the next update field by Mozilla, or the time period
> for the next update as agreed upon with Mozilla". I'd also change "the
> corresponding bug is resolved by a Mozilla representative" to "the
> corresponding bug is marked as resolved in bugzilla by a Mozilla
> representative" since the CA is resolving the actual bug, and Mozilla is
> managing its perception on the bug's status.
>

While I agree with the intent, I do fear that something this strict in
policy creates the wrong incentives (e.g. bots that auto-comment bugs with
no real updates, and others that create new incidents after 7 days and one
second). I'd be okay with adding something like "CAs SHOULD update status
weekly and MUST provide status updates at least every 30 days unless
otherwise agreed by a Mozilla representative."

The addition of "marked as resolved" makes sense to me.

On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:

>
> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer  wrote:
>
>>
>> I've drafted a specific proposal for everyone's consideration:
>>
>>
>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>
>>
> Having received no new comments on this proposal, I'll consider this issue
> closed and plan to include it in policy version 2.7.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7 Proposal: Update Appeal Process

[Wayne Thayer via dev-security-policy]

The last sentence of section 1.2 Policy Ownership states:

CAs or others objecting to a particular decision by either team MAY appeal
> to the Mozilla governance module owner
>  who will make a
> final decision.
>

Last year [1], Mozilla delegated this responsibility to the Firefox
Technical Leadership Module [2], and I have updated this sentence to
reflect that change [3].

This is https://github.com/mozilla/pkipolicy/issues/191

I will plan to make this change unless objections are raised.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.governance/YTTqUzWaJ00/-MopTK71AwAJ
[2] https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership
[3]
https://github.com/mozilla/pkipolicy/commit/2a30327cde67e9431cb9d6b5c270d7ad855887bd
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Wayne Thayer via dev-security-policy]

I'd like to revive this discussion. So far we've established that the
existing "required practice" [1] is too stringent for email address
validation and needs to be changed. We can do that by removing email
addresses from the scope of the requirement as Kathleen proposed, or by
exempting the local part of the email address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email
address to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how
removing the requirement entirely is beneficial, but no one else has spoken
in favor of this need. Kathleen did however point out that this requirement
doesn't appear to be the result of a thorough analysis. We have Ryan Sleevi
arguing that the process described by Ryan Hurst is insecure and thus a
reason to forbid delegation of validation of the domain name part. Pedro
Fuentes also wrote in favor of this outcome.

One thing that might help to resolve this is a more detailed description of
the weaknesses that are present in the process described by Ryan Hurst. If
we can all agree that the process is vulnerable, then it seems that we'd
have a strong argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to third
> > parties. However, the BRs don't forbid delegation of email address
> > validation nor do they apply to S/MIME certificates.
> >
> > Delegation of email address validation is already addressed by Mozilla's
> > Forbidden Practices [1] state:
> >
> > "Domain and Email validation are core requirements of the Mozilla's Root
> > Store Policy and should always be incorporated into the issuing CA's
> > procedures. Delegating this function to 3rd parties is not permitted."
> >
> > I propose that we move this statement (changing "the Mozilla's Root Store
> > Policy" to "this policy") into policy section 2.2 "Validation Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> Domain and Email validation are core requirements of the Mozilla's Root
> Store Policy and should always be incorporated into the issuing CA's
> procedures. Delegating this function to 3rd parties is not permitted."
>
> Based on the way that section is written, it appears that domain
> validation (and the BRs) was the primary consideration, and that the
> Email part of it was an afterthought, or added later. Historically, my
> attention has been focused on TLS certs, so it is possible that the
> ramifications of adding Email validation to this section was not fully
> thought through.
>
> I don't remember who added this email validation text or when, but I can
> tell you that when I review root inclusion requests I have only been
> concerned about making sure that domain validation is not being
> delegated to 3rd parties. It wasn't until a representative of a CA
> brought this to my attention that I realized that there has been a
> difference in text on this wiki page versus the rules I have been trying
> to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant security reasons to add our own
> S/MIME required/forbidden practices at this time, my preference is to
> wait for the CA/Browser Forum to create the S/MIME Working Group, and
> for that group to identify the S/MIME baseline requirements. Then we can
> add policy and required/forbidden practices based on the S/MIME BRs
> provided by that group.
>
> I do realize that my proposal is unfair to CAs who have been diligently
> following this section of this wiki page. Your diligence is appreciated,
> and your contributions to this discussion will also be appreciated.
>
> Thanks,
> Kathleen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer via dev-security-policy]

rrect profile information. The long cycle in
> getting information,  being a middle-man information gathering, and trying
> to convey both Mozilla and CAB forum policy makes controlling compliance
> very difficult, and a practice I would not recommend to any CA. Once you've
> established a relationship as a signer CA (or acquired a relationship),
> extraditing yourself is... difficult.  The certificates end up embedded on
> smart cards, used by government institutions and pinned in weird places.
> And the unfortunate part is you don't have the direct relationship with the
> end-user to offer counsel against some of the practices. That extra
> abstraction layer between the CA and root store program ends up adding a
> lot more complexity than you'd initially think. Delegating the CA
> responsibility ends up being a bad idea and takes years to fix. DigiCert is
> finally down to the final few TLS sub CAs (5) and each are operating in
> OCSP signing mode only. They'll all be revoked in 2020.
>
>
Unless I'm missing something, DigiCert is continuing to issue externally
operated S/MIME sub CAs, e.g. https://crt.sh/?id=1652799594

Jeremy
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Thursday, October 3, 2019 2:45 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate
> CAs
>
> I'd like to revisit this topic because I see it as a significant change
> and am surprised that it didn't generate any discussion.
>
> Taking a step back, a change [1] to notification requirements was made
> last year to require CAs that are signing unconstrained subordinate CAs
> (including cross-certs) controlled by a different organization to notify
> Mozilla. We have received few, if any, notifications of this nature, so I
> have to wonder if CAs are adhering to this requirement.
>
> This requirement applies as follows:
>
> an organization other than the CA obtains control of an unconstrained
> > intermediate certificate (as defined in section 5.3.2 of this policy)
> > that directly or transitively chains to the CA's included
> > certificate(s);
> >
>
> Is the "obtains control" language being interpreted to mean that this only
> applies when control of the private keys change, and not when a CA signs a
> key controlled by a different organization? I believe the intent is for
> this to apply in both situations - otherwise it is trivial to bypass.
>
> The new change [2] proposed for version 2.7 of our policy goes one step
> further and places transfers and signings of unconstrained subordinate CAs
> clearly in the scope of section 8.1, including the following language:
>
> If the receiving or acquiring company is new to the Mozilla root program,
> > it must demonstrate compliance with the entirety of this policy and
> > there MUST be a public discussion regarding their admittance to the
> > root program, which Mozilla must resolve with a positive conclusion in
> > order for the affected certificate(s) to remain in the root program.
> > If the entire CA operation is not included in the scope of the
> > transaction, issuance is not permitted until the discussion has been
> resolved with a positive conclusion.
>
>
> That means any organization "new to the Mozilla root program" for which a
> CA signs an unconstrained subordinate CA or cross-cert must go through an
> approval process including a public discussion before issuing certificates
> in order to comply with this policy.
>
> It also means that we need to decide what "new to the Mozilla root program"
> means. Organizations that control unconstrained subordinate CAs have not
> been considered members of the program in the past, so it's easy to argue
> that every such organization will be "new to the Mozilla root program"
> if/when this policy goes into effect. However, it may be more practical to
> "grandfather in" organizations that are currently in control of
> unconstrained subordinate CAs.
>
> This also raises the question of what it means to "demonstrate compliance
> with the entirety of this policy". Section 8.1 has historically applied to
> companies acquiring root CAs and we have not required them to go through
> the entire inclusion process - only a public discussion. Should that same
> interpretation apply to unconstrained subordinate CA?
>
> Before proposing any changes, I'd like to ask for everyone's input on
> these and any other concerns stemming from this policy proposal.
>
> - Wayne
>
> [1]
>
> https://github.com/mozilla/pkipolicy/commit/7a3

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer via dev-security-policy]

I'd like to revisit this topic because I see it as a significant change and
am surprised that it didn't generate any discussion.

Taking a step back, a change [1] to notification requirements was made last
year to require CAs that are signing unconstrained subordinate CAs
(including cross-certs) controlled by a different organization to notify
Mozilla. We have received few, if any, notifications of this nature, so I
have to wonder if CAs are adhering to this requirement.

This requirement applies as follows:

an organization other than the CA obtains control of an unconstrained
> intermediate certificate (as defined in section 5.3.2 of this policy) that
> directly or transitively chains to the CA's included certificate(s);
>

Is the "obtains control" language being interpreted to mean that this only
applies when control of the private keys change, and not when a CA signs a
key controlled by a different organization? I believe the intent is for
this to apply in both situations - otherwise it is trivial to bypass.

The new change [2] proposed for version 2.7 of our policy goes one step
further and places transfers and signings of unconstrained subordinate CAs
clearly in the scope of section 8.1, including the following language:

If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program. If the entire CA
> operation is not included in the scope of the transaction, issuance is not
> permitted until the discussion has been resolved with a positive conclusion.


That means any organization "new to the Mozilla root program" for which a
CA signs an unconstrained subordinate CA or cross-cert must go through an
approval process including a public discussion before issuing certificates
in order to comply with this policy.

It also means that we need to decide what "new to the Mozilla root program"
means. Organizations that control unconstrained subordinate CAs have not
been considered members of the program in the past, so it's easy to argue
that every such organization will be "new to the Mozilla root program"
if/when this policy goes into effect. However, it may be more practical to
"grandfather in" organizations that are currently in control of
unconstrained subordinate CAs.

This also raises the question of what it means to "demonstrate compliance
with the entirety of this policy". Section 8.1 has historically applied to
companies acquiring root CAs and we have not required them to go through
the entire inclusion process - only a public discussion. Should that same
interpretation apply to unconstrained subordinate CA?

Before proposing any changes, I'd like to ask for everyone's input on these
and any other concerns stemming from this policy proposal.

- Wayne

[1]
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
[2]
https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8


On Fri, May 10, 2019 at 1:58 PM Wayne Thayer  wrote:

> Having received no comments on these proposed changes, I plan to include
> them in version 2.7 of our policy.
>
> - Wayne
>
> On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer  wrote:
>
>> Ryan Sleevi made the following proposal:
>>
>> Issue #122 [1] previously discussed Section 8 in the context of
>>> subordinate CAs, with a change [2] being made to include subordinate CAs
>>> (in the context of Section 5.3.2) within scope of notification requirements.
>>>
>>> However, as presently worded, it's ambiguous as to whether or not
>>> Sections 8.1 through 8.3 also apply to subordinate CAs, or whether the only
>>> disclosure required is upon the initial introduction of the subordinate.
>>> This confusion results from language such as in Section 8.1, "or when an
>>> organization buys the private key of a certificate in Mozilla's root
>>> program", implying that private keys which transitively chain to a root
>>> certificate within Mozilla's program are exempt from such requirements.
>>>
>>> This ambiguity creates incentives for situations such as cross-signing
>>> CAs that might otherwise or have been otherwise rejected from direct
>>> inclusion within the Mozilla program. It further creates issues with
>>> respect to the supervision of audits and auditors.
>>>
>>> While it is true that the signing CA accepts the risk that an
>>> unfavorable verdict on the subordinate may impact the root, the cost of
>>> such a decision is primarily borne by Mozilla and the broader community, in
>>> that they are responsible for the collateral ecosystem challenges and
>>> devising appropriate solutions. This has been demonstrated, for example,
>>> through the discussion of Symantec issues [3].
>>>
>>> Because Mozilla and the community bear significant cost, 

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I've gone ahead and moved [4] to the "Recommended Practices" section.

The ballot to modify the BRs is now in the formal discussion period leading
up to a vote [5].

I'll be resolving the existing compliance bugs on this issue as INVALID.
I'd like to thank the CAs that proactively submitted incident reports
rather than taking a "wait and see" approach. That degree of transparency
is both appreciated and encouraged.

- Wayne

[5] https://cabforum.org/pipermail/servercert-wg/2019-October/001145.html

On Wed, Oct 2, 2019 at 2:20 AM Rob Stradling  wrote:

> On 02/10/2019 00:51, Wayne Thayer wrote:
> > On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> >
> > I propose that you update [4] to say that Mozilla won't treat
> > non-compliance with [4] as an "incident" whilst it remains the case
> > that the BRs are inconsistent with [4].
> >
> > I could simply move [4] to a "recommended practice" (SHOULD) until the
> > ballot comes into force, then move it back to "required". That implies
> > that the bugs which have been opened for this specific issue (responding
> > "unknown" - not to be confused with "returns 1 byte") will be closed as
> > INVALID.
> >
> > Are there strong objections to this course of action?
>
> It seems a bit strange to recommend a practice that CAs cannot currently
> adhere to without violating the BRs and some other root programs'
> policies, but at the same time it is helpful to signpost upcoming policy
> changes.
>
> I don't object strongly.
>
> > - Wayne
> >
> > [4]
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

Thank you Ryan. Brian reviewed these changes back in May, so I've gone
ahead and accepted them for the 2.7 policy update:
https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27

I'll consider this issue resolved unless there are further comments.

- Wayne

On Fri, May 24, 2019 at 1:38 AM Ryan Sleevi  wrote:

>
>
> On Wed, May 22, 2019 at 7:43 PM Brian Smith  wrote:
>
>> Ryan Sleevi  wrote:
>>
>>>
>>>
 It would be easier to understand if this is true if the proposed text
 cited the RFCs, like RFC 4055, that actually impose the requirements that
 result in the given encodings.

>>>
>>> Could you clarify, do you just mean adding references to each of the
>>> example encodings (such as the above example, for the SPKI encoding)?
>>>
>>
>> Exactly. That way, it is clear that the given encodings are not imposing
>> a new requirement, and it would be clear which standard is being used to
>> determine to correct encoding.
>>
>
> Thanks, did that in
> https://github.com/sleevi/pkipolicy/commit/80da8acded63618a058d26c73db1e2438a6df9ed
>
>
>>
>> I realize that determining the encoding from each of these cited specs
>> would require understanding more specifications, including in particular
>> how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
>> calling out all of these details individually less people get confused by
>> inevitable omissions.
>>
>
> Hopefully struck the right balance. These changes are now reflected in the
> PR at https://github.com/mozilla/pkipolicy/pull/183
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next Root Store Policy Update

[Wayne Thayer via dev-security-policy]

Over the past 3 months, a number of other projects distracted me from this
work. Now I'd like to focus on finishing these updates to our Root Store
policy. There are roughly 6 issues remaining to be discussed, and I will,
as always, greatly appreciate everyone's input on them. I'll be sending out
individual emails on each issue.

Meanwhile, you can view a redline of the changes we previously agreed on:
https://github.com/mozilla/pkipolicy/compare/master...2.7

- Wayne

On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:

> I've added a few more issues that were recently created to the list for
> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>
> 176 - Clarify revocation requirements for S/MIME certs
> 175 - Forbidden Practices wiki page says email validation cannot be
> delegated to 3rd parties
>
> I plan to begin posting issues for discussion shortly.
>
>
> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>
>> Later this month, I would like to begin discussing a number of proposed
>> changes to the Mozilla Root Store policy [1]. I have reviewed the list of
>> issues on GitHub and labeled the ones that I recommend discussing:
>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>
>> 173 - Strengthen requirement for newly included roots to meet all current
>> requirements
>> 172 - Update section 5.3 to include Policy Certification Authorities as
>> an exception to the mandatory EKU inclusion requirement
>> 171 - Require binding of CA certificates to CP/CPS
>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair
>> 169, 140 - Extend Section 8 to also encompass subordinate CAs
>> 168, 161, 158  - Require Incident Reports, move practices into policy
>> 163 - Require EKUs in end-entity certificates (S/MIME)
>> 162 - Require disclosure of CA software vendor/version in incident report
>> 159 - Clarify section 5.3.1 Technically Constrained
>> 152 - Add EV audit exception for policy constrained intermediates
>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>
>> I will appreciate any feedback on the proposed list of issues to discuss.
>>
>> I do recognize that the current DarkMatter discussions could result in
>> the need to add some additional items to this list.
>>
>> I have created a new branch for drafting these changes [1] and made one
>> commit that adds a bullet to the BR Conformance section informing the
>> reader that Mozilla policy has a more restrictive list of approved
>> algorithms [3]
>>
>> As we've done in the past, I plan to post individual issues for
>> discussion in small batches over the next few months, with the goal of
>> finalizing version 2.7 by June.
>>
>> - Wayne
>>
>> [1]
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
>> [2] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
>> [3] https://github.com/mozilla/pkipolicy/issues/167
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling  wrote:

>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case that
> the BRs are inconsistent with [4].
>
>
I could simply move [4] to a "recommended practice" (SHOULD) until the
ballot comes into force, then move it back to "required". That implies that
the bugs which have been opened for this specific issue (responding
"unknown" - not to be confused with "returns 1 byte") will be closed as
INVALID.

Are there strong objections to this course of action?

- Wayne

[4]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
identified.

I also want to acknowledge the feedback from Google on the timing of this.
I can appreciate the framing of this as a new policy that's been added
without due process, but I view this as a clarification of existing
requirements. Some CAs have already been held accountable for this
requirement [2] and some that have been paying close attention adhere to
it. Others were struggling to determine what to do. Under these
circumstances, it made no sense to me to roll back the policy, so the only
reasonable course was to clarify it in favor of the consensus that emerged
from this thread.

I'm still open to making changes to our "required practice" on
precertificates, but having caught up on the thread I don't think any
further changes are necessary.

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/00.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

On Wed, Sep 25, 2019 at 3:59 AM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Outdated resource links on CCADB

[Wayne Thayer via dev-security-policy]

Thank you for reporting this Matthew. I've updated that page with the
correct links: https://www.ccadb.org/resources

- Wayne

On Mon, Sep 23, 2019 at 8:23 AM Jos Purvis (jopurvis) via
dev-security-policy  wrote:

> Heh--my bad, I read that as "cabforum.org". I'll correct it there as
> well, but Kathleen or Wayne would have to handle the CCADB pages, methinks.
>
> Kathleen/Wayne: I did get confirmation from Mike at Microsoft that those
> are the correct URLs for their sites. :)
>
>
> --
> Jos Purvis (jopur...@cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  |
>
>
> On 9/23/19, 9:48 AM, "dev-security-policy on behalf of Jos Purvis
> (jopurvis) via dev-security-policy" <
> dev-security-policy-boun...@lists.mozilla.org on behalf of
> dev-security-policy@lists.mozilla.org> wrote:
>
> Thanks for pointing that out! I'll confirm those quickly with
> Microsoft and then fix up the links.
>
> Cheers,
>
> Jos
>
>
> --
> Jos Purvis (jopur...@cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  |
>
>
> On 9/22/19, 11:16 PM, "dev-security-policy on behalf of Mathew Hodson
> via dev-security-policy"  on behalf of dev-security-policy@lists.mozilla.org> wrote:
>
> On https://www.ccadb.org/resources some of the Microsoft links are
> outdated and need to be updated.
>
> Trusted Root Program Portal page is obsolete and can be removed
> since
> there is no equivalent page on docs.microsoft.com.
>
> Trusted Root Program Requirements new page at
> https://aka.ms/RootCert
>
> Trusted Root Certificate Program Updates new page at
> https://aka.ms/rootupdates
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos 
wrote:

> 
>
> Using the following practice as described in RFC 6960 should not be a
> violation of the BRs. That is, answering revoked where a pre-certificate
> has been issued but not the final certificate should be OK as long as the
> response contains the Extended Revoked extension and the revocationReason
> is certificateHold. With this practice, it is very clear that the final
> certificate has
> not been issued, so would this be considered a violation of the Mozilla
> policy?
>
Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
responder to return a certificateHold reason in a response for a
precertificate. As you noted, the BRs forbid certificate suspension.
Mozilla assumes that a certificate corresponding to every precertificate
exists, so the OCSP response would be interpreted as applying to a
certificate and thus violating the BRs.

In practice, I also think that Ryan has raised a good point about OCSP
response caching. If a revoked response for a precertificate were supplied
by a CA, would the Subscriber need to wait until that response expires
before using the certificate, or else risk that some user agent has cached
the revoked response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Apple: Precertificates without corresponding certificates return OCSP value of "unknown"

[Wayne Thayer via dev-security-policy]

Thank you for the notification. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1582519 to track this issue.

- Wayne

On Fri, Sep 13, 2019 at 4:24 PM Apple CA via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We’ve been following the discussions regarding how OCSP responders should
> handle Precertificates without corresponding certificates and what the
> appropriate response indicator should be (good, revoked, or unknown).
>
> Based on the recent clarifications at [1], we want to inform the community
> that Apple’s OCSP responders return a status of “unknown” for
> Precertificates without a corresponding certificate. We have identified one
> Precertificate that did not result in a corresponding certificate for which
> our OCSP responders are returning a status of “unknown” (
> https://crt.sh/?id=1368484681).
>
> We’ve updated the OCSP responders to respond “good” for that
> Precertificate and a long-term fix is in progress.
>
> We appreciate the efforts being made to amend the Mozilla Root Store
> Policy to explicitly address matters relating to Certificate Transparency.
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/24Fl9kc-AQAJ
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.

I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.

- Wayne

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer  wrote:

> Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
> and Ryan's:
>
> The current implementation of Certificate Transparency does not provide
>> any way for Relying Parties to determine if a certificate corresponding to
>> a given precertificate has or has not been issued. It is only safe to
>> assume that a certificate corresponding to every precertificate exists.
>>
>> RFC 6962 states “The signature on the TBSCertificate indicates the
>> certificate authority's intent to issue a certificate.  This intent is
>> considered binding (i.e., misissuance of the Precertificate is considered
>> equal to misissuance of the final certificate).”
>>
>> However, BR 7.1.2.5 states “For purposes of clarification, a
>> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
>> not be considered to be a “certificate” subject to the requirements of RFC
>> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
>> Revocation List (CRL) Profile under these Baseline Requirements.”
>>
>> Mozilla interprets the BR language as a specific exception allowing CAs
>> to issue a precertificate containing the same serial number as the
>> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
>> a precertificate that a corresponding certificate has been issued.
>>
>> This means, for example, that:
>>
>> * A CA must provide OCSP services and responses in accordance with
>> Mozilla policy for all certificates presumed to exist based on the presence
>> of a Precertificate, even if the certificate does not actually exist
>> * A CA must be able to revoke a certificate presumed to exist, if
>> revocation of the certificate is required under Mozilla policy, even if the
>> certificate does not actually exist.
>> * If any corresponding certificate with the same serial number and issuer
>> exists, and can not be verified to match the precertificate using the
>> algorithms in RFC 6962, it will be considered misissued.
>> * In examining historical issuance, the CA must consider both final
>> certificates and precertificates, even if the precertificate did not
>> ultimately result in the issuance of a certificate.
>>
>
> I propose adding this language to our "Required Practices" wiki page [2],
> then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
> serial numbers. That still leaves some uncertainty about the use of the
> "unknown" response for precertificates (and in general), although Ryan made
> some good points about why using this status beyond the very narrow scope
> described in RFC 6960 section 2.2 is a bad idea.
>
> Once again, I will greatly appreciate your feedback on this topic. Since
> this is a practice and not official policy, I'll go ahead and update the
> wiki when I sense that we're in agreement here.
>
> - Wayne
>
> [1] https://cabforum.org/pipermail/public/2014-January/002694.html
> [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
>
> On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>>
>> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org > dev-security-policy@lists.mozilla.org>> wrote:
>> >
>> >>
>> >>
>> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >>>
>> >>> Hi Kurt.  I agree, hence why I proposed:
>> >>>
>> >>>  "- I would also like to see BR 4.9.10 revised to say something
>> roughly
>> >>> along these lines:
>> >>>   'If the OCSP responder receives a status request for a serial number
>> >>>that has not been allocated by the CA, then the responder SHOULD
>> NOT
>> >>>respond with a "good" status.’"
>> >>
>> >> I suppose one issue there is for CAs which allocate the serial number
>> very
>> >> early on in the issuance workflow - signing a dummy certificate with an
>> >> untrusted key, for instance, but not committing the CA to actually
>> >> producing either a pre-certificate or certificate (e.g, because the
>> >> applicant has insufficient funds to complete the process). It would not
>> >> seem correct to start answering 

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Thanks Curt. Reading between the lines of Ryan's and your response, I'm
thinking that we should specifically ban or limit the scope of "unknown"
responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves
some room for a CA to argue that they are permitted to use that response in
situations such as the one you described.

On Wed, Sep 18, 2019 at 3:48 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> My interpretation is once a precertificate has been signed with the
> issuing CA key the corresponding OCSP service should only respond with
> "good" or "revoked". In this case an "unknown" response indicates the
> specific serial number for the issuing CA has not been assigned which isn’t
> the case. Since the serial number has been assigned the OCSP responder
> should know about the status of that serial number for the issuing CA. If
> there are no issues with the precertificate that would require its
> revocation the OCSP responder should respond with “good”. If the
> precertificate is classified as a misissuance (or any other reason that
> would require revocation) the OCSP responder should respond with “revoked”.
>
> - Curt
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Policy Update: Exceptions to Policies, Practices, and Audit Information

[Wayne Thayer via dev-security-policy]

When Rob Stradling announced the excellent addition of the "inconsistent
Audit details" and Inconsistent CP/CPS Details" sections to the crt.sh
Mozilla CA Certificate Disclosures report [1], we discovered some
inconsistencies between Mozilla's expectations and CCADB policy [2]. To
correct this, the following list of exceptions to providing audit
information *for intermediate certs* has been added to the policy:

   - The SHA-256 fingerprint of the certificate is specifically listed as
   in scope in the audit statements of the parent certificate, and the “Audits
   Same as Parent” checkbox is checked; or
   - The certificate has expired; or
   - The certificate is technically-constrained as described in section
   7.1.5 of the CA/Browser Forum Baseline Requirements, or
   - The certificate has been revoked, and the corresponding record in the
   CCADB has been updated with the correct revocation status.

This change is captured in CCADB policy issues #30 [3] and #31 [4].

- Wayne

[1] https://crt.sh/mozilla-disclosures
[2] https://www.ccadb.org/policy#5-policies-practices-and-audit-information
[3] https://github.com/mozilla/www.ccadb.org/issues/30
[4] https://github.com/mozilla/www.ccadb.org/issues/31
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 states “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [1]. Otherwise, Mozilla infers from the existence of a
> precertificate that a corresponding certificate has been issued.
>
> This means, for example, that:
>
> * A CA must provide OCSP services and responses in accordance with Mozilla
> policy for all certificates presumed to exist based on the presence of a
> Precertificate, even if the certificate does not actually exist
> * A CA must be able to revoke a certificate presumed to exist, if
> revocation of the certificate is required under Mozilla policy, even if the
> certificate does not actually exist.
> * If any corresponding certificate with the same serial number and issuer
> exists, and can not be verified to match the precertificate using the
> algorithms in RFC 6962, it will be considered misissued.
> * In examining historical issuance, the CA must consider both final
> certificates and precertificates, even if the precertificate did not
> ultimately result in the issuance of a certificate.
>

I propose adding this language to our "Required Practices" wiki page [2],
then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
serial numbers. That still leaves some uncertainty about the use of the
"unknown" response for precertificates (and in general), although Ryan made
some good points about why using this status beyond the very narrow scope
described in RFC 6960 section 2.2 is a bad idea.

Once again, I will greatly appreciate your feedback on this topic. Since
this is a practice and not official policy, I'll go ahead and update the
wiki when I sense that we're in agreement here.

- Wayne

[1] https://cabforum.org/pipermail/public/2014-January/002694.html
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>> wrote:
> >
> >>
> >>
> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>>
> >>> Hi Kurt.  I agree, hence why I proposed:
> >>>
> >>>  "- I would also like to see BR 4.9.10 revised to say something roughly
> >>> along these lines:
> >>>   'If the OCSP responder receives a status request for a serial number
> >>>that has not been allocated by the CA, then the responder SHOULD NOT
> >>>respond with a "good" status.’"
> >>
> >> I suppose one issue there is for CAs which allocate the serial number
> very
> >> early on in the issuance workflow - signing a dummy certificate with an
> >> untrusted key, for instance, but not committing the CA to actually
> >> producing either a pre-certificate or certificate (e.g, because the
> >> applicant has insufficient funds to complete the process). It would not
> >> seem correct to start answering (affirmatively) OCSP requests where no
> >> artefact has been signed by a trusted key.
> >>
> >
> > Why does a CA need to sign something to allocate a serial? Could you
> expand
> > a bit more on that?
> >
>
> Yes - on further consideration, I could have been a lot clearer. I didn’t
> mean that a CA _has_ to sign something to allocate a serial in some
> internal database; merely that the allocation of a serial number, in
> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
> start responding to the (Issuer, Serial Number) request with successful
> response codes.
>
> What I meant was that some workflows allocate a serial number, sign a
> dummy certificate containing that serial number (with an untrusted key),
> which then 

Re: CRL for decommissioned CA

[Wayne Thayer via dev-security-policy]

On Tue, Sep 17, 2019 at 8:23 AM nenyotoso--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and
> is no longer in operation [2],
> I become aware of CRL endpoint of both the CA and at least one of sub-CA
> is unavailable.
>
> a sub-CA: https://crt.sh/?id=9341006
> leaf certificate issued from the sub-CA: https://crt.sh/?id=524524172
> (you can browse all issued certificates from the sub-CA with
> https://crt.sh/?Identity=%25=1419)
>
> Both of them was revoked but CRL endpoint is unavailable now with HTTP 404
> error response.
> OCSP also fails.
>
> Is it OK to abandon CRL for the decommissioned CA even if there are still
> unexpired certificates?
> The certificates was revoked but we have no way to validate it in a
> PKI-ish manner...
>
>
If there are user agents that continue to trust this root, then this is
certainly a bad thing.

Sorry if it is off-topic because the CA has never been approved as Root CA
> by Mozilla.
>

It appears that Microsoft may still trust this root. I'll inform them.

Thanks,

Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling  wrote:

> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> 
>
> If a certificate (with embedded SCTs and no CT poison extension) is
> "presumed to exist" but the CA has not actually issued it, then to my
> mind that's a "certificate that has not been issued"; and therefore, the
> OCSP 'responder SHOULD NOT respond with a "good" status'.
>
> However, this is Schrödinger's "certificate that has not been issued",
> because a Precertificate has been issued that has the same serial number
> (as the "certificate presumed to exist" that doesn't actually exist).
>
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in question:
>(1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>(2) SHOULD NOT respond "good" (see BR 4.9.10).
>
>
If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
on to state "Effective 1 August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
"good" status for such certificates." (referring to 'certificates that have
not been issued' from the prior paragraph)

If the desired outcome is for CAs to respond "good" to a precertificate
without a corresponding certificate, we could override the BRs in Mozilla
policy, but I'd want to get the BRs updated quickly as Rob suggested to
avoid audit findings.

The other piece of this policy that's still unclear to me relates to the
"unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
provide an "unknown" OCSP response for an issued certificate? If not,
should it be? The implication here would be that CAs responding "unknown"
to precertificates without corresponding certificates are doing the right
thing, despite prior precedent indicating that this is a violation. [1]

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390


> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5:
>'For purposes of clarification, a Precertificate, as described in RFC
> 6962 – Certificate Transparency, shall not be considered to be a
> “certificate” subject to the requirements of RFC 5280'
>
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
> respond "good"'.
>
> I can't say I like this conclusion, but nonetheless it is the conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
>
> IDEAS FOR FIXING IT:
>
> Long-term:
>- In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
>
> Short-term:
>- I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>'If the OCSP responder receives a status request for a serial number
> that has not been allocated by the CA, then the responder SHOULD NOT
> respond with a "good" status.'
>
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trusted Recursive Resolver Policy in India

[Wayne Thayer via dev-security-policy]

Rich: I want to acknowledge your question, which I think is really "what is
the right forum for Mozilla TRR (DNS over HTTPS) policy [1] discussions?" I
don't currently have an answer for you, but will respond when I do.

- Wayne

[1] https://wiki.mozilla.org/Security/DOH-resolver-policy

On Wed, Sep 11, 2019 at 11:39 AM rich.salz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is this list the right place to discuss the TRR policy?
> If so, could the wiki page on the policy be updated to point to it?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:

* Accepted Jeremy's proposed language for the examples in the last
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a certificate exists by changing that sentence to
"Otherwise, Mozilla infers from the existence of a precertificate that a
corresponding certificate has been issued, even when we have no evidence of
the certificate."

The new statement of "required practice" reads:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given Precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every Precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a Precertificate containing the same serial number as the subsequent
> certificate. Otherwise, Mozilla infers from the existence of a
> Precertificate that a corresponding certificate has been issued, even when
> we have no evidence of the certificate.
>
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with Mozilla policy for all Precertificates as if
> the corresponding certificate exists, and (ii) a CA must be able to revoke
> a Precertificate if revocation of the certificate is required under Mozilla
> policy and the corresponding certificate doesn’t actually exist and
> therefore cannot be revoked.
>

I will again welcome everyone's constructive feedback on this proposal, and
when there are no further comments I'll add this to our wiki.

- Wayne

On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek 
wrote:

> Yes, but I think this clarifies things in the wrong direction.
>
> -Tim
>
> > -Original Message-
> > From: Rob Stradling 
> > Sent: Friday, September 13, 2019 4:22 AM
> > To: Tim Hollebeek ; Jeremy Rowley
> > ; Alex Cohn 
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > 
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > > So, this is something that would be helpfully clarified via either an
> > > IETF draft,
> >
> > There's already a 6962-bis draft [1] in IESG Last Call, which (when we
> finally
> > complete it!) will obsolete RFC6962.  6962-bis redefines precertificates
> so that
> > they're not actually X.509 certificates.
> > Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >
> > Thinking aloud...
> > Does anything need to be clarified in 6962-bis though?
> > A (non-X.509) 6962-bis precertificate contains the serial number that
> will
> > appear in the certificate (if or when that certificate is issued),
> > so: Should the CA be forbidden, permitted or required to operate
> revocation
> > services for that serial number once the 6962-bis precertificate has been
> > produced but before the certificate has been issued?  (And is this a
> technical
> > matter for 6962-bis to address, or a policy matter that's out of scope
> for the
> > 6962-bis document?)
> >
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >
> > > or clarifications in the BRs.  There are various things in the OCSP
> RFCs and
> > even the BRs that can be read as precluding good OCSP responses for pre-
> > certificates, although the situation is unclear since the relevant
> sections are
> > blissfully ignorant of CT, and the correct behavior here was
> unfortunately left
> > out of RFC 6962, which should have clarified this.
> > >
> > > Happy to help draft something.  There are some interesting complexities
> > once you dig deeper.
> > >
> > > -Tim
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Jeremy
> > >> Rowley via dev-security-policy
> > >> Sent: Thursday, September 12, 2019 1:46 PM
> > >> To: Alex Cohn 
> > >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> > >> 
> > >> Subject: RE: DigiCert OCSP services returns 1 byte
> > >>
> > >> The language says you have to provide the response for the cert as if
> > >> it exists, but the reality is that sending a response for the precert
> > >> is the same as calculating the 

Re: Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

[Wayne Thayer via dev-security-policy]

Thank you for the report and follow-up Andy. I created
https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue.

- Wayne

On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A quick follow-up to close this out.
>
> The push to fully address the issue was completed globally shortly before
> 16:00 UTC on 2019-09-02.
>
> After additional review, we're confident the only certificates affected
> were these two:
> https://crt.sh/?id=760396354
> https://crt.sh/?id=759833603
>
> Google Trust Services considers this matter fully addressed. We will of
> course continue our ongoing internal review program, but no other work or
> information is outstanding at this point.
>
> --
> Andy Warner
> Google Trust Services
>
> On Friday, August 30, 2019 at 2:39:51 PM UTC-4, Andy Warner wrote:
> > This is an initial report and we expect to provide some additional
> details and the completion timeline after a bit more verification and full
> deployment of in-flight mitigations. We are posting the most complete
> information we have currently to comply with Mozilla reporting timelines
> and will follow-up with additional details soon.
> >
> > 1. How your CA first became aware of the problem and the time and date.
> >
> > While performing an internal review and assessment of the CRL generation
> system for Google Trust Services' GTS CA 1O1 on August 16, 2019, it was
> discovered that the CRL generation service did not include CRL entries of
> expired certificates. The periodic job only considered certificates with
> valid lifetimes. This does not conform to RFC 5280 Section 3.3 which states
> that “An entry MUST NOT be removed from the CRL until it appears on one
> regularly scheduled CRL issued beyond the revoked certificate's validity
> period.”  We expect that few, if any, clients have been impacted.  For a
> client to be impacted they would have to: clock skewed to a time before the
> not-after field of the certificate; and have a CRL published after
> expiration dropping the revoked certificate.
> >
> >
> > 2. A timeline of the actions your CA took in response. A timeline is a
> date-and-time-stamped sequence of all relevant events. This may include
> events before the incident was reported, such as when a particular
> requirement became applicable, or a document changed, or a bug was
> introduced, or an audit was done.
> >
> > August 16, 2019 15:00 UTC - Reviewer realizes that CRL will not publish
> for one update past expiration
> > August 16, 2019 16:00 UTC - Reviewer checks for other issues & talks to
> peers to confirm problem
> > August 16, 2019 17:00 UTC - Bug is filed to fix the issue with a
> proposed design fix
> > August 16, 2019 23:30 UTC - Fix is sent for review
> > August 20, 2019 16:00 UTC - Remediation work is discussed & assigned
> > August  20, 2019 18:00 UTC - Query to inspect revoked certificates is
> created and sent to be run by production team for initial analysis.
> > August 21, 2019 10:40 UTC - Production team runs query and returns result
> > August 21, 2019 15:00 UTC - Reviewer analyzes data
> > August 21, 2019 20:30 UTC - Reviewer asks for a follow up query to
> ascertain if any certificates did not make it onto the CRL
> > August 22, 2019 07:00 UTC - Initial attempt at updating test systems
> with fix.
> > August 22, 2019 09:00 UTC - Updating of test systems aborted due to
> (unrelated) issues.
> > August 22, 2019 07:00 UTC - Production team runs query for CRLs that may
> have missed a certificate
> > August 22, 2019 15:00 UTC - Reviewer ascertains that certificates under
> question were on a CRL
> > August 26, 2019 11:00 UTC - Second attempt at updating test systems with
> fix.
> > August 26, 2019 13:00 UTC - Test systems updated, confirmed integrity of
> fixed software.
> > August 27, 2019 09:00 UTC - Confirmed fix is effective on test systems.
> > August 27, 2019 10:00 UTC - present: Ongoing staged deployment to
> production systems. Should complete fully by September 3, 2019 17:00 UTC
> (slightly extended window due to push policies around holiday weekends. The
> rollout was staged in accordance with Google's standard rollout procedures.)
> >
> >
> > 3. Whether your CA has stopped, or has not yet stopped, issuing
> certificates with the problem.
> >
> > The affected CA software has been patched.  It now populates expired
> certificates in the CRL for 7 days after their expiration to ensure they
> appear in at least one regularly issued CRL update.  Automated testing was
> added as part of the same patch to check that revoked certificates are kept
> in the CRL.  The patch was developed, tested, reviewed and landed within
> the codebase by August 19, 2019.  The CRL entry removal bug has been fully
> remediated.
> >
> >
> > 4. A summary of the problematic certificates. For each problem: number
> of certs, and the date the first and last certs with that problem were
> issued.
> >
> > Investigation began on 

Re: Request to Include 4 Microsoft Root CAs

[Wayne Thayer via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1448093.

- Wayne

On Thu, Sep 5, 2019 at 5:16 PM Wayne Thayer  wrote:

> Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.
>
> Unless a CA has an existing EV policy OID associated with root(s) in our
> program, we have been strongly encouraging the use of the CAB Forum OID.
>
> This request is past the 3-week minimum discussion period. If no
> significant comments are posted, I will close it on Tuesday 10-September.
>
> - Wayne
>
> On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Hello,
>>
>> Is there an EV Policy OID assigned? I can't find it.
>>
>> - Daniel
>>
>>
>> Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:
>> > This request is for inclusion of the Microsoft RSA Root Certificate
>> > Authority 2017, Microsoft ECC Root Certificate Authority 2017,
>> Microsoft EV
>> > RSA Root Certificate Authority 2017, and Microsoft EV ECC Root
>> Certificate
>> > Authority 2017 trust anchors as documented in the following bug:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1448093
>> >
>> > * BR Self Assessment is
>> > https://bugzilla.mozilla.org/attachment.cgi?id=8989260
>> >
>> > * Summary of Information Gathered and Verified:
>> >
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275
>> >
>> > * Root Certificate Download URL:
>> > https://www.microsoft.com/pkiops/docs/repository.htm
>> >
>> > * CP/CPS:
>> > ** CP:
>> >
>> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
>> > ** CPS:
>> >
>> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf
>> >
>> > * This request is to include the roots with the websites trust bit
>> enabled,
>> > and with EV treatment.
>> >
>> > * Test Websites
>> > ** Valid: https://actrsaevroot2017.pki.microsoft.com/,
>> > https://actrsaroot2017.pki.microsoft.com/,
>> > https://acteccevroot2017.pki.microsoft.com/,
>> > https://acteccroot2017.pki.microsoft.com/
>> > ** Expired: https://exprsaevroot2017.pki.microsoft.com/,
>> > https://exprsaroot2017.pki.microsoft.com/,
>> > https://expeccevroot2017.pki.microsoft.com/,
>> > https://expeccroot2017.pki.microsoft.com/
>> > ** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
>> > https://rvkrsaroot2017.pki.microsoft.com/,
>> > https://rvkeccevroot2017.pki.microsoft.com/,
>> > https://rvkeccroot2017.pki.microsoft.com/
>> >
>> > * CRL URLs:
>> > ** ECC:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
>> > ** RSA:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
>> > ** EV ECC:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
>> > ** EV RSA:
>> >
>> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl
>> >
>> > * OCSP URL:http://ocsp.msocsp.com
>> >
>> > * Audit: Annual audits are performed by BDO according to the WebTrust
>> for
>> > CA, BR, and EV audit criteria.
>> > ** WebTrust for CA:
>> https://bugzilla.mozilla.org/attachment.cgi?id=9083810
>> > ** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
>> > ** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813
>> >
>> > I’ve reviewed the CP, CPS, BR Self Assessment, and related information
>> for
>> > inclusion of the Microsoft roots that are being tracked in this bug and
>> > have the following comments:
>> >
>> > ==Good==
>> > * A root key generation ceremony audit report has been provided [1].
>> >
>> > ==Meh==
>> > * CPS section 3.2.4 stated that OU is not verified, however, BR section
>> > 7.1.4.2.2(i) does place requirements on this field, and the CPS made it
>> > unclear if these requirements are met. This was clarified in the latest
>> > version of the CPS.
>> > * CPS section 3.2.5 stated that Microsoft PKI Services shall verify
>> > authority for all certificate requests, and that for Domain Validated
>> > requests, this is done using one of the methods described in the BRs.
>> > Section 3.2.5 of the BRs only describes validation of authority for OV
>> > certificates using a reliable method of communication. This was
>> clarified
>> > in the latest version of the CPS.
>> > * CPS section 6.1.5 indicated that P-512 keys may be used, which would
>> > violate Mozilla policy. This was corrected in the latest version of the
>> CPS.
>> > * The content-type header in CRL responses is not set to
>> > 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280,
>> section
>> > 4.2.1.13). Microsoft explanation: the reason for the content-type being
>> set
>> > to octet-stream is that we use a content upload service at Microsoft
>> that
>> > hosts different types of content. All of the content in the service is
>> > hosted in Azure’s BLOB storage 

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

Do you have any suggestions for how I can improve/clarify?

On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley 
wrote:

> Hey Wayne - I take it that this "Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued" means a CA issuing
> a precert without the final cert must respond "good" unless the pre-cert is
> revoked? Responding unknown means the CA wouldn't know that they issued the
> cert, which means they disagree with the proof that a corresponding cert
> has been issued.
>
> Jeremy
>
> -Original Message-----
> From: dev-security-policy 
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Wednesday, September 11, 2019 7:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Mozilla has, to-date, not published policies related to Certificate
> Transparency, but this is a case where a clarification would be helpful. I
> propose adding the following language to our "Required Practices" wiki page
> [1]:
>
> The current implementation of Certificate Transparency does not provide any
> > way for Relying Parties to determine if a certificate corresponding to
> > a given precertificate has or has not been issued. It is only safe to
> > assume that a certificate corresponding to every precertificate exists.
> >
> > RFC 6962 states “The signature on the TBSCertificate indicates the
> > certificate authority's intent to issue a certificate.  This intent is
> > considered binding (i.e., misissuance of the Precertificate is
> > considered equal to misissuance of the final certificate).”
> >
> >
> >
> > However, BR 7.1.2.5 state “For purposes of clarification, a
> > Precertificate, as described in RFC 6962 – Certificate Transparency,
> > shall not be considered to be a “certificate” subject to the
> > requirements of RFC
> > 5280 - Internet X.509 Public Key Infrastructure Certificate and
> > Certificate Revocation List (CRL) Profile under these Baseline
> Requirements.”
> >
> > Mozilla interprets the BR language as a specific exception allowing
> > CAs to issue a precertificate containing the same serial number as the
> > subsequent certificate [2]. Mozilla recognizes a precertificate as
> > proof that a corresponding certificate has been issued.
> >
> > This means, for example, that the requirements for OCSP for end-entity
> > certificates apply even when a CA has issued a precertificate without
> > issuing a corresponding certificate.
> >
>
> I plan to add this to the wiki next week. I also plan to include this in
> in a future update to our Root Store Policy.
>
> I will greatly appreciate your constructive feedback on this proposal.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> [2] https://cabforum.org/pipermail/public/2014-January/002694.html
>
> On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Let me try that again since I didn't explain my original post very well.
> > Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
> >
> > What happened at DigiCert is that the OCSP service failed to return a
> > signed response for a certificate where a pre-certificate existed by a
> > certificate had not issued for whatever reason. The question asked was
> > what type of OCSP services are required for a pre-cert if there is no
> > other certificate. The answer we came up with is it should respond
> > "GOOD" based on the Mozilla policy, not Unknown or any other response.
> > Note that this was a bug in the DigiCert system but it lead to a fun
> internal discussion.
> > What I'm sharing is the outcome of the internal discussion - it's only
> > tangentially related to the bug, not the cause or remediation of it.
> >
> > Summary: Pre-certs require a standard OCSP response as if the pre-cert
> > was a normal cert. In fact, it's a mistake to ever think of pre-certs
> > as anything other than TLS certs, even if the poison extension exists.
> >
> > The question comes up because the BRs don't cover pre-certs. However,
> > as Ryan points out, the browsers sort-of cover this as does the
> > Mozilla policy. The browser say this is a promise to issue the cert
> > and mis-issuance of a pre-cer

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

Mozilla has, to-date, not published policies related to Certificate
Transparency, but this is a case where a clarification would be helpful. I
propose adding the following language to our "Required Practices" wiki page
[1]:

The current implementation of Certificate Transparency does not provide any
> way for Relying Parties to determine if a certificate corresponding to a
> given precertificate has or has not been issued. It is only safe to assume
> that a certificate corresponding to every precertificate exists.
>
> RFC 6962 states “The signature on the TBSCertificate indicates the
> certificate authority's intent to issue a certificate.  This intent is
> considered binding (i.e., misissuance of the Precertificate is considered
> equal to misissuance of the final certificate).”
>
>
>
> However, BR 7.1.2.5 state “For purposes of clarification, a
> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
> not be considered to be a “certificate” subject to the requirements of RFC
> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements.”
>
> Mozilla interprets the BR language as a specific exception allowing CAs to
> issue a precertificate containing the same serial number as the subsequent
> certificate [2]. Mozilla recognizes a precertificate as proof that a
> corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in
a future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Let me try that again since I didn't explain my original post very well.
> Totally worth it since I got a sweet Yu-gi-oh reference out of fit.
>
> What happened at DigiCert is that the OCSP service failed to return a
> signed response for a certificate where a pre-certificate existed by a
> certificate had not issued for whatever reason. The question asked was what
> type of OCSP services are required for a pre-cert if there is no other
> certificate. The answer we came up with is it should respond "GOOD" based
> on the Mozilla policy, not Unknown or any other response. Note that this
> was a bug in the DigiCert system but it lead to a fun internal discussion.
> What I'm sharing is the outcome of the internal discussion - it's only
> tangentially related to the bug, not the cause or remediation of it.
>
> Summary: Pre-certs require a standard OCSP response as if the pre-cert was
> a normal cert. In fact, it's a mistake to ever think of pre-certs as
> anything other than TLS certs, even if the poison extension exists.
>
> The question comes up because the BRs don't cover pre-certs. However, as
> Ryan points out, the browsers sort-of cover this as does the Mozilla
> policy. The browser say this is a promise to issue the cert and
> mis-issuance of a pre-cert is the same as mis-issuance of a cert. Although
> this isn't mis-issuance in the traditional profile sense, the lack of OCSP
> services for the pre-cert is a violation of the Mozilla policy. I couldn't
> figure out if it's a violation of the Chrome policy since Chrome says it's
> a promise to issue a cert. If the cert hasn't issued, then I'm not sure
> where that puts the OCSP service for Chrome. Regardless, according to
> Mozilla's policy, the requirement is that regardless of how long the cert
> takes to issue, the CA must provide OCSP services for the pre-cert. The
> reason is Mozilla requires an OCSP for each end-entity certificate listing
> an AIA in the certificate. Pre-certs are end-entity certificates.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, August 29, 2019 11:55 AM
> To: Peter Bowen ; Ryan Sleevi 
> Cc: Curt Spann ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> Yes. That was the point of my post. There is a requirement fo return an
> ocsp repsonse for a pre cert where the cert hasn't issued because of the
> Mozilla policy. Hence our failure was a Mozilla policy violation even if no
> practical system can use the response because no actual cert (without a
> posion extension) exists.
> 
> From: Peter Bowen 
> Sent: Thursday, August 29, 2019 11:44:11 AM
> To: Ryan Sleevi 
> Cc: Jeremy Rowley ; Curt Spann <
> csp...@apple.com>; mozilla-dev-security-pol...@lists.mozilla.org <
> mozilla-dev-security-pol...@lists.mozilla.org>
> 

Re: Auditor letters and incident reports

[Wayne Thayer via dev-security-policy]

Thanks for the response Jeff.

On Fri, Sep 6, 2019 at 4:17 PM jeffwardpki--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 21, 2019 at 11:46:37 PM UTC-5, Jeremy Rowley wrote:
> > Hey all,
> >
> > An interesting issue came up recently with audits. Because the Mozilla
> policy includes some requirements that diverge from the BRs, the audit
> criteria don't necessarily cover everything Mozilla cares about. Thus, it's
> possible to have an incident that doesn't show up on an audit. It's also
> possible that the auditor determines the incident is not sufficiently
> important/risky(?) to include it in an audit. For example:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1458024. Auditors aren't
> controlled by the CA and operate independently which means the CA can't
> dictate what goes into the opinion. One solution is to require CAs to list
> all of the incidents that occur during their audit in the management
> assertion letter. I posted an addendum to the management assertion on that
> thread. Going forward, we'll just include it as part of the main body. I
> need to look into whether I can get our existing audit reissued to the
> appendix is part of the seal as well.
> >
> > What do you think about just requiring that as part of the Mozilla
> policy? Ie - the management assertion letter must include a list of the
> incidents active/opened during the audit period. Something like that could
> ensure transparency and make sure all incidents are disclosed to the
> auditor, distinguishing the CA's disclosures from the auditors.
> >
> > Jeremy
>
> Reposting as I don't see my original response to this thread:
>
> Sorry for the delay in responding, but I first wanted to gather feedback
> from the members of the WebTrust Task Force.  Keep in mind any
> audit/assurance engagement entails professional judgment, which of course
> may vary from firm to firm.   We are certainly seeing a trend in audit
> reports whereby “Other Matters” are described that do not modify/qualify
> the auditor’s opinion but do allow the auditor to make mention of the
> issues.  Some firms use this section to list items noted in Bugzilla, for
> instance, to demonstrate that these types of issues were addressed in the
> course of the audit.
>
> Depending on the firm, some firms have been listing all issues noted in
> Bugzilla, while others are listing only those that are significant.  As a
> Task Force, it is not our position, or even a possibility, for us to
> mandate how these should be handled as professional judgment will dictate
> their treatment based on the respective firms’ risk management policies.
> That being said, we have as part of our draft practitioner guidance
> commentary that the browser community prefers seeing all these types of
> issues listed as either modifications/qualifications, or described in
> “Other Matters” and encourage practitioners to use this approach.
>
>
I would go beyond "all issues noted in Bugzilla" to "all issues, including
those noted in Bugzilla".

In most cases, management’s Assertion accompanies the audit report, and
> there is greater flexibility for what goes into them.  Our professional
> standards require certain items be present in the Assertion, but other
> items that management wants to add are permissible to include.  Except in
> the rare reporting scenario when an assertion by management is not
> provided, most of the Task Force members agree there would not be any issue
> with your proposed requirement to require a CA's management to detail
> Bugzilla or similar issues relevant to the current audit period in their
> assertion to the auditors.
>
>
By doing this, a CA can eliminate any question about disclosure of
incidents to auditors, which is terrific and encouraged. As a Mozilla
requirement it has the problem - as Ryan pointed out - that ETSI audits
don't include management assertions, at least not today.


> As far as the management representation letter, which is a required
> written communication to the auditors at the conclusion to the audit,
> regulatory non-compliance would normally form part of the management
> representation that is needed for each audit, and the assertion can form
> part of that representation.   Keep in mind that the management
> representation letter is not part of the deliverable that is viewed
> publicly as is the case with the auditor’s opinion and management assertion.
>
> To demonstrate that the auditor has addressed the significance of the
> relevant issues, we can propose that the standard WebTrust reports have an
> Exhibit that sets out the issues identified by reference to Bugzilla, as an
> example.  The audit report can then reflect the relevant significance
> either as a report qualification or through an "Other Matters" paragraph
> that provides further commentary.  The main issue is that, even by
> identifying and addressing them in the audit report, there is still the
> potential for disagreements 

Re: Request to Include 4 Microsoft Root CAs

[Wayne Thayer via dev-security-policy]

Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.

Unless a CA has an existing EV policy OID associated with root(s) in our
program, we have been strongly encouraging the use of the CAB Forum OID.

This request is past the 3-week minimum discussion period. If no
significant comments are posted, I will close it on Tuesday 10-September.

- Wayne

On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Hello,
>
> Is there an EV Policy OID assigned? I can't find it.
>
> - Daniel
>
>
> Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:
> > This request is for inclusion of the Microsoft RSA Root Certificate
> > Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft
> EV
> > RSA Root Certificate Authority 2017, and Microsoft EV ECC Root
> Certificate
> > Authority 2017 trust anchors as documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1448093
> >
> > * BR Self Assessment is
> > https://bugzilla.mozilla.org/attachment.cgi?id=8989260
> >
> > * Summary of Information Gathered and Verified:
> >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275
> >
> > * Root Certificate Download URL:
> > https://www.microsoft.com/pkiops/docs/repository.htm
> >
> > * CP/CPS:
> > ** CP:
> >
> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
> > ** CPS:
> >
> https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf
> >
> > * This request is to include the roots with the websites trust bit
> enabled,
> > and with EV treatment.
> >
> > * Test Websites
> > ** Valid: https://actrsaevroot2017.pki.microsoft.com/,
> > https://actrsaroot2017.pki.microsoft.com/,
> > https://acteccevroot2017.pki.microsoft.com/,
> > https://acteccroot2017.pki.microsoft.com/
> > ** Expired: https://exprsaevroot2017.pki.microsoft.com/,
> > https://exprsaroot2017.pki.microsoft.com/,
> > https://expeccevroot2017.pki.microsoft.com/,
> > https://expeccroot2017.pki.microsoft.com/
> > ** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
> > https://rvkrsaroot2017.pki.microsoft.com/,
> > https://rvkeccevroot2017.pki.microsoft.com/,
> > https://rvkeccroot2017.pki.microsoft.com/
> >
> > * CRL URLs:
> > ** ECC:
> >
> http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
> > ** RSA:
> >
> http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
> > ** EV ECC:
> >
> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
> > ** EV RSA:
> >
> http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl
> >
> > * OCSP URL:http://ocsp.msocsp.com
> >
> > * Audit: Annual audits are performed by BDO according to the WebTrust for
> > CA, BR, and EV audit criteria.
> > ** WebTrust for CA:
> https://bugzilla.mozilla.org/attachment.cgi?id=9083810
> > ** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
> > ** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813
> >
> > I’ve reviewed the CP, CPS, BR Self Assessment, and related information
> for
> > inclusion of the Microsoft roots that are being tracked in this bug and
> > have the following comments:
> >
> > ==Good==
> > * A root key generation ceremony audit report has been provided [1].
> >
> > ==Meh==
> > * CPS section 3.2.4 stated that OU is not verified, however, BR section
> > 7.1.4.2.2(i) does place requirements on this field, and the CPS made it
> > unclear if these requirements are met. This was clarified in the latest
> > version of the CPS.
> > * CPS section 3.2.5 stated that Microsoft PKI Services shall verify
> > authority for all certificate requests, and that for Domain Validated
> > requests, this is done using one of the methods described in the BRs.
> > Section 3.2.5 of the BRs only describes validation of authority for OV
> > certificates using a reliable method of communication. This was clarified
> > in the latest version of the CPS.
> > * CPS section 6.1.5 indicated that P-512 keys may be used, which would
> > violate Mozilla policy. This was corrected in the latest version of the
> CPS.
> > * The content-type header in CRL responses is not set to
> > 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280,
> section
> > 4.2.1.13). Microsoft explanation: the reason for the content-type being
> set
> > to octet-stream is that we use a content upload service at Microsoft that
> > hosts different types of content. All of the content in the service is
> > hosted in Azure’s BLOB storage and the content type by default is octet
> > stream. This has not been an issue because the browsers will resolve the
> > file type based on the extension in the file name. It should also be
> noted
> > that the RFC 5280 shows SHOULD rather than MUST.
> >
> > ==Bad==
> > * It had been more than a 

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

[Wayne Thayer via dev-security-policy]

On Mon, Aug 26, 2019 at 5:39 AM Josef Schneider via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:
> > On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:
> > > Deploying a Stripe Inc EV SSL from a state other than CA is one thing,
> but using an EV SSL in conjunction with a domain name and website with the
> true intent to dupe potential customers is another matter. I'm trying to
> get past the theoretical and get to real world instances.
> >
> > I don't understand the idea that the Stripe proof-of-concept is
> > "theoretical". We know that phishing is epidemic, and we also know that
> > phishers presently need -- at most -- a DV cert. The POC shows that --
> > should something cause phishers to need an EV cert -- they can also get
> > one of those quickly and inexpensively. But why would a phisher bother
> > with an EV cert if a DV cert works just as well?
>
>
> The important question is can they get this without making them easily
> traceable?
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?
>
> How long do you think would it have taken for the police to come and get
> Ian Carroll if he'd actually committed fraud?
>
> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them. But they do raise the bar for criminals. And in my
> opinion, significantly.
>
> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to the
> problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.
>
>
The counter-argument is that not all problems can be solved with UX, and
getting browser users to recognize and respond to the lack of an EV
indicator is in that class of unsolvable problems.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Nation State MITM CA's ?

[Wayne Thayer via dev-security-policy]

(resending because the first attempt was not posted to the list)

Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> News reports[1][2] are now showing that the certificate has been
> "cancelled". I do not have a way to verify that it has been revoked
> independently at this time.
>
> Sources:
> [1] https://tsarka.org/post/national-certificate-cancelled
> [2]
> https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Nation State MITM CA's ?

[Wayne Thayer via dev-security-policy]

Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.

- Wayne

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> News reports[1][2] are now showing that the certificate has been
> "cancelled". I do not have a way to verify that it has been revoked
> independently at this time.
>
> Sources:
> [1] https://tsarka.org/post/national-certificate-cancelled
> [2]
> https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Request to Include 4 Microsoft Root CAs

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Microsoft RSA Root Certificate
Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
Authority 2017 trust anchors as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448093

* BR Self Assessment is
https://bugzilla.mozilla.org/attachment.cgi?id=8989260

* Summary of Information Gathered and Verified:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0275

* Root Certificate Download URL:
https://www.microsoft.com/pkiops/docs/repository.htm

* CP/CPS:
** CP:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
** CPS:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf

* This request is to include the roots with the websites trust bit enabled,
and with EV treatment.

* Test Websites
** Valid: https://actrsaevroot2017.pki.microsoft.com/,
https://actrsaroot2017.pki.microsoft.com/,
https://acteccevroot2017.pki.microsoft.com/,
https://acteccroot2017.pki.microsoft.com/
** Expired: https://exprsaevroot2017.pki.microsoft.com/,
https://exprsaroot2017.pki.microsoft.com/,
https://expeccevroot2017.pki.microsoft.com/,
https://expeccroot2017.pki.microsoft.com/
** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
https://rvkrsaroot2017.pki.microsoft.com/,
https://rvkeccevroot2017.pki.microsoft.com/,
https://rvkeccroot2017.pki.microsoft.com/

* CRL URLs:
** ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
** RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
** EV ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
** EV RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl

* OCSP URL:http://ocsp.msocsp.com

* Audit: Annual audits are performed by BDO according to the WebTrust for
CA, BR, and EV audit criteria.
** WebTrust for CA: https://bugzilla.mozilla.org/attachment.cgi?id=9083810
** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813

I’ve reviewed the CP, CPS, BR Self Assessment, and related information for
inclusion of the Microsoft roots that are being tracked in this bug and
have the following comments:

==Good==
* A root key generation ceremony audit report has been provided [1].

==Meh==
* CPS section 3.2.4 stated that OU is not verified, however, BR section
7.1.4.2.2(i) does place requirements on this field, and the CPS made it
unclear if these requirements are met. This was clarified in the latest
version of the CPS.
* CPS section 3.2.5 stated that Microsoft PKI Services shall verify
authority for all certificate requests, and that for Domain Validated
requests, this is done using one of the methods described in the BRs.
Section 3.2.5 of the BRs only describes validation of authority for OV
certificates using a reliable method of communication. This was clarified
in the latest version of the CPS.
* CPS section 6.1.5 indicated that P-512 keys may be used, which would
violate Mozilla policy. This was corrected in the latest version of the CPS.
* The content-type header in CRL responses is not set to
'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
4.2.1.13). Microsoft explanation: the reason for the content-type being set
to octet-stream is that we use a content upload service at Microsoft that
hosts different types of content. All of the content in the service is
hosted in Azure’s BLOB storage and the content type by default is octet
stream. This has not been an issue because the browsers will resolve the
file type based on the extension in the file name. It should also be noted
that the RFC 5280 shows SHOULD rather than MUST.

==Bad==
* It had been more than a year since the CP was updated when I reviewed
this request. CPS and BR section 2 require annual updates. The CP was
updated on 5-August.
* CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
clear problem reporting instructions. This was corrected in the latest
versions of the CP and CPS.
* A number of unrevoked certificates chaining to the Microsoft RSA Root
Certificate Authority 2017 have recently been issued with BR violations [2]

This begins the 3-week comment period for this request [3].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of these roots into the Mozilla CA program.

- Wayne

[1] https://bug1448093.bmoattachments.org/attachment.cgi?id=8986854
[2]
https://crt.sh/?caid=109424=cablint,zlint,x509lint=2019-05-01
[3] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

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

[Wayne Thayer via dev-security-policy]

Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
which is expected to be released on 22-October. Details below.

If the before and after images are stripped from the email, you can view
them here:

Before:
https://lh4.googleusercontent.com/pSX4OAbkPCu2mhBfeleKKe842DgW28-xAIlRjhtBlwFdTzNhtNE7R43nqBS1xifTuB0L8LO979yhpPpLUIOtDdfJd3UwBmdxFBl7eyX_JihYi7FqP-2LQ5xw4FFvQk2bEObdKQ9F

After:
https://lh5.googleusercontent.com/kL-WUskmTnKh4vepfU3cSID_ooTXNo9BvBOmIGR1RPvAN7PGkuPFLsSMdN0VOqsVb3sAjTsszn_3LjRf4Q8eoHtkrNWWmmxOo3jBRoEJV--XJndcXiCeTTAmE4MuEfGy8RdY_h5u

- Wayne

-- Forwarded message -
From: Johann Hofmann 
Date: Mon, Aug 12, 2019 at 1:05 AM
Subject: Intent to Ship: Move Extended Validation Information out of the
URL bar
To: Firefox Dev 
Cc: dev-platform , Wayne Thayer <
wtha...@mozilla.com>


In desktop Firefox 70, we intend to remove Extended Validation (EV)
indicators from the identity block (the left hand side of the URL bar which
is used to display security / privacy information). We will add additional
EV information to the identity panel instead, effectively reducing the
exposure of EV information to users while keeping it easily accessible.

Before:


After:


The effectiveness of EV has been called into question numerous times over
the last few years, there are serious doubts whether users notice the
absence of positive security indicators and proof of concepts have been pitting
EV against domains  for
phishing.

More recently, it has been shown  that EV
certificates with colliding entity names can be generated by choosing a
different jurisdiction. 18 months have passed since then and no changes
that address this problem have been identified.

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.



On our side a pref for this
(security.identityblock.show_extended_validation) was added in bug 1572389
 (thanks :evilpie for
working on it!). We're planning to flip this pref to false in bug 1572936
.

Please let us know if you have any questions or concerns,

Wayne & Johann
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Entrust Root Certification Authority - G4 Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is to include the Entrust Root Certification Authority - G4 as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1480510

* BR Self Assessment is here:
https://bug1480510.bmoattachments.org/attachment.cgi?id=8997108

* Summary of Information Gathered and Verified:
https://bug1480510.bmoattachments.org/attachment.cgi?id=9016839

* Root Certificate Download URL:
https://bug1480510.bmoattachments.org/attachment.cgi?id=8997105

* CP/CPS:
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf

* This request is for Websites and Email trust bits. EV treatment is
requested.
** EV Policy OID: .16.840.1.114028.10.1.2

* Test Websites:
** Valid: https://validg4.entrust.net/
** Expired: https://expiredg4.entrust.net/
** Revoked: https://revokedg4.entrust.net/

* CRL URL: http://crl.entrust.net/g4ca.crl

* OCSP URL: http://ocsp.entrust.net/

* Audit: Annual audits are performed by Deloitte according to the WebTrust
for CA, BR, and EV audit criteria.
** WebTrust for CAs and EV:
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230012
** BR:
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Entrust Root Certification Authority - G4 inclusion request that is being
tracked in this bug and have the following comments:

==Good==
* I’m pleased to see the “Other Matters” section of this and last year’s
audit reports.
* This root was signed in 2015, but there is no evidence that it has been
used other than to sign test certificates, and I can find no evidence of
misissued certificates chaining to this root.

==Meh==
* Entrust has had some compliance issues recorded during the life of this
root certificate that are now resolved:
** Metadata in ST and OU fields [1] [2]
** OCSP responding “good” for unknown certificates. [3]
** IP address in dNSName form [4] and [5]
** Late revocation of misissued certificates [6]
** Question marks in certificate O and L fields [7]
** Issued certificates to incorrect organization [8]
** AffirmTrust Issuing CA Impacted by EJBCA Serial Number Issue [9]
** Late revocation of underscore certificates [10]
* External RAs are permitted, but the CPS I originally reviewed (version
3.2) did not make it clear that domain validation will not be delegated as
required by BR section 1.3.2. Entrust addressed this in the current version.
* BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly
specify the set of Issuer Domain Names that the CA recognises in CAA
"issue" or "issuewild" records as permitting it to issue.” The Entrust CPS
instead references section 3.2.2.8 where the Issuer Domain Name is listed.
* CPS section 9.12.3 is blank. Mozilla recommends against this [11].

==Bad==
* Entrust self-reported a bug in which they had improperly encoded an IP
address in a certificate. [4] In March 2018, they indicated in the bug that
they would implement pre-issuance linting, but not until early 2019. It was
ultimately implemented in May 2019. While pre-issuance linting is not a
requirement, it is certainly a best practice and taking over a year to
implement it is discouraging. It appears [12] that at least one other
misissuance would have been prevented if pre-issuance linting had been
implemented sooner.
* Entrust’s current and prior [13] BR audit reports contain a qualification
for failing to address critical vulnerabilities within 96 hours. Entrust
engaged Deloitte to confirm the the problem had been remediated in
September 2018. [14] The current period-of-time report confirms that the
issue was remediated as of 30-June 2018.
* The most recent BR audit report lists two additional qualifications
related to the Network Security requirements:
** During the Period, there were instances of some Certificate Systems not
undergoing a Vulnerability Scan at least every three (3) months.
** During the Period, there were instances where a technical control to
restrict remote access to only those devices owned or controlled by Entrust
did not operate effectively.
* Entrust has the following open CA compliance bugs (as of 25-June):
** Outdated audit statement for intermediate cert [15]
** Certificate issued with incorrect Country Code [16]
** Certificate issued with validity greater than 825 days [17]
** SHA-1 Issuance and other misissuance while testing [18]
* CPS version 3.2 section 9.8.2.2 appeared to limit liability to $1000 USD
per Subscriber, but EVGL section 18 sets a minimum of $2000 USD. Entrust
addressed this in the current version.

This begins the 3-week (minimum) comment period for this request [19].

I will greatly appreciate your thoughtful and constructive feedback on the
decision to include this root certificate.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512018
[2] 

Re: Disclosure and CP/CPS for Cross-Signed Roots

[Wayne Thayer via dev-security-policy]

Thank you Rob! These are excellent additions to this report.

I'd like to ask all the CA representatives on this list to take a look at
the updated report (https://crt.sh/mozilla-disclosures) and correct any
issues with your company's disclosures as soon as possible.

Regarding Peter's earlier comment:

> I think that the process should be updated to list CAs (subject, subject
public key, subject key identifier), is addition to listing the CA
certificates.

It makes sense. I'll discuss this suggestion with Kathleen.

For now, what I'm hearing is that the GoDaddy and Asseco cases are clearly
incorrect disclosures due to the certificates not showing up on the
"parent" audit statement.

I think we want to continue to hold the issuing CA accountable for
disclosing any cross-certificates it signs, but they need to indicate that
the audit and applicable CP/CPS is that of the subject CA when that is the
case. I will also consider adding guidance on this issue to
https://www.ccadb.org/cas/intermediates

- Wayne

On Wed, Jul 24, 2019 at 9:41 AM Rob Stradling  wrote:

> [Wearing Sectigo hat]
>
> Andrew, thanks for filing [1].  Sectigo will provide a full response on
> that bug, but I'll just note here that we have updated the CCADB records
> for the cross-certificates such that the Audit and CP/CPS details are
> now consistent with the Web.com roots.  As it happens, I was already
> aware of this inconsistency, but I'd delayed fixing it so that I could
> use it as a test case for...
>
> [Wearing crt.sh hat]
>
> https://crt.sh/mozilla-disclosures now has two new buckets:
> - Disclosed, but with Inconsistent Audit details
> - Disclosed, but with Inconsistent CP/CPS details
>
> (I started discussing this new feature with Kathleen, Wayne and Sleevi
> off-list a few months ago, but I was not able to finish implementing it
> until a few days ago).
>
> I've also made the checks for the "Disclosure Incomplete" bucket
> stricter.  Missing/incomplete disclosures of BR and/or EV audits are now
> flagged.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060
>
> On 18/07/2019 21:46, Andrew Ayer via dev-security-policy wrote:
> > On Thu, 18 Jul 2019 11:40:31 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> >> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
> >> a bit of discussion.
> >
> > There's a third bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1567062
> >
> > Like the GoDaddy case, the intermediate supposedly having the same
> > CP/CPS/audits as parent is not listed in the parent's audit report, so
> > this too looks like an incorrect disclosure.
> >
> > Regarding Sectigo and Web.com, although their CPSes use extremely
> > similar language, they are not consistent, since they list different
> > CAA domains.
> >
> > Regards,
> > Andrew
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissuance Report: Incorrect CA-Issuers URI in some certificates

[Wayne Thayer via dev-security-policy]

Neil,

Thank you for posting this detailed incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1568356 to track this issue
and I have no questions at this time.

- Wayne

On Tue, Jul 23, 2019 at 10:20 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To m.d.s.p,
>
> The following contains an incident report, compiled as a result of the
> release of two example certificates with an incorrect CA-Issuers URI
> included.
>
> Any questions or observations on this incident are gratefully received,
> and I will endeavour to answer them as quickly as I can.
>
> Regards,
>
> Neil Dunbar,
> CA Administrator,
> TrustCor Systems, S. de R.L.
>
> —
>
> 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.policy, a Bugzilla bug, or internal self-audit),
>   and the time and date.
>
> 2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
> monitoring process, Internal QA identified two (2) certificates which
> contained an incorrect URI value in the CA Issuers part of the
> authorityInformationAccess extension.
>
> 2. A timeline of the actions your CA took in response. A timeline is a
>   date-and-time-stamped sequence of all relevant events. This may include
>   events before the incident was reported, such as when a particular
>   requirement became applicable, or a document changed, or a bug was
>   introduced, or an audit was done.
>
> 2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
> 2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA
> hierarchy suspended, pending investigation of issue.
> 2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected
> certificates completed.
> 2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect
> value stipulated for an Internal Example Certificate profile under the
> ECA-1 root (no other hierarchies shared this issue).
> 2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile
> values for ECA-1 internal example certificates corrected on testing and
> production platforms.
> 2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected
> certificates.
> 2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected
> certificates.
>
> 3. Whether your CA has stopped, or has not yet stopped, issuing
>   certificates with the problem. A statement that you have will be
>   considered a pledge to the community; a statement that you have not
>   requires an explanation.
>
> TrustCor stopped issuing certificates identified with this problem and
> rapidly resolved the issue.
>
> 4. A summary of the problematic certificates. For each problem: number
>   of certs, and the date the first and last certs with that problem were
>   issued.
>
> Two (2) certificates were identified with this issue. The first was
> issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
> at 2019-07-22 11:22:10 UTC.
>
> 5. The complete certificate data for the problematic certificates. The
>   recommended way to provide this is to ensure each certificate is logged
>   to CT and then list the fingerprints or crt.sh IDs, either in the report
>   or as an attached spreadsheet, with one list per distinct problem.
>
> Two (2) certificates were identified: one was revoked immediately post
> production (as it is there to demonstrate a revoked certificate), and
> the second certificate, which was otherwise valid, was then revoked
> upon identifying the issue.
>
> The crt.sh URIs for the certificates (now revoked) are:
>
> https://crt.sh/?id=1695491402 
> https://crt.sh/?id=1695520034 
>
> 6. Explanation about how and why the mistakes were made or bugs
>   introduced, and how they avoided detection until now.
>
> The problem was that the authorityInformationAccess CA-Issuers URI, (BR
> Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA
> certificate, not the ECA-1 External CA certificate. While the BRs do not
> actually mandate the inclusion of the CA-Issuers URI, providing an
> incorrect value is certainly a mis-issuance.
>
> When TrustCor CA created the new certificate profiles for the ECA-1 example
> hierarchy, the profile QA tool previously only verified that the CA issuers
> URI point to a valid TrustCor CA certificate.
>
> Certificate profiles being copied from the test CA software are compared
> with the intended profiles for production as part of the QA
> process. Because the CA-Issuers URI is always different in test
> vs. production, and the test URI domain is different from
> production, the error was missed before the certificates were issued.
>
> 7. List of steps your CA is taking to resolve the situation and ensure
>   such issuance will not be repeated in the future, accompanied with a
>   timeline of when your CA expects to accomplish these 

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

Benjamin,

On behalf of Mozilla I'd like to acknowledge that your request has been
received and is under review.

- Wayne

On Tue, Jul 16, 2019 at 12:14 PM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Message Body (6 of 6)  APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS
>
> 1) Violation of Anti-Trust Laws:
>
> The Module Owner’s discretionary decision, when taken into context with
> the comments of other Mozilla Peers employed by other Browsers and/or
> competing Certificate Authorities, are intended to result in the types of
> unfair competition that are prohibited under the United States Sherman Act,
> the United States Federal Trade Commission Act, the Canadian Competition
> Act, the European Union Anti-Trust Policies, and the United Arab Emirates
> Competition Laws.
>
> a) Notwithstanding to the assertions for a decision “made on a collective
> assessment of all the information at hand”, the Module Owner, and Mozilla
> staff, have blatantly ignored, or failed to acknowledge and consider, the
> impact of anti-competitive comments made by Mr. Ryan Sleevi, a Google
> employee, with regard to the Applicants’ Root Inclusion request.
>
> > “I highlight this, because given the inherently global nature of the
> Internet, there is no technical
> > need to work with local CAs, and, with a well-run root store, all CAs
> provide an equivalent level
> > of protection and security, which rests in the domain authorization."
> [1]
>
> The above statement is quite startling in that it is being made by a
> representative of a dominant market power as an argument against the
> inclusion of a new economic participant’s entry into the global CA market
> place. In light of the fact that representative has tried to justify a
> technical non-compliance to support revocation of the Applicants’ Root
> Inclusion (note that significantly higher number of users were at risk due
> to the same serial entropy violations of his own employer Google) [2], and
> considering that this representative was a key player in the demonstration
> of dominant Browser market power against a significant CA global business
> [3], the Applicants have a reasonable basis to believe that the distrust
> discussion are more likely to be motivated by economic considerations that
> preserve incumbent parties market domination and monopolization.
>
> b) Additionally, the Module Owner, and Mozilla staff, have blatantly
> ignored, or failed to acknowledge and consider, the Applicants’ response to
> the Google Representative in their decision-making process. The General
> Counsel of DarkMatter asserted unambiguously in the public discussion as
> follows:
>
> We are of the view that CA monopolies are inherently bad for the internet
> in that they unfairly exploit market power. The result is a fundamental
> right to Internet security and privacy being deliberately priced out of
> reach for a significant population of the world.  We ask you, what can be
> more of an anti-competitive monopoly than a "well run store" (read
> Google/Mozilla) that does not take into consideration that sovereign
> nations have the fundamental right to provide digital services to their own
> citizens, utilizing their own national root, without being held hostage by
> a provider situated in another nation.” [4]
>
> The above discussions are highly relevant to the decision-making process,
> considering that the Module Owner is aware of the significant economic
> investment the Applicants have made in progressing the Root inclusion
> requests over the past two years.  In fact, the Applicants have received
> further communications from other relevant Browser Stores indicating that
> their respective decision to permit the Applicants to participate in the
> global CA business ecosystem will be based and influenced by the Mozilla
> Module Owner’s highly subjective discretionary decision. The entire global
> internet traffic is controlled by four (4) Browser Root Stores (Mozilla,
> Microsoft, Google and Apple). As Reuters pointed out in its July 4 story,
> three (3) of those Browser Stores will likely adopt and enforce this
> decision by Mozilla. In light of this, the Module Owner would be, or should
> be, aware of the significant economic harm of a decision based on less than
> verifiable “credible evidence”.
>
> c) Notwithstanding the above highly relevant elements of the public
> discussion, the Module Owner has now made a significant decision (on less
> than verifiable “credible evidence”) which we believe is intended to
> unfairly affect commerce in the global CA ecosystem through the use of the
> coercive influence he wields on the Applicants as a result of his
> discretionary decision making power. While rejecting the right of the
> Applicants to participate directly within the Mozilla Root Store, and by
> extension setting the stage for an outright denial of the Applicants’
> inclusions in any other browser store, the Module Owner has 

Re: Nation State MITM CA's ?

[Wayne Thayer via dev-security-policy]

On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi  wrote:

>
> On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Finally, I'll point out that Firefox implements public key pinning via a
>> preloaded list of sites, so the reported MITM will fail for those:
>>
>> https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status
>
>
> Wayne,
>
> I don't believe this is correct. Locally-installed trust anchors bypass
> pinning, as they're indicators of explicit user action (or coercion) to
> configure. As a consequence, unless the pinning mode is set to 2. Strict
> (which will typically preclude the use of a number of anti-virus products,
> for better or worse), which it is not by default, the MITM will not fail.
> From the Firefox point-of-view, it's completely transparent whether the
> MITM is being done by local security software or a nation-state
>

Yes, I had just realized that - in the default state, pinning in Firefox
will not block this type of MITM.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy