Certificates with metadata-only subject fields

496 views
Skip to first unread message

Jonathan Rudenberg

unread,
Aug 9, 2017, 12:08:40 PM8/9/17
to mozilla-dev-s...@lists.mozilla.org
Baseline Requirements section 7.1.4.2.2(j) says:

> All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

There are 522 unexpired unrevoked certificates known to CT issued after 2015-11-01 that are trusted by NSS for server authentication and have at least one subject field that only contains ASCII punctuation characters.

The full list can be found here: https://misissued.com/batch/5/

Since there are so many, I have included a list of the CCADB owner, intermediate commonName, and count of certificates for the 311 certificates in this batch that were issued in the last 365 days so that the relevant CAs can add the appropriate technical controls and policy to comply with this requirement in the future. Please let me know if there is any additional information that would be useful.

Jonathan



DigiCert (131)
Cybertrust Japan Public CA G3 (64)
DigiCert SHA2 Extended Validation Server CA (36)
DigiCert SHA2 High Assurance Server CA (12)
TERENA SSL CA 3 (7)
DigiCert SHA2 Secure Server CA (6)
Cybertrust Japan EV CA G2 (6)

GlobalSign (62)
GlobalSign Organization Validation CA - SHA256 - G2 (46)
GlobalSign Extended Validation CA - SHA256 - G2 (8)
GlobalSign Extended Validation CA - SHA256 - G3 (8)

Symantec / VeriSign (35)
Symantec Class 3 Secure Server CA - G4 (32)
Symantec Class 3 EV SSL CA - G3 (2)
Wells Fargo Certificate Authority WS1 (1)

Symantec / GeoTrust (34)
GeoTrust SSL CA - G3 (25)
GeoTrust SHA256 SSL CA (5)
RapidSSL SHA256 CA (2)
GeoTrust Extended Validation SHA256 SSL CA (2)

Comodo (19)
COMODO RSA Organization Validation Secure Server CA (11)
COMODO RSA Extended Validation Secure Server CA (8)

Symantec / Thawte (17)
thawte SSL CA - G2 (12)
thawte SHA256 SSL CA (3)
thawte EV SSL CA - G3 (2)

T-Systems International GmbH (Deutsche Telekom) (6)
Zertifizierungsstelle FH Duesseldorf - G02 (3)
TeleSec ServerPass Class 2 CA (2)
Helmholtz-Zentrum fuer Infektionsforschung (1)

QuoVadis (3)
QuoVadis EV SSL ICA G1 (2)
QuoVadis Global SSL ICA G2 (1)

SECOM Trust Systems Co. Ltd. (2)
NII Open Domain CA - G4 (2)

SwissSign AG (1)
SwissSign Server Gold CA 2014 - G22 (1)

Entrust (1)
Entrust Certification Authority - L1K (1)

Jeremy Rowley

unread,
Aug 9, 2017, 5:22:22 PM8/9/17
to Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
And this is exactly why we need separate tiers of revocation. Here, there is zero risk to the end user. I do think it should be fixed and remediated, but revoking all these certs within 24 hours seems unnecessarily harsh. I think there was a post about this a while ago, but I haven't been able to find it. If someone remembers where it was, I'd appreciate it.
Entrust Certification Authority - L1K (1) _______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Peter Bowen

unread,
Aug 9, 2017, 5:50:43 PM8/9/17
to Jeremy Rowley, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
The point of certlint was to help identify issues. While I appreciate
it getting broad usage, I don't think pushing for revocation of every
certificate that trips any of the Error level checks is productive.
This reminds of me of people trawling a database of known
vulnerabilities then reporting them to the vendors and asking for a
reward, which happens all too often in bug bounty programs.

I think it would be much more valuable to have a "score card" by CA
Operator that shows absolute defects and defect rate.

Thanks,
Peter

Jonathan Rudenberg

unread,
Aug 9, 2017, 5:55:11 PM8/9/17
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley

> On Aug 9, 2017, at 17:50, Peter Bowen <pzb...@gmail.com> wrote:
>
> The point of certlint was to help identify issues. While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.

I agree, and I don’t really have a position on the revocation of certificates with errors that do not appear to have any security impact like these.

Jonathan


David E. Ross

unread,
Aug 9, 2017, 6:35:29 PM8/9/17
to mozilla-dev-s...@lists.mozilla.org
I strongly disagree. Errors like this make me question whether the
certification authority is sufficiently competent to be trusted. Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross
<http://www.rossde.com/>

President Trump demands loyalty to himself from Republican members
of Congress. I always thought that members of Congress -- House
and Senate -- were required to be loyal to the people of the
United States. In any case, they all swore an oath of office
to be loyal to the Constitution.

Jonathan Rudenberg

unread,
Aug 9, 2017, 7:01:04 PM8/9/17
to David E. Ross, mozilla-dev-s...@lists.mozilla.org

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>>
> I strongly disagree. Errors like this make me question whether the
> certification authority is sufficiently competent to be trusted. Small
> errors can indicate an increased likelihood of serious errors.

I’m not saying the errors are okay. They aren’t. All I’m saying is that for this batch I’m not requesting revocation directly from CAs using their problem reporting contact details, as I’ve done with other more serious issues.

Jonathan

Ryan Sleevi

unread,
Aug 9, 2017, 8:37:21 PM8/9/17
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> The point of certlint was to help identify issues. While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.
> This reminds of me of people trawling a database of known
> vulnerabilities then reporting them to the vendors and asking for a
> reward, which happens all too often in bug bounty programs.
>
> I think it would be much more valuable to have a "score card" by CA
> Operator that shows absolute defects and defect rate.

In one of the few times I think it's happened, I think I disagree with you, Peter.

I appreciate the perspective that revocation of these certificates externalizes the cost of misissuance from the CA (responsible for it) onto the customer (who purchased the certificate), and thus a viewpoint that suggests this is somehow unjust (since it's the victim of misissuance who suffers), but I think an argument that suggests these shouldn't be revoked is similar to an argument that says those who purchased stolen merchandise should get to keep it, as long as they didn't know it was stolen.

That is, if we look at it from a lens of incentives, CAs have little incentive to properly issue the certificates if the consequence of misissuance is not an immediate result, but one of potential future action. Sadly, humans are terrible at recognizing those potential long-term costs (c.f. obesity/heart disease/dental care/global warming as all examples of long-term costs with short-term benefits).

While I don't disagree we should keep a scoreboard, I think it's also the right incentive - for CAs, and the overall ecosystem - to ensure that any misissuance is revoked in a timely fashion (which is currently 24 hours), because it helps encourage a market where the best step a CA can take to minimize risk to their subscribers, the ones actually paying them money and engaging in a business relationship with them, is to simply not misissue the certificates.

Alex Gaynor

unread,
Aug 10, 2017, 9:20:10 AM8/10/17
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these
non-compliant certs to be issued, and I expect them to send post-portems to
mdsp explaining what the root cause for these issues was and how they
corrected it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues. While I appreciate
> > it getting broad usage, I don't think pushing for revocation of every
> > certificate that trips any of the Error level checks is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it) onto
> the customer (who purchased the certificate), and thus a viewpoint that
> suggests this is somehow unjust (since it's the victim of misissuance who
> suffers), but I think an argument that suggests these shouldn't be revoked
> is similar to an argument that says those who purchased stolen merchandise
> should get to keep it, as long as they didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future action.
> Sadly, humans are terrible at recognizing those potential long-term costs
> (c.f. obesity/heart disease/dental care/global warming as all examples of
> long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also the
> right incentive - for CAs, and the overall ecosystem - to ensure that any
> misissuance is revoked in a timely fashion (which is currently 24 hours),
> because it helps encourage a market where the best step a CA can take to
> minimize risk to their subscribers, the ones actually paying them money and
> engaging in a business relationship with them, is to simply not misissue
> the certificates.

Jeremy Rowley

unread,
Aug 10, 2017, 2:18:19 PM8/10/17
to David E. Ross, mozilla-dev-s...@lists.mozilla.org
I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise. If there are bigger issues, let's find those.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
I strongly disagree. Errors like this make me question whether the
certification authority is sufficiently competent to be trusted. Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross
<http://www.rossde.com/>

President Trump demands loyalty to himself from Republican members of
Congress. I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States. In any case,
they all swore an oath of office to be loyal to the Constitution.

Ryan Sleevi

unread,
Aug 10, 2017, 2:24:24 PM8/10/17
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
Can you provide an example of what you believe is a bigger issue that has
been masked? Otherwise, it sounds like you're saying "Ignore the obvious
errors, because maybe someone will find something non-obvious, and we don't
want to miss out" - but that's a deeply flawed argument, and I would hope
isn't the substance of what you're saying.

Note: I still disagree with you about the artificial ontology; all of these
errors equally speak to the CA's ability to execute on Best Practices, such
as using available tools that have been evangelized for over a year as
something that can (and arguably should) be integrated into issuance
pipelines. Discussions at this point are extremely relevant, as they speak
to how well the CA is staying abreast of changes, as well as how
effectively they're managing their subsidiaries - both issues that are key
to public trust.

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

> I strongly disagree. The discussion around errors like these masks the
> bigger issues in the noise. If there are bigger issues, let's find those.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digice...@lists.mozilla
> .org] On Behalf Of David E. Ross via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:35 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Certificates with metadata-only subject fields
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> >

Jeremy Rowley

unread,
Aug 10, 2017, 2:24:57 PM8/10/17
to mozilla-dev-s...@lists.mozilla.org
On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e. space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <ry...@sleevi.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues. While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it)
> onto the customer (who purchased the certificate), and thus a
> viewpoint that suggests this is somehow unjust (since it's the victim
> of misissuance who suffers), but I think an argument that suggests
> these shouldn't be revoked is similar to an argument that says those
> who purchased stolen merchandise should get to keep it, as long as they
didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future
action.
> Sadly, humans are terrible at recognizing those potential long-term
> costs (c.f. obesity/heart disease/dental care/global warming as all
> examples of long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also
> the right incentive - for CAs, and the overall ecosystem - to ensure
> that any misissuance is revoked in a timely fashion (which is
> currently 24 hours), because it helps encourage a market where the
> best step a CA can take to minimize risk to their subscribers, the
> ones actually paying them money and engaging in a business
> relationship with them, is to simply not misissue the certificates.

Jeremy Rowley

unread,
Aug 10, 2017, 2:29:38 PM8/10/17
to ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org
Not really – and I don’t object to the certificate problem reports. I greatly appreciate the work Alex and Jonathan are doing.



I disagree that finding small issues indicates larger issues as a whole. There’s no support for that claim. It’s just as likely that larger issues are going ignored because of noise as the smaller issues are indicators of something like domain validation going wrong. I doubt they speak equally to CA’s ability to execute on best practices as well. Seems like a failure to do validation would be way more severe than ensuring the OU field doesn’t have metadata.





From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields



Can you provide an example of what you believe is a bigger issue that has been masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, because maybe someone will find something non-obvious, and we don't want to miss out" - but that's a deeply flawed argument, and I would hope isn't the substance of what you're saying.



Note: I still disagree with you about the artificial ontology; all of these errors equally speak to the CA's ability to execute on Best Practices, such as using available tools that have been evangelized for over a year as something that can (and arguably should) be integrated into issuance pipelines. Discussions at this point are extremely relevant, as they speak to how well the CA is staying abreast of changes, as well as how effectively they're managing their subsidiaries - both issues that are key to public trust.



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

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise. If there are bigger issues, let's find those.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley <mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digice...@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
I strongly disagree. Errors like this make me question whether the
certification authority is sufficiently competent to be trusted. Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross
<http://www.rossde.com/>

President Trump demands loyalty to himself from Republican members of
Congress. I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States. In any case,
they all swore an oath of office to be loyal to the Constitution.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy


_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy



Jeremy Rowley

unread,
Aug 10, 2017, 2:52:20 PM8/10/17
to mozilla-dev-s...@lists.mozilla.org
Thinking about it more, this particular issue is the most annoying one because:

1. There’s not a limited defined set of items that encompass what the OU may include,
2. The OU is generally the dumping ground for information, and
3. There’s no requirement this information is verified other than ensuring it doesn’t have org/address info.



Building a rule set to shore up this particular issue is difficult as the parameters are not well defined like they are with domain and identity validation.



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields



Can you provide an example of what you believe is a bigger issue that has been masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, because maybe someone will find something non-obvious, and we don't want to miss out" - but that's a deeply flawed argument, and I would hope isn't the substance of what you're saying.



Note: I still disagree with you about the artificial ontology; all of these errors equally speak to the CA's ability to execute on Best Practices, such as using available tools that have been evangelized for over a year as something that can (and arguably should) be integrated into issuance pipelines. Discussions at this point are extremely relevant, as they speak to how well the CA is staying abreast of changes, as well as how effectively they're managing their subsidiaries - both issues that are key to public trust.



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

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise. If there are bigger issues, let's find those.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley <mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digice...@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>

Jeremy Rowley

unread,
Aug 10, 2017, 7:19:08 PM8/10/17
to mozilla-dev-s...@lists.mozilla.org
A couple of people also pointed out that we previously discussed these exact
certs here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/DgeLqKMzId
s/E9--gj5WEAAJ

The decision then was that we should prevent further issuance of certs with
N/A and other metadata but that revocation was not necessary in this case.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:24 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: RE: Certificates with metadata-only subject fields

On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e. space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <ry...@sleevi.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues. While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level
> > checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
Reply all
Reply to author
Forward
0 new messages