Consider telco root store applications as high risk ?Thanks,M.D.Sent from my
Galaxy
Original message From: Ben Wilson Date:
10/13/22 04:04 (GMT+02:00) To: Michel Le Bihan
Cc: dev-security-policy@mozilla.org, "matt...@thisisntrocket.science"
, Matt Palmer Subject:
Re: Prot
All,
In the article, I saw advice about actions that project owners can take to
protect themselves, but what about things that CAs or root store programs
can or should do?
Ben
On Thu, Sep 29, 2022 at 12:16 AM Michel Le Bihan <
michel.lebihan2...@gmail.com> wrote:
> Recently there was another case
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
> 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.
___
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 bug
> I believe at least part of the problem Andrew mentions is because of
> Salesforce or some intermediary processing within CCADB tooling.
>
> I had pinged Andrew offline and he mentioned what he was seeing from our
> JSON was no "" around the URL, we have confirmed what we publish does have
>
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
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:
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 bri
> 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 C
10 matches
Mail list logo
