On Tue, Mar 12, 2019 at 7:14 AM Jakob Bohm via dev-security-policy < [email protected]> wrote:
> 5. As a special exception, systems that require signing certificates > with the same serial-number more than once (such as CT and CA > validity adjustments) are not required to change the serial number > after initial selection). While I am largely ignoring the rest of this message/thread, I feel obligated to point out to any CAs that get distracted by this thread (e.g. If they struggle to understand what “at least” means) that the reuse of serials for “CA validity adjustments” is not, nor has it ever been, compliant with RFC 5280 nor the Baseline Requirements. Serials that are duplicated in such a manner are non-compliant and incidents, as has been discussed repeatedly in the past [1] [2]. While I hope and expect CAs are well aware of these basic requirements, its necessary to call out when participants are advocating for violating the Baseline Requirements. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/OJIhgypNvkc/c7_sHuCeFAAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/SM3cUnENmUw/ZeNCpR2eBgAJ 6. As a special exception due to widespread technical failures, > certificates issued on or prior to 2019-03-31 UTC may instead use > serial numbers consisting only of 63 random bits chosen as per #2, > but checked to reject any value that would be encoded to 7 or fewer > bytes or be the same as a previously issued serial number. Again, it is worth reiterating that exceptions are not and cannot be retroactively granted, even by the Baseline Requirements. This thread will not be beneficial, either for Mozilla participants nor the CA/Browser Forum. There are plenty of avenues one could take if one felt they had a unique and valuable technical contribution to offer, such as creating an IETF Internet-Draft that attempts to formalize a given algorithm, while providing a degree of IP protection/disclosure to such a contribution. However, this group is not that. On a more fundamental level, suggestions such as this highlight the confusion that some non-CA participants may have with respect to the Baseline Requirements. In many ways, the BRs specify the expectations and goals, while the technical means of achieving those goals are left for other specifications. For example, the recently completed RFC 8555 provides an algorithm for fulfilling the obligations of 3.2.2.4 of the Baseline Requirements. FIPS 140 series provides methods for fulfilling the obligations of key protection requirements. Threads proposing changes to the BRs should be left to archive, as they do not provide value to the community here, and create significant risks and problems. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
