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 < [email protected]> 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
