Re: Sectigo to Be Acquired by GI Partners

2020-10-01 Thread 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


Sectigo to Be Acquired by GI Partners

2020-10-01 Thread Ben Wilson via dev-security-policy
 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

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


Policy 2.7.1 Issues to be Considered

2020-10-01 Thread Ben Wilson via dev-security-policy
Below is a list of issues that I propose be addressed in the next version
(2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
issues related to the MRSP listed here:
https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13
items to consider for this policy update; which are tagged as v.2.7.1 in
GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
appreciate your input on this list as to whether there are issues that
should be added or removed. Then, based on the list, I will start a
separate discussion thread in mozilla.dev.security.policy for each issue.

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153.

#147  - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

#153  – Cradle-to-Grave
Contiguous Audits – Specify the audits that are required from Root key
generation ceremony until expiration or removal from Mozilla’s root store.
Related to Issue #139.

#154  - Require Management
Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to
the WebTrust criteria, the Management Assertion letter MUST include all
known incidents that occurred or were still open/unresolved at any time
during the audit period.”

#173  - Strengthen
requirement for newly included roots to meet all past and present
requirements – Add language to MRSP 7.1 so that it is clear that before
being included CAs must comply and have complied with past and present
Mozilla Root Store Policy and Baseline Requirements.

#186  - Clarify MRSP 5.3
Requirement to Disclose Self-signed Certificates – Clarify that self-signed
certificates with the same key pair as an existing root meets MRSP 5.3’s
definition of an intermediate certificate that must be disclosed in the
CCADB.

#187  - Require disclosure
of incidents in Audit Reports –  To MRSP 3.1.4 “The publicly-available
documentation relating to each audit MUST contain at least the following
clearly-labelled information: “ add “11. all incidents (as defined in
section 2.4) that occurred or were still open/unresolved at any time during
the audit period, or a statement that the auditor is unaware of any;”

#192  - Require
information about auditor qualifications in the audit report – Require
audit statements to be accompanied by documentation of the auditor’s
qualifications demonstrating the auditor’s competence and experience.

#205  - Require CAs to
publish accepted methods for proving key compromise – Require CAs to
disclose their acceptable methods for proving key compromise in section
4.9.12 of their CPS.

#206  - Limit re-use of
domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
verify ownership/control of each dNSName and iPAddress in the certificate's
subjectAltName at intervals of 398 days or less;”

#207  - Require audit
statements to provide information about which CA Locations were and were
not audited, and the extent to which they were (or were not) audited

#211  - Align OCSP
requirements in Mozilla's policy with the section 4.9.10 of the Baseline
Requirements
#218  Clarify CRL
requirements for End Entity Certificates – For CRLite, Mozilla would like
to ensure that it has full lists of revoked certificates. If the CA uses
partial CRLs, then require CAs to provide the URL location of their full
and complete CRL in the CCADB.

Ben Wilson
Mozilla Root Program Manager
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mandatory reasonCode analysis

2020-10-01 Thread Ryan Sleevi via dev-security-policy
On Thu, Oct 1, 2020 at 6:39 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Although RFC 5280, section 5 [2] mandates that conforming CAs MUST produce
> v2 CRLs, the CAs issuing v1 CRLs pre-date any browser root requirements
> that mandate adherence to the RFC 5280 profile.


To clarify: You mean the CAs were issued prior to 2012, yet are still
trusted? That seems an easy enough problem to fix, in the spirit of
removing roots and hierarchies that predate the Baseline Requirements 1.0
effective date
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mandatory reasonCode analysis

2020-10-01 Thread Corey Bonnell via dev-security-policy
I did some searching in this area after Microsoft announced the new root 
program requirement back in February [1] and it appears that v1 CRLs are still 
being actively published in the webPKI. Notably, v1 CRLs do not support 
extensions in revoked entries, so there is no way to encode the reasonCode 
extension.

Although RFC 5280, section 5 [2] mandates that conforming CAs MUST produce v2 
CRLs, the CAs issuing v1 CRLs pre-date any browser root requirements that 
mandate adherence to the RFC 5280 profile. Switching to v2 CRLs may present 
interoperability concerns for legacy clients that consume CRLs issued from such 
CAs. Additionally, RFC 5280 specifies that conforming clients must be able to 
consume both v1 and v2 CRLs, so modern clients should be able to consume v1 
CRLs.

Given the requirement as specified originally by Microsoft (and later in the 
BRs), I'd think that only v2 CRLs are acceptable moving forward but the 
potential legacy client interoperability issues may pose challenges with 
transitioning to v2 CRLs. I'm interested to hear if anyone has any thoughts on 
this.

Thanks,
Corey

[1] 
https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#Microsoft-Root-Program-Update
[2] https://tools.ietf.org/html/rfc5280#section-5


From: dev-security-policy  on 
behalf of Rob Stradling via dev-security-policy 

Sent: Wednesday, September 30, 2020 11:58:45 AM
To: dev-security-policy@lists.mozilla.org 

Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Frobstradling%2F3088dd622df8194d84244d4dd65ffd5fdata=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435%7C1%7C0%7C637370783420551771sdata=7kogxCZ1c%2F1ksbkNYEfMyP91gyIpJ8ppG%2F%2BOjevVl1Y%3Dreserved=0


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policydata=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435%7C1%7C0%7C637370783420551771sdata=fkGX6tVkyTLHNtQkoiEdoF13ypjqCm6%2Ffq7FywIpa%2Fo%3Dreserved=0
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mandatory reasonCode analysis

2020-10-01 Thread pfuen...--- via dev-security-policy
Hello,
as we are in the "list of shame" and as a way to ensure we are following these 
discussions, I'd like to say that the OISTE CA that is referenced here (it's an 
old intermediate CA expiring in December 2020, and its CRL contains some 
unspecified revocations for Issuing CAs from 2015 and older) is under a root 
for which we already requested to remove the TLS trust bit to the different CA 
programs (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1653092), so now is 
out of the scope of BR.
Best,
Pedro


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