RE: Misissuance/non-compliance remediation timelines

[James Burton via dev-security-policy]

The idea of a grading system being used to judge CAs compliance will be a total 
disaster. We should instead be focusing our efforts on more transparency.

James


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jb=0.me...@lists.mozilla.org] On Behalf Of 
Tim Hollebeek via dev-security-policy
Sent: 07 February 2018 16:11
To: Alex Gaynor 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Paul Kehrer 

Subject: RE: Misissuance/non-compliance remediation timelines

Alex,

 

Most CAs probably wouldn’t aim for an A.  I don’t think doing this would be a 
game changer.

 

However there are some CAs that would.  And I think that would be a positive 
thing, and lead to more innovation in best practices that could become 
mandatory for everyone over time.

 

And I don’t disagree with you that action is needed on those who are currently 
getting Ds.  I’m very disturbed by the behavior of about half of the CAs in the 
industry.

 

-Tim

 

From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Wednesday, February 7, 2018 8:15 AM
To: Tim Hollebeek 
Cc: Paul Kehrer ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Misissuance/non-compliance remediation timelines

 

Hey Tim,

 

A piece I think I'm missing is what you see as the incentive for CAs to aim for 
an "A" rather than being happy to have a "B". It reminds me of the old joke: 
What do you call the Dr^W CA who graduated with a C average? Dr.^W trusted to 
assert www-wide identity :-)

 

That said, given the issues Paul highlighted in his original mail (which I 
wholeheartedly concur with), it seems the place to focus is the folks who are 
getting Ds right now. Therefore I think the essential part of your email is 
your agreement that CAs which are persistently low performing need to be 
recognized and potentially penalized for the sum total of their behaviors.

 

Alex

 

On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy 
 > wrote:

Paul,

I understand your frustration.  I've read some of the recent threads about "how 
long does it take to update a CPS?" and clearly there needs to be some stronger 
compliance language in either the BRs or Mozilla policy ("CAs MUST be able to 
update their CPS within 90 days").  And as you note such policies need to have 
teeth otherwise there will be some who will just ignore them.

However  negative penalties are not the only thing that should be considered.
Mozilla should also have some way of recognizing CAs that are performing above 
and beyond the minimum requirements.  I would love to see Mozilla encourage CAs 
to compete to be the best CA in Mozilla's program.

To satisfy both goals, I'd like to suggest an idea I've had for a while: at 
some point in time (annually?), Mozilla should assess their opinion of how well 
each CA in the program is performing, and give them a letter grade.  This could 
include policy improvements like "Two consecutive failing grades, or three 
consecutive C or lower grades and you're out of the Mozilla program."

This would not preclude other actions as Mozilla deems necessary.  But it would 
provide a regular checkpoint for CAs to understand either "Hey, you're great, 
keep up the good work!" or "Meh, we think you're ok." or "Your performance to 
date is unacceptable.  Get your sh*t together or you're gone."

-Tim


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
> 
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
> bounces+ ] On Behalf Of Paul
> Kehrer via dev-security-policy
> Sent: Tuesday, February 6, 2018 6:03 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> 
> Subject: Misissuance/non-compliance remediation timelines
>
> A bit over 5 months ago I reported a series of OCSP responders that 
> were violating BRs (section 4.9.10) by returning GOOD on unknown 
> serial
numbers.
> Since that time the majority of those responder endpoints have been 
> fixed,
but
> several are still non-compliant; either with little communication or
continuing
> assurances that it will be fixed "soon", where soon is a date that
continuously
> slides into the future.
>
> At the moment Mozilla possesses very few options when it comes to 
> punitive action and the lesson some CAs appear to be learning is that 
> as long as
you
> don't rise to PROCERT levels of malfeasance/incompetence then the 
> maximum penalty is censure on bugzilla and email threads. Clearly this 
> is not a
deterrent.
>
> So, how long is too long? At what point should a CA incur consequences
(and
> what form can those consequences take) for failure to remediate 
> despite
being
> given such immense latitude?
>
> 

Re: ccadb.org

[Kathleen Wilson via dev-security-policy]

On 1/30/18 6:19 AM, Gervase Markham wrote:

On 30/01/18 00:48, James Burton wrote:

I was doing research on the ccadb.org site and was surprised to find that
the site is running only in HTTP and is not using HTTPS. Now, I understand
that GitHub pages don't support HTTPS for custom domains but you could
always use CloudFlare for HTTPS support in the meantime until GitHub
enables HTTPS for custom domains.


The Cloudflare solution turns out not to be ideal for Mozilla IT. They
have instead proposed another solution using AWS and Nubis, which is
being implemented in the (infrastructure-confidential) bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 . I've pinged the
bug so hopefully something should happen soon.

Gerv




All,

At 6pm PST on Thursday, February 8th, we will begin the migration of 
ccadb.org to https.


It is possible that during this migration users may receive errors when 
trying to access the ccadb.org site.


Cheers,
Kathleen


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

RE: Misissuance/non-compliance remediation timelines

[Tim Hollebeek via dev-security-policy]

Alex,

 

Most CAs probably wouldn’t aim for an A.  I don’t think doing this would be a 
game changer.

 

However there are some CAs that would.  And I think that would be a positive 
thing, and lead to more innovation in best practices that could become 
mandatory for everyone over time.

 

And I don’t disagree with you that action is needed on those who are currently 
getting Ds.  I’m very disturbed by the behavior of about half of the CAs in the 
industry.

 

-Tim

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Wednesday, February 7, 2018 8:15 AM
To: Tim Hollebeek 
Cc: Paul Kehrer ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Misissuance/non-compliance remediation timelines

 

Hey Tim,

 

A piece I think I'm missing is what you see as the incentive for CAs to aim for 
an "A" rather than being happy to have a "B". It reminds me of the old joke: 
What do you call the Dr^W CA who graduated with a C average? Dr.^W trusted to 
assert www-wide identity :-)

 

That said, given the issues Paul highlighted in his original mail (which I 
wholeheartedly concur with), it seems the place to focus is the folks who are 
getting Ds right now. Therefore I think the essential part of your email is 
your agreement that CAs which are persistently low performing need to be 
recognized and potentially penalized for the sum total of their behaviors.

 

Alex

 

On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy 
 > wrote:

Paul,

I understand your frustration.  I've read some of the recent threads about
"how long does it take to update a CPS?" and clearly there needs to be
some stronger compliance language in either the BRs or Mozilla policy
("CAs MUST be able to update their CPS within 90 days").  And as you note
such policies need to have teeth otherwise there will be some who will
just ignore them.

However  negative penalties are not the only thing that should be
considered.
Mozilla should also have some way of recognizing CAs that are performing
above and beyond the minimum requirements.  I would love to see Mozilla
encourage CAs to compete to be the best CA in Mozilla's program.

To satisfy both goals, I'd like to suggest an idea I've had for a while: at
some
point in time (annually?), Mozilla should assess their opinion of how well
each CA in the program is performing, and give them a letter grade.  This
could include policy improvements like "Two consecutive failing grades,
or three consecutive C or lower grades and you're out of the Mozilla
program."

This would not preclude other actions as Mozilla deems necessary.  But it
would provide a regular checkpoint for CAs to understand either "Hey,
you're great, keep up the good work!" or "Meh, we think you're ok." or
"Your performance to date is unacceptable.  Get your sh*t together or
you're gone."

-Tim


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
>  
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
>  ] On Behalf Of Paul
> Kehrer via dev-security-policy
> Sent: Tuesday, February 6, 2018 6:03 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
>  
> Subject: Misissuance/non-compliance remediation timelines
>
> A bit over 5 months ago I reported a series of OCSP responders that were
> violating BRs (section 4.9.10) by returning GOOD on unknown serial
numbers.
> Since that time the majority of those responder endpoints have been fixed,
but
> several are still non-compliant; either with little communication or
continuing
> assurances that it will be fixed "soon", where soon is a date that
continuously
> slides into the future.
>
> At the moment Mozilla possesses very few options when it comes to punitive
> action and the lesson some CAs appear to be learning is that as long as
you
> don't rise to PROCERT levels of malfeasance/incompetence then the maximum
> penalty is censure on bugzilla and email threads. Clearly this is not a
deterrent.
>
> So, how long is too long? At what point should a CA incur consequences
(and
> what form can those consequences take) for failure to remediate despite
being
> given such immense latitude?
>
> As a straw man: what if we developed a set of technical constraints
related to
> minimizing risk associated with CAs that are deemed to be acting poorly?
> For example, CAs deemed a risk would have their certificate maximum
lifetime
> constrained to some amount less than the BRs currently allow.
> Additional penalties could include removal of EV trust indicators,
constraining
> trust to a limited set of domains, marking contexts as insecure, and
finally full
> distrust. Once a CA lands in a risk category further misissuance would
escalate
> their risk to the community and thus incur 

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

Hi Wyane,
resopnding to your notes:

Section 4.9 states that in any case that Comsign is notified about a 
misissuance (no matter if it was notified by a subscriber or in any other way) 
Comsign shall revoke the certificate.

It is true that we didn’t update the version number and we have corrected it. 
Along with updating the CPS version management table as well.

about the software we use for issuing certificate- As we commented on the 
January Communication we didn’t issue any SSL certificate in the last years at 
all – we do not plan to issue any SSL certificates in our current RSA software 
– only with our new one who is under audit now.
So, like we mentioned earlier we would like to be approved in advance so we 
could start issuing as soon as the new system will be in use.

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

RE: Misissuance/non-compliance remediation timelines

[Tim Hollebeek via dev-security-policy]

That’s pretty much exactly not what I said.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, February 6, 2018 10:38 PM
To: Tim Hollebeek 
Cc: Paul Kehrer ; 
mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com
Subject: Re: Misissuance/non-compliance remediation timelines

 

So your view is the “carrot” is getting to use Mozilla’s brand as an 
endorsement, and the “stick” being that if you don’t get that endorsement for a 
while, you get kicked out?

 

The assumption is that the branding of “best” is valuable - presumably, through 
the indirect benefit of being able to appeal to customers as “the highest rated 
(by Mozilla) CA”.

 

In practice, much like the CA/Browser Forum indirectly gave birth to the CA 
“Security” Council, or the existence of firms like Netcraft or NSS Labs, the 
more common outcome seems to be that if you don’t like the rules of the game 
you’re playing, you make up your own/redefine them and try to claim equivalency 
(much lol “alternative facts”). That is, I’m skeptical of approaches that 
attempt to say “most good,” because those seem to encourage all sorts of games 
of coming up with their own schemes, while “least bad” is more actionable - as 
“most bad” is more likely to receive sanctions.

 

On Tue, Feb 6, 2018 at 10:03 PM Tim Hollebeek via dev-security-policy 
 > wrote:

Absolutely not.  I view the competition as being based as the “most best”.



You cannot get an “A” (or even A- or B+) without significantly exceeding the 
minimum requirements, or demonstrating behaviors and practices that, while not 
required, are behaviors Mozilla wants to encourage.



Sticks are good.  Carrots are tasty.



-Tim



Do you see the competition based on being the 'least bad' (i.e. more likely to 
get an A because of no issues than a B because of some?)

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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy