Make ocsp optional updates #3
Conversation
Typo (thanks, Wendy!)
docs/BR.md
Outdated
|
|
||
| | __Conditions__ | __Minimum CRL Issuance Frequency__ | __Maximum nextUpdate Period__ | | ||
| | ---- | - | - | | ||
| | The CA has revoked at least one unexpired Certificate since the `thisUpdate` field of the last CRL. | A CRL MUST be generated and published within 24 hours of the `thisUpdate` field of the last CRL. <br><br> A CRL SHOULD be generated and published within 4 hours of the `thisUpdate` field of the current CRL. | The value of the `nextUpdate` field MUST NOT be more than 10 days beyond the value of the `thisUpdate` field. | |
There was a problem hiding this comment.
I must admit I'm still not enamored with this use of "has revoked". Despite Dimitris' totally valid point that we already do this for Subordinate CA Certificates, to me it feels like an unfortunate precedent to carry forward. How can a CA be said to "have revoked" something if they haven't published a CRL containing it yet?
Also, this phrasing is impossible. Suppose that a CA issues a CRL, and then coasts for 5 days with no revocations being necessary. This is permitted under the "All other conditions" entry. Then, a cert needs to be revoked. But significantly more than 24 hours have already passed since the thisUpdate of the previous CRL! So in practice, a CA would be required to issue at least every 24 hours, just in case a new revocation request comes in.
These kinds of accidental gotchas are why I'm opposed to a two-tiered system of CRL issuance frequency requirements. We've already demonstrated that it is difficult to write and read (I missed this contradiction on my first two reads of this diff!) requirements like this. We should not be making things more difficult than necessary.
I'm still in favor of the previous "CAs issuing Subscriber Certificates SHALL update and reissue CRLs at least once every 24 hours".
There was a problem hiding this comment.
Abandoned the table (the more I thought about it, the more it seemed to overcomplicate things).
Back to a bulleted list and including a slightly modified version of Dimitris' latest proposal.
There was a problem hiding this comment.
I must admit I'm still not enamored with this use of "has revoked". Despite Dimitris' totally valid point that we already do this for Subordinate CA Certificates, to me it feels like an unfortunate precedent to carry forward. How can a CA be said to "have revoked" something if they haven't published a CRL containing it yet?
Also, this phrasing is impossible. Suppose that a CA issues a CRL, and then coasts for 5 days with no revocations being necessary. This is permitted under the "All other conditions" entry. Then, a cert needs to be revoked. But significantly more than 24 hours have already passed since the
thisUpdateof the previous CRL! So in practice, a CA would be required to issue at least every 24 hours, just in case a new revocation request comes in.These kinds of accidental gotchas are why I'm opposed to a two-tiered system of CRL issuance frequency requirements. We've already demonstrated that it is difficult to write and read (I missed this contradiction on my first two reads of this diff!) requirements like this. We should not be making things more difficult than necessary.
I'm still in favor of the previous "CAs issuing Subscriber Certificates SHALL update and reissue CRLs at least once every 24 hours".
I believe this reading is a bit egregious. Every CA must record the status of a certificate (intermediate or end-entity). Due to the way PKI works, there is always some delay (greater than zero), between changing the status of a certificate to "revoked" and issuing a CRL or signing a new OCSP response. This is especially obvious when CAs perform offline ceremonies with CRLs/OCSP responses issued from Root CAs. I hope people agree with this.
I proposed some text that I consider clear and unambiguous. I hope more Members can chime-in and state their opinion whether this language works and delivers what is expected.
There was a problem hiding this comment.
(Reviewed and incorporated @dzacharo suggested edits.)
Editorial Co-authored-by: Aaron Gable <[email protected]>
Editorial Co-authored-by: Aaron Gable <[email protected]>
Address comment from Aaron: "I'm not in favor of allowing CRLs to remain non-updated for 7 days because that is a regression from current OCSP behavior. Section 4.9.10.(4) makes it so that updated revocation information is always available "no later than four days after the thisUpdate". Therefore, a CA operating in a CRLs-only mode should be required to update their CRLs at least once every 4 days."
Co-authored-by: Dimitris Zacharopoulos <[email protected]>
Co-authored-by: Dimitris Zacharopoulos <[email protected]>
"twenty four" -> "twenty-four"
Add provision to handle nonces per RFC8954
Improve readability.
|
Merging and closing PR to help kickoff a second round of public discussion. |
Staging updates for continued discussion....
This PR is intended to make it easier to collect community feedback.