CRL partitioning and IDPs

[Corey Bonnell]

Hello,

As you all know, the new Apple and Mozilla policies for CAs to disclose the locations of CRL-based revocation information became effective this month. One of the options for CAs to provide this CRL-based revocation information is to provide a list of all CRL URLs, which when combined, provide a complete list of revoked certificates for the CRL issuer (CA) in the CCADB “JSON Array of Partitioned CRLs” field.

 

The issuance of partitioned CRLs is described in some detail in section 5.2.5 of RFC 5280 [1]. This section notes that CAs may partition CRLs any way they see fit. However, there is this requirement when partitioning CRLs:

 

“If the distributionPoint field is absent, the CRL MUST contain

   entries for all revoked unexpired certificates issued by the CRL

   issuer, if any, within the scope of the CRL.”

 

Although the wording could be improved, this passage is rather clear that the IDP extension with the distributionPoint field (which contains the URI of the CRL, in the WebPKI case) must be included if the CRL is partitioned.

 

X.509 08/2005 (which RFC 5280 profiles), section 8.6.2.2 is even clearer regarding the requirement to include the IDP extension in partitioned CRLs:

 

“If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer.”

 

Why does all this matter? Including the IDP extension not only aligns the CRL with the RFC 5280 profile, but also provides a security-critical function: it provides sufficient information to Relying Parties so that they can confirm they have retrieved the correct CRL and detect substitution attacks. Without the information carried in the IDP, an on-path attacker could substitute another CRL which doesn’t contain a serial number for a certificate that has been revoked, thus allowing the attacker to “hide” the revocation of a certificate. Given that the transport of these CRLs listed in CCADB is plaintext HTTP, such an attack would be feasible and would allow bad actors to tamper with the creation of the “compressed CRLs” that are generated by Apple, Mozilla, or other user agents. This security issue also has been raised several times on the IETF PKIX mailing list [2][3].

 

It does not appear that there is universal agreement or awareness on the above, based on some CCADB entries that were observed. Given this, I wanted to raise this topic for discussion to ensure that there is universal understanding of the requirements and expectations of Root Programs.

 

Thanks,

Corey

 

[1] https://www.rfc-editor.org/rfc/rfc5280#section-5.2.5

[2] https://mailarchive.ietf.org/arch/msg/pkix/sdBe9RXFcot9P23XPW-FiOvV2aM/

[3] https://mailarchive.ietf.org/arch/msg/pkix/qAQHDXOM_Y3xY3te-xR0e7lQLjM/

 

[Aaron Gable]

On Thu, Oct 6, 2022 at 10:09 AM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

 

Although the wording could be improved, this passage is rather clear that the IDP extension with the distributionPoint field (which contains the URI of the CRL, in the WebPKI case) must be included if the CRL is partitioned.

 While I agree with the analysis of the security risk in the historical usage of CRL URLs embedded in certificates, I do not agree with the above interpretation of RFC 5280 and do not believe that the security analysis applies in the modern context of CRL URLs consumed by root programs from CCADB.

(Full disclosure: Let's Encrypt does not currently include the Issuing Distribution Point extension, and therefore does not include its distributionPoint field, in its CRLs. This is because we conducted the analysis laid out below and came to the conclusion that it is not required.)

As Corey quoted, RFC 5280 Section 5.2.5 says that the CRL must cover "all revoked unexpired certificates... within the scope of the CRL". Section 5 defines the scope of a CRL:

>   Each CRL has a particular scope.  The CRL scope is the set of

>   certificates that could appear on a given CRL.  For example, the
>   scope could be "all certificates issued by CA X", "all CA
>   certificates issued by CA X", "all certificates issued by CA X that
>   have been revoked for reasons of key compromise and CA compromise",
>   or a set of certificates based on arbitrary local information, such
>   as "all certificates issued to the NIST employees located in
>   Boulder".

It's clear from this definition that a scope is not required to be something representable within the fields of the CRL itself (e.g. "employees in Boulder"), nor something representable within the fields of the certificate itself (e.g. "revoked for reason X"). The Let's Encrypt CRL shards have the scope "all certificates issued by CA X with notAfter timestamps between Y and Z". This is a fairly straightforward scope. Since the CRLs do contain entries for all revoked unexpired certificates within that scope, they are not required to contain the distributionPoint field, as per RFC 5280 Section 5.2.5.

The argument that the distributionPoint field should be present anyway due to the protection it provides against replacement attacks was compelling in the time when CRL URLs were included in certificates and fetched directly by clients. But it does not apply when the CRLs are only intended for consumption by root programs and researchers who are downloading the full collection of CRL shards disclosed in CCADB. An on-path attacker can only replace a CRL shard with another CRL shard issued by the same issuer, which was valid for some particular scope at some particular time (perhaps in the past). A client downloading the full collection of CRL shards can check the thisUpdate timestamps to ensure it is not receiving old data, and can check for duplicate shards to ensure it doesn't receive the same shard twice. As long as they download the correct expected number of sufficiently-recent shards, there are no duplicates, and all signatures validate, they can be confident that none of the shards have been replaced.

If we want to make the IDP extension and its distributionPoint field to be mandatory for all sharded CRLs, that makes plenty of sense and is fine by me. I think it is totally reasonable to conclude that RFC 5280's "within the scope of the CRL" language is a bug. As Rob Stradling said in the IETF mail thread Corey linked[1]: "Time for a defect report for RFC5280?". But today (11 years later!) the text is still there, and clearly means that a CRL which covers all certificates within its scope does not need an IDP extension.

Aaron

[1] https://mailarchive.ietf.org/arch/msg/pkix/X2EjIzHz7ZqxhlX4M_GfZFku6Xw/

[Andrew Ayer]

On Thu, 6 Oct 2022 11:32:50 -0700
"'Aaron Gable' via dev-secur...@mozilla.org"

<dev-secur...@mozilla.org> wrote:

> A client downloading the full collection of CRL shards can check the
> thisUpdate timestamps to ensure it is not receiving old data, and can
> check for duplicate shards to ensure it doesn't receive the same
> shard twice. As long as they download the correct expected number of
> sufficiently-recent shards, there are no duplicates, and all
> signatures validate, they can be confident that none of the shards
> have been replaced.

Could you elaborate on your proposed logic, in particular how a client
would determine whether a shard is "sufficiently-recent"? Let's say a
client considers anything less than 24 hours old to be
"sufficiently-recent" but a CA reissues CRLs every 12 hours. Then an
attacker would always be able to replace the shard they want to hide
with an older but still sufficiently-recent version of a different
shard.

Regards,
Andrew

[Aaron Gable]

An older but still sufficiently-recent version of a different shard would contain serials which also appear on the current version of that same different shard. These duplicate serials would immediately indicate that a substitution has occurred.

[Andrew Ayer]

On Thu, 6 Oct 2022 12:33:17 -0700

"'Aaron Gable' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

> An older but still sufficiently-recent version of a different shard
> would contain serials which also appear on the current version of
> that same different shard. These duplicate serials would immediately
> indicate that a substitution has occurred.

What if the shard is empty?

Regards,
Andrew

[Aaron Gable]

Ah, that's a good point!

In Let's Encrypt's particular case, we guarantee that all of our CRL shards in a given "generation" share the same CRL Number, so detecting one shard substituted from a previous generation would be very easy. But I recognize that doing so is not required and could not be relied upon in the general case.

Aaron

[Andrew Ayer]

On Thu, 6 Oct 2022 13:36:03 -0700

"'Aaron Gable' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

> Ah, that's a good point!
>
> In Let's Encrypt's particular case, we guarantee that all of our CRL
> shards in a given "generation" share the same CRL Number, so
> detecting one shard substituted from a previous generation would be
> very easy. But I recognize that doing so is not required and could
> not be relied upon in the general case.

Right. I'm not seeing any way for a client to avoid the attack
described by Corey without making assumptions about the CA's practices
which might not be true in all cases.

So I have to concur with Corey that there is currently a security issue
which would allow attackers to tamper with Apple and Mozilla revocation
systems.

A simple fix would be to require that CAs use HTTPS URLs for CRL
shards, though this wouldn't be as strong as relying on indicators
within the CRL itself.

Regards,
Andrew

[Rob Stradling]

Aaron Gable wrote:

> (Full disclosure: Let's Encrypt does not currently include the Issuing Distribution Point extension, and therefore does not include its distributionPoint field, in its CRLs. This is because we conducted the analysis laid out below and came to the conclusion that it is not required.)

Hi Aaron.

Corey began this thread by appealing to RFC5280 and X.509, and I see that you rediscovered my rather ancient PKIX post [1] that pointed out that there's "nothing to stop an RFC5280-compliant CA from partitioning CRLs using arbitrary scopes and always omitting the IDP extension" due to a "defect" in the RFC5280 language.

Although this "defect" remains in RFC5280, ISTM that the original X.509 requirement is restored by MRSP section 5.2 [2], which says:

"CA operators MUST NOT issue ... partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension"

Does this observation cause you to rethink your conclusion?

[1] https://mailarchive.ietf.org/arch/msg/pkix/X2EjIzHz7ZqxhlX4M_GfZFku6Xw/

[2] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices:~:text=CA%20operators%20MUST%20NOT,a%20critical%20issuingDistributionPoint%20extension).

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Andrew Ayer <ag...@andrewayer.name>
Sent: 07 October 2022 15:01
To: Aaron Gable <aa...@letsencrypt.org>
Cc: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Corey Bonnell <Corey....@digicert.com>
Subject: Re: CRL partitioning and IDPs

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F20221007100135.dbb57df7c258081cac2953f1%2540andrewayer.name&amp;data=05%7C01%7Crob%40sectigo.com%7C2b6603bb81ae4881fd1c08daa86c78e0%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638007481084138290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=wxvk2aikAMdS%2BKo4yOkkce73iGMrgATyEz%2BzKXvnWQo%3D&amp;reserved=0.

[Tim Hollebeek]

If you think there is a bug in RFC 5280, please file an errata and let the IETF process take care of it, instead of coming to your own independent conclusion.

 

-Tim

[Rob Stradling]

Hi Tim.  That's the theoretically correct process, but...

Is filing an erratum actually worth the effort?

I filed a bunch of errata against RFC8555 (ACME) several years ago (https://www.rfc-editor.org/errata_search.php?rfc=8555&rec_status=0), but despite several attempts (on-list requests, private messages to doc authors, and private messages to A-Ds) I have been unable to persuade anyone to even begin the "IETF process" that should "take care of it".

Given that experience, ISTM that an erratum filed against RFC5280 would probably also fall into a black hole.

---

From: 'Tim Hollebeek' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: 07 October 2022 17:30
To: Aaron Gable <aa...@letsencrypt.org>; Corey Bonnell <Corey....@digicert.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: RE: CRL partitioning and IDPs

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

If you think there is a bug in RFC 5280, please file an errata and let the IETF process take care of it, instead of coming to your own independent conclusion.

 

-Tim

 

I think it is totally reasonable to conclude that RFC 5280's "within the scope of the CRL" language is a bug.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SJ0PR14MB5489EFE496E0ABE381BA6607835F9%40SJ0PR14MB5489.namprd14.prod.outlook.com.

[Job Snijders]

Dear fellow X.509 aficionados,

I'd like to share some observations and an idea from a PKIX sibling of
the WebPKI used for Internet routing security. Technical innovation
should of course follow the IETF process; I'm sending this message here
to offer myself as a point of contact for further off-list discussion
with interested parties.

On Fri, Oct 07, 2022 at 10:01:35AM -0400, Andrew Ayer wrote:
> Right. I'm not seeing any way for a client to avoid the attack
> described by Corey without making assumptions about the CA's practices
> which might not be true in all cases.
>
> So I have to concur with Corey that there is currently a security
> issue which would allow attackers to tamper with Apple and Mozilla
> revocation systems.
>
> A simple fix would be to require that CAs use HTTPS URLs for CRL
> shards, though this wouldn't be as strong as relying on indicators
> within the CRL itself.

The issue at hand appears to be similar to some challenges the Resource
Public Key Infrastructure (RPKI) community faced when designing the
foundation for a Secure Internet Routing architecture [RFC6480].

[ crash course: The RPKI is a constellation of Trust Anchors (root
certs, aka unconstrained CAs), regular CAs (each more narrowly
constrained following hierarchical IP & AS resource delegations),
CRLs, and lots of Signed Objects (containers carrying EE certificates
and payloads relevant to BGP routing). A key point here is that the
distribution of RPKI data from CAs towards Relying Parties solely
relies on object security, not transport security like HTTPS. ]

Some risks were identified at the time: (1) RPs must be able to verify
they have the complete set of files in hand the CA intended them to
have; (2) none of the files were tampered with mid-flight; (3) the RP is
not falling victim to replay attacks of previously valid data.

To mitigate the above risks, the concept of "Manifests" was introduced.
A RPKI Manifest [RFC9286] is a Cryptographic Message Syntax (CMS)
protected content type which carries as payload a monotonically
increasing value (manifestNumber) and a listing of pairs of a file name
and SHA-256 message digests calculated over the file's contents. Each
Manifest listing contains the filename of a CRL and the SHA-256 of that
CRL file.

As a certificate can list multiple CRL Distribution Point URLs (pointing
to shards), the WebPKI RP can establish there is a set of files to
consider, and for each file can verify the issuer signature; but cannot
verify whether each file within the set is the most current one, (or
whether the set of files are coherent from a versioning perspective).

On the other hand, RPKI RPs are 'better off' in this regard: they can
compare whether the newly fetched Manifest has a higher manifestNumber
than the (previously fetched, locally cached) Manifest, and each
manifestNumber corresponds to a list of SHA-256 hashes; making for a
great mechanism to robustly deal with distribution bundles of files.

Perhaps a bit of glue is missing in this ecosystem if there are concerns
about replay attacks (or more innocently phrased 'caching decoherence'),
and CRL sharding? Maybe researchers & auditors would benefit from a
RPKI-Manifest-like extension to the products generated by the likes of
Boulder?

I'm happy to share what I know (having authored a few internet-drafts
and some experience implementing RPKI RP software). Perhaps there is an
opportunity here to do better than 'just put the files on HTTPS'! :-)

Kind regards,

Job

[Aaron Gable]

On Fri, Oct 7, 2022 at 8:49 AM Rob Stradling <r...@sectigo.com> wrote:

Although this "defect" remains in RFC5280, ISTM that the original X.509 requirement is restored by MRSP section 5.2 [2], which says:

"CA operators MUST NOT issue ... partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension"

Does this observation cause you to rethink your conclusion?

I had read that requirement differently, as "MUST NOT issue CRLs that have a critical issuingDistributionPoint extension that does not have a distributionPoint field". My reading bound the verb "lack" to the noun "distributionPoint", rather than to the noun phrase "distributionPoint in a critical issuingDistributionPoint extension". I think the appropriate text to convey the intended requirement here would be "partial/scoped CRLs which lack a critical issuingDistributionPoint extension with the distributionPoint field".

It's of course also unfortunate that it picks as an example something that is not clearly laid out by RFC 5280; examples should be drawn from the underlying source, not laid on top of it.

But I agree that there's a reasonable reading which arrives at your interpretation, and we have already decided to begin including the issuingDistributionPoint in our CRLs in the near future in order to prevent replacement attacks.

Aaron

[Tim Hollebeek]

As you correctly point out, IETF processes differ significantly from WG to WG, and occasionally IETF doesn’t live up to the standards it claims to uphold, for various reasons.  I haven’t been closely following your experiences with ACME, but I apologize if you feel that they were not handled to your satisfaction, and if I can help with that in any way with that I’m willing to do so.

 

If people feel that filing errata is not worth their time, that is their choice to make.  However, even if the errata is never incorporated into an update, it’s still useful documentation to have.  For example, the 6844 errata were even referenced in the BRs long before they ever got put into 6844-bis.  Many of the IETF RFCs (including RFC 5280!) have published errata that are quite useful.

 

I happen to know that both of the LAMPS chairs (I’m one) are pretty familiar with RFC 5280, and if there are important errors to call out, we’d certainly be interested in seeing that done.  It’s an important RFC.

 

I’m dancing around the merits, because I don’t want to comment on a topic that might come to LAMPS in the near future, but I do want to reiterate, if you think that there is something wrong with RFC 5280, I’d appreciate if people would file errata, and we can take things from there.

 

-Tim

 

From: 'Rob Stradling' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Friday, October 7, 2022 1:13 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: dev-secur...@mozilla.org; Aaron Gable <aa...@letsencrypt.org>; Corey Bonnell <Corey....@digicert.com>
Subject: Re: CRL partitioning and IDPs

 

Hi Tim.  That's the theoretically correct process, but...

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729F3A7356AEBD37C087047AA5F9%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Corey Bonnell]

> A simple fix would be to require that CAs use HTTPS URLs for CRL shards,
> though this wouldn't be as strong as relying on indicators within the CRL
> itself.

I believe including the IDP is the better solution, for three reasons:

Firstly, compromise of the web server/CDN serving the sharded CRLs would allow
an attacker to carry out the substitution attack described in this thread,
whereas the use of IDP would require the attacker to compromise the CA's
signing infrastructure to suppress the inclusion of the extension. Thus, there
is a different level of security in the two approaches.

Secondly, using HTTPS for transport raises the possibility of recursive
revocation lookups, depending on the certificate chain employed.

Lastly, the inclusion of the IDP extension and distributionPoint field in
sub-scoped CRLs is a requirement of RFC 5280 and X.509 and thus must be
unconditionally included (it is a deviation of the profile to omit it). Given
that the inclusion of the IDP is the standard mechanism to prevent exactly the
attack described in this thread, it should be employed here as opposed to
layering hacky fixes on top of CRLs that do not adhere to the profile.

Thanks,
Corey

-----Original Message-----
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On
Behalf Of Andrew Ayer
Sent: Friday, October 7, 2022 10:02 AM
To: Aaron Gable <aa...@letsencrypt.org>

Cc: 'Aaron Gable' via dev-secur...@mozilla.org
<dev-secur...@mozilla.org>; Corey Bonnell <Corey....@digicert.com>
Subject: Re: CRL partitioning and IDPs

--
You received this message because you are subscribed to the Google Groups
"dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to dev-security-po...@mozilla.org.
To view this discussion on the web visit

https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221007100135.dbb57df7c258081cac2953f1%40andrewayer.name.

[Clint Wilson]

I'm in agreement with Corey here. The IDP URL must be present in sharded CRLs (i.e. if a CRL is not a complete CRL for the entire CA). I'm also inclined to say HTTPS must not be used here. There are cases where it could work, others where it could cause issues, but overall I don't believe it brings sufficient benefit to be worth outlining the allowance.
Further, it's probably worth noting that CRL URL(s) referenced only in the CCADB JSON array should match the IDP URL(s).

Cheers,
Clint

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186663D6051018A3B789B4B92229%40DM6PR14MB2186.namprd14.prod.outlook.com.

[Aaron Gable]

On Wed, Oct 12, 2022 at 7:07 AM Corey Bonnell <Corey....@digicert.com> wrote:

> A simple fix would be to require that CAs use HTTPS URLs for CRL shards,
> though this wouldn't be as strong as relying on indicators within the CRL
> itself.

I believe including the IDP is the better solution, for three reasons:

Definitely agreed, I've been convinced by this thread that including the IDP is the right thing to do.

 

Firstly, compromise of the web server/CDN serving the sharded CRLs would allow
an attacker to carry out the substitution attack described in this thread,
whereas the use of IDP would require the attacker to compromise the CA's
signing infrastructure to suppress the inclusion of the extension. Thus, there
is a different level of security in the two approaches.

Secondly, using HTTPS for transport raises the possibility of recursive
revocation lookups, depending on the certificate chain employed.

Lastly, the inclusion of the IDP extension and distributionPoint field in
sub-scoped CRLs is a requirement of RFC 5280 and X.509 and thus must be
unconditionally included (it is a deviation of the profile to omit it). Given
that the inclusion of the IDP is the standard mechanism to prevent exactly the
attack described in this thread, it should be employed here as opposed to
layering hacky fixes on top of CRLs that do not adhere to the profile.

But no, including the distributionPoint is absolutely not required by RFC 5280 as long as the CRL includes all revoked unexpired certificates within its scope. It is not even required by the Mozilla Root Store Policy, as long as there is no critical IssuingDistributionPoint extension in the CRL. It is required by X.509, but the whole point of RFC 5280 is that it defines what portions of X.509 apply to the Web PKI; it does not include that requirement from X.509. These may be oversights or mistakes, and I agree they should be changed, but we try very hard to separate intent from actual requirements here.

Aaron

 

[Corey Bonnell]

Hi Aaron,

 

> But no, including the distributionPoint is absolutely not required by RFC 5280 as long as the CRL includes all revoked unexpired certificates within its scope. It is not even required by the Mozilla Root Store Policy, as long as there is no critical IssuingDistributionPoint extension in the CRL. It is required by X.509, but the whole point of RFC 5280 is that it defines what portions of X.509 apply to the Web PKI; it does not include that requirement from X.509. These may be oversights or mistakes, and I agree they should be changed, but we try very hard to separate intent from actual requirements here.

 

I’ll quote the relevant passage from RFC 5280 again here for easy reference:

 

“If the distributionPoint field is absent, the CRL MUST contain

   entries for all revoked unexpired certificates issued by the CRL

   issuer, if any, within the scope of the CRL”

 

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.

 

Can you expand upon how your interpretation would work in practice?

 

Thanks,

Corey

 

From: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Wednesday, October 12, 2022 12:26 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Andrew Ayer <ag...@andrewayer.name>; 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: CRL partitioning and IDPs

 

On Wed, Oct 12, 2022 at 7:07 AM Corey Bonnell <Corey....@digicert.com> wrote:

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEreuC0JKJo5kOjaYqgPB9zS8xgeM3j0afJ_HcQmkx%3DsEUA%40mail.gmail.com.

[Rob Stradling]

FWIW, I'm confident that my reading is what was intended when this sentence was added to the MRSP, because I recall some of the events that led to that language being proposed.  It's very unfortunate that an alternative interpretation is possible, and that there don't seem to be any Incident bugs dating back to previous occasions that CAs were found to be omitting IDP in partial CRLs, and that RFC5280 bungled X.509's requirement that IDP must be present in all partial CRLs.

---

From: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: 07 October 2022 18:45
To: Rob Stradling <r...@sectigo.com>
Cc: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Corey Bonnell <Corey....@digicert.com>; Andrew Ayer <ag...@andrewayer.name>

Subject: Re: CRL partitioning and IDPs

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdZnuDo2%2BUtsY8q_8YBCYUKpojPdbrkEWboDqUMjH1rWw%40mail.gmail.com.

[Rob Stradling]

> I'm also inclined to say HTTPS must not be used here.

I just went through the same thought process regarding the Full CRL field (see https://bugzilla.mozilla.org/show_bug.cgi?id=1794899#c1).  It turns out that several CAs are currently using HTTPS URLs for CRL.

---

From: 'Clint Wilson' via dev-secur...@mozilla.org
Sent: Wednesday, October 12, 2022 17:25
To: Corey Bonnell
Cc: Andrew Ayer; Aaron Gable; MDSP

Subject: Re: CRL partitioning and IDPs

I'm in agreement with Corey here. The IDP URL must be present in sharded CRLs (i.e. if a CRL is not a complete CRL for the entire CA). I'm also inclined to say HTTPS must not be used here. There are cases where it could work, others where it could cause issues, but overall I don't believe it brings sufficient benefit to be worth outlining the allowance.
Further, it's probably worth noting that CRL URL(s) referenced only in the CCADB JSON array should match the IDP URL(s).

Cheers,
Clint

> On Oct 12, 2022, at 7:07 AM, 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
>
>> A simple fix would be to require that CAs use HTTPS URLs for CRL shards,
>> though this wouldn't be as strong as relying on indicators within the CRL
>> itself.
>
> I believe including the IDP is the better solution, for three reasons:
>

> Firstly, compromise of the web server/CDN serving the sharded CRLs would allow
> an attacker to carry out the substitution attack described in this thread,
> whereas the use of IDP would require the attacker to compromise the CA's
> signing infrastructure to suppress the inclusion of the extension. Thus, there
> is a different level of security in the two approaches.
>
> Secondly, using HTTPS for transport raises the possibility of recursive
> revocation lookups, depending on the certificate chain employed.
>
> Lastly, the inclusion of the IDP extension and distributionPoint field in
> sub-scoped CRLs is a requirement of RFC 5280 and X.509 and thus must be
> unconditionally included (it is a deviation of the profile to omit it). Given
> that the inclusion of the IDP is the standard mechanism to prevent exactly the
> attack described in this thread, it should be employed here as opposed to
> layering hacky fixes on top of CRLs that do not adhere to the profile.
>

> Thanks,
> Corey
>
> -----Original Message-----
> From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On
> Behalf Of Andrew Ayer
> Sent: Friday, October 7, 2022 10:02 AM
> To: Aaron Gable <aa...@letsencrypt.org>

> Cc: 'Aaron Gable' via dev-secur...@mozilla.org
> <dev-secur...@mozilla.org>; Corey Bonnell <Corey....@digicert.com>
> Subject: Re: CRL partitioning and IDPs
>

> On Thu, 6 Oct 2022 13:36:03 -0700

> "'Aaron Gable' via dev-secur...@mozilla.org"

> <dev-secur...@mozilla.org> wrote:
>
>> Ah, that's a good point!
>>
>> In Let's Encrypt's particular case, we guarantee that all of our CRL
>> shards in a given "generation" share the same CRL Number, so detecting
>> one shard substituted from a previous generation would be very easy.
>> But I recognize that doing so is not required and could not be relied
>> upon in the general case.
>
> Right.  I'm not seeing any way for a client to avoid the attack described by
> Corey without making assumptions about the CA's practices which might not be
> true in all cases.
>
> So I have to concur with Corey that there is currently a security issue which
> would allow attackers to tamper with Apple and Mozilla revocation systems.
>

> A simple fix would be to require that CAs use HTTPS URLs for CRL shards,
> though this wouldn't be as strong as relying on indicators within the CRL
> itself.
>

> Regards,
> Andrew

>
> --
> You received this message because you are subscribed to the Google Groups
> "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-po...@mozilla.org.
> To view this discussion on the web visit

> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221007100135.dbb57df7c258081cac2953f1%40andrewayer.name.

>
> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186663D6051018A3B789B4B92229%40DM6PR14MB2186.namprd14.prod.outlook.com.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/71AA3CBA-C335-4BB8-8D3F-34588615CFA0%40apple.com.

[Aaron Gable]

On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell <Corey....@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

[Aaron Gable]

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

[Clint Wilson]

Thanks Aaron, I’ll endorse.

-- 
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.

[Tim Hollebeek]

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 1^st 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-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Friday, October 14, 2022 12:30 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Andrew Ayer <ag...@andrewayer.name>; 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@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:

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.

[Aaron Gable]

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

[Tim Hollebeek]

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 1^st being bad to help out other people who might be affected.

 

I have previously noted that the 15^th day of odd months tends to dodge most holidays (e.g. Jan 15^th or Mar 15^th), 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-secur...@mozilla.org <dev-secur...@mozilla.org>

Sent: Friday, October 14, 2022 1:07 PM
To: Tim Hollebeek <tim.ho...@digicert.com>

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.

[Corey Bonnell]

Hi Aaron,

I had a draft reply written up to better explain my interpretation but deleted it since I think the CABF ballot is a more constructive path forward on this issue.

 

Are you also considering filing an erratum against 5280 so this particular PKI footgun can be addressed at the IETF?

 

Thanks,

Corey

 

 

From: Aaron Gable <aa...@letsencrypt.org>
Sent: Wednesday, October 12, 2022 7:51 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Andrew Ayer <ag...@andrewayer.name>; 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: CRL partitioning and IDPs

 

On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell <Corey....@digicert.com> wrote:

[Aaron Gable]

On Fri, Oct 14, 2022 at 11:19 AM Corey Bonnell <Corey....@digicert.com> wrote:

Are you also considering filing an erratum against 5280 so this particular PKI footgun can be addressed at the IETF?

Thank you for the reminder! I have done so just now. I'm not sure how long that process will take to work through things, nor what all the steps in that process are, but it has at least started.

I proposed a simple diff, removing only the trailing words "if any, within the scope of the CRL" from the requirement in section 5.2.5, bringing that sentence's structure in line with the corresponding text in X.509 (08/2005) Section 8.6.2.2.

Aaron

[Tim Hollebeek]

More information about the process: https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

 

Thanks for filing it.  I’m actually curious to see where the discussion goes, and what the people who were around at the time (including the author) have to say about the history, original intent, and proposed resolution.

 

-Tim

 

From: 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Sent: Friday, October 14, 2022 3:44 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Andrew Ayer <ag...@andrewayer.name>; 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: CRL partitioning and IDPs

 

On Fri, Oct 14, 2022 at 11:19 AM Corey Bonnell <Corey....@digicert.com> wrote:

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErd1g11zCEMnMHbSQf2n1o5GUm5A%2BGa4H93c05%2B3bAuJnA%40mail.gmail.com.

[Aaron Gable]

Interested parties can follow the discussion regarding the errata here: https://mailarchive.ietf.org/arch/msg/pkix/-Z00K5As5WN37pnyoIRvm7mNPRY/