RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:24 PM
To: mozilla-dev-security-pol...@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=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <r...@sleevi.com>
Cc: mozilla-dev-security-pol...@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-security-policy@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.
> ___
> dev-security-policy mailing list
> dev-se

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@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> =digicert.com@lists.mozilla

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

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@gmail.com 
>> <mailto:pzbo...@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
>
>

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-security-policy@lists.mozilla.org 
<mailto: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 
<mailto: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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@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> =digicert.com@lists.mozilla

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

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@gmail.com 
>> <mailto:pzbo...@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
>
>

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-security-policy@lists.mozilla.org 
<mailto: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 
<mailto: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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <r...@sleevi.com>
Cc: mozilla-dev-security-pol...@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-security-policy@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.
> ___
> 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


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

Re: Certificates with metadata-only subject fields

[Ryan Sleevi via dev-security-policy]

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-security-policy@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=
> digicert.com@lists.mozilla
> .org] On Behalf Of David E. Ross via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:35 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with metadata-only subject fields
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> >
> >> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@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
> >
> >
>
> 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-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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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=digicert.com@lists.mozilla
.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> 
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@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
> 
> 

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

Re: Certificates with metadata-only subject fields

[Alex Gaynor via dev-security-policy]

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-security-policy@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.
> ___
> 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

Re: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>> 
>>> On Aug 9, 2017, at 17:50, 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.
>> 
>> 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
>> 
>> 
> 
> 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

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

Re: Certificates with metadata-only subject fields

[David E. Ross via dev-security-policy]

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> 
>> On Aug 9, 2017, at 17:50, 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.
> 
> 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
> 
> 

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


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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 17:50, 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.

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


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

Re: Certificates with metadata-only subject fields

[Peter Bowen via dev-security-policy]

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

On Wed, Aug 9, 2017 at 2:21 PM, Jeremy Rowley via dev-security-policy
 wrote:
> 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.
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
>  On Behalf Of Jonathan Rudenberg via dev-security-policy
> Sent: Wednesday, August 9, 2017 10:08 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Certificates with metadata-only subject fields
>
> 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) 
> ___
> 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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

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.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Wednesday, August 9, 2017 10:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with metadata-only subject fields

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