This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
is about to be revoked (or because they want to shift which SCTs are
embedded, or to indicate an appropriate renewal period for short lived
certs, or... turns out there are a lot of use case!) and then automatically
revoke at the end of the defined period.

Hopefully something useful comes out of that :-)

Alex

On Thu, Aug 10, 2017 at 7:11 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Not really - most CAs reuse validation information for the time period
> specified under the BRs, which is currently 825 days under section 4.2.1.
> The hardest part of the whole process is typically contacting the customer
> to start the replacement process. The problem is probably worse for fully
> automated CAs who don't necessarily have a close relationship with the
> customer, perhaps only an email address that can be used to let them know
> their website is about to go down.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Thursday, August 10, 2017 3:40 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
>
> But that would require the issuer of the replacement cert (which might not
> be a fast-issue DV cert) to complete validation in something like 36 hours,
> which is much shorter than the normal time taken to do proper OV and/or EV
> validation.
>
> I have previously suggested 14 days for live certificates that don't cause
> actual security issues.  This would be enough for most subscribers to
> either
> get a reissued certificate (for free) from the original CA or set up an
> account with a competing CA and get at least a basic OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
> > No objection to 72 hours v. 1 business day.  I agree it should be
> > short and
> > 72 hours seems perfectly reasonable .
> >
> > -----Original Message-----
> > From: dev-security-policy
> > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> > ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
> > Sent: Wednesday, August 9, 2017 4:57 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Certificates with invalidly long serial numbers
> >
> > On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> >> All CAS are required to maintain the capability to process and
> >> receive
> > revocation requests 24x7 under the baseline requirements. The headache
> > is not with the CA. Rather, it's notifying the customer that their
> > certificate will be revoked before the start of the next business day.
> > Having a one to two business day rule  instead of 24 hours for non
> > compromise issues gives the end entity time to receive the
> > notification and replace their certificate with a compliant version.
> >
> > I'm sure many customers would absolutely prefer that and on the
> > surface it does sound like a good solution. However, I think it's
> > another example of the general difference of opinion between people on
> > this list around whether we should be holding CAs to the highest
> > standards or not. These mis-issued certificates are typically not a
> > security concern, but they speak to either ignorance on the part of CA
> > operators or a pattern of lackadaisical controls within the issuance
> > systems. Neither of these is acceptable behavior at this juncture.
> Conformance with the BRs has been mandatory for over 5 years now.
> > Customers need to be made aware of the failures of their chosen
> > providers and the responsibilities incumbent upon them as subscribers,
> > and if their own certificate installation/replacement processes are
> > sufficiently archaic as to make it difficult to replace a certificate
> > in an automated fashion then they should rectify that immediately.
> >
> > That said, to continue the thought experiment, what does "1-2 business
> days"
> > really mean?Does the CA get 1-2 business days followed by 1-2 for the
> > customer? What if there's a holiday in the CA's country of operations
> > followed by a holiday in the customer's home country? How quickly does
> > this window extend to 2+ weeks? If you were to go down this path I'd
> > strongly prefer it to be a hard deadline (e.g. 72 hours) and not
> > anything related to business days.
> >
>
>
> 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
>
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to