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

Section :
"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
.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


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

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

dev-security-policy mailing list

Reply via email to