> -Tim
>
>
>
> *From:* 'Aaron Gable' via dev-security-policy@mozilla.org <
> dev-security-policy@mozilla.org>
> *Sent:* Friday, October 14, 2022 3:44 PM
> *To:* Corey Bonnell
> *Cc:* Andrew Ayer ; 'Aaron Gable' via
> dev-security-policy@mozi
history, original intent, and proposed resolution.
-Tim
From: 'Aaron Gable' via dev-security-policy@mozilla.org
Sent: Friday, October 14, 2022 3:44 PM
To: Corey Bonnell
Cc: Andrew Ayer ; 'Aaron Gable' via
dev-security-policy@mozilla.org
Subject: Re: CRL partitioning and IDPs
On Fri, Oct 14, 2022 at 11:19 AM Corey Bonnell
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 thing
?
Thanks,
Corey
From: Aaron Gable
Sent: Wednesday, October 12, 2022 7:51 PM
To: Corey Bonnell
Cc: Andrew Ayer ; 'Aaron Gable' via
dev-security-policy@mozilla.org
Subject: Re: CRL partitioning and IDPs
On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell mailto:corey.bonn...@di
Cc: Corey Bonnell ; Andrew Ayer
; 'Aaron Gable' via dev-security-policy@mozilla.org
Subject: Re: CRL partitioning and IDPs
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
org>
> *Sent:* Friday, October 14, 2022 12:30 PM
> *To:* Corey Bonnell
> *Cc:* Andrew Ayer ; 'Aaron Gable' via
> dev-security-policy@mozilla.org
> *Subject:* Re: CRL partitioning and IDPs
>
>
>
> To ensure that future parties don't have to have this same disc
that’s generally best avoided.
-Tim
From: 'Aaron Gable' via dev-security-policy@mozilla.org
Sent: Friday, October 14, 2022 12:30 PM
To: Corey Bonnell
Cc: Andrew Ayer ; 'Aaron Gable' via
dev-security-policy@mozilla.org
Subject: Re: CRL partitioning and IDPs
To ensure that
Thanks Aaron, I’ll endorse.
> On Oct 14, 2022, at 9:30 AM, 'Aaron Gable' via
> dev-security-policy@mozilla.org 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 distributio
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 num
On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell
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. Howev
for CRL.
From: 'Clint Wilson' via dev-security-policy@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
la.org
Sent: 07 October 2022 18:45
To: Rob Stradling
Cc: 'Aaron Gable' via dev-security-policy@mozilla.org
; Corey Bonnell ;
Andrew Ayer
Subject: Re: CRL partitioning and IDPs
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments
an you expand upon how your interpretation would work in practice?
Thanks,
Corey
From: 'Aaron Gable' via dev-security-policy@mozilla.org
Sent: Wednesday, October 12, 2022 12:26 PM
To: Corey Bonnell
Cc: Andrew Ayer ; 'Aaron Gable' via
dev-security-policy@mozilla.org
Su
On Wed, Oct 12, 2022 at 7:07 AM Corey Bonnell
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:
d 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-security-policy@mozilla.org On
> Behalf Of Andrew Ayer
> Sent: Friday, Octob
here to the profile.
Thanks,
Corey
-Original Message-
From: dev-security-policy@mozilla.org On
Behalf Of Andrew Ayer
Sent: Friday, October 7, 2022 10:02 AM
To: Aaron Gable
Cc: 'Aaron Gable' via dev-security-policy@mozilla.org
; Corey Bonnell
Subject: Re: CRL partitioning and IDPs
ubject: Re: CRL partitioning and IDPs
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), b
On Fri, Oct 7, 2022 at 8:49 AM Rob Stradling 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 is
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-li
y also fall into a black hole.
From: 'Tim Hollebeek' via dev-security-policy@mozilla.org
Sent: 07 October 2022 17:30
To: Aaron Gable ; Corey Bonnell
Cc: dev-security-policy@mozilla.org
Subject: RE: CRL partitioning and IDPs
CAUTION: This email originated from outside of t
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 thi
7;Aaron Gable' via dev-security-policy@mozilla.org
; Corey Bonnell
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.
On Thu, 6 Oct 2022 1
On Thu, 6 Oct 2022 13:36:03 -0700
"'Aaron Gable' via dev-security-policy@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
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 r
On Thu, 6 Oct 2022 12:33:17 -0700
"'Aaron Gable' via dev-security-policy@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 immedia
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.
On Thu, Oct 6, 2022 at 12:15 PM Andrew Ayer wrote:
On Thu, 6 Oct 2022 11:32:50 -0700
"'Aaron Gable' via dev-security-policy@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
On Thu, Oct 6, 2022 at 10:09 AM 'Corey Bonnell' via
dev-security-policy@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 include
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, provi
29 matches
Mail list logo
