On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote: > > On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> I believe that may be misunderstanding the concern. > >> > >> Once these certificates expire, there's not a good way to check whether > or > >> not they were revoked, because such revocation information may be culled > >> after certificate expiration. > >> > >> Similarly, if one is looking to verify the claims about revocation dates > >> and timelines, once those are culled from the CRLs, you can only > >> demonstrate with past CRLs or responses that may have been archived. > >> > >> The concern about December 6 represents when some of the certificates > begin > >> to expire, and thus being able to examine whether or not and when things > >> were done may no longer be available. > >> > > > > This is one of the reasons we also need revocation transparency. > > > > Or just a crt.sh enhancement to remember the previously collected > revocations. > > Unlike certificates, revocations are already published in signed CRLs > that auditing services can simply gather and store, along with some > timestamping of the fact that they were seen at a given time. > > The exception being Let's Encrypt, because they only provide OCSP. > > A secondary auditing process can statistically sample certificates > from CRLs and CT and check that the samples have the published OCSP > response, plus/minus an acceptable delay (policy dictated) between > updating of OCSP and CRL servers. > Of course this is also useful. Transparency, however, would prevent certain attacks that this does not. > > > > >> > >> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy < > >> dev-security-policy@lists.mozilla.org> wrote: > >> > >>> On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via > >>> dev-security-policy wrote: > >>>> I was under the impression that CAs were allowed to remove CRL entries > >>> and OCSP support for expired certificates for some reason. Good to > know! > >>> > >>> CT logs are not CRLs or OCSP responders, nor do they track revocation. > >>> > >>> - Matt > >>> > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
