[Servercert-wg] Ballot proposal: require distributionPoint in sharded CRLs

[Wendy Brown - QT3LB-C]

So just to be clear, this change proposal is only trying to address the
ability of a browser relying on CRL disclosures in CCADB to be able to
ensure they have the complete set of CRLs disclosed there, not to address
the potential risk to any given revoked certificate not being seen as
revoked because the RP is looking at a CRL that does not have that
certificate in scope due to sharding?

Seems there may still be a residual small risk if a new CRL shard is
started before CCADB is updated any certificate that should be covered in
that new shard gets revoked prior to the CCADB update.  But maybe people
perceive that timing issue as too small to be a concern.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Fri, Oct 14, 2022 at 3:48 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> On Fri, Oct 14, 2022 at 12:34 PM Wendy Brown - QT3LB-C <
> wendy.brown at gsa.gov> wrote:
>
>> Just a question -
>> if a certificate that is being checked for revocation does not contain a
>> cDP, how will requiring iDP in the CRL assist in preventing a CRL
>> substitution attack? If you don't have the correct cDP for a given
>> certificate how will the iDP in that sharded CRL provide assurance that the
>> RP is looking at the correct CRL?
>>
>
> In the case of the CRLs disclosed in CCADB's JSON Array of Partitioned
> CRLs field, the relying party (e.g. Mozilla or Apple) can verify that the
> distributionPoint contained within the CRL matches the URL disclosed in
> CCADB.
>
> On Fri, Oct 14, 2022 at 11:14 AM Corey Bonnell <Corey.Bonnell at digicert.com>
> wrote:
>
>> I don’t believe the profiles ballot modifies section 7.2 at all, so there
>> should be no conflict in having a separate proposal.
>>
>
> The current profiles ballot lightly modifies Section 7.2.1 (
> https://github.com/cabforum/servercert/pull/373/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR3118),
> but not in a way that would lead to a merge conflict with this ballot.
>
> Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221014/9a67ce6a/attachment.html>