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 <[email protected]> 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 [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]> wrote: > > On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell <[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]" 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/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/CAEmnErekmR76rbFvjyPQK7z85QbPQHynszFSN8tee48B_XcO%2Bw%40mail.gmail.com.
