Re: PROCERT issues

[Ryan Sleevi via dev-security-policy]

Hi Kathleen,

With respect to providing a list - is there any requirement to ensure
Mozilla accepts that as a reasonable remediation?

For example, would "We plan to not do the same in the future" be an
acceptable remediation plan? As currently worded, it would seem to meet the
letter of this requirement.

This would be useful to ensure before [2]

On Tue, Oct 3, 2017 at 10:38 AM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Here's a draft of the Bugzilla Bug that I plan to file to list the action
> items for PROCERT to complete before they may re-apply for inclusion in
> Mozilla's Root Store. I will appreciate feedback on this.
>
> == DRAFT ==
> Subject: PROCERT: Action Items
>
> As per Bug #1403549 the PSCProcert certificate will be removed from
> Mozilla’s Root Store due to a long list of problems and they way that
> PROCERT responded to those problems (and to previous CA Communications).
> For details about the problems, see Bug #1391058 and
> https://wiki.mozilla.org/CA:PROCERT_Issues
>
> The purpose of this bug is to record the action items that PROCERT must
> complete before their certificate may be included as a trust anchor in
> Mozilla’s Root Store again.
>
> PROCERT may apply for inclusion of a new certificate[1] following
> Mozilla's normal root inclusion/change process[2], after they have
> completed all of the following action items.
>
> 1. Provide a list of changes that the CA plans to implement to ensure that
> there are no future violations of Mozilla's CA Certificate Policy and the
> CA/Browser Forum's Baseline Requirements.
>
> 2. Implement the changes, and update their CP/CPS to fully document their
> improved processes.
>
> 3. Provide a reasonably detailed[4] public-facing attestation from a
> licensed auditor[3] acceptable to Mozilla that the changes have been made.
> This audit may be part of an annual audit.
>
> 4. Provide auditor[3] attestation that a full performance audit has been
> performed confirming compliance with the CA/Browser Forum's Baseline
> Requirements. This audit may be part of an annual audit.
>
>
> Notes:
> [1] The new certificate (trust anchor) may be cross-signed by the removed
> certificate. However, the removed certificate may *not* be cross-signed by
> the new certificate, because that would bring the concerns about the
> removed certificate into the scope of the new trust anchor.
> [2] Mozilla's root inclusion/change process includes checking that
> certificates in the CA hierarchy comply with the CA/Browser Forum's
> Baseline Requirements.
> [3] The auditor must be an external company, and approved by Mozilla.
> [4] “detailed” audit report means that management attests to their system
> design and the controls they have in place to ensure compliance, and the
> auditor evaluates and attests to those controls. This assertion by
> management - and the auditor's independent assessment of the factual
> veracity of that assertion - will help provide a greater level of assurance
> that PROCERT has successfully understood and integrated the BRs.
> ==
>
> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Issuing and using SHA-1 OCSP signing certificates

[Doug Beattie via dev-security-policy]

Hello Gerv,

The BRs are clear on the use of SHA-1, but I have a question about the Mozilla 
policy and how it relates to the use of SHA-1 OCSP signing certificates.

In December 2016 the Mozilla policy 2.3 was published and it didn't address the 
use of SHA-1 on OCSP signing certificates (see anyone that needs it, this page 
for links to the Mozilla CA policies: https://wiki.mozilla.org/CA:CertPolicy )

In February 2017, Mozilla Policy 2.4 was published which added stipulations for 
use of SHA-1 and that has been subsequently updated a few times this year to 
evolve to this:

5.1.1 SHA-1
CAs MAY sign SHA-1 hashes over end-entity certificates which chain up to roots 
in Mozilla's program only if all the following are true:
1.The end-entity certificate:
ois not within the scope of the Baseline Requirements;
ocontains an EKU extension which does not contain either of the 
id-kp-serverAuth or anyExtendedKeyUsage key purposes;
ohas at least 64 bits of entropy from a CSPRNG in the serial number.
2.The issuing certificate:
ocontains an EKU extension which does not contain either of the 
id-kp-serverAuth or anyExtendedKeyUsage key purposes;
ohas a pathlen:0 constraint.
Point 2 does not apply if the certificate is an OCSP signing certificate 
manually issued directly from a root.
In late 2016 we pre-generated a number of OCSP signing certificates for use in 
signing OCSP messages under our SSL CAs, but since we didn't know this same 
rule would be applied to non-BR certificates, we didn't pre-generate any OCSP 
signing certificates for those CAs.

The specific issue is that these client certificate CAs don't have the EKU 
extension even though we have no intent of issuing SSL certificates (they are 
WT audited and verified to not issue any SSL certificates per the BRs).

Is it permissible to continue issuing SHA-1 OCSP signing certificates for these 
existing legacy non-SSL CAs so we may continue providing revocation services 
using algorithms they support until all certificates under the CAs expire?  
This would be no later than the end of 2020.




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