On Sat, Jul 4, 2020 at 6:22 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> El viernes, 3 de julio de 2020, 18:18:49 (UTC+2), Ryan Sleevi escribió: > > Pedro's option is to reissue a certificate for that key, which as you > point > > out, keeps the continuity of CA controls associated with that key within > > the scope of the audit. I believe this is the heart of Pedro's risk > > analysis justification. > > I didn't want to participate here for now and just learn from other's > opinions, but as my name has been evoked, I'd like to make a clarification. > > My proposal was not JUST to reissue the certificate with the same key. My > proposal was to reissue the certificate with the same key AND a short > lifetime (3 months) AND do a proper key destruction after that period. > > As I said, this: > - Removes the offending EKU > - Makes the certificate short-lived, for its consideration as delegated > responder > - Ensures that the keys are destroyed for peace of mind of the community > > And all that was, of course, pondering the security risk based on the fact > that the operator of the key is also operating the keys of the Root and is > also rightfully operating the OCSP services for the Root. > > I don't want to start another discussion, but I just feel necessary making > this clarification, in case my previous message was unclear. Thanks! I really appreciate you clarifying, as I had actually missed that you proposed key destruction at the end of this. I agree, this is a meaningfully different proposal that tries to balance the risks of compliance while committing to a clear transition date. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
