I disagree - 24 hours is enough to reissue the certificate, but  24 hours 
usually isn't enough to contact the subscriber, regardless of cert type. 

-----Original Message-----
From: dev-security-policy 
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm <jb-mozi...@wisemo.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given 
that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have such 
certificates revoked in 24 hours. If the subscriber's selection of certificate 
type (e.g. OV or EV) makes it difficult to replace, then that's a market choice 
they've made, given that it offers no objective security value over DV, and it 
being possible to replace that certificate with a DV certificate in a timely 

24 hours is enough for most subscribers to get a reissued certificate. I don't 
think we should speculate about what cost it is (that's between them and the 
CA) or their selection of validation type (of which, for objective security 
value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> 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.mozilla
>> .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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to