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