Thanks Aaron, I’ll endorse. > On Oct 14, 2022, at 9:30 AM, 'Aaron Gable' via > [email protected] <[email protected]> wrote: > > 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 > <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]" 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/BDAD4891-FB72-4550-AE37-A77A40660F03%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
