On 11/08/2017 00:12, Ryan Sleevi wrote:
Could you explain how it benefits Mozilla users to optimize for OV or EV,
given that it does not provide any additional security value?


Of all the browsers I have tried, Firefox is the one that most
aggressively promotes EV certificates, going to the extent of displaying
unhelpful status messages ("This website does not supply ownership
information") for OV and DV certificates.

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

Note that I was considering the desirability of the subscriber switching
CAs in response to such events (others have argued for that in this
thread).  If the subscriber switches to a different CA, that CA has no
validation data on file.

Also, the way the BRs specify the validation data reuse period and the
maximum certificate validity period, they encourage the creation of
situations where certificates expire long after the validation data
reuse limit.  Some CAs go out of their way to avoid that, but it is not
a BR requirement.


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


The only cost consideration I mentioned was a strong suggestion that if
the original CA issues the replacement certificate, the CA should bear
the cost.


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

Reply via email to