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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
