We largely don’t care as we consider this to be an existing requirement, so the date doesn’t really matter for us, but I’m totally ok with enhancing the BRs to make the requirement more explicit, and putting an agreed upon future compliance date in there for anyone who might have missed this subtle requirement. I was mostly commenting on Jan 1st being bad to help out other people who might be affected.
I have previously noted that the 15th day of odd months tends to dodge most holidays (e.g. Jan 15th or Mar 15th), and choosing from those six compliance dates might make CABF BR compliance schedules look a little bit more organized and less like 100 individuals randomly throwing darts at a calendar, but that’s just a personal preference of mine. -Tim From: 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Sent: Friday, October 14, 2022 1:07 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: Corey Bonnell <corey.bonn...@digicert.com>; Andrew Ayer <a...@andrewayer.name>; 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Subject: Re: CRL partitioning and IDPs Yep, and I just got sidetracked by a meeting in between sending the message to this list and sending the corresponding one to the servercert-wg list! It's been sent now, and can be viewed in the public archive here: https://lists.cabforum.org/pipermail/servercert-wg/2022-October/003347.html You're absolutely right that Jan 1 is not a great compliance deadline in general. I figured in this case it would probably be okay due to the likely small number of people affected, but I'm by no means attached to that date. Would you prefer a shorter or a longer timeline? Thanks again, Aaron On Fri, Oct 14, 2022 at 9:51 AM Tim Hollebeek <tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>> wrote: Shouldn’t CABF ballot discussions and endorsement conversations happen on the relevant CABF lists? This is somewhat important both to make sure the relevant conversations are properly documented and archived in the right place, as well as for compliance with the CABF IPR rules. It doesn’t horribly matter for small ballots like this, but it’s still probably a good idea to do things the usual ways and locations. Also, January 1st is not a particularly good date to use as a compliance deadline. The proximity to the winter holidays and year rollover causes all sorts of fun silliness that’s generally best avoided. -Tim From: 'Aaron Gable' via dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org>> Sent: Friday, October 14, 2022 12:30 PM To: Corey Bonnell <corey.bonn...@digicert.com<mailto:corey.bonn...@digicert.com>> Cc: Andrew Ayer <a...@andrewayer.name<mailto:a...@andrewayer.name>>; 'Aaron Gable' via dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org>> Subject: Re: CRL partitioning and IDPs To ensure that future parties don't have to have this same discussion again, I have put together a CA/BF ballot to update the BRs to explicitly require the distributionPoint field in sharded CRLs: https://github.com/cabforum/servercert/pull/396 I'm seeking endorsers so it can be given a ballot number and formally proposed for a discussion and voting period on the CA/BF mailing lists. Thanks, Aaron On Wed, Oct 12, 2022 at 4:50 PM Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> wrote: On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell <corey.bonn...@digicert.com<mailto:corey.bonn...@digicert.com>> wrote: My interpretation of this passage is that it is defining the required scope of the CRL in the absence of the distributionPoint field. Namely, all revoked certificates issued by the CA must be contained within the scope of the CRL. However, it sounds like your interpretation is that the CRL must contain all revoked certificates that are within its scope. This sounds tautological or seemingly indicates that it is somehow possible to recursively scope CRLs (i.e., a scope within a scope) by including the distributionPoint field. Ah, I see, your reading is "If the distributionPoint field is absent, then the CRL MUST have a scope which contains all certificates issued by the CRL issuer". This reading would be nice, but in my opinion is plainly not the actual meaning of the sentence. To see why, ask the question: with this reading, what must be within the scope of the CRL? What is the object of the verb "contain"? The answer from your interpretation is "entries for all revoked unexpired certificates issued by the CRL issuer": "the CRL MUST contain (entries for all revoked unexpired certificates issued by the CRL issuer, if any) within the scope of the CRL". First, note that this is not how one would usually construct an English sentence: we don't like to repeat the subject of the sentence ("the CRL") twice. If this were the intended reading, the sentence would be constructed as: "the CRL MUST contain (entries for all revoked unexpired certificates issued by the CRL issuer, if any) within its scope"; or "the CRL MUST contain within its scope (entries for all revoked unexpired certificates issued by the CRL issuer, if any)"; or best yet "the CRL's scope MUST contain (all revoked unexpired certificates issued by the CRL issuer, if any)". But even more tellingly, CRL scopes do not contain "entries", CRL scopes contain "certificates": RFC 5280 Section 5 "The CRL scope is the set of certificates that could appear on a given CRL.". So since we know that this noun phrase cannot be the object of the verb "contains", what other candidate is there? The only option is the whole rest of the sentence: "the CRL MUST contain (entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL)". And here it's clear that "within the scope of the CRL" is a modifier on the object of the sentence, not the second half of a split subject of the sentence. Can you expand upon how your interpretation would work in practice? Sure. RFC 5280 makes a distinction between the "scope" of a CRL (which again is the set of certificates which could appear on a CRL), and whether or not that CRL contains revocations for all reason codes (which it refers to as "partitioning"). In particular, the Issuing Distribution Point extension can (and must) indicate when a CRL only contains revocations for some reason codes, but does not serve a purpose in identifying any other scope that a CRL may be limited to: "The reason codes associated with a distribution point MUST be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point MUST contain revocations for all reason codes. CAs may use CRL distribution points to partition the CRL on the basis of compromise and routine revocation." Thus, a CA could issue two separate CRLs with different scopes (say, odd vs even serial numbers), and not be required to include a distributionPoint field and an Issuing Distribution Point extension in their CRLs. But if they instead wanted to issue four CRLs, with the same scopes but additionally partitioned by revocation reason (say, keyCompromise vs all other reasons), then they would be required to include the Issuing Distribution Point extension and the onlySomeReasons field... and the distributionPoint field, because the CRLs no longer contain entries for all revoked unexpired certs within their scope. With this understanding, we see that RFC 5280 is invested in the CRL having a distributionPoint field if it does not contain all certificates within its scope -- i.e. if certificates within its scope but which were revoked for other reasons appear on a different CRL. RFC 5280 does not care about the distributionPoint field as long as all certificates within the CRL's scope have their entries in this CRL -- i.e. it is not additionally partitioned by reasonCode. Again, I'm not saying this is a good requirement to have, but it does seem like the plainest interpretation of the language contained in the standard. Aaron -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org>" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org<mailto:dev-security-policy+unsubscr...@mozilla.org>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfpyPYrhu35fJ1nDGqeht%3D7Dyw8VZKzoMfVvk%3DM3GyP1g%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfpyPYrhu35fJ1nDGqeht%3D7Dyw8VZKzoMfVvk%3DM3GyP1g%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org>" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org<mailto:dev-security-policy+unsubscr...@mozilla.org>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErekmR76rbFvjyPQK7z85QbPQHynszFSN8tee48B_XcO%2Bw%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErekmR76rbFvjyPQK7z85QbPQHynszFSN8tee48B_XcO%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SJ0PR14MB54893C685CE3AA5D6218A5BE83249%40SJ0PR14MB5489.namprd14.prod.outlook.com.
