Hi Kathleen.

The aspect of this proposal that most concerns me is the idea that after 
receiving proof of key compromise a CA MUST wait at least 24 hours before 
revoking the corresponding certificate(s).  Whilst this delay would certainly 
benefit an attacker who has a copy of the compromised private key (because 
their window of opportunity is enlarged), ISTM that this delay is most 
certainly not the best outcome for either the server operator or the relying 
parties.  IMHO, DOS'ing the website is better than enabling a false sense of 
security.

By way of analogy (albeit a fairly extreme analogy), imagine if it had just 
been discovered that the Golden Gate Bridge had become structurally unsound and 
was likely to collapse at any moment.  To avoid inconveniencing commuters that 
didn't receive prior warning to make alternative travel plans, should we wait 
24 hours before closing the bridge?  Or should we close the bridge immediately, 
to ensure no loss of life?

If a Subscriber has failed to protect their private key, then they've probably 
failed to uphold the terms of the Subscriber Agreement.  Why shouldn't the CA 
be permitted to revoke immediately?

________________________________
From: [email protected] <[email protected]> on 
behalf of Kathleen Wilson <[email protected]>
Sent: 29 December 2021 22:11
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>; 
[email protected] <[email protected]>; Matt Palmer 
<[email protected]>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Thank you to those of you who have provided more feedback. I have updated the 
draft policy text here:

https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3LT%2FaeXApN1PCwUYyZ3w%2FeYkgS6%2Bz4D84DyGgtob0Vs%3D&reserved=0>

I highlighted the changes in the document, and below is a summary of the 
changes.

1) The first sentence of the second paragraph has been changed to make my 
intent more clear, and I added a comment that we will need to determine an 
effective-date because this means code changes (e.g. ACME).

"When a certificate revocation is not initiated by the certificate subscriber, 
the CA MUST notify the certificate subscriber about its intent to revoke the 
end-entity SSL certificate at least 24 hours before revoking the certificate."

I am open for feedback on wording and the time frame (e.g. 24 hours), and I 
will also appreciate thoughts about the effective-date for this new policy. I 
intend to require that CAs notify certificate subscribers before revoking their 
certificates, because when certificate revocation is enforced by the browser 
the CA can essentially cause DOS for websites.

2) Per the feedback from Wendy 
(here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fg%2Fdev-security-policy%2Fc%2FCls1b2iuOLU%2Fm%2F-wAFl43kCwAJ&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LI%2Bx9n6ByrRqE4yc%2FSfgtzSXLQT9C7Ajp%2BIC8hbXSV8%3D&reserved=0>)
 I replaced "affiliationChanged (3)" with "cessationOfOperation (5)" in the 
proposed text, because despite the previously referenced 
document<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Ftn-archive%2Fcc700843(v%3Dtechnet.10)&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZIKRh4n3bJ%2B0JJnwx%2B4nSRBL9Upq7t7O4otOUuDsFuI%3D&reserved=0>
 about revocation reasons, I agree with Wendy that cessationOfOperation makes 
more sense in regards to a TLS certificate no longer being needed because the 
website it was used in has been taken down or the certificate subscriber no 
longer owns the domain name(s) in the certificate. Whereas affiliationChanged 
seems to be about how a person is associated with an organization.

So the "affiliationChanged (3)" paragraph has been replaced by the following.

"cessationOfOperation (5)

The CRLReason cessationOfOperation (5) MUST be used when the subscriber has 
requested that their certificate be revoked for this reason, or the CA has 
received verifiable evidence that the subscriber no longer owns the domain 
names in the certificate and there is no evidence of a private key compromise. 
Otherwise this CRLReason MUST NOT be used. The CRLReason cessationOfOperation 
(5) is intended to be used to indicate that the subscriber no longer owns the 
domain names in the certificate or will no longer be using the certificate. For 
example, this revocation reason should be used if the website with the 
certificate is shut down prior to the expiration of the certificate."

I will continue to appreciate your input on this draft proposal.

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]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/985030a9-d162-4102-8724-adeec29be6ean%40mozilla.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F985030a9-d162-4102-8724-adeec29be6ean%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r0rPLLiPhXZvekbtXkCr11BP1%2BPOOE82kGRiM19aZZg%3D&reserved=0>.

-- 
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/MW4PR17MB4729ED29CE2AD8536B5CB36EAA459%40MW4PR17MB4729.namprd17.prod.outlook.com.

Reply via email to