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 [email protected] <[email protected]> Sent: Friday, October 14, 2022 12:30 PM To: Corey Bonnell <[email protected]> Cc: Andrew Ayer <[email protected]>; 'Aaron Gable' via [email protected] <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell <[email protected]<mailto:[email protected]>> 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 "[email protected]<mailto:[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/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 "[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/SJ0PR14MB5489AFA5CC11B8FAD6F997AB83249%40SJ0PR14MB5489.namprd14.prod.outlook.com.
