Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

2019-01-28 Thread Wayne Thayer via dev-security-policy 
Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186

The report discloses another misissuance that occurred during testing,
resulting in a serverAuth certificate with a duration of over 5 years.

On Sun, Jan 27, 2019 at 12:52 PM piotr.grabowski--- via dev-security-policy
 wrote:

> W dniu czwartek, 17 stycznia 2019 21:12:58 UTC+1 użytkownik Wayne Thayer
> napisał:
> > Hello Piotr,
> >
> > On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr 
> > wrote:
> >
> > > Hello Wayne,
> > >
> > >
> > >
> > > I am very sorry for the  delay. Please find below our answers to Ryan's
> > > questions. Regarding the question why we didn't report this misissuance
> > > of this 1 certificate as separate incident in my opinion it is still
> the
> > > same incident. I can create new incident if you want me to. Taking into
> > > account my email and Ryan's response I assumed it is not required to
> > > create separate incident for  misissuance of this 1 certificate.
> > >
> > >
> > > I am not so concerned about creating a new bug and/or a new email
> thread.
> > My concern is that you did not report the new misissuance even though you
> > appear to have known about it. Why was it not reported as part of the
> > existing incident, and what is being done to ensure that future
> > misissuances - either in relation to existing or new incidents - are
> > promptly reported?
> >
> > So our comments in blue:
> > >
> > >
> > > I don't think it's reasonable to push the problem to your CA software
> > > vendor.
> > >
> > > - We are not pushing the problem to CA software vendor. I have just
> tried
> > > to explain how it happened.
> > >
> > >
> > >
> > > If Verizon does not provide this support, what steps will your CA take?
> > >
> > > - We are almost sure that Verizon will provide at least policy field
> > > validation for maximum field size which can be sufficient to eliminate
> > > the last gap in our policy templates which in turn led us to
> misissuance
> > > of this certificate. If Verizon will not provide this feature we will
> be considering
> > > usage of another UniCERT component - ARM plug-in - which analyzes
> > > requests but this means custom development for us. It would be a big
> > > change in many processes and the challange to preserve current security
> > > state as well so this should be an absolute last resort.
> > >
> > >
> > > If you know what those steps are, is there reason not to take them
> now? If
> > > you do not know what those steps are, when will you know?
> > >
> > > The main reason why we are not taking these steps now (changing
> processes
> > > and custom development) is absolute conviction that the cost and the
> risk of
> > > implementing them is much, much higher that the risk related with
> waiting
> > > for that feature being delivered by vendor.  Just to recall, now we
> have
> > > the only gap which in the worst case can give us specific field in
> > > certificate longer than RFC specifies. Of course we are practicing due
> care
> > > and have put as much counter-measures as we can (procedure, labels
> above
> > > the fields).
> > >
> > >
> > >
> > > Your software is producing invalid and improper certificates. The
> > > responsibility for that ultimately falls on the CA, and understanding
> what
> > > steps the CA is taking to prevent that is critical. It appears that the
> > > steps, today, rely on human factors. As the past year of incident
> reports
> > > have shown, relying solely on human factors is not a reasonable
> practice.
> > >
> > > -I agree entirely with you, that's why we will keep exerting pressure
> on
> > > Verizon to deliver:
> > >
> > > o   Policy field size validation – in our opinion it is simple change
> request and should be delivered ASAP.
> > >
> > > o   native x509lint or zlint feature
> > >
> > >
> > >
> > When can we expect an update from you on Verizon's response to your
> > request? If I was the customer, I would expect a prompt response from
> > Verizon.
>
> I have response from Verizon that they will send us a patch containing some
> pre-issuance linting features on 03/02. By the way I kindly inform you
> that  I’m out of the office from 28/01 to 07/02 and will be responding to
> my emails when I return on 11/02.
>
> Regards
> Piotr Grabowski
>
> > > Regards ,
> > >
> > >
> > > Piotr Grabowski
> > > Linia biznesowa podpis elektroniczny
> > > Krajowa Izba Rozliczeniowa S.A.
> > > ul. rtm. W. Pileckiego 65
> > > 02-781 Warszawa
> > >
> > > Tel. +48 22 545 56 76
> > >
> > > Tel. +48 507 024 083
> > >
> > >
> > >
>
> ___
> 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

Re: misissued.com FYI

2019-01-28 Thread Eric Mill via dev-security-policy 
Would you consider tossing the backup in a zip file in an S3 bucket or
something, and sharing a link for the record here, for others finding this
in the future?

On Mon, Jan 28, 2019 at 10:05 AM Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi All,
>
> For anyone using https://misissued.com/ I wanted to provide a quick FYI
> about some database maintenance. The database was nearing its storage
> capacity limit, and so I deleted all certificates from it that had expired
> before 2019. The main consequence of this is that you can't use
> misissued.com as a complete historical record anymore.
>
> I captured a database backup before doing this, so if anyone does want that
> data, it hasn't been completely lost.
>
> Cheers,
> Alex
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

misissued.com FYI

2019-01-28 Thread Alex Gaynor via dev-security-policy 
Hi All,

For anyone using https://misissued.com/ I wanted to provide a quick FYI
about some database maintenance. The database was nearing its storage
capacity limit, and so I deleted all certificates from it that had expired
before 2019. The main consequence of this is that you can't use
misissued.com as a complete historical record anymore.

I captured a database backup before doing this, so if anyone does want that
data, it hasn't been completely lost.

Cheers,
Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy