All,

I have updated the bright green text in the draft policy 
<https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing>
 
again...
==
The CRLReason keyCompromise (1) MUST be used when one or more of the 
following occurs:
- the CA obtains verifiable evidence that the certificate subscriber’s 
private key corresponding to the public key in the certificate suffered a 
key compromise;
- the CA is made aware of a demonstrated or proven method that exposes the 
certificate subscriber’s private key to compromise;
- there is clear evidence that the specific method used to generate the 
private key was flawed;
- the CA is made aware of a demonstrated or proven method that can easily 
compute the certificate subscriber’s private key based on the public key in 
the certificate (such as a Debian weak key, see 
https://wiki.debian.org/TLSkeys); or
- the certificate subscriber requests that the CA revoke the certificate 
for this reason. 

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 limit revocation to only certificates that are associated 
with that subscriber and which contain that public key.
==

Thanks again to all of you for your patience and continued effort to help 
find a reasonable balance and make this more clear.

Thanks,
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].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/2baa9599-22e1-4db0-ac3e-4d6f9e9c368cn%40mozilla.org.

Reply via email to