One minor question, but generally I agree with this approach also!

 

Should this be changed to MUST NOT?

*       …The CA SHOULD NOT assume that it has evidence of private key 
compromise for the purposes of revoking the certificates of other subscribers 
or blocking issuance of future certificates with that key.

 

 

From: [email protected] <[email protected]> On 
Behalf Of Ryan Sleevi
Sent: Thursday, February 3, 2022 3:08 PM
To: Kathleen Wilson <[email protected]>
Cc: [email protected]; Ben Wilson <[email protected]>; Ryan 
Sleevi <[email protected]>; Doug Beattie <[email protected]>; 
[email protected] <[email protected]>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates

 

 

 

On Thu, Feb 3, 2022 at 2:47 PM Kathleen Wilson <[email protected] 
<mailto:[email protected]> > wrote:

These concrete suggestions of alternative text are very helpful.

 

I have updated the  bright green text in the draft policy document 
<https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing>
  per your recommendations:

===

The scope of revocation depends on whether the certificate subscriber has 
proven possession of the private key of the certificate.
- If anyone requesting revocation has previously demonstrated or can currently 
demonstrate possession of the private key of the certificate, then the CA MUST 
revoke all instances of that key across all subscribers.
- If the certificate subscriber requests that the CA revoke the certificate for 
keyCompromise, and has not previously demonstrated and cannot currently 
demonstrate possession of the associated private key of that certificate, the 
CA SHOULD revoke all certificates associated with that subscriber that contain 
that public key. The CA SHOULD NOT assume that it has evidence of private key 
compromise for the purposes of revoking the certificates of other subscribers 
or blocking issuance of future certificates with that key.

===

 

I think that works! Thanks for highlighting the concerns with the language, 
Aaron, and thanks for the improvements, Kathleen. 

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected] 
<mailto:[email protected]> .
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFL98PAXj2dR6ETDeMpfKOjTX%2B_KZ-O8uHfhrRq7gD6-Q%40mail.gmail.com
 
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFL98PAXj2dR6ETDeMpfKOjTX%2B_KZ-O8uHfhrRq7gD6-Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
 .

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB612970E63361FF95EE0CD820F0289%40PUZPR03MB6129.apcprd03.prod.outlook.com.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to