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
