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. - Wayne On Mon, May 6, 2019 at 2:04 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote: > I think it should be added by Mozilla. The CAB Forum is a long way from > having an s/MIME policy in place (there's not even a working group yet). > Having no policy for cert revocation related to s/MIME ignores that s/MIME > are part of the Mozilla ecosystem and sequesters them from the rest of the > policy. Without a revocation policy, there's no requirement to revoke a > certificate mis-issued that's non-TLS. > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Friday, May 3, 2019 12:44 PM > To: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.7 Proposal: Clarify Revocation Requirements for > S/MIME Certificates > > Kathleen and Pedro, > > Thank you for raising these legitimate concerns. I continue to believe > that a literal reading of the current requirement is that it already does > apply to S/MIME certificates, and the discussion I mentioned supports that > interpretation. > > I propose two new options to solve this problem: > * Remove S/MIME certificates from the scope of section 6 and wait for the > CAB Forum to publish baseline requirements for S/MIME. I suspect that is a > few years away given that the working group is still in the process of > being chartered. However, this option is consistent with some people's > interpretation of the existing requirements. > * Add a subsection on revocation specific to S/MIME certificates and > populate it with a version of the BR requirements tailored to S/MIME. We'd > probably need to include requirements for S/MIME Intermediates as well as > leaf certificates. > > A third option would be to specify the parts of the BR revocation > requirements that don't apply to S/MIME certificates, but after reviewing > section 4.9.1, I think this would be confusing, at best. > > I would appreciate everyone's input on the best way to address this issue. > > - Wayne > > > On Fri, May 3, 2019 at 5:12 AM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hello, > > my main concern about applying this would be that this would lead to > > forbid the option to suspend a personal certificate. > > > > On a side note about suspension... I was not active in the forums when > > this was discussed and adopted and I'm sure there was a clear benefit > > on disallowing suspensions, but it's kind of a hassle already because > > of the application of this rule to the whole hierarchy. We'd like for > > example to have the capability to suspend a subordinate CA that is > > under investigation or that is pending of an audit, but right now we > > can't do it... extending these rules to personal certificates is not > > something I'm personally too enthusiastic. > > > > Best, > > Pedro > > > > El jueves, 2 de mayo de 2019, 17:32:43 (UTC+2), Kathleen Wilson > escribió: > > > Just want to make it very clear to everyone, that the proposal, to > > > add the following text to section 6 of Mozilla's Root Store Policy > > > would mean that certs constrained to id-kp-emailProtection > > > (end-entity and intermediate), i.e. S/MIME certs, would be subject > > > to the same BR rules and revocation timelines as TLS/SSL certs. > > > > > > > This requirement applies to certificates that are not otherwise > > required > > > >> to comply with the BRs. > > > > > > For example, Section 4.9.1.1 of the BRs says: > > > "" > > > MUST revoke a Certificate within 5 days if one or more of the > > > following > > > occurs: ... > > > > > > 1. The Certificate no longer complies with the requirements of > > > Sections > > > 6.1.5 and 6.1.6; > > > ... > > > 7. The CA is made aware that the Certificate was not issued in > > > accordance with these Requirements "" > > > > > > I interpret "these Requirements" to mean the BRs. Therefore, my > > > interpretation of the proposed additional text is that certs that > > > are constrained to S/MIME would also have to be issued in full > > > accordance with the BRs and would have to be revoked within the > > > timeline as specified in the BRs when found to be not in full > > > compliance with the BR issuance rules. > > > > > > Section 1.1 of Mozilla's root store policy limits the scope of the > > > policy such that the proposed additional text would only > > > specifically add the rules to S/MIME certs. Certs with no EKU > > > extension or anyExtendedKeyUsage are considered technically capable > > > of issuing TLS certs, so already subject to the rules of the BRs. > > > > > > Therefore, my concern is that the proposed additional text would > > > mean that all of the BR issuance rules and revocation rules would > > > also apply to S/MIME certs. I do not think that S/MIME certs have > > > been taken into account in the BRs, so I do not think we should > > > impose all the BR issuance and revocation rules on S/MIME certs. > > > > > > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
